Re: Porting to GTK+ 3

[Damon Chaplin <damon karuna eclipse co uk>]

On Tue, 2010-06-15 at 16:30 +0100, Ed Griffiths wrote:
> Hi,
> 
> although we don't use goocanvas right now we have plans to use it in the future 
> and that was partly based on the MVC bit.....

You could still have an MVC architecture, but you'd create the model
yourself and just use GooCanvas for each view. I did that with my
SynthForge app, and it was fairly easy.

The problem with the MVC stuff in GooCanvas is that I tried to make it
usable as a simple canvas or alternatively as a MVC canvas and it just
made the code too complicated.


> Our problem is this:
> 
> currently we use the foocanvas and we have a lot of features and if the user 
> splits the window we have to create a whole new foocanvas. It would be great to 
> not have all that overhead. I originally hoped that goocanvas would solve all 
> that but with Damons help came to realise that the MVC implementation in 
> goocanvas saves some memory but not as much as you might think.
> 
> It would be great if any new version had some way to tackle this problem....

I think your best bet would be to cut down the number of real canvas
items as much as possible. I'd use "lightweight" items (basically just
data structs) and special canvas items that handled a whole bunch of
them at once (maybe a column of your data). The app would probably
startup faster and also run faster (if you kept the data sorted and used
quick search routines).


The current GooCanvas MVC architecture creates separate item hierarchies
for each GooCanvas view, which can use lots of memory. An alternative
approach is used by QGraphicsView in QT, I think, where the
QGraphicsScene model consists of a hierarchy of items, and the
QGraphicsView view is a single view object.
   See http://doc.trolltech.com/4.2/graphicsview.html
Maybe that might be possible with GooCanvas.

Damon