| 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 |
Archives