Over the last few days and weeks or so, a few of the people I follow and interact with on Fedi have been talking about centralising information, tools, applications, and expertise from the Motif (and Xt, Xlib, and X11) ecosystem. There’s a ton of information, resources, and actively maintained applications out there, but it’s all spread out and sometimes difficult to find, and so Thomas Adam – one of the core developers of FVWM, among other things, as well as creator of CoW (FVWM for Wayland, more or less) – has created an effort to centralise all of this.
Motif Central brings together information about Motif, Xt, Xlib and X11: how they fit together, how to program with them, and where to find the manuals, examples and historical material that explain them.
Begin with the X programming stack, build your first Motif application, or explore the programming resources. The history pages describe the libraries’ origins, while the archive guide helps you navigate older documentation.
↫ MotifCentral
There’s been a whole flurry of activity around Motif lately, including the updated and maintained fork we talked about a few weeks ago. The people loosely collaborating on MotifCentral also submitted patches to CDE to make sure it works on the new Motif fork, with the CDE developers setting up a build pipeline for easier testing. Making sure CDE, the classic Motif desktop environment, works well with the maintained Motif fork quite a few people seem to be rallying around is a worthwhile effort.
We’re still quite far from a complete(-ish) modern Motif ecosystem, but it’s very heartwarming to see just how many people are actually still interested in it. My perhaps misguided hope is that we can somehow get to a modernised Motif/CDE desktop environment and applications, making it possible to more easily run a modern Motif environment on Linux and the BSDs.
One may dream.
For me, the most interesting thing here is CoW as I had not seen it before. I had been wondering when somebody would try to create FVWM for Wayland. It would be great if fans of FVWM and its configurability found a home in CoW. Who knows? Maybe somebody will use it to create an NsCDE for Wayland as well.
It is interesting that CoW bills itself as a “window manager” that uses River as its compositor. I will have to keep an eye on the list of River projects. Using River in this way really addresses the “everybody has to write a huge compositor” criticism that Wayland so often gets.
https://codeberg.org/river/wiki/src/branch/main/pages/wm-list.md
I’m glad this is finally happening, I’ve pushing this idea for a while on the mailing list. It was Thomas Adams (of FVWM) who got the ball rolling. Still a lot of work to do, but it looks like its happening.
I created a youtube video “Motif X11 framework dev complete tutorial” https://www.youtube.com/watch?v=9RYq9018fh8
The example application includes the line:
(void)call_data;
in a couple of places and
(void)client_data;
This construction is quite widely used in the Motif site, but I cannot think I have seen it before.
On the face it, it seems to cast call_data to void and ignores the result. This cannot be right, so what does it really do?
It’s an idiom to suppress a compiler warning about an unused parameter. I does nothing except for trick the compiler into thinking the parameter is used.
Nicolas95,
It seems you are right. I appreciate that not everyone wants to see those warnings, but IMHO those who don’t care about unused parameters should instruct the compiler to suppress unused parameter warnings instead. I agree with AlistairH that it is an awkward fix and perhaps more importantly anyone who actually wants to enable the warning and see the these unused parameters won’t be able to anymore.
Thanks for those answers. It is one of these problems that is just about unsearchable (I did try, and try!)
There is more info here: https://stackoverflow.com/questions/3599160/how-can-i-suppress-unused-parameter-warnings-in-c
I think it is a bit off that the Motif people included this rather arcane C use withuot a comment in the code!
In my experience, the world of Linux seems to be mostly accepting of compiler warnings, wheras the world of BSD seems to treat them as unacceptable so they are, effectively, errors. I think I am with BSD on this one, but I still dislike the cludge we have here.
I always found Motif to be ugly as hell and quite user unfriendly. But I’m glad there’s some love for the bugger.
how cool!!
To bad this arrived 30 years late.
MotifCentral does not have everything. You can now build and run Motif apps on Wayland natively. No Xwayland. No X11 protocol. Real Xt intrinsics.
https://github.com/jmalcolm137/xlib-wayland
CDE on Wayland. Fun project.
https://github.com/jmalcolm137/cde-wayland
GTK2 is now a native Wayland GUI Framework.
Is there a GTK2 application holding you back from migrating to Wayland? Not anymore.
In addition to many other GTK2 applications, I have used this to build GIMP 2.10.24 as a native Wayland application. Works brilliantly. No Xwayland. No X11 protocol at all.
https://github.com/jmalcolm137/gtk2-wayland
LeFantome,
It was only a matter of time before application frameworks got ported to native wayland. However it should be noted that wayland is technically feature incomplete in some areas over ideological differences. These missing features can negatively impact GTK2 applications. For example the inability to absolutely position windows can and does break traditional multiwindow interfaces. Admittedly these used to be more prevalent than today, nevertheless barring a shift in attitude it means there are some applications that will never work correctly under wayland.
https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/
I’ve worked on multi-window web UI, and verified it doesn’t work with wayland either. Obviously all the screen sharing programs broke as well. Naturally people debate what should or should not be supported by wayland, however it does represent a real caveat in terms of application compatibility. I would have preferred for wayland to support the missing features but bring about real improvements to application permissions. Alas, it is what it is.
Alman,
> It was only a matter of time before application frameworks got ported to native wayland
GTK3 and GTK4 have worked on Wayland for years. This is the first time I have heard anybody try to run GTK2 on Wayland though. You can probably run plain GTK+ (version 1) on Wayland using xlib-wayland (I have not tried). You can run Xt, Athena, and XForms on xlib-wayland just fine. And CDE/Motif of course.
> there are some applications that will never work correctly under wayland
First off, you and I agree that the technical process and politics around Wayland have been wildly dysfunctional. But I disagree with your statement. You can build a Wayland protocol to do whatever you want. “will never work” is not a technical statement but a political one. I am not accusing you of politics. I am saying that the obstacle is politics. Many of the earlier “will never work” obstacles already already behind us.
> the inability to absolutely position windows
This is a great example. A straight-forward protocol to absolutely position windows was proposed. The GNOME guys vetoed it. Politics. But it could be built. And you could make an “unofficial” one. Even an individual app could do this for themselves. I am not advocating that kind of fragmentation but it is important to frame things correctly.
Session save and restore is working on Wayland now. That allows windows to come back exactly where they were at least.
> break traditional multiwindow interfaces
Much of this has already been addressed. The xx-zones protocol has already ratified for example and addresses many MDI uses cases.
You can always ask the compositor. For example, KWin can precisely position windows. As a user, you can tell Kwin to place a window exactly to or create Window Rules so that it will. As an application, you can use Kwin scripting to specify exact placement. River, as another example, allows you to precisely position windows but the mechanism is different than that used by Kwin.
This highlights the current fragmentation aspect of Wayland. How to do things still, today, depends on what compositor the user is running. Much like the web, I think this will all standardize and homogenize over time. But today there are still many things where each compositor is doing its own thing. Precise window placement is one of those. It is more maturity than anything else. But, of course, that politics thing we mentioned prolongs the immaturity and disunity.
But if you are building a “desktop environment” for example, you can already build these kinds of solutions in Wayland.
> negatively impact GTK2 applications
GTK2 may be one of the least impacted toolkits. The xlib-wayland layer has a few tricks up its sleeve. As all, Xlib apps talk to this layer, it is possible to communicate and coordinate between these applications without going through the compositor. This is also how things like GTK and Motif window hints, clipboards, and drag-and-drop still work between unmodified clients (source code from the 90’s) while also interacting properly with the Wayland equivalents.
> all the screen sharing programs broke as well
X11 programs that this this kind of thing relied on the lack of security. You would have had to break them no matter what. At the very least, you would need to inject some form of user permission granting mechanism. And this is an example of an area that is already well addressed under Wayland. In fact, the mechanism to do something like share a screen is much better specified under Wayland than it ever was under X. And this standardization helps with other “sandboxed” solutions like containers or Flatpak.
LeFantome,
Of course it could be made to work technically. To be fair though I did specifically qualify my statement that it would never work on wayland with “barring a shift in attitude…”. So I think we should be in agreement.
Obviously I know what’s technically possible and I agree with you about that. But I don’t follow why you are agitated by what I said? I don’t think I framed things incorrectly.
I personally tested absolute window positioning via x-wayland about a year ago and it wasn’t working then. In terms of asking developers to sidestep wayland and use compositor specific APIs, yes obviously that can be done, but it seems like we can both agree it is far from ideal.
Though perhaps it came across as nit-picking, I felt this to be a bit overstated since clearly the standard wayland stack has not reached feature parity.
“Is there a GTK2 application holding you back from migrating to Wayland? Not anymore.”
Based on everything else you are saying it really feels like we ought to be in agreement about this.
I actually disagree. Technically they could have added permissions without breaking compatibility more so than x-wayland already did. Screen sharing programs without permission would be broken exactly as they are under x-wayland today. Screen sharing programs with permission could work under x-wayland without changing client source code. As you’ve been saying, it’s not technology that’s the limiting factor, but rather the “politics” and I agree with you that most of wayland’s shortcomings have been political.
Alman,
> I don’t follow why you are agitated by what I said
I am not agitated in the least. I regret if it came off that way.
> Though perhaps it came across as nit-picking
Not at all. You raise a very real and valid point.
> I did specifically qualify my statement
Agreed. And I did notice and appreciate that.
> I don’t think I framed things incorrectly.
Not incorrectly. More a matter of degree. I only responded to “will never work correctly” as, not only do I hear this as a concrete complaint about Wayland all the time, but also because quite a large number of “will never work” claims I have seen people make about Wayland in the past are working perfectly well already. Including very similar ones like session restore or even basic MDI.
The nitpicking is entirely mine. I made the same kinds of complaints about the “RISC-V is Sloooow” article. It is not that it was wrong in absolute terms. It simply gave the wrong impression, especially to readers that wanted to use it as ammo to fuel their already negative views. And, even though that article was only a few months ago, the facts have changed enough since then that its entire premise is no longer valid. “will never work” is a trigger for me I suppose. One person leaving the GNOME project may be enough for “never” to become “soon” as an example in this case.
Alfman,
Ug. And now I have typed your name wrong. I offer my apologies again.
> Only a Sith deals in absolutes
The best thing about this quote is that it is, itself, an absolute.
Again, I am merely expressing my own preference for being careful about the word “never” when dealing with things that, in fact, have the potential to change rapidly and completely (even if the likelihood that they actually will may be small).
Leantome,
We’re even now 🙂
I hear you, but I confess I’m confused why you are saying my sentence was absolute. Consider the assertion “If A then B”. B can eventually be shown to be false without contradicting the assertion; B is conditionally qualified and not absolute. From my perspective the “barring a shift in attitude” changes it from being an absolute statement to a conditional one. N’est-ce pas?
Anyway, I do agree with you about absolute statements and enjoy our banter. My only regret is that we’ll never get to have an in person chat over a couple of beers.
( See what I did there! )