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
On Wed, 02 Apr 2008 13:58:18 +0200
René 'Necoro' Neumann <lists@...> wrote:
> 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.
We want to provide the functionality users need to get the job done.
> > 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 client.
> 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.
Realistically, there are some potentially useful things that just don't
map well onto a command line environment. Dynamic selection of || ( )
choices is a good example of this -- there's no sane way of offering it
in a CLI, but in a GUI (or even in ncurses if you push it) it isn't too
> 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 thus the GUI will end up delivering a half-arsed minimally
functional toy. That isn't what users need.
> 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.
You could implement it for Portage by using exec() yourself...
> 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.
To get what done? If the API can't be used to write a decent app,
people are going to stick with the package manager APIs.