On 19/01/2021 12:57, damonachaplin gmail com wrote:
On Tue, 2021-01-19 at 10:38 +0000, Paul Emsley via goocanvas-list wrote:Ah, OK. that's interesting. I linked against system goocanvas-2.0 and it just works! Hmm... so you are right. But... where do we go from here?How did you install your local version of goocanvas-2.0? Did you do a 'make install'? If you just copied the built files that may be the problem.
Hi Damon,So, for the moment, I am going with the system installation - I can worry about my build another time.
This is a "have you seen this pathology before?" questionI have now removed all GtkCanvas usage and replaced it with GooCanvas as I transition to Gtk3. Good. It looks pretty. And dark mode.
So, I have turned my attention to graphs rather than the previous plot (the box with the blue spots). And it seems that the canvas behaves in a similar way to the way it behaved for me in the plot. I should note that I created the dialog using glade-2 and that contained a scrolled_window with a viewport. The scrolled window is below a simple GtkLabel. I added the goocanvas to the viewport. I also make size requests:
gtk_widget_set_size_request(GTK_WIDGET(canvas), canvas_usize_x, canvas_usize_y);
gtk_widget_set_size_request(dialog, 600, 400);And that results in the <attached> behaviour. The canvas behaves OK until the dialog is expanded, then it "jumps" to the top left of the dialog (obscuring the GtkLabel (if I hadn't made it semi-opaque)). There is no terminal output when this happens. The blocks appear to whatever is handling the button_press_event to be below where they are drawn after jumping has occurred (i.e. where they used to be).
If you know how I can fix this, that would be great.I might be able to fix this by creating the dialog by hand or by using a more recent version of glade and builder. But I'd like to try to avoid that. It might be a one-line fix.
Thanks, Paul.
Attachment:
pre-resize.png
Description: PNG image
Attachment:
post-resize.png
Description: PNG image
