What's going on with display connections?

juce_linux_messaging seems to have some errors, unless I’m not understanding it.

There’s an extern definition - windowHandleXContext. At around line 313, the code creates a display connection. It doesn’t assign it to that extern though.

Then if that display connection has failed, it makes an XContext of some kind, but then it used the null display to try to create a window.

I think I’m missing something and there’s some errors. I can’t see that XCreateWindow should work with a null displayconnection?


Eh? The code does that stuff if the display connection didn’t fail.

But if display == 0 it goes into a failsafe area, but that then uses the display variable, AFAICT. Is that kosher?

EDIT - sorry reread what you said. I’ll look again. I added extern Display* display; to my files, if that sounds right?

I still don’t understand!? My code says this:

[code] display = XOpenDisplay (displayName.toUTF8());

if (display != 0)  // This is not fatal! we can run headless.
    // do display stuff..


…so it only uses “display” if it is NOT null!

Why would you add that?? To which files?

To my OpenGLContext file - it’s an offscreen GL Context, kept around to have consistent shares between transient contexts. There’s some evidence that the contexts may need the same display connection to share properly. Still working on why it’s not currently working.


The current OpenGLContext stuff is a real mess in Juce.
For whatever safety/dumb reason, the fact we can’t call an official Juce method to build a context makes all of us try to hack our own bad-magic code.
I think a better way is to allow the user to create a context, and yet let the method fail if the platform/situation doesn’t allow it.
With time and some forum monitoring, the reason for such failure will be documented and probably worked around.

But having to write platform specific hack code is a PAIN to me!

Yeah, alright, I know, and I’m working on a better design for it!