Filipus Klutiero a écrit : > Christian Perrier wrote: >> Is this silly to think that, as most of the (good) work was made in >> aptitude-gtk, an aptitude-qt development would be a better idea?
> At first sight, it does sound silly to me. aptitude-gtk is a GTK+ GUI > for Aptitude. Similarly, aptitude-qt would be a Qt UI for Aptitude. But > Aptitude is an APT front-end. Which means aptitude-qt would be a > front-end to a front-end. We only want a Qt/KDE APT front-end. To be exact, "aptitude-gtk" is as much a "front-end" of "aptitude" as the ncurse version of aptitude is, or the console version for that matter, is a "front-end" of "aptitude". Aptitude is much more than a bare APT front-end. It embarks its own elaborate resolver and quite a few other things. Also, aptitude-gtk is not just making calls to the aptitude binary or libraries or whatever, it's an integral part of the code. > aptitude-foo was tried in last summer's GSoC, resulting in aptitude-gtk. > It's only experimental, but it not only depends on aptitude, it's also > part of the aptitude source package. I'm not convinced that an > aptitude-qt would do much better. Aptitude-gtk is aptitude and aptitude is aptitude-gtk... The "aptitude" package in experimental is actually "aptitude-gtk" with the -gtk parts turned off at build-time. As to the fact that some don't like the aptitude UI paradigm, well, that's one of the reasons I'm pushing for an alternative package manager with Adept, for those who prefer a more task-based UI. I hope I clarified a few points. Arthur -- Obey Arthur Liu <http://www.milliways.fr>
signature.asc
Description: OpenPGP digital signature
