Jun 21
State of the Aptitude
I promised to post some updates about how the Aptitude project would be going so here it is.
Here’s what aptitude-gtk currently looks like :
Well, nothing very special right now. It’s really only a testing interface. The final GUI will probably be different. Now you may be interested by what’s going on behind it ?
Where to start ?
Aptitude is written in C++ with varying dosages of OO coding depending on the age of the code 
.
For the most part, the code is neat, clean and easy to understand. Sometimes, it’s overengineered: the code that implements the progress status of packages downloads and actions is exhaustive enough to cover the setup phases of a hydraulic dam, although sometimes you can still see progress bars mysteriously going backwards. Sometimes, Daniel Burrows will be happy to provide you with complimentary barf bags while explaining some ungodly oddities that have existed for years because it’s easier to remember the ritual dances to do than to make stuff behave logically.
Currently Aptitude-gtk is able to execute the libapt-pkg initialization phase, load up repository lists and update lists (think “aptitude update”). The next big task will be to load up the installed packages list and display it. It involves quite a lot of code because of all the things that connect to it : incremental package searches, sorts, filters and so on.
It’s been very interesting so far.
By the way, the minesweeper feature is already implemented, courtesy of gnomine
June 21st, 2008 at 10:04 pm
Interesting, but I’d have thought that the most interesting way of doing aptitude-gtk would be to write a gtk backend for libcwidget.
June 21st, 2008 at 10:07 pm
To Karellen:
Aptitude-gtk intends to be much more than only a skin over the ncurse interface
Considering that Aptitude is the main (if only ?) application using cwidget, there’s not real advantage of writing a gtk backend for cwidget. That would be a very heavy task also..
June 22nd, 2008 at 10:15 pm
Hi Arthur,
why do you use gtk+ and not qt4?
Have you choose the framework?
June 22nd, 2008 at 10:17 pm
To Romain:
- Gnome is the default on Debian
- Qt already has the Adept project anyway
- I use Gnome (arbitrary I know)
June 22nd, 2008 at 10:55 pm
> Gnome is the default on Debian:
I regret that (snif)
Gtk+ already has the synaptic project anyway
(and adept don’t use aptitude)
Where is the url of your svn repository? I just find the browser url (http://dev.graffit.net/aptitude/trac/browser).
June 22nd, 2008 at 10:58 pm
To Romain:
http://dev.graffit.net/aptitude/hg
(It’s Mercurial by the way)
June 23rd, 2008 at 10:53 am
I didn’t know Mercurial.
I’d get the sources. Thank you.
Now, how compile aptitude-gtk?
Have you a mailing list for the project (or Trac’s tickets are sufficient?)?
June 23rd, 2008 at 9:55 pm
To Romain:
I added some information on the wiki (http://dev.graffit.net/aptitude/trac).
June 24th, 2008 at 5:04 am
Karellen:
Although I can see where you’re coming from, a GTK+ backend to cwidget would have no significant upsides and significant downsides.
The main upside to doing that from a practical point of view is that you would have only one piece of “driver” code for the GTK+ and curses interfaces. You wouldn’t have to rewrite the entire interface from scratch to create a GUI frontend.
But this is just an illusory benefit. cwidget is a terminal interface library and aptitude’s curses frontend is a terminal-based UI. From a practical point of view, this means that aptitude regularly assumes that, for instance, to clear out a line it’s sufficient to output $WIDTH space characters (ASCII 32) with the desired background style. A port of cwidget to GTK+ would have to introduce new, interface-independent abstractions for all operations like this and eliminate all direct use of terminal-based assumptions, at a significant cost in complexity for both cwidget and the aptitude frontend. In order to transition to these new conventions, I believe you would have to rewrite large portions of both cwidget *and* aptitude in order to make the interface abstraction layer work. (remember: the justification for doing this is to avoid having to rewrite aptitude!)
Furthermore, while this approach avoids reimplementing aptitude’s curses interface (sort of, except where it doesn’t — see above), it does so at the cost of requiring you to reimplement all of cwidget, for GTK+. I just did a quick line count (with “wc -l”): in all of cwidget there are 23,390 lines of code, while aptitude’s curses frontend has around 23,359 lines of code (some of which are actually shared with the other frontends but are in the curses directory due to the historical organization of the code tree). Not only is a rewrite of cwidget more involved, but the amount of code you’d have to replace is comparable to the amount implicated in a rewrite of aptitude itself!
Finally, even if these costs weren’t enough to eliminate the idea, it’s not at all clear to me that a GTK+ backend for cwidget is even desirable. Although aptitude has some superficial similarities to a GUI program, the process of designing an interface to run in a terminal (where the available input mechanisms are relatively restricted and all output is to a character-cell grid) is rather different from the process of designing a GUI. GUI programs can’t rely on some simplifying assumptions that terminal programs can, and at the same time they have a lot more options available to them (just to name a few: graphics, multiple windows, differing text sizes and rotated text). Trying to force everything through an abstraction designed for terminal output would require you to either (a) eschew those options, (b) provide abstract GUI components that somehow “fell back” to terminal rendering in a terminal, or (c) add ways for the frontend to extend the abstract widgets with custom functionality. (a) is not an option because I (and, I think, Arthur) want to design a good GTK+ package manager, not a good GTK+ imitation of a console package manager. (b) and (c) amount, in my strong opinion, to writing two separate interfaces but intertwining their implementations in a mass of maintenance-resistant and extension-resistant spaghetti code.
At the end of the day, I think that having two separate frontends (sharing backend logic where appropriate, of course) is a far cleaner and more maintainable design, and also easier to create.
PS: Arthur, is there any way to get a “preview” button on these blog comments? Trying to review this post has been a pain.
June 25th, 2008 at 5:35 pm
Arhtur: compilation has failed:
romain@debian:~/Desktop/tests/aptitude-gtk$ ./autogen.sh
aclocal-1.9: autom4te terminated by signal: 9
romain@debian:~/Desktop/tests/aptitude-gtk$ ./configure && make
bash: ./configure: Aucun fichier ou répertoire de ce type
romain@debian:~/Desktop/tests/aptitude-gtk$ ls -lh autom4te.cache/requests
-rw——- 1 romain romain 17G jun 25 16:54 autom4te.cache/requests
17Go ???
It would be a mistake, but autom4te.cache/requests seems be a big file.
Do you use hg-buildpackage to compile aptitude-gtk?
————————-
i apt – Advanced front-end for dpkg
i autoconf – automatic configure script builder
i automake1.9 – A tool for generating GNU Standards-compliant Makefiles
i A docbook-xml – standard XML documentation system, for software and syst
i docbook-xsl – stylesheets for processing DocBook XML files to various
i A g++ – The GNU C++ compiler
i A gettext – GNU Internationalization utilities
i html2text – An advanced HTML to text converter
i libcppunit-dev – Unit Testing Library for C++
i libcwidget-dev – high-level terminal interface library for C++ (developme
i libglademm-2.4-dev – C++ wrappers for libglade2 (development files)
i A libglibmm-2.4-dev – C++ wrapper for the GLib toolkit (development files)
i libgtkmm-2.4-dev – C++ wrappers for GTK+ 2.4 (development files)
i A libsigc++-2.0-dev – type-safe Signal Framework for C++ – development files
i A make – The GNU version of the “make” utility.
i po4a – tools for helping translation of documentation
i A xsltproc – XSLT command line processor
June 25th, 2008 at 5:36 pm
Arthur and not Arhtur: i’m sorry
June 25th, 2008 at 6:50 pm
@Romain :
I opened a Trac ticket for you : http://dev.graffit.net/aptitude/trac/ticket/1
June 27th, 2008 at 11:26 am
Arthur:
I wrote a new answer yesterday:
http://dev.graffit.net/aptitude/trac/ticket/1