Why mate-session is not used? #16
Comments
|
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. |
|
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 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. |
Can't you add |
|
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. |
Yeah, that's yet another gain of setting |
|
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. 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? |
|
I've backtraced the crashes I have Mate-power-manager: Mate-settings-daemon Seems that XkbGetMap is causing the crashes. |
|
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) |
|
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. |
|
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
|
|
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. |
|
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. 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. |
|
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. |
|
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
<#16 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATEWZ2WM4UV5K2GYOP3NJXDYZU5N7AVCNFSM6AAAAABFCQHT4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGQYTGMJSGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
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)
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. |
|
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. |
|
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
|
|
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.
|
|
Just found a very simple way to run mate-settings-daemon in a wayland session to control all the xwayland apps: 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 |
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.
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. |
|
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 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. |
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. |
|
Tried: 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 |
|
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.
|
|
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. |
|
We now have 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 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. |
I had that happen if I stopped m-s-d and tried to restart it from a different terminal for some reason. |
|
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: |
|
Now working up 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. |
|
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.
|
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.
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 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.
I recommend to check that you have the wayland plugin installed (qt5-wayland and qt6-wayland on Arch), |
This really sounds like you have mate-settings-daemon running in fact. Have you checked by grepping the output of |
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 |
|
Although, does wayfire has the possibility to not to apply compositor scaling on Xwayland just like KDE does? Xwayland is unusable without that IMO. |
|
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.
|
|
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? |
|
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
|
|
One more option for scaling might be possibe: have mate-settings-daemon detect Xwayland and disable it in such cases.
|
I also use Avidemux a lot - so will give a try. |
|
If we disable these plugins in |
|
And it you do, it can no longer control theming etc in xwayland apps, which is what we now use it for in the wayland session
|
|
What I am thinking of here - those plugins are absolutely useless for wayland, is it possible to force just those plugins to use X11 backend. I know such tricks are done in Kicad and Prusaslicer - those apps are unusable under Wayland. It starts - but you can not grab a chip on PCB layout or drag something on 3d model. So the developers simply hardcoded switch to xwayland within the program itself - so no matter what your environment variables are Kicad will always run in Xwayland mode and the only way to try in (useless but....) native mode is to patch the source and rebuild. And why not to follow this approach in Mate - if we have the apps that are not needed at all for Wayland native and only sitting here for compatibility with Xwayland apps - why not make them hardcode forced to X11 mode? |
That's something I suggested somewhere in my first messages here. The answer was
Although it's one-line change adding |
|
This entire situation - of throwing out a lot of already written code and crafting replacements via hacky bash scripts - makes me really sad. |
|
Well - I would look at this from different angle. When we use Wayland a lot of things are controlled by compositor. So by the nature of this process a lot of code becomes useless. Or - if you want too keep it - you have to take care of your own compositor and integrate it with the code you have. With the current resources MATE project has it is absolutely dead end, and I really like the approach to use Wayfire. So from here things like window frame design , input devices, output devices, virtual desktop size, gectures etc becomes the part of composer. Even for Xwayland apps you can not control this. And making those applets to control Wayfire - possible, but does it worth it? I bet not at all, and the best solution would be - disable useless code when run in wayland (like mouse speed control, media kwys or keyboard layout - it is a composer thing now), force some applets to run in X11 (the ones needed to Xwayland apps only but still having effect - do not know thew by the way but believe there are some). And just add WCM (wayfire config manager) launcher as an applet to Mate control panel to handle the things we removed. Because in fact it is confusing - well I am changing the mouse speed in X11 applet but it has no effect - as I need to do it in WCM instread. SO what for I need the X11 code here? From the other hand Mate is a perfect X11 desktop, and X11 is here and is working well and will be for a long time. And keeping both display systems in same binaries looks a bit complex - always detect at run time are we wayland or are we X now, what to do how to go. And that makes code very complex, an gives more space for bugs. so maybe it worth to do a fork for some of the components where this X or Wayland switching becomes extremely complex and dangerous. |
If it was useless, you wouldn't recreate it in bash. But you do and the result is of less quality than mate-session as it, for instance, supervises the launched processes, while those bash scripts don't. mate-session also launches autostart applications and provides various d-bus APIs consumed by other applications. mate-session is kind of mini-systemd which compositor couldn't replace. mate-settings-daemon keeps various settings in sync, reacting to dconf settings changes and the effective state to re-enforce them. Those components make the system feel robust. Without them, the system feels half-baked. |
|
Perhaps when MSD starts, it can determine whether it is currently running in a wayland environment, and if so, not load those X-related plugins. |
|
A better idea is to make it always use X11 to style Xwayland apps |
|
In the current session, we have The compositor controls theming in wayland, but does not control theming in Xwayland. In x11 including Xwayland that is the settings daemon's job, but in native wayland it is the compositor's job. This is one of the architectural differences between x11 and wayland. |
Compositors don't control theming. All they do is compositing. |
|
Actually they do: wayfire and many other compositors read the GNOME gsettings values for things like GTK theming, then pass that to GTK. This is why I had to modify the code for mate-appearance-properties to write to both MATE and GNOME gsettings keys when running in wayland. |
There is no reason to do that on a per-plugin basis rather than globally when the settings daemon is called, as we do not. Do note that I have limited time and energy, some other team members have helped a lot with getting past some tough spots on this experimental wayland support but I've done most of the heavy lifting myself. I don't have anything like the resources a paid team hired to port MATE to wayland would have, not even close. |
You're wrong here. Wayfire doesn't read anything from GNOME. You had to modify mate-appearance-properties because GTK itself reads GNOME keys. That is, toolkit controls theming, not compositor. |
|
I thought the compositors were reading this. If this is GTK directly under wayland, than no compositor can fix this and if we wanted MATE's gsettings keys to be used it's GTK we'd have to fork, which we don't have the resources for. Since GNOME doesn't like theming and has ported gnome-shell etc to libadwaita, it is likely that later GTK4 versions or GTK5 might not read any GNOME keys for theme etc, and these could be deprecated. They cannot so easily (within the de facto rules that is) remove them from GTK3, but this is one more reason we are not porting to GTK4 at all. |
|
Compositor controls only server-side window decorations. The rest of the theming is a bigger problem - in Linux you can not even imagine the structure of using just one toolkit for all like you always have in Windows or MacOS, You for sure will have gtk3 apps as you are in MATE desktop, most likely qt5/qt6 also will be there, maybe some gtk2 and apps using own free-coded toolkits like Blender. With the session code - the story is different from other point. In X you can from any software get the list of running apps, window locations and sizes. And when your session is restarted mate-session can save the state of your previous session and restart all the windows in same size and location as you used to have. X allows that but not Wayland. In Wayland only compositor knows what is running, what windows are opened , where on screen located and what is the size. And that is not the error or we do not know how to do it - it is a part of Wayland security concept. So here if we want to repeat the X functionality with wayland MATE-session have to communicate with compositor. And - this is not standard protocol, this is something every compositor do its own way or do not do at all, So if you want to re-create the functionality of MATe-session manager you need to program the communication protocol for every compositor that can be used. Or say MATE works only with Wayfire and that's it. Or create own compositor like Gnome does (hate the idea by the way - gnome compositor is ugly). Too much effort for the team that have so limited time and energy - as I understand Mate is a true community project that people develop free of charge in their free time. And here the simple shell script is not giving less functionality than a C code potentially can because it just launch the initial session, just launch the apps. One more idea that came to my mind - fixing mate-session in impossible because of wayland limitation. But in is possible to create Wayfire plugin that will do the same. It will run in compositor space and can get the info about apps and window locations and sizes directly, save them, restart them at exit and have the graphical config tool. Unfortunately it is too big for me to handle... |
|
If more folks want to work on Wayland we can sure use more team members. A job too big for one person could be broken down into smaller units, multithreaded and parallelized so to speak, |
What? Its main job (launching and supervising session-critical processes) is completely orthogonal to X11/Wayland. It doesn't need any communication to compositor and so there's nothing impossible.
It is. The bash script won't supervise processes it starts. It also won't implement the xdg autostart spec (i don't imagine correct implementation in bash) what mate-session already does for free. |
|
if we give up save-restore session then it can be done I guess. But also keep in mind that not much of components left. Power-manager gone. Screensaver-screenlocker gone. Window-manager gone. Out-of-process applets gone - so you will have just the panel process. Running caja to paint desktop wallpaper - not sure if it is needed, I've ditched this myself and use Wayfire background tool as a lighter solution. So as a user I see no much drawback of using shell script - everything I need works well. But there are the issues that are annoying for me as a user - and I guess I am not unique here. The big issue with control panel and themes is gone now - but there are some more
If I was a mate developer with skills and time I would focus on those issues first trying to make the desktop more usable first, and leave session launcher after those. |
|
None of that is stuff I can easily fix. I was able to get MATE to mostly run on Wayland, but am not up to soloing all of this |
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.
I wonder why some weird shell scripts used here rather than reusing the existing service management infrastructure (mate-session) or systemd?
The text was updated successfully, but these errors were encountered: