[Aptitude-devel] 002-qt-stubs review

[Daniel Burrows]

On Wed, Jul 14, 2010 at 1:10 PM, Piotr Galiszewski <piotr at galiszewski.pl> wrote:
> 2010/7/14 Daniel Burrows <dburrows at debian.org>:
>>  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.

  Instead of me spouting a bunch of generalities, how about we play
a "game": you give me an example of some code that you think
won't work with this approach, and I'll try to make it work. :-)

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

  Please feel free to suggest improvements to views::download_progress
if you need them -- it's strongly defined by what the command-line view
needed, and I'd be happy to clean it up.

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

  The main problem is that I don't want to have to do this by hand,
because that inevitably means we miss some corner case and then
get inscrutable crashing bugs.  But I think that we can probably
implement this behavior in some qt_controller<> base class.

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

  This is definitely a slightly roundabout way of building up GUIs.  It tends
to force you to think more up-front about the logical structure of your
program, which can mean some up-front cost, but also tends to produce
better code once you get the hang of it (IMO).

  I did find an online article pushing this style of coding, in the context
of the Google Web Toolkit.  It uses the term "presenter" where I used
"controller", but the idea is the same: touch UI libraries as little as
humanly possible, and divide your code up into small logical
components that you can test easily.

http://code.google.com/webtoolkit/articles/testing_methodologies_using_gwt.html

  As the article discusses, this is even more important in GWT, because
as long as your code doesn't touch the UI, it can run in a JVM, but the
moment you invoke a UI function, you have to run the test *inside a
Web browser*, which is exactly as fun as you probably imagine it is.

  Daniel