conky
conky copied to clipboard
brndnmtthws
Any plan for wayland?
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 :)
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.
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.
So yeah, we should start by cleaning up and adding some platform base classes…
@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
@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.
@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?
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.
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.
Ok, I had a try at cleaning up the mess. I already managed to decouple the HTTP stuff.
I think I almost got it for X11 in conky.cc except for the event loop, which is quite involved.
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).
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).
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.
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.
Note: Wayland has replaced X as the default in Ubuntu 21.04. That version of Ubuntu was released on 22 April 2021. (Here is the release announcement.)
Well I still intend to get this work merged someday, but each time I look at it I have to rebase over and spend hours integrating changes that happened since then to avoid regressions, so it's not fun.
It should not be too complicated! Conky works with Wayland on my Virtualbox VMs and it succeeds the second time on HW too. I created a bug report for Ubuntu https://bugs.launchpad.net/bugs/1947185 I have a working bypass. I have a script that starts conky twice, the first time starting conky fails, but it waits a second and the second time it succeeds. The reporting of conky after the starts is different. On the real hardware it starts the first time as: conky: desktop window (b4) is root window On the VMs and on the real hardware after the second time it starts as: conky: desktop window (800014) is subwindow of root window (b4)
conky does work on wayland, atleast on gnome without any problem, it is the wlr-layer-shell protocol that it's currently incompatible with
So, I'll have a try at rebasing #664 once again, hopefully for the last time, so we can get this merged. Looking at pending PRs only #955 touches the same files, and just for a few lines so it shouldn't be too hard to port that over to the new code. So this means we have a good window to get this in.
This time I'm going through every newer commit on main, and rebasing over each I think could conflict… Oh the joy or fixing conflicts a second time because of the clang-format pass… Oh dear, another pass again adding a space it removed before :-( What now… yet another one… why isn't clang-format stable on these and keeps changing its mind? It's really painful to work over those…
-#else /* BUILD_X11 */
+#else /* BUILD_X11 */
And the Xft scaling I have to backport as well… each time risking more copy-pasting error…
Hello, I think conky project should pause any non-critical PRs getting merged until the GUI backend is fully mergeable. This doesn't have to mean fully operational; just fully mergeable.
This is just a suggestion! :)
@brndnmtthws
It'd be great to have testers for it, I only tested some configs I have around here…
I can test, Currently having issues with conky showing off screen on wayland, is fine on X. At least I can see if that issue is fixed.
Will pull and build after I have walked my dog
Well since it's just the X11 code that's been moved around it won't be fixed, but it shouldn't introduce any regression. I'll leave you to implement the Wayland backend then :-D
Not really, I wanted to do some more cleanups on #664 but it should be mergeable already mostly. I didn't get many returns on it, anyone ever tried it?