Re: [gentoo-desktop-research] New Portage GUI Proposal

munky@××××××.com said:

> /*Idea for new project known as PortageUI to be a front end to Portage*/
>
> Portage or commonly known as 'emerge' is the powerful package system of
> Gentoo. Gentoo's success is directly related to the quality of Portage.
> Portage has the ability to find sources, compile, and install the
> binaries. It can also update all programs and keep your system up to date.
> Portage consists of one command 'emerge' with _many_ arguments to> put it
> in. For the n00b, remembering and executing all of the correct arguments
> can be a bit difficult. A GUI program called Kportage had been created a
> while back. It was written in QT and had many bugs. The idea of Kportage
> is great but the actual implementation was not. New ideas have been formed
> in an attempt to provide users with the ease and power> of controlling
> portage through a GUI.

It's a great idea, and needed project. I think you should also contect the
portage manager, to explain how you'll interact with portage, and if he has
tricks to do things better. I also think that you hsould take a look at some
portage API projects that have emerged (!), namely gentoolkit frontends.

>
> PortageUI is an idea at this point and will remain such for some time.Some
> basic decisions have been decided as for the languages of> PortageUI. The
> head devs (Munky, Frog) are big fans of C, not its offspring C++. Kportage
> had been written in C++ and we feel that it is not the best language for
> the job. We initially planed on using ansi C for this project, but Python
> has also been suggested. Both the devs of this project are quite weak in
> Python, which may influence our decision. We also plan to use GTK2.
> Suggestions concerning language and toolkit choice are most welcome.

my opinion: C, C++, java programs are long to develop, and difficult to
maintain. Scripting language are easy to maintain, easier to be retaken by
other devs, and faster to develop. So I prefer perl, python, ruby, over C C++
java. Now, python is easier to learn than perl, despite the fact that it seems
less powerfulle, and that it's slower. But we don't care for a frontend
application. Ruby is nice, but even slower than python, and have less libraries
available. So the good choici would be imho python. Now for the gui, you can
use gtk2, it's a good choice for me, but qt is also perfect for the job.

>
> Kportage really only provided a GUI for portage not adding on any new
> ideas. There are many things that users do with portage, or can do with
> portage that they do. For instance, the easiest way to keep your system up
> to date is "emerge -u world". This will update all applications that have
> been installed using portage, including your kernel libraries. This is
> very important for those users whom don't update single applications.
> Thus, it seems optimal to integrate PortageUI with cron and have various
> tasks set. Such as a weekly "emerge sync" and a monthly "emerge -u world".
> This would help to keep your system up to date and secure.

That's a good idea.

>
> In reference to the application of the GUI itself, considering the>
> _great_ size of the portage tree, it seems fit to use a database to keep>
> track of the data. The best database to use would probably be that of
> Postgresql. The database can hold a list of each ebuild and various data
> for it. This data will include: installed version, current version,
> dependencies, as well as its README, and other docs. In addition, the db
> will hold specific categorizes that the ebuild fits in. The ebuilds are
> already sorted in a directory structure, but in reality that is not as
> user friendly or easy to understand as simple categories. The user will
> have the ability to modify the categories to their own interpretation.

I'm strongly against asking the user to install (and configure) a postgresql db
on his system. You should look at sqlite, a sql relational database which is
light fast, and fits in one single file, so no installation, no configuration
required. The drawbacks are that it'ssingle user, and less optimized for very
large database. But this application will be single user, and the database
won't be big, so sqlite is the perfect candidate imo.

-- 
dams

--
gentoo-desktop-research@g.o mailing list