Any plan for wayland?

[zhw2101024]

Is it possible to add support for wayland?

[kees-closed]

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: Conky-for-macOS#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

[mmuman]

Since #664 has been merged, we're not far from being able to support other GUI frameworks. There are still some strings attached to X11 here and there, like settings objects, that we should discuss how to handle. Do we want to fake them on other platforms, or do we want to have separate ones…

[npyl]

I took a stub at starting a METAL port, and I realised that there are some variables like out_to_x for example that are still tied to X11 (as you said).

Some of them though, like colours seem platform neutral. Maybe some should go in display-output.hh??

I will try to write down the variables that were needed in the first case later today!

[mmuman]

Some of them though, like colours seem platform neutral. Maybe some should go in display-output.hh??

I was thinking those were too GUI-specific but they could also be used by ncurses, so why not.

[mmuman]

I had a try at an SDL 1.2 backend (2.x is not available on older OSes). For now it opens a window. Still building with X11 too so it didn't need cleanup yet.

[mmuman]

And we have some text…

[saltasatelites]

Have you taken a look to nwg-wrapper? Maybe could help; allows show text on the screen and show image too. But the developer has said he has no interest to make a fork on conky to wayland...

[Iss-in]

i would say eww is a much better replacement

[github-actions]

This issue is stale because it has been open 365 days with no activity. Remove stale label or comment, or this issue will be closed in 30 days.

[Soundtoxin]

Bump.

[Galicarnax]

I don't understand why the repo title now mentions Wayland, as if Conky is as usable in Wayland as in X now. I've spent some time now trying to get rid of XWayland and re-configure conky to use with pure Wayland (swaywm), but failed miserably. ${image ...} does not work (Imlib2 complains about some NULL params), graphs are not drawn, even just using ${stippled_hr} prevents further output. Was trying that with the latest conky version, for sure.

Please note, I'm not complaining that Wayland support is still poor. My point is that saying "for X, Wayland, and other things, too" in the title might be misleading. It's just too early for that. Or am I the only one with these kind of issues in Wayland?

[ben2talk]

conky.config = {
-- Conky settings
	background = true,
	update_interval = 30,
	double_buffer = true,
	no_buffers = true,

-- Window specifications
	alignment = 'br',
	gap_x = 20,
	gap_y = 42,
	
	own_window = true,
	own_window_transparent = true,
	own_window_argb_visual = true,
	own_window_argb_value = 70,
	own_window_hints = 'undecorated,below,sticky,skip_taskbar,skip_pager',
	own_window_class = 'conky',

-- Text
	use_xft = true,
	xftalpha = 0.1,
	font = 'Arial Rounded MT bold :size=10',
	font = 'firacode nerd font :bold:size=9',

	draw_shades = true,
	default_color = '#666666',
};

conky.text = [[${fs_bar 5,55 /} Evo ${goto 100}${fs_free /}${if_match ${fs_used_perc}>=75}${color lightsalmon}${endif}${if_match ${fs_used_perc}>=85}${color red}${endif}$color
${if_existing /dev/sdd}${fs_bar 5,55 /mnt/T3}${font }${color } T3 ${goto 100}${fs_free /mnt/T3} ${if_match ${fs_used_perc /mnt/T3}>=85}${color salmon}${if_match ${fs_used_perc}>=85}${color red}${endif}${endif}$color
${if_existing /dev/sdc}${fs_bar 5,55 /mnt/T4}${font }${color } T4 ${goto 100}${fs_free /mnt/T4} ${if_match ${fs_used_perc /mnt/T4}>=85}${color salmon}${endif}${if_match ${fs_used_perc}>=95}${color red}${endif}$color
${if_existing /dev/sdd}${fs_bar 5,55 /mnt/W2}${font }${color } W2 ${goto 100}${fs_free /mnt/W2} ${if_match ${fs_used_perc /mnt/W2}>=85}${color salmon}${endif}${if_match ${fs_used_perc}>=95}${color red}${endif}$color]];

If set for Wayland, the GoTo's and 'Align' lines are broken.
If set for X, now on Plasma 6, then Conky windows are presented as windows in Overview and Grid.

Is there any future here? Or is Conky the last (and ONLY) existing app of it's kind?

[brndnmtthws]

Please note, I'm not complaining that Wayland support is still poor. My point is that saying "for X, Wayland, and other things, too" in the title might be misleading. It's just too early for that. Or am I the only one with these kind of issues in Wayland?

This is fair. I updated the description accordingly:

And the README in #1790.

The reality is that it's very hard to support all the different things while not breaking existing functionality. I personally have to focus my life energy on doing things that allow me to pay rent and buy food, and it's quite time consuming to debug these issues.

I should also mention that I really appreciate all the help and contributions from everyone with this project, and I know that it has its deficiencies, but at the very least I will never use it as a way to extract money from people.

[Caellian]

I created a milestone for Wayland.

Basic support is here thanks to previous contributors, there's a lot of work ahead, but I'm closing this issue as resolved because any support exists, this issue is quite old, and pinging all 17 participants for followup questions might not be the best idea.

Future wanderers, take a look at the milestone to check if your specific issue is already tracked or create a new one.

[Dreamsorcerer]

For those installing through downstream packages, from which version is Wayland supported in?

[Dreamsorcerer]

Looking through the wiki, I've just seen that this won't work with GNOME yet, so probably doesn't matter to me.
I'd note that the link in the wiki is labelled as 'WON'T FIX' (https://github.com/brndnmtthws/conky/wiki/Window-Configuration#wayland), but reading the details it appears that they are expecting GNOME Shell to implement the extension instead of Mutter, so it may work in future (appears something was merged last week as the first step to this being possible).

[Caellian]

@Dreamsorcerer I can't find a single issue where they said anything other than:

No there is not, we don't intend to support third party panels, lock screens, notification UI's etc.

Such a thing could be implemented by either Mutter or GNOME Shell. But they've been asked about this A LOT (through 4/5 different issues, spanning 5 years) and they consistently answer that they don't support 3rd party widgets and that such things need to be implemented through their plugin system. I'm sure if they're adding "first steps" they're meant for their plugin system.

If you don't want a Windows-esque interface, don't use GNOME. If support gets added, it will work with conky without any modifications. If some other layer protocol gets added suggested, we can (probably) easily support it as well.

EDIT: Dreamsorcerer referenced this issue for Mutter (as he later linked to in a discussion), which allows dependents to implement their own protocols. This doesn't meant GNOME will and it's likely they'll create their own layer protocol.