[Aptitude-devel] aptitude-qt code design

[Daniel Burrows]

On Sat, Jun 5, 2010 at 4:45 PM, Piotr Galiszewski <piotr at galiszewski.pl> wrote:
> 2010/6/2 Daniel Burrows <dburrows at google.com>:
>>  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?
>>
>
> Yes of course. I am planning to separate GUI code from the one which
> will be interacting with aptitude/apt classes. This way linking
> between Qt signals and slots and sigc++ one will be only necessary in
> this "low level classes". The gui code will be more readable by
> average Qt developer, because it will not require the knowledge of
> aptitude internals. I hope more developers will be ready to help with
> maintaining this code. This will also be consistent with Simple
> Responsibility Principle
>
> In my plan GUI classes ask low level classes for particular
> informations/services (e.g information about package or downloading
> changelog). Low level classes use aptitude/apt classes to get required
> informations and send them back to GUI by Qt Signal and Slots
> mechanism. To use signals and slots class have to extend QObject
> class, so this is "wrapping".

  So, to bring this to a more specific level, here are the translations you
definitely need to do:

  1. Passing a Qt slot as a sigc++ slot.
  2. Receiving sigc++ slots and invoking them in the main UI thread.

  For 1, I don't think that a translation is necessary, actually, except
maybe derving the Qt object from sigc::trackable.  Qt slots are just
normal function calls (IIRC), so you can use sigc::mem_fun as usual
to set up the callback slot.

  For 2, I have no idea how to do it in Qt :).  I doubt it requires a new
internal API, though, since it just requires writing a single function
somewhere (to receive and interpret the slots).

> Example of displaying package list:
> 1) The view is created
> 2) The widget is asking model what should be displayed on the list
> 3) The model ask the service for the informations
> 4) Informations are displayed on the list

  I don't understand what happens in step 3.

  This is one area where there might be some ability to improve
separation of data and presentation.  At least in GTK+, the "model"
is still a fairly direct representation of what shows up on the screen.
I have some notes on a scheme for moving all the logic controlling
what goes into the table into non-GUI code, leaving just the core
"rendering" bits behind.  I'll try to get a prototype put together soon
so that you can see it.

> I agree with you. I will try to reuse as much code as it is possible.
> It looks for me that some classes could be reused/shared nearly
> without any changes. Perfect example is changelogs fetching. I will
> try to describe such classes till the end of the next week and ask you
> what will be the best way to proceed with them. I will also reuse as
> much translations/icons as it will be possible from the current code.

  BTW, if you come across a place where you need some code to be
refactored, I'm happy to put that in my queue.  e.g., when the GTK+
frontend was being initially developed, the code to parse a description
would paint a curses widget as it went.  I rewrote it to produce an
intermediate representation of the description that both curses and
GTK+ could consume.  There should be less of that now, but you might
still run into some cases.

> I have also two more questions:
> 1) Should I use official aptitude repository (in new branch) or set up
> my own repository somewhere?

  For now, I think I'd prefer to have you work in a separate repository.
I can merge your work into the main branch.

> 2) Which build system is the future build system of aptitude? There
> are two now and Sune is working on cmake version :)

  From what Sune said, it sounds like cmake will work better for Qt
and KDE?  For right now, I suggest using one of the ones that's checked
in.  The automake build system is probably a bit more stable -- I know of
a few places where scons' dependency checking fails in the unit tests (it
doesn't always realize it has to rebuild the dependencies of the tests).

  Daniel