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.
Earned some good credits
Earned some good credits
Posts: 110
Joined: Thu Jun 06, 2019 3:41 am
Contact:

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

Post by Mick P. » Fri Jun 14, 2019 2:02 am

doublemax wrote:
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).
Well... that would be a crying shame, because there aren't many cross-platform libraries to choose from. I may end up pretty active with wxWidgets in the coming years. I expected it to be more mature (more tested) than it is. Because there isn't an alternative to wxWidgets closing the door on users is especially mean. If there are real deficits, it can be retooled to be more accommodating.

Mick P.
Earned some good credits
Earned some good credits
Posts: 110
Joined: Thu Jun 06, 2019 3:41 am
Contact:

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

Post by Mick P. » Fri Jun 14, 2019 2:43 am

DavidHart wrote:
Thu Jun 13, 2019 3:09 pm
'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.
For the record, on my system cube exhibits the exact same misbehavior, predictably, as when I custom built the sources package's.
ONEEYEMAN wrote:
Thu Jun 13, 2019 2:32 pm
Especially the pyramid one, as I believe it uses more modern (and current) OpenGL implementation.
I don't have a "pyramid" in my package. I see the GitHub commits you mentioned. Maybe we can involve Paul here? I put in a request to Paul: https://github.com/wxWidgets/wxWidgets/ ... t-33935315

It may take me a while to switch over to working out of a custom-built wxWidgets module. It's probably inevitable, but I really had not anticipated this level of trouble on this front. I'm glad Paul (or anybody) is looking at OpenGL on GTK. I think we may need to look at specific cases of running it over an indirect display to see if that changes anything. Maybe backing windows aren't constructed correctly. But there are also the big problems with events I'm seeing. I've read some things about needing to sandwich an additional wxPanel between the frame and canvas to make certain things work... of course this is 3 windows to do the job of 1, which could be a problem too if for some (crazy) reason X11 doesn't keep the obscured windows from drawing on top of the children.

Mick P.
Earned some good credits
Earned some good credits
Posts: 110
Joined: Thu Jun 06, 2019 3:41 am
Contact:

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

Post by Mick P. » Fri Jun 14, 2019 4:15 am

:( FWIW, I now believe there are gremlins in wxGTK or GTK.

While stepping through the initialization code to figure out what it does, I didn't see anything that looked like it should be cause for the dysfunction I'm observing, but I did see that depending when/where I break into the code I could reproduce the same problems, and I also noticed GTK is probably running its own thread called "gmain" and what I found is slipping in wxMilliSleep(500) where I had moved the CallOnInit before achieved similar results.

So, what I think is happening is some kind of major defect around thread synchronization. Adding a "Sleep" to get things to "just work" is always a sign something is horribly wrong...

Needless to say.

I think it's not just a matter of start up. I think probably injecting arbitrary sleep here or there might solve some of the jamming issues. But it's not a sound way to solve a problem.

wxEntryStart calls gtk_init (gtk_init_check) and OnRun calls gtk_main, and CallOnInit calls nothing that seems to touch GTK, so it make sense that moving it should have no effect, and that it only (somehow) changed the timing...

Worst yet, is now the same code is not producing good results. So it's all just complete chaos, down to magical timing issues :cry:
Mick P. wrote:
Thu Jun 13, 2019 5:39 am

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
}
EDITED: For the record, I don't think the jamming issue is related to the volatility of the canvas's pixels observed in the cube demo. It might be related to the cube demo crashing Xming. But I don't know if this stuff is strictly isolated to wxGLCanvas either...

The only way to tell would be to try to set up some non OpenGL tests under the same conditions. I don't see any reason for this stuff to not work.

Update: Running from the command-line it's random if the windows will be interactable or not. Nothing should be random this way. It's kind of depressing :lol:

What would cause that?
Last edited by Mick P. on Fri Jun 14, 2019 5:05 am, edited 1 time in total.

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

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

Post by doublemax » Fri Jun 14, 2019 4:55 am

I expected it to be more mature (more tested) than it is.
wxWidgets is very mature and works well. It's just not suited for your purpose. Just like a fork doesn't work well to eat soup.
Use the source, Luke!

Mick P.
Earned some good credits
Earned some good credits
Posts: 110
Joined: Thu Jun 06, 2019 3:41 am
Contact:

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

Post by Mick P. » Fri Jun 14, 2019 4:59 am

doublemax wrote:
Fri Jun 14, 2019 4:55 am
I expected it to be more mature (more tested) than it is.
wxWidgets is very mature and works well. It's just not suited for your purpose. Just like a fork doesn't work well to eat soup.
Okay, I respected you, but you have nothing at all to back that up with [-X

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

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

Post by doublemax » Fri Jun 14, 2019 5:06 am

Okay, I respected you, but you have nothing at all to back that up with
Except that's i'm using wx for 15 years and that you're the only person who has problems like this.
Use the source, Luke!

Mick P.
Earned some good credits
Earned some good credits
Posts: 110
Joined: Thu Jun 06, 2019 3:41 am
Contact:

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

Post by Mick P. » Fri Jun 14, 2019 5:22 am

For the record, wxGLCanvas doesn't seem to be responsible for the event system breaking down. Or at least, I replaced it wxPanel to the same results.
doublemax wrote:
Fri Jun 14, 2019 5:06 am
Except that's i'm using wx for 15 years and that you're the only person who has problems like this.
Well, it's hard to say. wxGTK is obviously the problem here. The only difference in how I use it could be that I use the wxIMPLEMENT_APP_NO_MAIN option. In which case, maybe you can tell me if my replacement code does not behave identically to if the more vanilla options are chosen?

In any case, this is the nature of software problems: They aren't problems until they are problems.

Be of help. Why would a wxFrame not receive wxEVT_CLOSE_WINDOW (or any events more likely) randomly each time it's run? It probably has something to do with a disconnect between the X client and server. But it could be anything else too. If wxWidgets is mature, your response is not.

Mick P.
Earned some good credits
Earned some good credits
Posts: 110
Joined: Thu Jun 06, 2019 3:41 am
Contact:

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

Post by Mick P. » Fri Jun 14, 2019 11:20 am

Here is Cygwin crash output. It might be too soon to say, but I think this could be telling of what's happening with wxGTK.

Code: Select all

** (example:5182): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying
      0 [main] example 5182 cygwin_exception::open_stackdumpfile: Dumping stack trace to example.exe.stackdump
This link mentions it in relation to GTK:

https://unix.stackexchange.com/question ... us-error-n

I don't know. I will try the examples (cube) with Cygwin tomorrow. But anyway, this is the result of the Cygwin run with wxWidgets. It doesn't show any window with the Cygwin X server.

EDITED: Actually one of my demos (F6) works. It sometimes outputs the same error, so it could be benign, but it's definitely coming from wxGTK. There's nothing that distinguishes the demos much. F6 is only interesting for being contained in a single window. I apologize if this is not interesting.

ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 3402
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 » Fri Jun 14, 2019 2:43 pm

Hi,
Out of curiosity - do you access any GUI from the secondary thread?
By "secondary thread" I mean - the one that do not start the wxApp-derived class.

All wxWidgets GUI classes are NOT THREAD-SAFE!!
So if you need to access it from the secondary thread - use either wxThreadEvent or a custom event.

What you describe is definitely sounds like a MT problem.

Thank you.

Mick P.
Earned some good credits
Earned some good credits
Posts: 110
Joined: Thu Jun 06, 2019 3:41 am
Contact:

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

Post by Mick P. » Sat Jun 15, 2019 9:59 am

ONEEYEMAN wrote:
Fri Jun 14, 2019 2:43 pm
Hi,
Out of curiosity - do you access any GUI from the secondary thread?
By "secondary thread" I mean - the one that do not start the wxApp-derived class.

All wxWidgets GUI classes are NOT THREAD-SAFE!!
So if you need to access it from the secondary thread - use either wxThreadEvent or a custom event.

What you describe is definitely sounds like a MT problem.

Thank you.
Well, my app is single thread, so no. But in the debugger, there are other threads, that I thought one probably belonged to GTK because it was called "gmain". But I read that GTK is also primarily single-thread, so.

In any event, I had more success with Cygwin. I had to take some time to replace some GLUT shape drawing routines because Cygwin had a newer version of freeglut that was made incompatible with my plans. That was why it was crashing when I first built with Cygwin. I had a really bad time with Cygwin yesterday after updating because either it blew its own legs off, or one of the updates took all the safety wheels off Cygwin, so I had to go into my .bashrc file and basically rebuild the vanilla Cygwin experience from scratch.

That said, Cygwin is still really crumby (it always has been) and has a lot of issues, that maybe I can address individually, though I'm unsure it's worth it. I use it and now "WSL" to confirm cross-platform things basically work. And I hope real Linux systems are better, though in theory they should be identical.

I have kind of a new theory on why Ubuntu (on Windows) may not be working out. But it's just an intuition I got from debugging Cygwin, which is a lot better. BTW, both are having drawing issues. I added a wxPaintDC dc(this); line to my PAINT event, but cannot a see a difference. Cygwin's are more predictable, whereas on the Ubuntu system it's pretty much out of the blue, patches just appear. I would just dismiss it, but other 3D apps don't do this, so I want to find out why...


My theory is that maybe Eclipse/GDB are total crap, and really somehow the process is terminating underneath them, leaving just the ghost of a window in the X server... since it doesn't know the process is dead either. I think the Suspend button in Eclipse works until the program enters this state. Then it goes gray. That confused me because I couldn't break into the program to see where it's stuck. But if this theory is correct, it's somehow all but dead, but also not dead, since there is a Terminate Process option in Eclipse, and that brings down the X server windows. So maybe it's in a kind of debugger keep-alive state, so that the debugger can sit on it. Eclipse doesn't generate any kind of exception or anything to indicate there is a problem, so this is out of left-field, but I have a sinking feeling this is what is actually happening.

In that case, there may be a simple reason for the program's crashing, but the development tools are just inadequate to locate it if so. With Cygwin I use Netbeans, but it's actually not a Cygwin version of Netbeans. It is native Netbeans, but knows how to interface with Cygwin.

Readers who don't care about correctness may be thinking now, who cares if GTK works in a Linux on Windows setting? But I have a feeling if there is something wrong there, then it's probably something that will affect other systems also. Tough cases are good for revealing errors in code. I always test/debug my Windows code on XP even today because it always turns up useful errors that have implications not limited to XP.

I think my code is sound, evidenced by operating flawlessly on Windows. But I don't know if it can be massaged to work as well on GTK too. I intend to try to make it so. But I think it would work just as well on wxGTK too if the system were sound, because it's semantically straightforward. I wish there was a better X server for Windows, since it's always hard to gauge which side the problems are on. This is taking up a lot of my time I didn't expect to be dedicating to making Linux work, but I still have a lot more tests to do. Actually just minutes ago I was watching a Microsoft presentation (https://www.youtube.com/watch?v=lwhMThePdIo) that says there is a "Remote VS Code" tool that works with its new Linux subsystems, that I may try. If Eclipse is the weak link it might help. If GDB is it might not. Eclipse seems to have difficulty mapping itself to the source packages and symbols for debugging sessions. The paths in the binaries (wxWidgets) don't match the packages, but it has a remapping feature. It just doesn't always work once remapped.

Sorry to type so much here. I really regret making this thread now... it started out generic, but it's turned into a slog. Nobody likes it when technology fails. I hope there isn't a dumb explanation, like Eclipse has exception breakpoints disabled or something like that. But at the same time, dumb explanations are always a relief too. I'm attempting to develop a very serious cross-platform UI framework. It's not a fly by night project.

ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 3402
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 » Sat Jun 15, 2019 1:48 pm

Hi,
Well for what its worth, you should look at the yramid sample which has modern OpenGL implementation.
Build it, run it, look at the code. Then follow it in your program (if everything works).

If not, it would be interesting to know what doesn't.

Thank you.

Mick P.
Earned some good credits
Earned some good credits
Posts: 110
Joined: Thu Jun 06, 2019 3:41 am
Contact:

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

Post by Mick P. » Sun Jun 16, 2019 4:18 am

ONEEYEMAN wrote:
Sat Jun 15, 2019 1:48 pm
Hi,
Well for what its worth, you should look at the yramid sample which has modern OpenGL implementation.
Build it, run it, look at the code. Then follow it in your program (if everything works).

If not, it would be interesting to know what doesn't.

Thank you.
Well, I'm not sure you mean by modern, but what I'm doing tests in is by no means modern, since I'm mostly not using DRI in my tests.

Mysteriously, after a long day yesterday trying to massage GLX on Cygwin to ensure the screen remains correctly painted (By inserting all manner of hacks, hocus pocus, delayed repaint/resize events etc. It's really a mess this environment.) the Ubuntu build now works on the Cygwin X Server. So, it's close to parity with the (opengl) samples.

I wonder if there are ancillary paint events I'm not handling, or wxGTK is not handling. It seems like there is a problem that the X server can't back its pixels, in which case it should be sending a request to repaint those pixels. It seems like that's not happening in the samples or my test program. If there are window overlap/reveal style events, they need to processed also somehow. I haven't seen anything like that in my adventures with wxWidgets so far.

Since I've come a long way, I should probably take a break for my own sanity for a little while, and circle back later to better perfecting these things. From my experience, I've determined that it takes so much fenangling to make the Linux environment work, that I don't see how it's possible to work with it without wrapping another layer around it that compartmentalizes the black magic entailed so user code doesn't have to deal with surprises. wxWidgets could try to be that layer itself, but it's probably best that it doesn't, so that doesn't turn into a knot of Christmas lights.


EDITED: I should add that these X servers work fine with Cygwin clients, but fail to back their pixels with Ubuntu's (Windows.) That suggests that the libraries are behaving differently. Or there is something different about the system itself. I don't know if the versions are different. They probably are somewhat.
Last edited by Mick P. on Sun Jun 16, 2019 6:11 am, edited 1 time in total.

Mick P.
Earned some good credits
Earned some good credits
Posts: 110
Joined: Thu Jun 06, 2019 3:41 am
Contact:

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

Post by Mick P. » Sun Jun 16, 2019 5:24 am

Code: Select all

#ifdef __WXGTK3__
    g_signal_connect(m_wxwindow, "draw", G_CALLBACK(draw), this);
#else
    g_signal_connect(m_wxwindow, "map",           G_CALLBACK(gtk_glwindow_map_callback),      this);
    g_signal_connect(m_wxwindow, "expose_event",  G_CALLBACK(gtk_glwindow_expose_callback),   this);
#endif
...is one difference between these implementations. Funnily this is the exact same code "Paul" deleted three days ago. It may have no connection to anything (since I'm just stabbing the dark) but what if this makes a difference? Obviously wxGLCanvas is not reliable enough. (I was trying to site the code in the master, but Paul had deleted it.)

https://github.com/wxWidgets/wxWidgets/ ... 8#comments

These things should be tested with indirect X servers on different systems before making changes. I don't know how old GTK+2 is but wxGTK on Ubuntu for Windows is still using it. It's not that old. Unfortunately it's not easy to update either. You pretty much have to reinstall from scratch. The new system Microsoft is releasing later this month can host multiple installations at least. That removes the risk from pseudo-upgrades.

EDITED: In any case, the OpenGL canvases aren't reliable compared to the regular ones (e.g. wxPanel?) under GLX. I think they have not received enough attention. I worry it's not a reliable foundation for building a UI.

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

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

Post by doublemax » Sun Jun 16, 2019 6:48 am

Can you provide a minimal compilable sample that uses your component?
Use the source, Luke!

Mick P.
Earned some good credits
Earned some good credits
Posts: 110
Joined: Thu Jun 06, 2019 3:41 am
Contact:

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

Post by Mick P. » Mon Jun 17, 2019 10:33 am

doublemax wrote:
Sun Jun 16, 2019 6:48 am
Can you provide a minimal compilable sample that uses your component?
The opengl examples (wx3.0-examples) should be adequate for that? although Cygwin doesn't have that package.

I think I will be publishing new code in the next week, but it's not really pertinent. Maybe my little initiative will lead to more interest and eyeballs on wxWidget's 3D component. Do you know if wxGLCanvas is a critical part of any major software with a large user base? It's kind of a whole separate thing from the traditional GTK controls that X servers all seem geared for.

Post Reply