Jump to content
Ultra Engine Community
  • entries
    944
  • comments
    5,899
  • views
    929,541

The Ancient Forbidden Knowledge of X11

Josh

Entry posted by Josh ·

3,202 views

 Share

The most interesting thing about the development of Leadwerks is digging into low-level X11 libraries that no one really understands. If the stock answers of "use GTK" or "use QT" were sufficient, this project would not be necessary. No one really knows how X11 works anymore, so it's like we are exploring an archaeological ruin and discovering ancient forbidden knowledge.

 

blogentry-1-0-34666000-1476717931_thumb.jpg

 

Here's me looking at the X11 documentation. rolleyes.gif

 

blogentry-1-0-66760200-1476718613.png

 

X11 doesn't really have a concept of non-embedded child windows like Win32 and Mac have. The desired behavior has two characteristics:

  • A child window always appears on top of the parent.
  • A child window does not appear in the taskbar.

 

Here's how we do it:

//Make it act like it's parented to the parent window, but not really

if (parent) XSetTransientForHint(display, window->handle, parent->handle);

 

//Hide from taskbar

window_type = XInternAtom(display, "_NET_WM_STATE", false);

value = XInternAtom(display, "_NET_WM_STATE_SKIP_TASKBAR", false);

XChangeProperty(display,window->handle, window_type, XA_ATOM, 32, PropModeReplace, (unsigned char *) &value, 1);

 

(The child window should actually be parented to the desktop window, not the intended parent.)

 

Here is the result. Notice the main window is the active one, but the subwindow and its child still appear on top, in the correct order.

 

blogentry-1-0-65625300-1476718281_thumb.png

 

So at this point I think it's safe to say this design will work with Linux, with an absolute minimum of external libraries installed. (Possibly working on SteamOS.) I frankly have more confidence that Mac will provide everything we need, so at this point I think we're going to be good.

 

If you've tried the Game Launcher on Linux, you'll know that LeadwerksGUI is a huge upgrade over GTK. Our user experience for Linux users is about to get a lot better. It's been a slow gradual process, but moving away from Windows dependency is really happening, and other options are becoming more viable.

  • Upvote 8
 Share

6 Comments

Recommended Comments

Rick

And all of this translates into more sales or getting more completed games made with Leadwerks? I assume those are the 2 ultimate goals of the company? This is a pretty big investment and I'm curious what you think the big payoff is.

 

This doesn't seem to be about giving the community a GUI to use in game more than your own GUI for the launcher and editor and some games could take advantage of the framework for their game if they want which if not using the stock drawing still requires a fair amount of work which reduces the benefit for us.

 

Is it justified for the Linux share or even future Mac support share to do this? Do you know the share between the 3 OSs and does doing all of this make financial sense for Leadwerks or is it more of a pet project of yours because desktop GUIs can be painful to work with?

 

This aspect of what you're doing or have planned just seems like classic scope creep of a simpler idea of giving us a game ui framework. Feel free to put me in my place and explain the ROI but at face value I don't see it when there are so many other game related things people are looking for.

 

I'm just curious on your thoughts from a business standpoint.

  • Upvote 1
Link to comment
Josh

Rick, that's a good question. There's a few things to consider.

 

The education market is a natural fit for Leadwerks and a good opportunity to get real-life usability testing, but without Mac support we can't go after it. Cocoa and some BlitzMax OpenGL code are presently preventing Leadwerks Editor from running on Mac. It's not impossible, but I hate to throw a lot of work into something that's ultimately going to give a sort of half-*** result and a lot of continued bugs.

 

On the Windows side, the Win32 API is our primary obstacle in producing a 64-bit build of the editor. The API used 32-bit integers for some pointers, back before anyone imagined the length of a pointer would change, so that causes a lot of problems.

 

I know I want to add more game templates, revise the documentation, and add video tutorials. If we ever intend to refresh the UI, then it makes a lot of sense to do that before working on docs so we don't have to go back and redo everything.

 

Finally, I know I have to implement an in-game GUI for you to use, so it makes sense to knock the UI refresh out at the same time, with the same code.

 

Finally, Microsoft has completely abandoned all semblance of UI consistency, and unfortunately the standard win32 interface is now perceived as "outdated".

 

Taking control of the GUI code frees us from a lot of vendor APIs and bugs, and allows me to innovate in the user interface in ways I can't do with the Windows API. When I think about the editor I want new students using next year, the UI refresh makes a lot of sense.

 

So yeah, better learning materials + formal education = higher rating on Steam and more games.

  • Upvote 3
Link to comment
Charrua

every day i felt a couple of month outdated about almost everything!

 

thinking it twice that's a good signature to use :)

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...