Look to replace GTK and Qt as they go Wayland only.

[VJSLH]

Describe the task

Gtk And Qt are and both have been the main standard for the graphics stack behind desktop environments. However, anyone who has been paying attention to the development direction, Gtk5 will be wayland only and qt5 will likely be fully deprecated around the same time frame.

Given the size of qt5, gtk3 and gtk4, trying to keep them up to date would be a major challenge, and there is no guarantee that new applications will continue to be made using these three. X11 will be in a tough position. So this means that a new tool kit may be required to keep Xlibre viable.

If a new alternative cannot be found, then you may be forced into creating an abstraction layer to run wayland inside of xorg. Not sure which of these two routes will be the right call.

It should be done because

Longevity is important. Without an evolving graphical tool kit to compete with wayland only mainstream options, Xlibre will have considerable difficulty in keeping program developers on board with making programs compatible with Xlibre. I am by no means a developer, but I do know that standards exist for a reason. If those standards cannot be met, then you just don't have enough to bring to the table.

Additional Information (Edited)

Right now, I think the only toolkit that could keep things going would be dart, the main toolkit behind flutter. Fltk is too small, wxwidgets is not as feature rich as gtk, EFL is moving towards wayland. So this is just what I think, this is a long term task that requires some serious considerations right now.

Extra fields

**Post Edit: Late to the conversation but, I think I agree with other solutions then my own. I made my post to get a conversation going on the subject. I acknowledge that I am not the most informed person for the subject. **

• I have checked the existing issues
• I have read the Contributing Guidelines
• I'd like to work on this issue

[magiruuvelvet]

Where did you read that Qt will be dropping X11 support? Qt is a commercial cross-platform framework and supports far more platforms than just Linux, including the BSDs and proprietary UNIXes. They have no incentive to drop X11. Qt will continue to support X11 for the forseeable future. Wayland support still isn't included in the qtbase bundle and is still distributed as a separate module, unlike X11 support, which is part of qtbase.

[VJSLH]

Sorry for not replying sooner, been really busy with my life. So I was under the impression that come Qt7, they would drop x11 support. Maybe I misinterpreted it. Thanks for clarifying.

[callmetango]

Thank you for reporting the issue! It will be moved to X11Libre 1 New Ideas · Discussions · GitHub to be discussed and refined further.

[kkofler]

Instead of coming up with yet another toolkit, it would make a lot more sense to maintain the X11 backends for GTK and Qt if and when they are dropped upstream, because:

1. it is a lot less work than developing a completely new toolkit, also because the code exists and just needs to be forward-ported, and
2. it will make the applications other people write to those toolkits just work, as opposed to only applications developed by XLibre users for the XLibre toolkit working.

Also, the current version of Qt is Qt 6, not Qt 5. Qt 6 still supports X11 (xcb backend).

[kkofler]

E.g., there is my soft fork that restores the old gl rendering backend that supports OpenGL ES 2.0 that should remain a drop-in replacement.

This is how readding the X11 backend should be done too when they remove it upstream, tracking upstream and remaining binary-compatible so everything just works.

[tseli0s]

@tseli0s There are a few forks of gtk here and there already. Not big one, per se, but still, could be great for a starting point

Are there? I'm aware of nocsd and mutter patches but I haven't seen any proper fork.

Though it shouldn't be needed for a long time. GTK 5 is still years away and a simple X11 backend would be super easy to write.

[givememymilk]

Though it shouldn't be needed for a long time. GTK 5 is still years away and a simple X11 backend would be super easy to write.

@tseli0s That's probably why there aren't any big fork yet. After all, GTK3 is still maintained. I suspect that something will happen once GTK officially drops the ball on xorg

Also, apparently chromium isn't even using gtk that much, just for handling some linux stuff but the bulk of the work is on their own internal framework already.

[darkhog]

I don't think it'll be long before GTK itself gets forked if I'm being honest. Their board is just as stubborn and close-minded as the Wayland developers, and with libadwaita already forcing all GNOME apps to look alien on anything non-GNOME, I don't know what could happen. I don't use GHex exactly for this.

Frankly I've toyed with creating a soft fork of libadwaita that goes further than the libadapta and makes every libadwaita app themeable (while being ABI-compatible with libadwaita) regardless of whether the dev wants it to be themeable or not. I'd call it libbanana, but honestly I don't have time for that.

[kkofler]

The big problem with libadapta is that it requires recompiling the application (and even making changes to #include statements). A binary-compatible drop-in replacement would be more effective.

[callmetango]

Thank you for your idea! It will be moved to X11Libre 4 Good Ideas For Later · Discussions · GitHub since it is about something in the future.

[SuperDuperDeou]

As far as I know, KDE Plasma 7 is probably removing the X11 session, but QT7 is not removing the X11 backend, and KDE applications are already cross-platform applications eager to support things outside of the KDE desktop. I'm fairly convinced that the worst that can happen is KDE giving lower priority to X11-specific issues.

Meanwhile, the Gtk5 is planning to drop the X11 backend, but Gtk4 is already not the most popular toolkit, and Gtk5 looks like is going keep going down the same path as Gtk4: becoming more and more the GNOME Toolkit, and this time without luring application developers with the addition of GPU acceleration and an Android backend, because they're already in Gtk4. My guess is that only GNOME and GNOME Circle apps will be switching to it, and, in that case, nothing of value is lost.

Either way, I don't think that forcing application developers to port their stuff to a new toolkit is the answer.

[darkhog]

A GTK fork that supports X11 and which only requires the app developer to recompile against it (being API-compatible) would solve that, I think. Little to no work for a developer and support for X11 can still be done.

[kkofler]

It should not be necessary to recompile most applications. Only if they use Wayland-specific code with compile time #ifdefs (or even unconditionally, so you have to patch the code out). If they use only public GTK APIs, they should not notice at all that a different backend is being used, as long as the GTK fork itself does not introduce binary incompatibilities (which should not be necessary).

[VJSLH]

Sorry if I wasn't paying attention to my original post. Life has been pretty hectic. I am happy to see the direction this conversation has been going. And yes, I agree that a new toolkit would be rather burdensome.

[bugcrazy]

GTK 2 was good, reasonable with patches and GTK 3, which came later is crap, there are two alternatives to GTK, one is fork CTK , another Nuclear to rewrite GTK apps, like Gparted, QT already has its fork Copperspice.