Why mate-session is not used?

[ilya-fedin]

I have some handcrafted Wayland session from the mirco times, I just patched mate-session + mate-settings-daemon to make them running on Wayland (even through Xwayland) so it was enough for me to just launch micro + mate-session, mate-session was handling everything else just like on X11.

diff --git a/mate-session/main.c b/mate-session/main.c
index 96c1092..32a696c 100644
--- a/mate-session/main.c
+++ b/mate-session/main.c
@@ -634,6 +634,7 @@ int main(int argc, char** argv)
    sigaction(SIGPIPE, &sa, 0);

    error = NULL;
+   gdk_set_allowed_backends("x11");
    gtk_init_with_args(&argc, &argv, (char*) _(" - the MATE session manager"), entries, GETTEXT_PACKAGE, &error);

    if (error != NULL)
diff --git a/tools/mate-session-check-accelerated-gles-helper.c b/tools/mate-session-check-accelerated-gles-helper.c
index e6312c6..50eb422 100644
--- a/tools/mate-session-check-accelerated-gles-helper.c
+++ b/tools/mate-session-check-accelerated-gles-helper.c
@@ -217,6 +217,7 @@ main (int argc,
         }

 #ifdef GDK_WINDOWING_X11
+        gdk_set_allowed_backends ("x11");
         char *renderer = get_gles_renderer ();
         if (renderer != NULL) {
                 if (print_renderer)
diff --git a/tools/mate-session-check-accelerated.c b/tools/mate-session-check-accelerated.c
index 6fe6ec4..b1c2374 100644
--- a/tools/mate-session-check-accelerated.c
+++ b/tools/mate-session-check-accelerated.c
@@ -146,6 +146,7 @@ main (int argc, char **argv)
         glong is_accelerated, is_software_rendering;
         GError *gl_error = NULL;

+        gdk_set_allowed_backends ("x11");
         gtk_init (NULL, NULL);

         /* mate-session-check-accelerated gets run before X is started in the wayland

diff --git a/mate-settings-daemon/main.c b/mate-settings-daemon/main.c
index dcff17c..8859381 100644
--- a/mate-settings-daemon/main.c
+++ b/mate-settings-daemon/main.c
@@ -491,6 +491,7 @@ main (int argc, char *argv[])
         }

         mate_settings_profile_start ("opening gtk display");
+        gdk_set_allowed_backends ("x11");
         if (! gtk_init_check (NULL, NULL)) {
                 g_warning ("Unable to initialize GTK+");
                 exit (EXIT_FAILURE);
diff --git a/plugins/mouse/msd-locate-pointer.c b/plugins/mouse/msd-locate-pointer.c
index e384017..8b3ac86 100644
--- a/plugins/mouse/msd-locate-pointer.c
+++ b/plugins/mouse/msd-locate-pointer.c
@@ -578,6 +578,8 @@ set_locate_pointer (void)
 int
 main (int argc, char *argv[])
 {
+  gdk_set_allowed_backends ("x11");
+
   gtk_init (&argc, &argv);

   set_locate_pointer ();

I wonder why some weird shell scripts used here rather than reusing the existing service management infrastructure (mate-session) or systemd?

[mark-herbert42]

It's clear why - because mate-settings-daemon coredumps under wayland. And mate-control-center does not work without mate-settings-daemon. And mate-power-manager dumps. So almost nothing works even from 1.28 release.

So far i have panel (without auto-hide and window grouping and per-workspace window list), menu. menu editor, caja, clock applet(with weather), mixer applet, tray (thanks God it is there finally!!!), and apps - pluma, eom, atril, terminal, calculator. Session management is done by wayfire. Workspace switching also. Settings - in dconf editor. So in fact there is a lot of space for improvement before Mate can be wayland-comaptible. Now it is wayland-usable. Sort of.

[lukefromdc]

I have mate-control-center working, displaying all the capplets though only those that function without depending on mate-settings-daemon (an xsettings manager, keyword "x") actually work. For a mate on wayfire session, be sure you have wcm (wayfire configuration manager) installed, as that's where you change a lot of the settings used by the compositor. You will also for now be stuck w using dconf-editor to change theme, icon theme, or font.

If you turn off ALL the plugins, mate-settings-daemon will run(at least on some setups), but it won't be doing anything.

One piece that would be very useful, but might be beyond my limits to code right now would be a wayland backend for mate-appearance-properties or alternately a from-scratch mate-wayland-appearance-properties capplet (even just a simple dialog that would list installed themes, fonts etc) that would be part of mate-control-center. This would be even more valuable because dconf-editor got so much harder to use when the interface was rewritten.

One complication is this: we cannot easily show .desktop files in the control center just for the wayland or just for the x11 session, because to have a separate session name for ShowOnlyIn would require freedesktop.org to approve a new session name.

There is a proposal in wayfire (or is it in wlroots) to expose more of the workspace code, which would allow having the window list show only the windows on the current workspace if it gets merged and is what I think it is. We have show desktop (via keyboard d and workspace switching by the same keybindings as compiz, but I haven't figured out how to trigger those from a panel applet yet. Help with that would allow making the show desktop and workspace switcher applets work in wayland. Ideally this would leverage wlroots rather than be wayfire-specific so that any wlroots compositor can be used in a custom session.

An interesting thought for the session manager (though well beyond me right now) would be to merge the wayland session into it, but also give it the ability to create a MATE session around any wlroots based compositor found to be installed, using the same or a similar algorithm for each as the scripts I came up with. Also a way to read the autostart files so they can be started or not and controlled from startup applications in the control center.

Note that most of the recent wayland work has been bottomlined by myself with the rest of the team helping out the many times I got stuck. We can always use more help with this. I wasn't able to make sense of a lot of the m-s-m code the way it is divided up, so I wrote the current session simply to create a reasonably easy way to get a wayfire session running with caja, mate-panel, most of the applets etc.

[ilya-fedin]

It's clear why - because mate-settings-daemon coredumps under wayland. And mate-control-center does not work without mate-settings-daemon. And mate-power-manager dumps. So almost nothing works even from 1.28 release.

Can't you add gdk_set_allowed_backends ("x11"); temporarily to them like I did in the patches? This allowed me to run mate-session. The gain is GTK Xwayland applications styling/X11 session management continued to work. I haven't apparently encountered mate-power-manager crashes though...

[mark-herbert42]

There is a lot of things to do. Unfortunately I am abap developer and my c++ skills are not good enough yet to really help. Trying to learn but still long way to go.

[ilya-fedin]

Also a way to read the autostart files so they can be started or not and controlled from startup applications in the control center.

Yeah, that's yet another gain of setting gdk_set_allowed_backends ("x11"); temporarily and using mate-session

[lukefromdc]

I for one do not want to rely on using Xwayland as part of the process for starting or controlling a wayland session. An alternative approach would be to read the files using another program, but also detect whether we are on wayland or X. Again, with my limited skills I have not been able to figure out how these are parsed, if I could I would use them to control startup applications. The control center capplet for this BTW does in fact work under wayland, we just don't use the override files made by it or the .desktop files in /etc/XDG/autostart yet to launch anything under wayland.

Some help figuring out how these are parsed could change this

[ilya-fedin]

Some help figuring out how these are parsed could change this

with GKeyFile, G{,Desktop}AppInfo and https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html I suppose?

[mark-herbert42]

I've backtraced the crashes I have

Mate-power-manager:

0 0x0000000000000004 in ??? ()

1 0x00007f3294500b27 in XkbGetMapChanges () at /usr/lib64/libX11.so.6

2 0x00007f32944fc59f in XKeysymToKeycode () at /usr/lib64/libX11.so.6

3 0x000055eab17be69f in ??? ()

4 0x000055eab17be957 in ??? ()

5 0x00007f32937b298b in g_type_create_instance () at /usr/lib64/libgobject-2.0.so.0

6 0x00007f32937953b0 in ??? () at /usr/lib64/libgobject-2.0.so.0

7 0x00007f3293796a6e in g_object_new_with_properties () at /usr/lib64/libgobject-2.0.so.0

8 0x00007f3293797939 in g_object_new () at /usr/lib64/libgobject-2.0.so.0

9 0x000055eab17bf021 in ??? ()

10 0x000055eab17c0e39 in ??? ()

11 0x00007f32937b298b in g_type_create_instance () at /usr/lib64/libgobject-2.0.so.0

12 0x00007f32937953b0 in ??? () at /usr/lib64/libgobject-2.0.so.0

13 0x00007f3293796a6e in g_object_new_with_properties () at /usr/lib64/libgobject-2.0.so.0

14 0x00007f3293797939 in g_object_new () at /usr/lib64/libgobject-2.0.so.0

15 0x000055eab17b99ab in ??? ()

16 0x00007f32933c5eea in ??? () at /usr/lib64/libc.so.6

17 0x00007f32933c5fa5 in __libc_start_main () at /usr/lib64/libc.so.6

Mate-settings-daemon

0 0x00007f41c266bcaf in XkbGetUpdatedMap () from /usr/lib64/libX11.so.6

[Current thread is 1 (Thread 0x7f41c1657f00 (LWP 265141))] (gdb) bt

0 0x00007f41c266bcaf in XkbGetUpdatedMap () at /usr/lib64/libX11.so.6

1 0x00007f41c266bdbd in XkbGetMap () at /usr/lib64/libX11.so.6

2 0x00007f41c2667d39 in ??? () at /usr/lib64/libX11.so.6

3 0x00007f41c2668558 in XKeysymToKeycode () at /usr/lib64/libX11.so.6

4 0x00007f41c1621d93 in ??? () at /usr/lib64/mate-settings-daemon/libxrandr.so

5 0x00007f41c355598b in g_type_create_instance () at /usr/lib64/libgobject-2.0.so.0

6 0x00007f41c35383b0 in ??? () at /usr/lib64/libgobject-2.0.so.0

7 0x00007f41c3539a6e in g_object_new_with_properties () at /usr/lib64/libgobject-2.0.so.0

8 0x00007f41c353a939 in g_object_new () at /usr/lib64/libgobject-2.0.so.0

9 0x00007f41c1623d91 in msd_xrandr_manager_new () at /usr/lib64/mate-settings-daemon/libxrandr.so

10 0x00007f41c161eea0 in ??? () at /usr/lib64/mate-settings-daemon/libxrandr.so

11 0x00007f41c355598b in g_type_create_instance () at /usr/lib64/libgobject-2.0.so.0

12 0x00007f41c35383b0 in ??? () at /usr/lib64/libgobject-2.0.so.0

13 0x00007f41c3539a6e in g_object_new_with_properties () at /usr/lib64/libgobject-2.0.so.0

14 0x00007f41c353a939 in g_object_new () at /usr/lib64/libgobject-2.0.so.0

15 0x000055d7bfa45bf1 in mate_settings_plugin_info_activate ()

16 0x000055d7bfa448d8 in ??? ()

17 0x00007f41c2949300 in g_slist_foreach () at /usr/lib64/libglib-2.0.so.0

18 0x000055d7bfa44d97 in mate_settings_manager_start ()

19 0x000055d7bfa440b6 in ??? ()

20 0x00007f41c2b3041c in ??? () at /usr/lib64/libgio-2.0.so.0

21 0x00007f41c2b30a78 in ??? () at /usr/lib64/libgio-2.0.so.0

22 0x00007f41c2b2045b in ??? () at /usr/lib64/libgio-2.0.so.0

23 0x00007f41c2923d68 in ??? () at /usr/lib64/libglib-2.0.so.0

24 0x00007f41c2927087 in ??? () at /usr/lib64/libglib-2.0.so.0

25 0x00007f41c292796f in g_main_loop_run () at /usr/lib64/libglib-2.0.so.0

26 0x00007f41c2dfe48d in gtk_main () at /usr/lib64/libgtk-3.so.0

27 0x000055d7bfa43931 in main ()

Seems that XkbGetMap is causing the crashes.

[ilya-fedin]

It would be way better if you rebuilt the package with the debug option in makepkg.conf (assuming Arch) but I guess it tries to call Xlib with a X11 display extracted from the GDK display which is a Wayland display. You can either just set gdk_set_allowed_backends as well or try to examine why it uses xkb and find a replacement (you would a better trace with debug option for that though)

[ilya-fedin]

Personally I use NixOS and I want to try this new Wayland session in a couple of days/weeks, maybe I will get it to work with mate-session just as well as I did it with mirco in the past.

[lukefromdc]

EDIT: responding over email I did not realize two people were talking to oneanother rather than directly to me. Using Debian Unstable here.

I don't have enough understanding of the existing session manager to really work on it. The way it is divided up probablyh makes rational sense or did when it was written over 20 years ago, but it does look like a plateful of spaghetti to me, since I have not done much experimenting with it in the past.

Also I considered it a top priority to minimize anything that could interfere with the x11 session, especially early in my experiments. All of this is limited by my skills, open to testing PRs submitted by others of course. Thus my approach of duplicating the functions of supporting a shutdown from the panel (we'd need wlogout as a dependency to also support logout from the panel, still waiting for feedback on that) and restarting core components if crashed, by a totally separate session startup system, most simply done with those scripts.

Were you able to get mate-settings-daemon to set GTK theme, icon theme, and font for a wayland session via the use of xwayland and apply them to all the GTK apps running under native wayland? If so, that's rather a big deal, and would be the only thing I can think of that would in my mind justify using xwayland as a core part of starting a wayland session. Note that doing so means if xwayland gets a crasher bug, the whole session won't start unless whatever is managing it will timeout on whatever is being started under xwayland and continue with the rest of the session.

Also note that if this does in fact work, we would be using an undocumented feature of GTK that someone else could well decide is a bug and "fix." Time and energy put in that direction would be at risk of being made useless by even a totally unintended/accidental removal of an undocumented GTK behavior

[mark-herbert42]

For me almost nothing works from Mate. mate-settings-daemon crashes instantly. Xwayland is running - does not help, it crahshes trying to set some keyboard operations. I can make it work by deleting almost on pluins - then it starts but do nothing, and control center appears very limited. Gtk theme, fonts etc - impossible to change.

Mate-power-manager - dumps, also on keyboard thing. Mate-session dumps on some other libX11 call. Some applets does not start or does not work - battery applet for example. Sometimes it show % but it is very unstable and I still can not understand why.

I clearfly inderstand what you mean here. Mate is very X11 oriented. A lot of things out of it can not work in wayland, Screensaver - tottally unuseable, and this thing is glued to power manager. Brightness control - also part of PM that need a rework. All the settings regarding input devices. Window decorations etc. And unfortunately my knowledge in desktop programming is to low to do something usefull myself.

[lukefromdc]

Mate-power-manager uses x11 code to manage the screen, in an x11 session you must use x11 code to control input devices. The x11 mate-session handles a lot of Xorg-specific stuff. There are two battery applets: Battstat, which does work on wayland if built in-process, and mate-power-manager's status icon which cannot be made to due to the power manager's dependence on X and the status icon's dependency on Xembed/GtkPlug/GtkSocket. Battstat is enough to at least monitor the battery's state of charge and charging/discharging status.

Window management is separate from the display server in Xorg. The compositor and the window manager are one and the same in wayland. This is as though marco, compiz, IceWM etc all provided the entire xserver themselves in their own code, with differences among them, and Xorg itself was just the protocol describing how it must be done so apps could interact with it.

Main hassles of this are that you must start a new session to change compositors, and at the moment a compositor crash kills the whole session. The KDE folks are trying to fix the latter with a "keep-alive" socket system that could allow recovery from compositor crashes once this matures.

In wayland, input devices are managed by the compositor. Thus, in a wayfire session (including MATE on wayfire) , you use wcm (wayfire configuration manager) to control the keyboard and mouse settings. Right now in MATE under wayland we can show a desktop with icons, and run the file manager with essentially all of its options. We can run the panel with most of its options and applets including an indicator-only tray (cannot use Xembed so no legacy status icons). We can use mate-control-center to control most MATE-specific settings that don't depend on X or an xsettings manager , and use WCM which works like CCSM in compiz to control the compositor settings, including mouse and keyboard. Together those two provide a great deal of control, main missing item here is a theme capplet for wayland for the control center.

We can use almost all of the toplevel apps. We can monitor the battery with the battstat applet. Most GTK3 software can run under Xorg or wayland. Same for GTK4 stuff but that will usually look like crap due to libadwaita clashing with MATE styling. We can run most Xorg-only toplevel apps using xwayland.

At any rate, nobody at MATE is planning to drop x11 support! Rather, the purpose of supporting wayland is to ensure that distros that sunset x11 don't also have to drop MATE.

[mark-herbert42]

I could not manage battstat to work. It does not crash - but does not show anything.

With power-manager mate-power-statistics is looking promising - at least it starts (in Xwayland - but that seems to be doable) and shows the staticstcis of chagarge/discharge and battery details. Also I've looked at brightness control code - seems that it talks to sysfs interface not X, and painting the pop-up with status using gtk calls not X calls. So far for wayland session only this functionality looking possible - battstat applet ( dont know why is is not working for me, maybe some junk in dconf left from old X session ) , mate-power-statistics (if we can "connect" it to some mouse click on battstat could be great), and brightness control wiith the pop-up where shortcuts can be replaced with dbus calls. Now brigtness up/down keys in Wayfire apped to light -U 5/ -A 5. So for mate-wayland the brightness control can possible be conwerted from power-manager function to standalone app bate-backlight with the same fucntion as light + pop up showing the current brightness. Same for volume control - current I've done using amixer, but it also does not show the status/value of current sound volume. That should be easier than trying to adopt tons of useless code and will end up with the same functionality and user experience.

Just in addition - maybe we can have extra mate package - f/e mate-wayland-utilities, where those small utilities can be collected and leave the big daemon-like packages that listen for global hotkeys for Xorg session only.

[mark-herbert42]

Thats exactly my point. Mate is a good stable DE for X and some of its components designed to handle X specific things, that are restricted to compositor in wayland session. So trying to make this components work under wayland wil not help much. And may introduce bugs in X code. So if introduce mate wayland utilities as a separate package to workaround the missing hotkey functions and possibly communicate with compositor.

сб, 23 мар. 2024 г., 11:37 Luke from DC @.***>:

Mate-power-manager uses x11 code to manage the screen, in an x11 session you must use x11 code to control input devices. The x11 mate-session handles a lot of Xorg-specific stuff. There are two battery applets: Battstat, which does work on wayland if built in-process, and mate-power-manager's status icon which cannot be made to due to the power manager's dependence on X and the status icon's dependency on Xembed/GtkPlug/GtkSocket. Battstat is enough to at least monitor the battery's state of charge and charging/discharging status.

Window management is separate from the display server in Xorg. The compositor and the window manager are one and the same in wayland. This is as though marco, compiz, IceWM etc all provided the entire xserver themselves in their own code, with differences among them, and Xorg itself was just the protocol describing how it must be done so apps could interact with it.

Main hassles of this are that you must start a new session to change compositors, and at the moment a compositor crash kills the whole session. The KDE folks are trying to fix the latter with a "keep-alive" socket system that could allow recovery from compositor crashes once this matures.

In wayland, input devices are managed by the compositor. Thus, in a wayfire session (including MATE on wayfire) , you use wcm (wayfire configuration manager) to control the keyboard and mouse settings. Right now in MATE under wayland we can show a desktop with icons, and run the file manager with essentially all of its options. We can run the panel with most of its options and applets including an indicator-only tray (cannot use Xembed so no legacy status icons). We can use mate-control-center to control most MATE-specific settings that don't depend on X or an xsettings manager , and use WCM which works like CCSM in compiz to control the compositor settings, including mouse and keyboard. Together those two provide a great deal of control, main missing item here is a theme capplet for wayland for the control center.

We can use almost all of the toplevel apps. We can monitor the battery with the battstat applet. Most GTK3 software can run under Xorg or wayland. Same for GTK4 stuff but that will usually look like crap due to libadwaita clashing with MATE styling. We can run most Xorg-only toplevel apps using xwayland.

At any rate, nobody at MATE is planning to drop x11 support! Rather, the purpose of supporting wayland is to ensure that distros that sunset x11 don't also have to drop MATE.

— Reply to this email directly, view it on GitHub https://github.com/mate-desktop/mate-wayland-session/issues/16#issuecomment-2016413122, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATEWZ2WM4UV5K2GYOP3NJXDYZU5N7AVCNFSM6AAAAABFCQHT4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGQYTGMJSGI . You are receiving this because you commented.Message ID: @.***>

[ilya-fedin]

Were you able to get mate-settings-daemon to set GTK theme, icon theme, and font for a wayland session via the use of xwayland and apply them to all the GTK apps running under native wayland?

No, only for Xwayland applications. Although it shouldn't be hard to monitor gsettings changes and apply them to GNOME keys (if you don't like the idea of settings both keys right from mate-control-center which is likely to be even simpler)

and would be the only thing I can think of that would in my mind justify using xwayland as a core part of starting a wayland session

IMO it has sense to first achieve a fully working session with the least effort (including using Xwayland where it works as is) and then start decoupling X11 bits for Wayland bits. That's the fastest way with limited efforts and once it works, it can attract more people for harder things.

[mark-herbert42]

I may be wrong but so far I ha ve running Xwayland but can not run some mate things at all. Without decoupling calls to capture global keyboard shortcuts it does not seem possible. With the rest I agree - if it just require Xwayland to paint some fancy widget it does not hurt.

[lukefromdc]

Well, we definately don't want to have a session where theming etc work only for applications running under XWayland. BTW, your mention of this just told me why I've been unable since some January updates to Debian to use my GTK theme in QT applications (via the GTK plugin). I only have those working under xwayland-and for some reason an xwayland update in that time period broke use of nondefault GTK themes.

Your theming idea thus would be useful as a standalone theme setter for xwayland apps only, though ideally it would pick up whatever the user set in the GNOME gsettings so as to ensure Xwayland and wayland apps get the same theme and fonts.

I had blamed QT for this, and switched to the "Plastique" theme for it with a custom palette to keep Adwaita off Kdenlive

[lukefromdc]

Update: rolling back xwayland didn't fix the xwayland theming issue. Most of my applications run under native Wayland, this has basically broken theming QT and tK apps only on my setup.

Until sometime last Fall, Xwayland apps used to pick up the GTK theme being used in Wayland apps, now for some reason they do not. Rolling back xwayland doesn't help

Thus we have this mess: an xsettings manager cannot set the theme for any wayland app, and the theme used in wayland apps is no longer being applied to Xwayland. It now seems that GTK theming under xwayland is entirely broken in the absence of an xsettings manager.

[lukefromdc]

Just found a very simple way to run mate-settings-daemon in a wayland session to control all the xwayland apps: launch it with GDK_BACKEND=x11, and it starts and runs. No code changes required in the daemon itself.

Seems that GTK running under Xwayland ignores everything but an xsettings manager, thus we do in fact need the xsettings manager so long as anything needs Xwayland, meaning essentially forever

Will add GDK_BACKEND=x11 mate-settings-daemon to the session startup script, we already have /usr/libexec and /usr/local/libexec available in it path wise.

[ilya-fedin]

Will add GDK_BACKEND=x11 mate-settings-daemon to the session startup script, we already have /usr/libexec and /usr/local/libexec available in it path wise.

Environment variables leak to child processes and so if you would use it with mate-session, autostarted applications will use X11. gdk_set_allowed_backends is a nice solution affecting only the binary in question.

Well, we definately don't want to have a session where theming etc work only for applications running under XWayland.

That's a good start, IMO. First set gdk_set_allowed_backends to all the crashing binaries and you will already have kind of working system with a little effort. Then you can add handling of GNOME's gsettings keys (which shouldn't be a lot of effort, too) and start to moving the the daemons to XOpenDisplay so GDK's backend no longer matters. Those X11 bits in mate-session and mate-settings-manager are really only Xwayland-relevant mostly, like the X11SM proxy and the XSETTINGS manager. Abandoning those already ready implementations and re-doing XSETTINGS management, application autostart and etc from scratch is just wasting of effort, IMO.

[lukefromdc]

I was writing my reply under time pressure. I did not export the backend for the whole startup script, rather I opened one program only (mate-settings-daemon) with it and from a subshell. The subshell is to handle any crash such as would occur if the user has to stop and restart xwayland or xwayland crashes for any reason.

What I did for https://github.com/mate-desktop/mate-wayland-session/commit/a61421b90450b5479b53b377b4a403603b48993b was add this stanza to the autostart script, note that it only sets the backend for mate-settings-daemon (needed for xwayland apps) and nothing else:

(pgrep "wayfire"
while  true; do
GDK_BACKEND=x11 mate-settings-daemon
pgrep "wayfire"
if [ $? -ne 0  ]; then
       break
fi
done) &

No duplication of effort to worry about, this is already working. The job you are talking of doing exceeds my skills and I am not the one to pursue it. Only way it happens is someone familiar with the old code gets it working. What your ideas did do however was fix a nasty xwayland issue that wasn't present when I first got MATE working in wayfire.

Note that in wayland, any attempt I made to start wayfire from the session instead of the other way around led to the programs trying to open outside not inside the compositor environment. Thus, the compositor's inbuilt autostart function is used to start a single script that manages autostarting and restarting any crashed core component.

If you are able to get a wayfire session running under a modified mate-session-manager and not create issues for the x11 session, I can test it, you could submit it as a PR for mate-session-manager etc. There is also this problem: we just released 1.28 and this would have to wait for 1.30 to be in a stable release. We could however branch 1.28 and bump version to 1.29. If your system became preferred by myself or the rest of the team, this package could be archived in favor of it, but like I said, coding it up is more than I am up to myself.

[lukefromdc]

I wonder why some weird shell scripts used here rather than reusing the existing service management infrastructure (mate-session) or systemd?

We don't want to depend on systemd as some distros don't use it, and I was unable to figure out how the old session manager code works.

[mark-herbert42]

Tried: GDK_BACKEND=X11 /usr/libexec/mate-settings-daemon

Xwayland is up and running - I can easily execute xterm from the same shell and it immediately starts.

But mate-settings-daemon instantly quits with the following:

(mate-settings-daemon:339195): WARNING : 08:59:22.173: Unable to initialize GTK+

So yes - no more crash, but still mate-control-center is unable to do anything usefull like setting a gtk theme. Maybe I do something wrong here

[lukefromdc]

If you set the GTK theme in dconf-editor it should be applied-unless your GTK version is behaving differently than mine does. We are going to need a control center capplet that when wayland is runnjng, sets the theme by changing BOTH the MATE and GNOME gsettings preferences at the same time. Possibly new backend.for mate-appeaeance properries but likely a new cappplet if there are stability issues.

Releasing known crashy code is just begging for a lot of work down the road.

[mark-herbert42]

I've done some pilot testing - not usable for proposing any patches yet because I've simply wiped out some X-related code and deleted some plugins from mate-settings-daemon.But as a result it worked wll for me without any GDK_BACKEND=X11 hack.

So it is doable, just need to spend some time to place some pre-processor directives in order to keep compilation possible without wayland includes, and implement the check for wayland display in wm actions..

The things I've found that some parts of code are duplicated between settings daemod plugin and control-center caplett, so both packages need to be patched.

Also some plugins should be prevented from loading with wayland - they crash with wayland and they do nothing with wayland even if the crash is fixed - I mean all this keyboard/mouse/touchpad/windowmanager/power manager/screen stuff. They should either disappear from control center or call wcm where those settings are controlled.

[lukefromdc]

We now have https://github.com/mate-desktop/caja/pull/1771 for use with GTK_BACKEND=x11 mate-settings-daemon as present in mate-wayland-session since https://github.com/mate-desktop/mate-wayland-session/commit/a61421b90450b5479b53b377b4a403603b48993b

This gives us back the traditional mate-appearance-properties tab for changing the desktop background as in x11 in wayland sessions. When mate-settings-daemon is running and mate-control-center is installed, we use mate-appearance-properties --show-page=background and if not, we show the standalone wayland background changing dialog to support use of caja in wayland but outside of this particular wayland session or with older versions.

Testing appreciated. I've tested with mate-settings daemon running, with it not running, with mate-control-center installed, and with mate-control-center not installed. Worked in all cases.

[lukefromdc]

Tried: GDK_BACKEND=X11 /usr/libexec/mate-settings-daemon

Xwayland is up and running - I can easily execute xterm from the same shell and it immediately starts.

But mate-settings-daemon instantly quits with the following:

(mate-settings-daemon:339195): WARNING : 08:59:22.173: Unable to initialize GTK+

So yes - no more crash, but still mate-control-center is unable to do anything usefull like setting a gtk theme. Maybe I do something wrong here

I had that happen if I stopped m-s-d and tried to restart it from a different terminal for some reason. With the session starting (and restarting it if crashed), I was able to bring up xterm and runpgrep mate-settings-daemon in it and get a PID. Also my theme was applied successfully to xterm in xwayland, had the settings daemon crashed I would have seen adwaita instead as that is GTK's default.

[lukefromdc]

Also, since mate-appearance-properties now runs (will need to limit it to x11 backend to start it from mate-control-center though), to set themes for both wayland and xwayland simultaniously should now be a matter of doing just two things: 1: set x11 as the allowable backed for mate-appearance-properties 2: ensure that all writes to gsettings by it concerning theme, icon theme, or font go to both org/mate and org/gnome settings. This should control them together from one application.

[lukefromdc]

Now working up https://github.com/mate-desktop/mate-control-center/pull/749 which allows using mate-control-center to set the theme for both wayland and xwayland apps by writing to both org/gnome and org/mate gsettings

Like the caja PR, this depend on having xwayland and mate-settings-daemon to work. If m-s-d is not running, m-c-c should show the "cannot start the settings manager" error dialog.

[mark-herbert42]

Tried the things. So far findings

1. Changing appearance themes do nothing. Almost. Changes only the control center theme - the rest follows gnome schema, not mate.
2. settings daemon is not needed for wayland. Removed the bits from control center that calls settings daemon - and no change in behavior.

Looks like Mate settings for wayland session need major rework. The main point is - a lot of functionality is no more under Mate control. It is a part of compositor. Mate has no resources to start own compositor, and probably no need to. We have a lot of ugly semi-working compositors, so the reason to start a new one is zero. Wayfire is the only choice as the rest are tiling.

Use of mate-session for me looks not needed. Because session functionality is handled by comhositor, and thats how wayland works. So keeping session as a shell script looks nice, It is just added to wayfire session config - so no extra daemons, extra tools, CPU/GPU/RAM usage.

I will continue trying to make mate-control-center to work under wayland - but without settings daemon at all. Not sure if I will work - but anyway it is better to try. So far I will try to do following 1) get rid of settings daemon for wayland session 2) hide all control center oprions that do not make any sense in wayland. 3) make control center use gome dconf keys indstead of mate.

My skills in C still need improvement thou - still not ready to make any PR....

[lukefromdc]

I have in fact found a use for mate-settings-daemon in wayland and it's a big one: controlling Xwayland app theming. Without it, these apps now fall back to Adwaita. Something changed outside of MATE, and theming that used to be applied in Xwayland without mate-settings-daemon running is no longer applied.

If Xwayland is not available, we should then return from the start of functions requiring m-s-d though.

[mark-herbert42]

I have in fact found a use for mate-settings-daemon in wayland and it's a big one: controlling Xwayland app theming. Without it, these apps now fall back to Adwaita. Something changed outside of MATE, and theming that used to be applied in Xwayland without mate-settings-daemon running is no longer applied.

Do you have the example of such apps? Just want to try this - my Xwayland apps like cinelerra are not gtk based so do not care about adwaita.

[mark-herbert42]

Ok - I've tried to run gimp 3beta in 2 sessions - with GDK_BACKEND=x11 and GDK_BACKEND=wyalnd.

in gnome settings I have my own macos-like theme. In mate settings - motif-like theme. Mate-settings-daemon is not running - I've deleted the exec file so it can not be pulled.

And - gimp wayland take gnome settings. gimp Xwayland - tale mte settings. No gimp used adwaita, So I doubt that it has something to do with mate-settings daemon, seems that it just looks at different dconf keys,

And changing the theme in mate keys instantly switch gimp-Xwayland into new theme. So settings daemon is not required. But duplicating mate and gnome keys - different story.

[lukefromdc]

GIMP may be a special case, but none of my QT apps will run in native wayland, all of them seem to require xwayland. With the settings daemon running they follow my GTK theme (using that plugin for QT theming). Without it they default to Adwaita or possibly Raleigh(the QT gtk plugin follows the GTK2 theme or at least used to), which clash strongly with my theme. The same is true for git gui, which is a QT app.

If you don't need Xwayland you also don't need the settings daemon. I have yet to find any other way to force any Xwayland app to follow the GTK theme set by MATE or by GNOME.

A way around that would be useful, as there is an issue with scaling: in an x11 session we have to set the scaling, but in a wayland session the compositor handles it. Thus, if we have window scaling=2 in the x11 session, in the wayland session Xwayland apps will get scaled twice. This forces a different setting for x11 and wayland sessions, but this is not as bad as having every QT app coming up in Adwaita or Raleigh if I use the GTK theme plugin.

[lukefromdc]

https://github.com/mate-desktop/caja/pull/1771 and https://github.com/mate-desktop/mate-control-center/pull/749 run mate-appearance-properties in wayland

[mark-herbert42]

Great!!!! I would suggest one more thing - stop activating mate settings daemon and checking if it is running under wayland session

Settings daemon is used mostly to force apply changes over running marco/metacity. Marco/metcity are 100% unisable on wayland - so starting daemon is not needed and the attempt to run/activate/reapply settings over marco/metacity just crash the capplet.

[lukefromdc]

We have to support Xwayland, and that means getting getting Xwayland apps to honor the theme by whatever means.

[lukefromdc]

Examples: Kdenlive and Avidemux, which I use a lot

[lukefromdc]

Changes I made in the capplet should block attemping.to communicate w marco under wayland. I looked for all X-specific code and the capplet works, wirh the compositor treated as an "unsupported window manager" for that purpose. The separate Window management capplet obviously won't work, though redirecting it to WCM in the session might be possible.

There IS one marco item that might be usable in the future: marco theme setting. There is a brand new "external decorator" plugin that reads marco themes but not from gsetting. Very new alpha code now but once stabilized would be great in our session. I am using it now, trying to gently both push and aid development but I don't want to drown a possible single maintainer in feature requests so starting with the bugs on that.

The only crashes I am getting now are in that very new decorator, it takes down the compositor when it crashes, usually on exiting an Xwayland application by the close button. New code, fact that I can now have the compositor follow marco themes at all is stunning so I use it now.

[ilya-fedin]

The main point is - a lot of functionality is no more under Mate control. It is a part of compositor.

Well, theming is not a part of the compositor. GNOME/GTK actively prevents any attempts to move it to compositor, they even made drama of cursor-shape-v1. So theming is still completely client-side (thus under MATE control), especially in GTK world.

Use of mate-session for me looks not needed. Because session functionality is handled by comhositor, and thats how wayland works. So keeping session as a shell script looks nice, It is just added to wayfire session config - so no extra daemons, extra tools, CPU/GPU/RAM usage.

Perhaps you misunderstand the role of mate-session. It has nothing to do with the compositor, its only solely role is to start and monitor things, as there were no systemd back in the time. The only good reason to drop mate-session is going to be managed by systemd and dropping support for systemd-less systems. If you want to support systemd-less systems, you have to use mate-session, as you need something to start, monitor and shutdown the services. Replacing it with shell scripts will just make the session more hacky and buggy.

Settings daemon is used mostly to force apply changes over running marco/metacity. Marco/metcity are 100% unisable on wayland - so starting daemon is not needed and the attempt to run/activate/reapply settings over marco/metacity just crash the capplet.

Settings daemon isn't connected to marco/metacity in any way. It just announces the settings for applications which has no relation to window managing. On Wayland, dconf has such role, so settings daemon is indeed not really needed for a pure Wayland session (unless you want it to synchronize GNOME and MATE settings which might be a good idea, just like kde-gtk-config daemon does for KDE). Still, it's needed for Xwayland.

but none of my QT apps will run in native wayland

I recommend to check that you have the wayland plugin installed (qt5-wayland and qt6-wayland on Arch), XDG_SESSION_TYPE is set to wayland and WAYLAND_DISPLAY is set.

[ilya-fedin]

And changing the theme in mate keys instantly switch gimp-Xwayland into new theme. So settings daemon is not required. But duplicating mate and gnome keys - different story.

This really sounds like you have mate-settings-daemon running in fact. Have you checked by grepping the output of ps aux?

[ilya-fedin]

A way around that would be useful, as there is an issue with scaling: in an x11 session we have to set the scaling, but in a wayland session the compositor handles it. Thus, if we have window scaling=2 in the x11 session, in the wayland session Xwayland apps will get scaled twice.

Checked how gnome-settings-daemon has solved this problem, they have moved from getting the value from dconf to getting the value from the compositor: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/plugins/xsettings/gsd-xsettings-manager.c#L650-687

[ilya-fedin]

Although, does wayfire has the possibility to not to apply compositor scaling on Xwayland just like KDE does? Xwayland is unusable without that IMO.

[lukefromdc]

I haven't seen any option in Wayfire ro disable compositor scaling in Xwayland, an option to do that might be a subject for a PR.

Another way might be in the session itself: Read the gtk window scaling gsettings value and store it in a variable. Reset it to 1, and when the session closes set ir back where it was.

[ilya-fedin]

What's the point of such dance if mate-settings-daemon is completely under your control and you can set whatever value you want for Xwayland applications?

[lukefromdc]

I have all QT stuff for wayland installed but I have never gotten it to work for some reason.

To run the existing mate-session-manager in a wayland session would probably require running it inside the compositor, autostarted by wayfire. In this role it would replace mate-wayland-components.sh but not the setup/startup script for the compositor itself. That could be another binary parr of the session I suppose.

Original goal with the session was to quickly get a session set up that would let people wanting to use MATE on wayfire run it from SDDM or whatever they have. I did it within my skills for a from-scratch program.

Again, I will gladly test a modified mate-settings-manager that can do this, but be aware right after the 1.28 release we cannot touch the x11 session unless we bump version or move that work to a dev-wayland branch.

There have been real issues getting enough people testing anything not part of a release picked up by distros, that slows everything down and means a torrent of "new" bugs wirh every new release.

For the binary to be lighter we would need to avoid making a bunch of system() calls too

[lukefromdc]

One more option for scaling might be possibe: have mate-settings-daemon detect Xwayland and disable it in such cases.

[mark-herbert42]

Examples: Kdenlive and Avidemux, which I use a lot

I also use Avidemux a lot - so will give a try. Yes - it seems that settings daemon is required - it is just the ugly gtk3 code which has hardcoded reading of org.gnome keys in wayland backend, but completely different configuration code in x11.