Conky: Any plan for wayland?

[zhw2101024]

Is it possible to add support for wayland?

[AquaL1te]

Conky is the last one that needs to add support for Wayland on my desktop. The other one was Redshift, but GNOME created an alternative themselves with Wayland support. Please add Wayland support :)

[q2dg]

Resolving this issue is crucial for Conky's future

[mmuman]

Hi, I started a Conky port to Haiku #433 ... while we don't use Wayland, we don't use X11 either. So we also need the X11 code to be factored out to add proper Haiku GUI support.

This year Haiku is participating into the Google Code-In contest that is just starting, and Ubuntu is participating as well, and since they are now moving to Wayland, they might also be interested. If any dev is willing to help mentor the students, we could propose GCI tasks to clean up the code and add proper Wayland and Haiku support.

It would be the occasion to introduce some GUI platform base class and have the different implementations override it.

[ghost]

I too would very much like Wayland support in Conky.

[ghost]

Any info on wayland support?

[npyl]

Please checkout my issue in conky-for-macOS project: https://github.com/Conky-for-macOS/conky-for-macOS/issues/35 . A similar problem has risen for the macOS port: there is need to ditch XLib and switch to modern APIs such as Metal.

[mmuman]

So yeah, we should start by cleaning up and adding some platform base classes…

[npyl]

@mmuman An idea is porting conky to wayland and then creating a translation layer between Wayland and Metal. This way both macOS and Linux get supported BUT other OSes get left out, eg. BSDs. I think Wayland doesn't run on BSD.

Probably X11 is to stay for BSDs 🤷‍♀️

I don't really know how this is possible though! :D

[mmuman]

@npyl Those kind of layers tend to never be finished because of all the complexity. Also, some things tend to be near impossible to translate between APIs. One such thing is the X11 concept of embedding a window as a child of a window of another application (which conky does to appear on the root window). Haiku for example cannot do it that way, it must use Replicants, where the hosting app kind of dlopen()s the hosted app as a library to find the BView constructor to use, and recreates the objects inside its own process.

I don't see why it couldn't be made properly, many apps are written this way with backends for different GUIs.

BZFlag has support for Windows, macOS and X11, and used to have BeOS support that I wrote, not sure anyone maintained it though. The C++ interface is quite clean IIRC.
NetSurf supports many antique platforms in addition to *nix and Haiku…
It should also be possible to look into toolkits like FLTK for how to do things on various platforms.

[npyl]

@mmuman I see... To be honest I was thinking it was a long-shot myself but was willing to dig into it and make the impossible possible as much as I could.

Now that you reminded me though that there are options such as FLTK I am starting to think we have much more hope.

Our options are FLTK, probably SDL, too?
For porting conky to FLTK one would use the GLUT Compatibility layer?

[mmuman]

Using a toolkit would be an option but again, the usage pattern in conky is quite specific with desktop placement, and I don't think it's properly implemented in most toolkits.

[mmuman]

I mean, putting an app's window on the desktop is a corner case that is probably not supported in most toolkits because it is usually very system-specific, and not used enough to require people to properly implement it.
At least I don't recall seeing a single toolkit mentioning it.
Even Qt even though it mentions "Desktop Widgets" actually uses that name for something else.
I don't know how Plasma widgets work in KDE but it's probably outside Qt. And while it's still possible to do it, one has to resort to "QtX11Extras" to do it because it's very specific.

[mmuman]

Ok, I had a try at cleaning up the mess. I already managed to decouple the HTTP stuff.

[mmuman]

I think I almost got it for X11 in conky.cc except for the event loop, which is quite involved.

[mmuman]

Btw, Haiku is again part of the Google Code-In contest, so if we get the X11 cleanup done we can have someone working on the Haiku port (if I don't do it myself in two nights first).
And possibly other ports under one of the umbrella orgs. For example, the KDE projects could be interested in a Qt port (although it probably wouldn't be as integrated as possible, like displaying on the desktop).

[emersion]

Wayland support for GNOME won't be possible. I think the way to go would be a GNOME Shell extension.

For other compositors, we have a standard called layer-shell. KDE doesn't implement it yet, but is interested in it. wlroots-based compositors and Mir support it. Feel free to ask us questions about porting to Wayland (you can join us in #sway-devel on Freenode).

[mmuman]

Well, supporting GNOME will require some creativity, but not much more than to support Haiku, which will require Tracker (the file manager which handles the desktop) to load ourselves as an add-on (essentially dlopen() to call an instantiation function to return a BView object to add to the hierarchy of widgets on the desktop), and triggering this from the command line.

Because it used to work with X11 which allows any window from any process to be grafted on another one doesn't mean this can't be changed.

[mmuman]

More explicitly: it could as well render a PNG in the process, and have a stub gnome-shell extension refresh it from whatever IPC is used these days.

[emersion]

Yeah sure, but it's more "GNOME support" than "Wayland support" :P