Xlib: How does wxWidgets understand x11's client options?

[Mick P.]

Sorry, this may not be the best link, but it's the first that shows up in searches online, and I am not finding a better source:

https://www.oreilly.com/library/view/x- ... ter08.html (scroll down)

I've so far not seen anything about this (except wxGLAttribsBase has an x11Direct field) and I don't find the word xlib in the manual's search function. For Windows like behavior everything is pretty much abstracted so that I didn't encounter any Win32-ese in my work so far. I did notice wxWidgets has numerous features that only work on Windows, that are not documented plainly in the code (various events, etc.)

I assumed the command-line integration was there to parse these (link) standard options that control window placement, size, display (remote) and so on. But I don't know. If not, how do I feed these to Xlib? Is abstract? Or is there Xlib specific classes?

Again, I'm sorry. I don't see any obvious materials to use as a reference. The Gnome Desktop page doesn't really get into these basic things.

https://docs.wxwidgets.org/trunk/plat_gtk_overview.html

I apologize. I feel bad to ask for help here, but I need to figure this out next, and I'm just hoping someone will leave me a present to find when I wake up tomorrow. I did use the forum search function.

This is not so arcane to have its own tutorial is it? https://www.wxwidgets.org/docs/tutorials/

[DavidHart]

Hi,

I've read your question several times and I'm afraid I still don't understand what you're asking; or, more important, why. What is it that you are trying to do? And why do you need to interact with x11 itself to do it?

Meanwhile, a general point that you probably already know, but just in case: the main wxWidgets ports are wxMSW, wxGTK and wxOSX. They wrap the native toolkits; for wxGTK that's gtk+, not x11. There is also a wxX11 port that doesn't depend on gtk+, but it's incomplete, little-used and barely maintained.

Regards,

David

[Mick P.]

I assume X11 is a subset of GTK, since all Linux desktops use x11 protocols. The so-called x11 port is probably unmanaged x11. Which looks pretty crumby if you use it like a desktop, but not so bad on systems that are able to do unmanaged x11 with just a popup window.

If you don't understand the question, then you don't understand Xlib or how Linux GUI works. So I will just have to figure it out myself if nobody knows. The x11Direct field in the GLX canvas demonstrates that wxWidgets has a concept of indirect x11. (Otherwise it would only do direct x11 protocol.)

EDITED: I want to add that I think if wxWidgets were somehow unable to host a remote X client then that would be a well known black eye on it. If it wraps Xlib (directly or indirectly) then it must expose the functionality surely. wxWidgets is really high-level, so I would not be surprised if it has a lot of infrastructure around this. So if I go off trying to do things manually, I might miss something obvious that's already built into wxWidgets.

[Mick P.]

It occurred to me that this likely works through environment-variables. In fact I know it does.

I don't do a lot of Linux development, so I don't know the ins-and-outs well. I do on occasion build/test software with GCC but I've never had to deal much with navigating system settings.

I think the variable that does the display is called DISPLAY and so it would work to set the variable from the command-line.

Sorry if that seems obvious. It was a mental blind-spot for me.

[DavidHart]

The so-called x11 port is probably unmanaged x11. Which looks pretty crumby if you use it like a desktop, but not so bad on systems that are able to do unmanaged x11 with just a popup window.

If it does what you want, that's fine. There's still one known user of wxMotif!

If you don't understand the question, then you don't understand Xlib or how Linux GUI works.

Indeed I'm not knowledgeable about such things, but then this is a wx forum, not an Xlib one.

However I mean "don't understand the question" at a much more basic level: I didn't, and still don't, understand what you are trying to do or why, or even approximately what answer you were hoping for. The topic sounds worrying like an example of an XY problem.

The good thing about wxWidgets is that it wraps the native toolkits, and hides most or all of the implementation details from the programmer. That doesn't mean that you can't access the toolkit direct (my programs do make a few gtk+ calls and, back when I supported wxX11, even x11 ones) but that you should rarely need to.

Are you sure that wx itself can't do ${X}?

[Manolo]

I assume X11 is a subset of GTK, since all Linux desktops use x11 protocols.

No. I think you should read the X11 guide slowly, again and again until you got it. Pay attention to "Display" "Window" "Map window" "Visual" "Color", "Event" and those X11 concepts, which sometimes -but not always- are the same as those used in wx or Windows or whatever.

All Linux distros provide the "X Window System" (shortly "X11"). Some new ones are picking with Wayland, but it isn't mature enough yet.
The X11 is mature, featured, and great, that's why it's still alive after so many years.
That is the "pro". The "cont" is that it's pretty basic. If you want some more complex control (e.g. a drop-down choice selector) you must build it, draw it, handle its events, and some more. That is what GTK+ does; and wxX11 also started to. Try to do it on your own, following any X11 guide, good luck to you. Dealing with text-rendering is another big beast.

Even you succeed with using just X11, let me ask you, do you see you're reinventing the wheel?, is your wheel better that GTK+?

If you want to dig more into X11 then take a look at GTK+ sources, which uses GDK and Pango (and others) for low-level (X11) calls.

wxWidgets uses GTK+ because it's a good "wheel", and so gives the user the native look.

BTW, x11Direct is used at wxGLContextAttrs, not wxGLAttribsBase, not wxGLCanvas.
It is a GLX (OpenGL extension for X11) parameter. It isn't used for "remote control", but for OGL rendering in the client graphics hardware.

[Mick P.]

I'm sorry to generate such lengthy replies. All I meant was wxWidgets is a cross-platform library, so X11 is pretty much synonymous with Linux. I understand what this stuff is. I just don't know wxWidgets well.

I've written Xlib interfacing code in the past. Like right now I have an app that works on Windows. I just want to make it work in a Linux environment. So far that's proving challenging because the GTK component seems to not work at all in most regards, but that's another topic.

Thanks for spilling your guts guys. I appreciate it, even it got nowhere

[ONEEYEMAN]

Hi,
To help you solve this out:

*nix port has 3 different distributions:

-wxX11 (AKA wxUniversal) - very un-maintained port. It usually used as a starting point to create a new port. It uses X11 primitives and internal wxWidgets to draw and operate. It is very rarely patched, unmaintained and there is no automatic builds for it (AFAIK).
- wxGTK: this is the most fully featured port of wxWidgets. It is a wrapper of GTK+ libraries and the most recommended to use. It suppotrs both GTK+2 and GTK+3. Some work is done for GTK+4, but as it is not released yet, it is not available.
- wxQt: this port started very recently and it is not mature enough. It is based on the Qt 5, because only Qt 5 has an appropriate license that wxWidgets can use. At this point it is not recommended.

Now that this is sorted out, lets continue.

What OS you are trying to build it under?
What is the WM you are using? Since you said GTK+ does not work for you I presume you have some kind of GNOME-based one.
What version of GTK+ do you have?

Now you have 2 choices:

- install wxWidgets/wxGTK (depending on the OS) from the official repository
- build it yourself.

If you try to install from the repository pay attention what version of GTK+ it is compiled against. It will also pull in all the necessary dependencies for you and set up the environment to do the development and build the project.

If you decide to build it yourself:

- unpack the source code archive somewhere (I presume it will be ~/wxWidgets)
- cd ~/wxWidgets
- mkdir buildGTK
- cd buildGTK
- ../configure --enable-debug {--with-gtk=3} (by default the build will use GTK+2 libraries. if you want GTK+3 you will have to explicitly specify it)
You can also check different configure options with "../configure --help".
- make

Sit back, relax and enjoy the show.

After it finishes depending on the environment you use:

if you are working from the Terminal all you need to do is go to the directory where you source code is and do:

Code: Select all

g++ -o <my_cute_binary_name> <my_source_file_name>.cpp `wx-config --cxxflags --libs`

That was a backticks around wx-config command (not an apostrophe).

If you are woring with the IDE, create the project as appropriate (for C::B project settings has to match settings you compiled the library with - it is MUST).
Build. Run. Enjoy.

Thank you.

[doublemax]

Just a small correction, unrelated to the original post:

wxX11 (AKA wxUniversal)

wxUniversal is something different, it's not related to wxX11. It's a port that doesn't use any native controls and draws everything itself. You could even build wxUniversal for Windows if you wanted. But it's not actively maintained anymore.

[Mick P.]

For the record, I came across the answer to this question. Although I'm testing this now, and it's not stripping out --sync from the command-line as claimed.

The next line:

gtk_init (&argc, &argv);

calls the function gtk_init(gint *argc, gchar ***argv) which will be called in all GTK applications. This sets up a few things for us such as the default visual and color map and then proceeds to call gdk_init(gint *argc, gchar ***argv). This function initializes the library for use, sets up default signal handlers, and checks the arguments passed to your application on the command line, looking for one of the following:

--gtk-module
--g-fatal-warnings
--gtk-debug
--gtk-no-debug
--gdk-debug
--gdk-no-debug
--display
--sync
--no-xshm
--name
--class

It removes these from the argument list, leaving anything it does not recognize for your application to parse or ignore. This creates a set of standard arguments accepted by all GTK applications.

[s]EDITED: I'm guessing (hoping) wxWidgets uses the --gdk-target=x11 option from this link...[/s]

Strike-through: I guess --gdk-target=x11 might be down to the package system. I'm looking into my options.

--sync. Makes all X requests synchronously. This is a useful option for debugging, but it will slow down the performance considerably. This option is only available if GTK+ has been configured with --gdk-target=x11.

[ONEEYEMAN]

Hi,
You are going low-level on X11/GTK+.

That's why people use wxWidgets - to abstract from using the low-level functions of different toolkits and use whatever is provided by the the toolkit/system.

And that's why wxWidgets on *nix/OSX uses automake && friends for the build - to use whatever provided by the system/toolkit.

Thank you.

[Mick P.]

I'm getting the command-line parsing system in my face again:

Code: Select all

Unknown long option 'sync'
Usage: example [-h] [--verbose]
  -h, --help    show this help message
  --verbose     generate verbose log messages

This asserts/aborts without any indication of what's wrong in Netbeans over GDB. I can only see this output on the command-prompt. I guess on wxGTK it doesn't generate the message-boxes that Windows does. It's not in Netbeans output. And it's call stack is just "???". Really crumby tools. The Windows world is a much better place to do software work.

Here's (https://www.databaseadm.com/article/135 ... +debugging) a possibly ancient discussion involving a mystery ONEEYEMAN on the topic of --sync.

I wonder if I'm supposed to install a developer package for GTK or something

That's why people use wxWidgets - to abstract from using the low-level functions of different toolkits and use whatever is provided by the the toolkit/system.

Well, I'm a serious developer, and besides if you got a problem you can't very well just throw up your hands and walk away. Systems like wxWidgets are for writing less code, but it's by no means high-level enough to solve everything. Nor should it be. It's a system API. So it's super low on the totem-pole. I would say wxWidgets is a base layer. It has the same semantics as a system API. It only abstracts multiple systems (on a good day.)

[Mick P.]

Sit back, relax and enjoy the show.

Sorry, I just noticed this post! I thought this topic was long dead

To answer your question, on Linux like systems there's usually (thankfully) a wxWidgets package handy. So you install that, and you have your dependency covered. Like I've said (possibly in other topics) I'm avoiding using a separate workstation presently, so I have access to versions of Linux that can be used on Windows.

It's actually all very straightforward. If you have to build things yourself things can get very involved and time consuming. So it's not something to do lightly. Ideally if GNU like systems are source oriented they'd give you the sources and let you easily edit them. But they generally aren't set up to make that as straightforward as it could be. I remember in the old days Debian would build everything in front of you. Maybe it still does. But I don't know then if that code was made available as a sandbox or not.

[ONEEYEMAN]

Hi,
Please have a look at the console sample.
IIRC, this is the only sample that gives an exampple on how to properly create and parse the command-line arguments for wxWidgets based applications.

Remember there is a difference between long and short options you pass to the program as an argument. And console program shows you how to do it.

Thank you.

[Mick P.]

Hi,
Please have a look at the console sample.
IIRC, this is the only sample that gives an exampple on how to properly create and parse the command-line arguments for wxWidgets based applications.

Remember there is a difference between long and short options you pass to the program as an argument. And console program shows you how to do it.

Thank you.

Thank you for the tip. I also looked at that OpenGL "pyramid" example, and from it, at least I have some working code to think about using wxWidgets to substitute for GLUT's text rendering capacity, since it has some (thankfully) brief code for that.