[Aptitude-devel] aptitude-qt code design

[Piotr Galiszewski]

2010/6/7 Daniel Burrows <dburrows at google.com>:
> 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).
>

It is not a problem to mix Qt and sigc++ code in the same class.
Program only need to be compiled with no_keywords flag and later use
macros instead of standard keywords for example: signals -> Q_SIGNALS.

I planned to do this to make GUI code cleaner and make writing this easier :)

>> 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.
>

I think that Sune's explanation is really good.

>  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.
>

OK. Thanks

>> 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.
>

OK. IIRC Arthur prefers hosting gsoc code on alioth, so I will create
there new project "AptitudeQt". Mirror on gitorious.org is also an
option. The project will be mirror of official Aptitude repository and
all my work will be done in aptitude-qt 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).
>

OK. I will use autotools. I am more familiar with them than with scons.

Great, Thanks for the informations, tomorrow evening I will start
coding (Earlier I have a Visa interview ;) )

>  Daniel
>
> _______________________________________________
> Aptitude-devel mailing list
> Aptitude-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/aptitude-devel
>

-- 
Regards
Piotr Galiszewski