status of mate-power-manager applet

[ericmarceau-rogers]

The following extract from the Notice statement is, for me confusing:

Note that the battery applet can be used in Wayland, which is important because mate-power-manager uses a lot of X11 specific code and does not work under Wayland at this time.

Does the mate-power-manager work correctly under Wayland: Yes or No?

I ask because, although being a code repository in its own right, it is not itemized as a tracked item on this page.

Also, for full transparency and communicating as clearly as possible to the community, the list on this last page should cover the full range of repositories/code which need to be migrated, along with the status thereof, not just a select few.

Thank you ... for all the Great Work that is being done on this most desirable of desktops!

[lukefromdc]

Mate-power-manager uses x11 specific code for almost everything. For it to work in wayland would be a total rewrite that is beyond me.

[mark-herbert42]

mate power manager use mate screensaver which is totally X11 , and it uses X11 dpms.
Also mate power manager is used as media key processing tool - if yo press voulme keys or brightness keys on your laptop is power manager that does this fancy OSD progress dialogs and control brightness and volume. And that's also X11 exclusive - as the hotkeys are controlled only by compositor.

So for me it looks better to drop this completely for wayland - and use battery applet from mate apples instead. And all the functions mentioned above should be handled by compositor., wayfire + some simple tools can do it pretty well. Or - if it looks more desirable to have this work done by mate component it looks more logical to have this done not as daemon, but as wayfire plugin. of course you can keep it as daemon, but in this case the need is to integrate the dbus calls to replace hotkeys. So you map a brightness up key to call the dbus , dbus will signal mate-power-daemon, daemon do the work. But is looks very inefficient - execute dbus command, catch dbus signal - instead of doing all the things within compositor plugin fast and easy.

[lukefromdc]

In wayland mate-power-manager is indeed not used, writing a wayland replacement is beyond me. Thankfully the battstat applet works fine with wayland when applets are built in-process. Note that we have no plans whatsoever to drop x11 support! Wayland support is insurance and future-proofing due to the possibiity of distros first not installing x11 by default, then later dropping x11 themselves.

As long as you can install x11 you should be able to use the MATE default x11 session

[mark-herbert42]

the issue is - distros going to drop x11 support toolkits going to drop x11 suport, productive software is going to drop or limit x11 support. So x11 only DE's will be dead together with x11. Not today and I believe not within the nearest 5 years, but that is the direction where Linux is going.

One of the promising technologies - Wayback, have not tried it but maybe it will be possible to run Mate X11 and allow apps like Firefox and MPV run in wayland native mode

And one more thing coming to my mind. It is very hard to achieve X11 + wayland support within one app. Alot of #ifdef's in the code , a lot of detections IsWaylandDisplay , IsX11Display within the code. A lot of fucntions that can not be ported to Wayland (like power-manager or eyes applet) And many functions that can be implemented require absolutely different approach. So while trying to improve-implement Wayalnd - have good chance to introduce regression to X. So why not to create replacement components as wayland-only software. Power-manager - as a wayfire plugin so it has access to whatever it requires, becaue wayland does not allow a process rather than compositor to access some fuctions. Panel toplevel - there is a huge pile of code that is X11 only - it runs under wayland but in fact does nothing. You can not position your panel in wayland like you do it in X, and if I try to use wayland-specific positioning code in the place where X does it (using gtk-shell , anchors and offsets - it works) - the panel starts eating cpu as mad. Current implementation of limited wayland support in panel seems not to be in favor of wayland. X11 functions are in postion of masters of the universe - they have access to all private data and methods of panel, while wayland functions are separated into wayland backend and for the access to private data have to act as external software calling method functions to read data like width, height, x, y and store them in temporary vars instead of simply reading it as X backend does.

[lukefromdc]

I have never experimented with Wayback. In developing the wayland support, I tried to avoid changes to x11-specific code as much as possible.

As for writing new Wayland-specific apps from scratch, that is beyond my programming experience and probably beyond my capability. If someone else wants to do so and they intergrate well into MATE I will be happy to test them of course