wxAUI with GTK Problem

[ggbutcher]

I'm using wxWidgets 3.1 to write a raw image processor. I have a 4-pane wxAUI layout, the main pane for the image, and three panes in a Left Dock: 1) wxTreeCtrl for the image operations, 2) a wxPanel-based histogram graphic drawn with wxDC, and 3) a blank wxPanel for image tool parameters. #3 is populated in turn by a panel created by the selected image tool, containing wxSliders or other controls. The tool panels are destroyed and created as tool selections in the tree control are changed, so only the selected tool's parameters show up.

It is #3 that is vexing me; it behaves just fine in Windows, but in Ubuntu/GTK2 when I add an image tool its parameters panel doesn't paint until I move the mouse into the histogram pane, #2. Further, I have one tool that is a simple wxTextCtrl for entering a value; even if I SetFocus() on it when the panel is created, it doesn't update unless I move the mouse into the histogram pane, #2.

I can post code, but I'm not sure what code would be relevant, and I'm hoping the above description of the behavior jogs someone's knowledge about event handling or window hierarchies that I'm not doing right. I'm at the point where I'm considering more drastic measures such as a redesign, but I thought I'd try soliciting feedback here as a last resort.

Thanks in advance for considering...

[doublemax]

I can't help directly, but it would be interesting to know if wxAUI is really a part of the problem. Could you replace wxAUI with a sizer-based layout temporarily to check if the problem is still there?

...its parameters panel doesn't paint until I move the mouse into the histogram pane, #2.

Do you have a mouse motion event handler in that panel? If yes: What happens if you disable it temporarily?

The tool panels are destroyed and created as tool selections in the tree control are changed, so only the selected tool's parameters show up.

Probably not related to the problem, but destroying and creating controls on-the-fly is a potential error source. Often it's better (and easier) to create all controls at once and only show/hide the ones you need/don't need.

[ggbutcher]

I can't help directly, but it would be interesting to know if wxAUI is really a part of the problem. Could you replace wxAUI with a sizer-based layout temporarily to check if the problem is still there?

Not there yet, but about to, see below.

...its parameters panel doesn't paint until I move the mouse into the histogram pane, #2. Do you have a mouse motion event handler in that panel? If yes: What happens if you disable it temporarily?

I tried disabling all events in the histogram pane; then, the only time the panel would update was when I resized the dock.

The tool panels are destroyed and created as tool selections in the tree control are changed, so only the selected tool's parameters show up. Probably not related to the problem, but destroying and creating controls on-the-fly is a potential error source. Often it's better (and easier) to create all controls at once and only show/hide the ones you need/don't need.

Acting on another thread where you recommended wxSimplebook, I spent the day converting over to it. When a tool is added, its parameter panel is created and inserted in the wxSimplebook, when an existing tool is selected, its parameter panel is made visible. Works fine, and actually more cleanly, in Windows, but the same discrepant behaviors exist in GTK. I forgot to note this in my first post, but the parameter panel operates normally when un-docked, but goes back to badness when re-docked.

I'm going to try the replace-aui-with-sizer suggestion next.

The gamma panel is the only one using a wxTextCtrl, the others, with wxRadioBoxes, wxSpinCtrls, wxSliders, etc, all work okay, so I'm considering just replacing the wxTextCtrl with a wxSpinCtrlDouble, but I'd rather understand what's going on.

[ggbutcher]

Okay, I did a wxBoxSizer replacement of wxAUI, and it still behaved the same way.

Now, I just finished linking with gtk3, and the behavior is much improved. The tool panels paint when created, and the gamma wxTextCtrl updates at keystrokes, not when the mouse moves somewhere else. Problem solved.

Well, now I have GTK3 issues: 1) the application segfaults on startup, but just occasionally. 2) I have a custom control whose EVT_SCROLL_THUMBRELEASE events aren't propagating up to the parent. I'll figure those out, and instruct folks who compile my program on Linux to use GTK3...

doublemax, thanks for your assistance. I've been using wxWidgets for about 10 years, both work and home, and over the years I've found your forum contributions to be of particularly significant utility in solving my wxWidgets ignorance.

[ggbutcher]

I've come to the following realizations in using wxWidgets and Linux/GTK:

1. GTK2 has wxWidgets event-handling issues.

2. GTK3 doesn't have the GTK2 event-handling issues, but it has wxAUI initialization issues. It'll occasionally crash on startup, somewhere in the wxAUI::SetManagedWindow call. The location of the crash differs; based on stack traces it seems as if there's a race going between Glib/GTK setup and the wxWidgets wxApp::OnInit() call, and sometimes SetManagedWindow gets to something GLib/GTK hasn't set up yet.

3. wxBoxSizer-based layout works fine with GTK3, so that's what I'm going to recommend for folks who build a Linux/GTK version of rawproc. I left it in the code, enabled with a -DSIZERLAYOUT define.

I'll keep chasing the wxAUI race, but I need to baseline a Version 0.6, so I can get back to honey-do's... If any are interested in the code, it's on GitHub:

https://github.com/butcherg/rawproc

Building it is a bit convoluted, you need wxWidgets 3.1 and gimage, an image processing library I wrote:

https://github.com/butcherg/gimage

To build gimage, you need libtiff, libjpeg (the distro versions will suffice), libraw 0.17.2, and LittleCMS 2.8

The payoff for your build journey will be a basic, no-hand-holding raw image processor, GUI and command-line programs.

[doublemax]

Unfortunately i can't help much with Linux/GTK related issues, but...

GTK2 has wxWidgets event-handling issues.

...this is a little strange. The GTK2 port is supposed to be the stable one, because it's already pretty old (= mature) and any serious event handling issues should have surfaced by now.

It would be really helpful if you could build a minimal sample that shows the problem.

[doublemax]

I just had a short look into the code for the pic and histogram panel. There is at least one thing you need to change, the size event handlers.

Code: Select all

void PicPanel::OnSize(wxSizeEvent& event) 
{
    Refresh();
} 

If you catch the size event, in 99% of all cases you need to call event.Skip(), so that the default sizing code gets executed, too. In your case it seems the only purpose of the size event handler is to force a full redraw. For that just add the wxFULL_REPAINT_ON_RESIZE style flag when creating the window.

[ggbutcher]

I just had a short look into the code for the pic and histogram panel. There is at least one thing you need to change, the size event handlers.

Code: Select all

void PicPanel::OnSize(wxSizeEvent& event) 
{
    Refresh();
} 

If you catch the size event, in 99% of all cases you need to call event.Skip(), so that the default sizing code gets executed, too. In your case it seems the only purpose of the size event handler is to force a full redraw. For that just add the wxFULL_REPAINT_ON_RESIZE style flag when creating the window.

I put event.Skip() calls in the myHistogramPane, PicPanel, and PicProcPanel that is the base class for all the parameters panels, but the gamma panel's wxtextctrl still behaves the same.

It may be a few days, but I'll produce a hard-coded minimal example that replicates the same object hierarchy. Thanks for looking...

[ggbutcher]

I cobbled together the minimal example, with the intent to post it. However, just got carried away and incrementally re-added pane elements until I found the offender, PicPanel, which displays the image being worked. I'm just a little sheepish to report that my problem was liberal over-use of Update(), in the misguided assumption it would make the program more responsive to mouse manipulation. Got rid of all of them, and now the wxTextCtrls behave in GTK2, and Refresh() is as timely as I need.

doublemax, thanks again for your insight.

[ggbutcher]

Turns out I had one more Refresh problem, manifested itself in wxAUI not updating after docking a pane. Turns out I was calling a function in a wxDC render routine that called Refresh(). To further vex me, the call was in an if statement, so it didn't happen all the time.

Lesson: Windows is much more tolerant of Refresh() misuse than GTK. Still, needs to be right in both places...