1 |
On Wed, 02 Apr 2008 13:58:18 +0200 |
2 |
René 'Necoro' Neumann <lists@××××××.eu> wrote: |
3 |
> We just have a lack of a common base here. I can't see why these two |
4 |
> points are disjoint. The current API is already used for a GUI - and |
5 |
> works. The problem I see, is that you (and paludis) always want to be |
6 |
> a little bit more fancy and more complex. |
7 |
|
8 |
We want to provide the functionality users need to get the job done. |
9 |
|
10 |
> > Of the Paludis clients we've experimented with, the one that makes |
11 |
> > by far the most complex use of the API is the GUI client. This isn't |
12 |
> > merely because we can -- the only time a GUI becomes useful is when |
13 |
> > it offers functionality that can't easily be provided quickly by a |
14 |
> > non-GUI client. |
15 |
> |
16 |
> Nope - a GUI should provide things which are cumbersome using the |
17 |
> commandline. If a GUI offers things, that can't be done using CLI / |
18 |
> scripts - the CLI is bad. |
19 |
|
20 |
Realistically, there are some potentially useful things that just don't |
21 |
map well onto a command line environment. Dynamic selection of || ( ) |
22 |
choices is a good example of this -- there's no sane way of offering it |
23 |
in a CLI, but in a GUI (or even in ncurses if you push it) it isn't too |
24 |
cumbersome. |
25 |
|
26 |
> Your description is fancy ... _but_ the things you are describing is |
27 |
> an integrated GUI. It's on the same level the CLI is on. |
28 |
> This is nothing which is achievable with catapult (at least at the |
29 |
> moment). Catapult _uses_ the package manager and is not part of it. |
30 |
> Thus also the GUI would _use_ the PM. |
31 |
|
32 |
And thus the GUI will end up delivering a half-arsed minimally |
33 |
functional toy. That isn't what users need. |
34 |
|
35 |
> And as mentioned in my earlier mail, avoiding the exec() stuff and use |
36 |
> the manager itself is bad in my eyes for different reasons. And for |
37 |
> portage it won't work at all. |
38 |
|
39 |
You could implement it for Portage by using exec() yourself... |
40 |
|
41 |
> Thus - I still vote for providing the exec interface. It can be |
42 |
> dropped if a nicer solution is found later on. |
43 |
> |
44 |
> To sum up: I vote for the simple API - to get things done. It can be |
45 |
> enhanced later on. |
46 |
|
47 |
To get what done? If the API can't be used to write a decent app, |
48 |
people are going to stick with the package manager APIs. |
49 |
|
50 |
-- |
51 |
Ciaran McCreesh |