Help? GTK events do/dont's for dummies (nothing works)

Do you have a typical platform dependent issue you're battling with ? Ask it here. Make sure you mention your platform, compiler, and wxWidgets version.
Mick P.
Experienced Solver
Experienced Solver
Posts: 75
Joined: Thu Jun 06, 2019 3:41 am
Contact:

Help? GTK events do/dont's for dummies (nothing works)

Post by Mick P. » Wed Jun 12, 2019 11:00 am

Sorry to be a bother, but I can't find any guides for wxGTK. I kind of hoped that wxWidgets would be transparent across platforms... like the common subset of all of its platforms? But that's not the experience I'm having.

I have a very simple system that spawns some windows that use the wxGLCanvas class only to paint their bodies. They have a few handlers for input and Size/Move events. This works for MSW. Under GTK the same code just doesn't work pretty much.

I remember reading something like GTK can't do recursive events... which I assume means that it would only use the equivalent to the Win32 PostMessage API instead of SendMessage? But I don't know what that means to be be honest. What is recursion?* Is there anything else that is poison to events? Because not even the Close buttons are generating events.

[*Before someone describes the concept of recursion, I just mean what is the meaning of this in terms of GTK's message passing framework.]

Pretty much everything under GTK is a no-go except for one of my demos partially works. Oddly it's the most complex of the demos. So it could be the others are somehow too simple?

Caveat: I don't have any experience using GTK. Which is why I'm using wxWidgets! So I don't have knowledge of its inner workings. But I thought my use-case was so simple that it couldn't be any simpler. But still it is not working... At all.

There must be a simple explanation. I'm a little bit at the end of my rope, because tinkering with Linux build tools is really time consuming, since everything they do takes 20 or 100 times longer than MSVC tools. It's really a pain to debug when a problem is isolated to Linux.

(Before someone asks, I'm using Ubuntu on Windows. Other software works fine. So there is something wrong with my wxWidgets code. I haven't published it yet, but I don't mind putting a file online somewhere to share it. But I think that will unlikely be productive, and I wouldn't want anyone to spend too much time studying my code. At its base it's stupid simple as UI logic goes. It should work. Like I say, MSW works perfectly with the same code.)

I imagine something is locking up the message pump somehow, but I can't see how :(


Background (EDITED)

EDITED: Here is a description of my symptoms. Pretty much the wxFrame windows do appear, but Paint events aren't generally generated for most demos. Breakpoints placed in the idle and paint events are not triggered. The Close button doesn't work. The X server is responsible for sending these events to the client (wxWidgets) but I don't know they are to blame, as other software works.

In the demo that does work (mostly) it has some child windows, that are separate OpenGL contexts (they emulate glutCreateSubWindow) and its Close button DOES work. Changing to other demos locks up the program. I would Suspend the program to see where it is, but that button is disabled in Eclipse (because Eclipse is generally a basket case. But maybe it's a GDB thing?)

The working demo has weird artifacts. Like other software behind it (hosted by the same X server) occasionally "damage" the demo's windows. They are behind it, so logically they should not be able to write over it. That's weird in itself. It's very unlike Win32. No clue what the X server is doing. But it's not sending paint events to repair. Dragging the window causes it to blank when the button is released, then it repaints. That's weird. Other software, including freeglut doesn't show these signs. So something is off. Either events are not getting through, or wxWidgets is not setting up its windows like other software's.

DavidHart
Site Admin
Site Admin
Posts: 3863
Joined: Thu Jan 12, 2006 6:23 pm
Location: IoW, UK

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by DavidHart » Wed Jun 12, 2019 11:44 am

I can't find any guides for wxGTK
Look at the samples that come with the wx source. Also build and run them; if they work, that makes it unlikely that your wxGTK build is buggy.
They have a few handlers for input and Size/Move events. This works for MSW. Under GTK the same code just doesn't work pretty much.
Without seeing code it's only a guess, but:
wxMSW has a bug: it propagates wxEvents to top-level windows when it shouldn't. That means that trying to catch e.g. wxMouseEvents and wxPaintEvents in a wxFrame often works, even when those events are generated by a child control. (What should happen is that only wxEvents derived from wxCommandEvent propagate to parent controls.)

That is the commonest event-related cause of "Works in wxMSW but not in wxGTK" topics. If it's the situation here, the standard solutions are either to Bind() the target controls/events to your frame instance handler, or catch and handle the events at child level.

Manolo
Ultimate wxWidgets Guru
Ultimate wxWidgets Guru
Posts: 690
Joined: Mon Apr 30, 2012 11:07 pm

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by Manolo » Wed Jun 12, 2019 5:10 pm

You don't post any code, so I can only guess about your issues using the few and hidden clues you give.
I have a very simple system that spawns some windows that use the wxGLCanvas class only to paint their bodies. They have a few handlers for input and Size/Move events. This works for MSW. Under GTK the same code just doesn't work pretty much.
Weird. This is the first time I hear something like that, appart from buggy GPU drivers.
I remember reading something like GTK can't do recursive events
Does your code for event-handling recursively calls itself? How? Why? I can think of an event that posts other event, but I can not think of an event that calls itself.

About your paint-events... whithout seeing your code my cristal-ball fails.

They way you talk makes me think... You use only wxWidgets controls and functions, no platform-specific API code, right?

ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 3358
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by ONEEYEMAN » Wed Jun 12, 2019 8:46 pm

As David said - try to build and run all opengl samples.
If they all works - great.
If they don't - let us know which one does not, what the symptoms are and how did you configure wxWidgets.
Also would be interesting - what video card/driver do you have and what EXACT GTK+ version is installed on your system.

Thank you.

Mick P.
Experienced Solver
Experienced Solver
Posts: 75
Joined: Thu Jun 06, 2019 3:41 am
Contact:

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by Mick P. » Thu Jun 13, 2019 12:07 am

I will. I will have to find those examples, because this is the first I've read of examples. Assuming they are test projects somewhere.

I will post the code if I don't figure out something. It's not OpenGL related, although the GTK version of the canvas has an awkward requirement that the window be shown in order to make the OpenGL context current. I assume that's necessary, but it seems like maybe it's overly defensive. It just seems very unlikely that OpenGL (GLX) would require a window to be visible on screen to use OpenGL, since that would necessitate hacks like moving the window off the desktop or making its size 0,0. (Typically you want to render the first frame before the window appears. Maybe GLX has a hack where it doesn't show the window until "SwapBuffers" is called, but this is very inelegant, and it would be nice if wxWidgets would handle differences like this automatically by virtualizing certain facilities, and also requiring facilities that don't work on all platforms to be expressly enabled, in order to aid in development of no-surprise portable apps.)

I can't imagine this relates to OpenGL drivers, at all. So I would not worry about that. And for what it's worth, I have MOVE and SIZE events both in the canvases and the frame, since they drive each others size in both directions. But not any of the MSW only events (which are not documented in code as being MSW only, but I read in the manual they are, and so avoided them. These are MOVING, SIZING, MOVE_START/END.)

For canvases, the required arrangement is to put the canvas in a frame. I assume that frames receive MOVE/SIZE events that are to do with dragging their headers/borders. That in turn changes the sizes of the frames, and client code selects their canvas sizes, which in turn fits the frame to their canvases. That is like glutReshapeWindow.

My code seems super vanilla. It uses Refresh and waits for PAINT events. That's pretty much the whole of it. I will attach the code if the forum will let me... it's real code (though a bit fresh) so I apologize if it's difficult to follow. It implements a wrapper around GLUT's APIs in terms of wxWidgets.
xcv_widgets.cpp
(33.61 KiB) Downloaded 8 times
EDITED: There are two different (experimental) modes for subwindows and timers that I recommend ignoring. Neither works. In the attached code I had tried a different (earlier) one with GTK just to see what it does. It's just something that might be confusing. They are compile-time options in case different systems work differently. (See subwin_model and timer_model.) The demos that aren't working (at all) don't have subwindows. And the timers pretty much aren't getting processed. I just recommend looking at the code to see that it's nothing out of the ordinary. The set up might be a little different and worth scrutinizing, since it doesn't have wxWidgets implement "main".

User avatar
doublemax
Moderator
Moderator
Posts: 13898
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by doublemax » Thu Jun 13, 2019 5:19 am

At least under Windows you must create a wxPaintDC in a paint event handler.

The rest of the code is so different from any "normal" application, it's very hard to follow and to spot potential problems.
Use the source, Luke!

Mick P.
Experienced Solver
Experienced Solver
Posts: 75
Joined: Thu Jun 06, 2019 3:41 am
Contact:

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by Mick P. » Thu Jun 13, 2019 5:39 am

Update: Looking at the samples, I got the idea to move CallOnInit to before the windows are created. Doing this solved the problem with nothing appearing to work properly, for instance the Close buttons, etc.

This change doesn't really explain why my more complicated demo was able to function. I think it's something the GTK module could try to solve if possible. Here is the code, rearranged:

Code: Select all

static void xcv_widgets_init(int* argc, char **argv)
{
	xcv_widgets = (xcv_widgets_app*)wxTheApp;

	if(!xcv_widgets) 
	{
		wxApp::SetInstance(xcv_widgets=new xcv_widgets_app);
	}

	#ifdef NDEBUG
	#error wxUSE_CMDLINE_PARSER
	#endif
	int fix_me = 1; argc = &fix_me;

	bool res = wxEntryStart(*argc,argv); assert(res);

	xcv_widgets->CallOnInit();
}
static void xcv_widgets_loop()
{
	xcv_widgets = (xcv_widgets_app*)wxTheApp;

//	if(xcv_widgets->CallOnInit())
	{
		xcv_widgets->OnRun();
		xcv_widgets->OnExit();
	}
//	else assert(0);

	wxEntryCleanup(); //xcv_widgets_init
}
I can't make a great case for this either way, but if this worked either way, then it would make life easier for users, since there's no obvious reason to do things one way or the other, and because MSW works perfectly fine both ways (whereas GTK does not.)


That said, I'm still having some issues. It seems like wxGTK doesn't subtract the title bar from GetClientSize. It's not really a problem, but it puts the header on the outside. So the windows end up larger. And their real position is above their set position.


There are a lot of issues actually. I don't want to go into detail. But at least I've made some progress, and so can try to solve the remaining issues now. I have a sinking feeling they will prove insoluble. I don't know why, it's just my instinct. The random "damage" remains. I feel like that's something that should not happen under any circumstances. The damaged section of the frame buffer seems like it is a similar color to the window's elements, but that could be a coincidence.

Mick P.
Experienced Solver
Experienced Solver
Posts: 75
Joined: Thu Jun 06, 2019 3:41 am
Contact:

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by Mick P. » Thu Jun 13, 2019 5:45 am

doublemax wrote:
Thu Jun 13, 2019 5:19 am
At least under Windows you must create a wxPaintDC in a paint event handler.

The rest of the code is so different from any "normal" application, it's very hard to follow and to spot potential problems.
It's not an application. It's a module, like wxWidgets is itself. Actually, this source file is an emulation of GLUT, which is itself a module, that provides a service.

Here (https://github.com/mick-p1982/glui/tree ... /bin/Win32) is a demo of the same basic code. You press F1 through F6 to see the demos I'm working with. When I get it working with wxWidgets I'm going to publish the code at https://sourceforge.net/projects/widgets-95/.

I'm going to see if I can build some of the wxWidgets samples with wxGTK. I'm not sure how to best go about it, because all I have is the sources package from Ubuntu. Maybe I need to download them from somewhere else if they're not part of that.
RE" wrote:The rest of the code is so different from any "normal" application, it's very hard to follow and to spot potential problems.
EDITED: It's actually a problem that wxWidgets is structured like an application. On Win32 you can implement a "message pump" anywhere, and there are typically many of them. A modal dialog is a message-pump. It's not clear to tell how wxWidgets works in that regard. In the real world "apps" don't exist. They are more like a description of a goal, but they are not really code, or anything real. It's like painting yourself into a corner to say you are going to encode an "app" into your code. Because you don't have to do that.

Mick P.
Experienced Solver
Experienced Solver
Posts: 75
Joined: Thu Jun 06, 2019 3:41 am
Contact:

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by Mick P. » Thu Jun 13, 2019 7:47 am

Update: On samples, I ended up copying my CMakeLists.txt file into the opengl sample, because I couldn't make any sense out of the wxWidget's build tree. I'm guessing you have to build wxWidgets and all dependencies to build the samples?

Anyway, the sample (cube) is randomly "damaged" in the same way ... meaning it can't hold a picture. You can force a paint by resizing, but the picture won't last long.

https://github.com/wxWidgets/wxWidgets/ ... pengl/cube


Mine is a fairly recent version of Microsoft's Ubuntu for Windows, which I assume is identical to Ubuntu's sources. I think the problem is likely in wxGTK. The sources folder is "/usr/lib/debug/wxwidgets3.0-3.0.2+dfsg" so the version is 3.0.2.


I have other opengl apps that don't have this problem. I don't know if it might help to pass different parameters to configure the OpenGL context, but that really shouldn't matter.

Mick P.
Experienced Solver
Experienced Solver
Posts: 75
Joined: Thu Jun 06, 2019 3:41 am
Contact:

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by Mick P. » Thu Jun 13, 2019 8:23 am

FWIW: The Xming X server fairs worse than Cygwin's. It doesn't get an OpenGL picture at all. The Close button doesn't work in my project, and the Cube crashes Xming. It appears on screen for a little while.

Code: Select all

[email protected] /usr/lib/debug/wxwidgets3.0-3.0.2+dfsg/samples/opengl/cube
$./sample
sample: Fatal IO error 0 (Success) on X server localhost:0.0.

EDITED: The Cygwin server actually fairs much worse than I described. It jams up still for two window demos, and its Close buttons do not work. Switching demos always fails, but maybe that's because spawning the second demo creates a second top-level window, and that jams up just the same.

I'm going to build some non-opengl demos. And I started to try Cygwin, but it wanted to do massive updates (even when I told it to Keep current versions) so I'm going try that again tomorrow. I will do a comparison of the freeglut and wxGTK code.
Last edited by Mick P. on Thu Jun 13, 2019 10:35 am, edited 1 time in total.

DavidHart
Site Admin
Site Admin
Posts: 3863
Joined: Thu Jan 12, 2006 6:23 pm
Location: IoW, UK

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by DavidHart » Thu Jun 13, 2019 10:21 am

I'm not sure how to best go about it, because all I have is the sources package from Ubuntu. Maybe I need to download them from somewhere else if they're not part of that.
I think you've now found that they're in a separate package: wx3.0-examples. It installs to /usr/share/doc/wx-examples/
Update: On samples, I ended up copying my CMakeLists.txt file into the opengl sample, because I couldn't make any sense out of the wxWidget's build tree. I'm guessing you have to build wxWidgets and all dependencies to build the samples?
The wx3.0-examples samples come ready to build. They were designed to build against the corresponding installed wx packages but in practice their makefiles seem able to cope with other wx versions; whichever is found by the wx-config script, so, if you want to use a different wx build, prepend its filepath to the terminal's $PATH.

Mick P.
Experienced Solver
Experienced Solver
Posts: 75
Joined: Thu Jun 06, 2019 3:41 am
Contact:

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by Mick P. » Thu Jun 13, 2019 10:53 am

DavidHart wrote:
Thu Jun 13, 2019 10:21 am
The wx3.0-examples samples come ready to build. They were designed to build against the corresponding installed wx packages but in practice their makefiles seem able to cope with other wx versions; whichever is found by the wx-config script, so, if you want to use a different wx build, prepend its filepath to the terminal's $PATH.
Kind of bummer here too. Building the projects in the examples package is much easier, but at least the first one I tried (opengl/cube) is not happening:

Code: Select all

$make
`wx-config --cxx` -c -o cube_cube.o -I. `wx-config --cxxflags --unicode=yes --static=no --toolkit=gtk2 --version=3.0`   -MTcube_cube.o -MF`echo cube_cube.o | sed -e 's,\.o$,.d,'` -MD -MP cube.cpp
`wx-config --cxx` -o cube cube_cube.o     `wx-config --unicode=yes --static=no --toolkit=gtk2 --version=3.0 --libs gl,core,base`
/usr/bin/ld: cube_cube.o: undefined reference to symbol 'glGetBooleanv'
//usr/lib/x86_64-linux-gnu/mesa/libGL.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:91: recipe for target 'cube' failed
make: *** [cube] Error 1
I'm not sure what's happening here exactly (wx-config) but searching for this "DSO" error suggests the linker dependencies might want to be in a different order?

EDITED: Some good news; the "controls" demo works well, and renders well. Maybe the opengl ones would also, if they built? (Thanks everyone, I'll be back tomorrow :mrgreen:)

P.S. I edited my previous reply, adding that there still seems to be real problems (the Close buttons etc. aren't working) after I moved the CallOnInit call. Two top-level windows seems to be a problem, that also jams things up. I thought it was still the last reply when I did so.

ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 3358
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by ONEEYEMAN » Thu Jun 13, 2019 2:32 pm

Hi,
Me again. ;-)

Code: Select all

/usr/bin/ld: cube_cube.o: undefined reference to symbol 'glGetBooleanv'
You need to first solve the above error.

Also, just to make sure - can you build other 3 samples from opengl? Especially the pyramid one, as I believe it uses more modern (and current) OpenGL implementation.

Thank you.

[EDIT]
I just saw couple of fixes Paul pushed to the Git master.

Could you please try to clone that and retry your with application,?
You will have to manually rebuild wxWidgets and then your application.

Those fixes might help you with your issues on OpenGL.
[/EDIT]

DavidHart
Site Admin
Site Admin
Posts: 3863
Joined: Thu Jan 12, 2006 6:23 pm
Location: IoW, UK

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by DavidHart » Thu Jun 13, 2019 3:09 pm

I'm not sure what's happening here exactly (wx-config) but searching for this "DSO" error suggests the linker dependencies might want to be in a different order?
I expected that to be the reason too, but the usual workaround (LDFLAGS="-Wl,--no-as-needed" make) failed. After some trial'n'error and googling, I successfully built the sample using:
LDFLAGS="-lGL -lGLU" make

'cube' runs successfully. So do 'isosurf' and 'penguin' after I re-gzipped each sample's .dat file and ran the sample from its dir, not from a different path.

I think these are issues with the debian samples packaging, not wx itself: the wx3.0.2 opengl sample builds and runs normally after a standard wxGTK configure + build.

User avatar
doublemax
Moderator
Moderator
Posts: 13898
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Help? GTK events do/dont's for dummies (nothing works)

Post by doublemax » Thu Jun 13, 2019 4:48 pm

It's not an application. It's a module, like wxWidgets is itself. Actually, this source file is an emulation of GLUT, which is itself a module, that provides a service.
I don't think wxWidgets is suitable for that.

wxWidgets only purpose is to write applications, it's not intended to write modules or components for applications written in another frameworks (or native ones).
Use the source, Luke!

Post Reply