1 |
On Thu, 2003-11-20 at 03:16, munky@××××××.com wrote: |
2 |
> /*Idea for new project known as PortageUI to be a front end to Portage*/ |
3 |
> |
4 |
> Portage or commonly known as 'emerge' is the powerful package system of |
5 |
> Gentoo. Gentoo's success is directly related to the quality of Portage. |
6 |
> Portage has the ability to find sources, compile, and install the |
7 |
> binaries. It can also update all programs and keep your system up to date. |
8 |
|
9 |
You are not kidding me right, does such a distro exist ? ;) |
10 |
|
11 |
> PortageUI is an idea at this point and will remain such for some time.Some |
12 |
> basic decisions have been decided as for the languages of> PortageUI. The |
13 |
> head devs (Munky, Frog) are big fans of C, not its offspring C++. |
14 |
|
15 |
Head devs for this project i assume or did i miss something ? And are |
16 |
there any reasons beyond a general disliking of C++ for choosing C, |
17 |
disregarding the fact that there are dozens of other capable languages |
18 |
out there. |
19 |
|
20 |
> Kportage |
21 |
> had been written in C++ and we feel that it is not the best language for |
22 |
> the job. We initially planed on using ansi C for this project, but Python |
23 |
> has also been suggested. Both the devs of this project are quite weak in |
24 |
> Python, which may influence our decision. We also plan to use GTK2. |
25 |
> Suggestions concerning language and toolkit choice are most welcome. |
26 |
|
27 |
I can't be against GTK+ 2 of course, but more important to me than the |
28 |
toolkit is the UI design. I would suggest it should follow the GNOME HIG |
29 |
for consistency for a start. |
30 |
|
31 |
> Kportage really only provided a GUI for portage not adding on any new |
32 |
> ideas. There are many things that users do with portage, or can do with |
33 |
> portage that they do. For instance, the easiest way to keep your system up |
34 |
> to date is "emerge -u world". This will update all applications that have |
35 |
> been installed using portage, including your kernel libraries. This is |
36 |
> very important for those users whom don't update single applications. |
37 |
> Thus, it seems optimal to integrate PortageUI with cron and have various |
38 |
> tasks set. Such as a weekly "emerge sync" and a monthly "emerge -u world". |
39 |
> This would help to keep your system up to date and secure. |
40 |
|
41 |
I wouldn't suggest cronning things like sys wide updates as dev, nor |
42 |
should we be promoting it by putting it in an 'official' (?) UI. Anyway |
43 |
i see no reason to have that integrated in a UI, people who want to cron |
44 |
updates (which i consider a bad practice), should be able to do that |
45 |
themselves (see it as a skill qualifier). |
46 |
|
47 |
> In reference to the application of the GUI itself, considering the> |
48 |
> _great_ size of the portage tree, it seems fit to use a database to keep> |
49 |
> track of the data. The best database to use would probably be that of |
50 |
> Postgresql. The database can hold a list of each ebuild and various data |
51 |
> for it. This data will include: installed version, current version, |
52 |
> dependencies, as well as its README, and other docs. In addition, the db |
53 |
> will hold specific categorizes that the ebuild fits in. The ebuilds are |
54 |
> already sorted in a directory structure, but in reality that is not as |
55 |
> user friendly or easy to understand as simple categories. The user will |
56 |
> have the ability to modify the categories to their own interpretation. |
57 |
|
58 |
Do you really know what you are getting into ? I wrote a gtk gui before |
59 |
i became a dev, it worked okayish, but i had to do all portage |
60 |
type-o-logic myself and that was at a time where portage and its related |
61 |
files (caches/db/etc.) were much simpler. Actually, rewriting that tool |
62 |
has been stuck on the fact that portage has virtually no usable API. |
63 |
That is what lacks and that is what needs fixing before any useful UI |
64 |
tools can be made (in my opinion). |
65 |
|
66 |
Using a db is all nice, but it would be duplication of information (and |
67 |
staying in sync might become very troublesome). Again, portage lacks |
68 |
here : i should have a unified db and an API to access it from outside. |
69 |
|
70 |
> At this point in time, both devs are going to be working on basic |
71 |
> prototypes as to how we will accomplish our goal. We are brushing up on |
72 |
> our knowledge of GTK2 and going over Python. We won't begin coding until |
73 |
> all the planning is done before-hand. If everything goes accordingly, it |
74 |
> seems realistic to say coding will begin around a month or so after the |
75 |
> project is approved. |
76 |
|
77 |
> Please let us know what you think of this proposal. It is just a series of |
78 |
> ideas, and much of it can be changed; nothing is set in stone. |
79 |
|
80 |
As much as i like the idea of a proper GUI for portage, I'm uncertain if |
81 |
you know what you are getting into. |
82 |
|
83 |
I suggest at least a total backend - frontend separation, because i |
84 |
think the backend is gonna be messy. |
85 |
|
86 |
- foser |
87 |
|
88 |
|
89 |
-- |
90 |
gentoo-desktop-research@g.o mailing list |