List Archive: gentoo-guis
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
-----BEGIN PGP SIGNED MESSAGE-----
>> Despite the current open issues (btw: I tried to collect them on a
>> wiki page: http://catapult.origo.ethz.ch/wiki/current_issues ), do
>> you think that the whole system can be brought to something useful in
>> the end?
> I think you have one big issue: you don't have a clear purpose for the
> On the one hand, you're saying that it should be a nice simple API for
> On the other hand, you're saying that you want to use it for writing a
> nice fancy GUI.
We just have a lack of a common base here. I can't see why these two
points are disjoint. The current API is already used for a GUI - and works.
The problem I see, is that you (and paludis) always want to be a little
bit more fancy and more complex.
> Of the Paludis clients we've experimented with, the one that makes by
> far the most complex use of the API is the GUI client. This isn't
> merely because we can -- the only time a GUI becomes useful is when it
> offers functionality that can't easily be provided quickly by a non-GUI
Nope - a GUI should provide things which are cumbersome using the
commandline. If a GUI offers things, that can't be done using CLI /
scripts - the CLI is bad.
> A GUI should be able to do things like display a resolution of
> 'update world with deps', and have little clicky things on each item
> saying things like "exclude this from the update" (greyed out if the
> item can't be excluded), "show me a tree of why this package is
> included in the list" and "select a different item from the || ( )
> branch that pulled this dep in". You can't do this without an extremely
> rich API (and you probably can't do it without lambdas hooked into the
> resolver...). You definitely can't do this by having a crude "give me a
> command I can exec()" way of installing things.
Your description is fancy ... _but_ the things you are describing is an
integrated GUI. It's on the same level the CLI is on.
This is nothing which is achievable with catapult (at least at the
moment). Catapult _uses_ the package manager and is not part of it. Thus
also the GUI would _use_ the PM.
And as mentioned in my earlier mail, avoiding the exec() stuff and use
the manager itself is bad in my eyes for different reasons. And for
portage it won't work at all.
Thus - I still vote for providing the exec interface. It can be dropped
if a nicer solution is found later on.
To sum up: I vote for the simple API - to get things done. It can be
enhanced later on.
And just because I feel like it - the get_x_option and their return
values as I see it for paludis:
deep : 
newuse: ["--dl-reinstall", "if-use-changed"]
- - Necoro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
email@example.com mailing list