Re: [gentoo-soc] Graphical portage front-end

[Brian Dolbec]

On Sat, 2010-03-20 at 12:44 +0100, Auke Booij wrote:
> First things first, I would not know why someone should be using a
> graphical installer instead of xterm or one of its colleagues.
>
> Anyway, the problems you are pointing out are exactly what you're
> sacrificing by using a GUI, and exactly the reason Gentoo doesn't have
> a graphical installer (or one that you should be using, anyway).

Different people think and use their system differently.  I do NOT
consider using/developing a graphical frontend for portage to be a
"sacrifice" to in usability.  There are things that a GUI is far better
at than a terminal, and vice/versa.  A well designed gui is great for
bringing large amounts of data together quickly and in a form that makes
it easy for a user to locate the relevant info required to make their
decision about a package to  upgrade/install, etc..

>  A lot
> of Portage's configuration consists of bash scripts, and any attempt
> to fully reproduce their capabilities in a GUI would lead to a big
> mess (point-and-click programming, *sigh*). If someone desperately
> wants a GUI, it would be for daily Portage activities, and definitely
> not for obscure feature x or y.

I think you misunderstood the purpose of the GUI here.  Kuroo was for
daily use, not just configuration changes.
>
> Further, resolving dependencies is, in my opinion, outside the scope
> of a GUI. Functionality that isn't present in the command-line version
> of some program shouldn't be added just for the GUI version.
>

The problem with dependency resolution has always been the lack of an
API in portage to get complete dependency graph, especially when
masked/keyworded packages were involved and the packages needed to
install.  Plus as I see it the needs of the GUI differ slightly from the
actual installing package manager.  In porthole we build and show a
complete dependency graph showing all dependencies for all use flag
conditionals, whether or not the installed conditions are met for the
dep, etc..

> That said, I'm sure some people would love a GUI integration of
> different package management tools (ie. search, install, sync...) into
> one big package, and it would definitely be a nice improvement to
> Sabayon.
>
> tulcod.

There are 3 already for Gentoo.  This isn't Sabayon.

>
> On Sat, Mar 20, 2010 at 12:25 PM, xqyz <xqyzii@×××××.com> wrote:
> > On 20 March 2010 11:16, Petteri Räty <betelgeuse@g.o> wrote:
> >>
> >> Last year we had a project for PackageKit integration that was never
> >> integrated into the main tree. I would rather continue that work and
> >> then any PackageKit GUI could be used with Portage.
> >
> > I agree, it would indeed be nice to have a portage integration in
> > PackageKit, but given the rather unique way of handling packages in Gentoo,
> > I would consider PackageKit to be a rather poor choice for a package
> > manager.
> > USE flags, inability to resolve circular dependencies properly and of course
> > the advanced compile configuration that Gentoo offers are hard, if not
> > impossible to be handled by PackageKit. Which is why I think that, even if
> > there was a working integration of portage, it would not be used much. The
> > problem with Gentoo is that it more often than not requires the users to
> > make a choice instead of just settling for a package and clicking install.
> >
> > --Patrick Lerner
> >

I have installed gnome packagekit and the portage backend and tried it.
But (I am biased) I found the interface sucked big time.  I personally
thought that the packagekit work was nearly a waste of time.  From what
I can see, it was just a "Me Too" project to put the gentoo name in
front of a few more binary distro users, unlikely that it will ever be
used.  Possibly only by a few people migrating to gentoo who previously
used it until they discovered the native gentoo guis any of which are
better imho.  The only good thing from it is the backend code which
brings a proper API to portage one step closer to being a reality.  That
API has been on the TODO list and promised for many years.  The lack of
it has been one of the reasons the current guis have not had a better
connection to portage.  As for it not being pushed in the main tree, Zac
informed me that there were some problems with it that needs a proper
API in portage for it to be stable and reliable.  He also intends to
implement it ( as have others in previous years), but he is only one
person, already busy with the core development of portage.

If there is to be a project to with portage it should be the
implementation of a proper public API for apps to use such as porthole,
portato, himerge, etc..


> Hello,
> I would be interested in coding a new and improved graphical front-end
> for portage, similar to the old Kuroo Project. The reason why I want
> to start from scratch is that I'm not particular inclined to use QT as
> a toolkit, nor would I consider CPP my language of choice.
> Personally, I would prefer to go with a combination of Python and
> wxWidgets on this project. For one thing, performance should allow to
> switch to Python without too much speed-loss, and I also think using
> Python instead of CPP could attract more non-professional, casual
> coders to contribute to the project.
>

Why do yet another gtk based portage frontend, there are 3 already.  The
idea was for a NATIVE QT implementation which is something htat KDE
users would like.  Besides that I find wxgtk lacking in many ways
compared to normal gtk interfaces.  If you want to work on a gtk
interface, I could always use more help with porthole, Necoro is
extremely busy with schooling and could use help with portato.  I
haven't talked with araujo enough to know if he needs help with himerge.

-- 
Brian Dolbec <brian.dolbec@×××××.com>