[Aptitude-devel] 002-qt-stubs review

[Piotr Galiszewski]

2010/7/14 Daniel Burrows <dburrows at debian.org>:
> On Wed, Jul 14, 2010 at 03:40:24PM +0200, Piotr Galiszewski <piotr at galiszewski.pl> was heard to say:
>> 2010/7/14 Daniel Burrows <dburrows at debian.org>:
>> >  If it's just a signal, could you leave it in the header despite the
>> > rest of the class being abstract?  I guess that means that other code
>> > could emit the signal, but other than that it should be OK for now...
>> >
>>
>> As I wrote above it is working now. Probably there will be no problems
>> with this in the future. So another parts could also be written as
>> abstract interface. Which classes should use this approach? Every
>> widget?
>
>  I would prefer to use abstract interfaces wherever we can get away
> with it.
>
>  The tricky part is often figuring out what the interfaces between
> components should be.  Also, you need to know when to stop. :-)  It's
> easy to end up with a bazillion tiny little interfaces for every piece
> of your program (which might actually be good for industrial
> development, but isn't worth it in a smaller project like this); on the
> other hand, having a few really broad interfaces doesn't do anyone any
> good.  Hopefully we can find some common-sensical middle ground.
>

I am not sure how it will work for widgets. It is common to use
inherited methods from QWidget or other parents classes. Also QWidget
has to be accessible base for every widget added to any layout.

>  If I look over your status widget, for instance, I might split it up
> like this (leaving public: virtual ~foo() out for concision).  Let me know if it seems irredeemably horrible :).
>
>  Note that I split this into views and controllers -- the idea is that
> the controller is completely free of GUI dependencies, so it's really
> easy to write automated tests for it, while the view is some really
> simple GUI code, so it's easy to verify by eye (if we had engineering
> time to spare we might test the views too, but this is already
> pushing it).
>
>  You can find a fully worked example of this technique over in the
> command-line code.  Look at cmdline_progress_display and
> cmdline_download_progress_display, along with the interfaces they
> implement, the code that uses them, and their test cases.  There's a
> more GUI-oriented example in the search_input controller and view (in
> src/generic/controllers and src/generic/views), plus the implementation
> in src/gtk/view-impls.
>

I will try to reuse this for my download progress bars.

>  There is one catch regarding views and controllers, which is that I
> picked up the paradigm from Java coders, and they have real garbage
> collection.
>
>  If the code goes down this path, we'll have to figure out how to
> attach a controller to a view safely: specifically, how to keep the
> controller alive for as long as it needs to exist, how to ensure that
> it's destroyed eventually, and how to avoid problems when the view
> is destroyed.  This is probably the biggest issue that I see with trying
> to use a controller/view separation in your frontend.  Whatever the
> solution is, it should be something that can be applied mechanically
> to all the code (preferably using some common code module, maybe base
> classes for Qt views and controllers).
>

It is easy to get know when every Qt object is destroyed. the
destroyed() signals is emitted in this situation. I am using it in
tabs_manager code to remove tab_widget pointers when it is destroyed

>  I hope this will be food for thought, anyway, even if it turns out
> to be impractical to do exactly this -- the places where I chose to
> split the code might still be interesting points to divide modules, even
> if the overall arrangement ends up a bit different.
>

Thanks for the code. I have just thought how should be done in better
way than before. Previous progress_widget approach looks little
problematic. I will read this code carefully and try to good
understand it.

It will take some time, because it is not a way the most Qt programs
are built. It is the new world for me and perfect opportunity to learn
new thinks (every day I learn something new) :)

[snip]

>
>> Making this code multi windows aware needed more (sometimes tricked)
>> functions, but it should work without problems
>
>  Thanks for humoring me on that point, I know it's not too important
> this early in the game. :)
>

No problem ;)

>> I have also split patches a little, but in different way than you
>> suggested. I tried to make every patch compilable.
>
>  I haven't had a chance to look at them yet, sorry.  Obviously I'll
> let you know when I do look at them.
>

Great. Thanks :)

>  Daniel
>
-- 
Regards
Piotr Galiszewski