[Aptitude-devel] aptitude-qt code design

[Daniel Burrows]

  Hi, Piotr.  I know you're still working on the UI mocks for
aptitude-qt (sadly I haven't had a chance to look at them yet, I'll
try to do that tomorrow), but I figured we should talk about your
implementation plan before it actually started.

  I particularly wanted to ask about your comments in your blog post
about wrapping non-Qt classes so that they appear to be Qt objects.
Could you describe in more detail what you're planning to do there?

  Also, are you available on any IM networks?  You should be able to
contact me as "gnulives" on AIM or as "dburrows at google.com" on Jabber
or Google Talk (but the latter is only reliable during my work day).



  I wanted to give you a heads-up that one of my ongoing projects is
to extract the generic parts of the GTK+ GUI into separate classes.
The basic idea is for the GUI to implement an interface which doesn't
mention any GUI types; the program logic uses this to drive things.

  I wanted to let you know because on the one hand, some of this code
might be useful to you, and on the other hand, it would be great if
you could write your own code in this style for reuse by the GTK+
frontend.  (this could also be used to write tests of the GUI's logic;
sadly, I don't have code right now to bring up an isolated test
instance of the apt database, and a lot of the GUI code will be hard
to test without one)


  I have one toy example implemented, wrapping up the interface
elements that comprise the search input box:

http://git.debian.org/?p=aptitude/aptitude.git;a=blob;f=src/gtk/views/search_input.h;h=9e0b0a5d88112c85811bab6613770baea8533937;hb=HEAD

  The only type related to GTK+ that appears in that interface is a
Glib::ustring, which could easily be changed to std::wstring or
std::string if those types were better for another module (e.g.,
yours).  The view interface is used by a "controller" class that tells
the view what to display and responds to signals that it emits:

http://git.debian.org/?p=aptitude/aptitude.git;a=blob;f=src/gtk/controllers/search_input.cc;h=dfd583bf66ace4efdcdcad802340bf8fc961f38d;hb=HEAD

  The split let me write a (toy) unit test for the "backend" half of
the GUI logic, although as I noted above, most of the aptitude code is
difficult to test due to dependencies on apt:

http://git.debian.org/?p=aptitude/aptitude.git;a=blob;f=tests/test_search_input_controller.cc;h=91e84e4edac267660c1d91708f4e40b4d253bce2;hb=HEAD



  Again, this is a toy example, but I have some sketched-out designs
for pushing this division further when I get some time.

  This is a little bit of an experiment and I'm not 100% sure whether
there will be a payoff for it, as a lot of the GUI code is really just
about manipulating GUI elements.  For instance, the dpkg terminal tab
is pretty much entirely GUI code, and I also doubt it makes sense to
try to write a generic backend for the package information screen.

  On the other hand, with two GUIs in the tree that will likely be
similar in many respects, I think we should be on the lookout for
opportunities to share code between them.

  Daniel