1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
>> Despite the current open issues (btw: I tried to collect them on a |
5 |
>> wiki page: http://catapult.origo.ethz.ch/wiki/current_issues ), do |
6 |
>> you think that the whole system can be brought to something useful in |
7 |
>> the end? |
8 |
> |
9 |
> I think you have one big issue: you don't have a clear purpose for the |
10 |
> API. |
11 |
> |
12 |
> On the one hand, you're saying that it should be a nice simple API for |
13 |
> clients. |
14 |
> |
15 |
> On the other hand, you're saying that you want to use it for writing a |
16 |
> nice fancy GUI. |
17 |
|
18 |
We just have a lack of a common base here. I can't see why these two |
19 |
points are disjoint. The current API is already used for a GUI - and works. |
20 |
The problem I see, is that you (and paludis) always want to be a little |
21 |
bit more fancy and more complex. |
22 |
|
23 |
> Of the Paludis clients we've experimented with, the one that makes by |
24 |
> far the most complex use of the API is the GUI client. This isn't |
25 |
> merely because we can -- the only time a GUI becomes useful is when it |
26 |
> offers functionality that can't easily be provided quickly by a non-GUI |
27 |
> client. |
28 |
|
29 |
Nope - a GUI should provide things which are cumbersome using the |
30 |
commandline. If a GUI offers things, that can't be done using CLI / |
31 |
scripts - the CLI is bad. |
32 |
|
33 |
> A GUI should be able to do things like display a resolution of |
34 |
> 'update world with deps', and have little clicky things on each item |
35 |
> saying things like "exclude this from the update" (greyed out if the |
36 |
> item can't be excluded), "show me a tree of why this package is |
37 |
> included in the list" and "select a different item from the || ( ) |
38 |
> branch that pulled this dep in". You can't do this without an extremely |
39 |
> rich API (and you probably can't do it without lambdas hooked into the |
40 |
> resolver...). You definitely can't do this by having a crude "give me a |
41 |
> command I can exec()" way of installing things. |
42 |
|
43 |
Your description is fancy ... _but_ the things you are describing is an |
44 |
integrated GUI. It's on the same level the CLI is on. |
45 |
This is nothing which is achievable with catapult (at least at the |
46 |
moment). Catapult _uses_ the package manager and is not part of it. Thus |
47 |
also the GUI would _use_ the PM. |
48 |
|
49 |
And as mentioned in my earlier mail, avoiding the exec() stuff and use |
50 |
the manager itself is bad in my eyes for different reasons. And for |
51 |
portage it won't work at all. |
52 |
|
53 |
Thus - I still vote for providing the exec interface. It can be dropped |
54 |
if a nicer solution is found later on. |
55 |
|
56 |
To sum up: I vote for the simple API - to get things done. It can be |
57 |
enhanced later on. |
58 |
|
59 |
And just because I feel like it - the get_x_option and their return |
60 |
values as I see it for paludis: |
61 |
|
62 |
deep : [] |
63 |
newuse: ["--dl-reinstall", "if-use-changed"] |
64 |
pretend: ["--pretend"] |
65 |
oneshot: ["--preserve-world"] |
66 |
|
67 |
- - Necoro |
68 |
-----BEGIN PGP SIGNATURE----- |
69 |
Version: GnuPG v2.0.7 (GNU/Linux) |
70 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
71 |
|
72 |
iD8DBQFH83Ta4UOg/zhYFuARAkofAJ4u7VQrzBzSyQLUEL8a7jfLSUxiCgCfT7f/ |
73 |
PBX30hWht2dQvL4RHOgd0YI= |
74 |
=b4xY |
75 |
-----END PGP SIGNATURE----- |
76 |
-- |
77 |
gentoo-guis@l.g.o mailing list |