[Aptitude-devel] aptitude-qt code design

[Piotr Galiszewski]

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

Hello Daniel,

Firstly I'd like to apologize for not contacting you for such long
time. I planned to do this on Monday, but unfortunately I was
overwhelmed by my studies duties. (I am trying to compress them in the
first part of week, so in the second part I could work on the
project). Later there were to much rain in my hometown, and I have
been forcedly offline for two days. Now this problems are behind me,
so this is my official "Hello" mail

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

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 will use Qt Model View Architecture for this so second and fourth
parts will be working "auto-magically" . The same situation with
changelog: widget asks, service uses aptitude code to fetch changelog
and return already parsed buffer to widget, widget adds formatting and
displays changelog for users.

>  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 do not have AIM account. For some reasons is not very popular
protocol in Poland. But I have several jabber accounts, so I will be
glad to talk with you on one of those :)

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

Thanks for the informations.
I am not sure how it will suit with approach I described before, but I
will try to merge them.

I have not thought about tests yet. I do not have much experience in
writing them (only some java tests during my study curses). So this
project will be great opportunity to learn them. Qt provides their own
QTestLib framework, but using gmock/gtest should be also possible.

>
>  I have one toy example implemented, wrapping up the interface
> elements that comprise the search input box:
>
(snip)
>  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.
>

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.

I have also two more questions:
1) Should I use official aptitude repository (in new branch) or set up
my own repository somewhere?
2) Which build system is the future build system of aptitude? There
are two now and Sune is working on cmake version :)

Thanks again for your email, and sorry for such delayed reply. I will
answer for your comments on my blog in follow-up email (blogger does
not support blockquote tag in comments :/ )

>  Daniel
>
-- 
Regards
Piotr Galiszewski