Re: [gnomemm] A couple Gnome::Canvas[2] issues...

[Paul Davis <pbd op net>]

>The first is that the behaviour of Canvas is different when expanding
>windows in the libgnomecanvas demo and the libgnomecanvasmm demo. In the
>libgnomecanvas demo, the canvas origin stays securly in the upper left
>hand corner of the container that it is in. In the libgnomecanvasmm
>implementation the origin of the canvas moves away from the top left
>corner proportional to the window resize that is occuring.

this sounds very related to a bug i filed in gnome bugzilla regarding
canvas "gravity". the canvas in v1 tried to center itself within the
size of the GtkLayout that is its (hidden) parent. a fix was added
that provided gravity options; someone complained that it broke
Evolution badly. i haven't tried it at all. its possible that the C
version sets the default gravity one way and the C++ one resets that. 

>I thought at first it was my use of the canvas causing the problem but
>now that I see this in the demo I know it's not just me.
>
>Incidently how can one determine what the current "size" of the canvas
>is after someone has resized the window that contains it?

use the "size_allocate" signal.

>The second issue that I had has to do with subclassing gnome canvas
>items. I subclassed a Group so that I could manipluate a collection of
>objects on the canvas. This worked great, or so I thought. The initial
>implementation added some of these items to the canvas during
>construction *before* the Gtk mainloop was started. This worked fine,

you have to ensure that the libgnomecanvasmm initialization routine is
called before doing anything with the canvas. i don't recall what the
eventual resolution of the naming discussion of this was, but
something like Gnome::Canvas::init() should exist. using
Gtk::Main::init() doesn't work for the Canvas stuff - its an extra,
independent library that needs its own initialization.

--p