mate-desktop/mate-control-center

Icon theme is not updated in org.gnome.desktop.interface.icon-theme key after the wayland-compatibility patches landed.

Opened this issue · 11 comments

The point is that gtk3 for wayland has a hadcode to read the config exclusively from org.gnome.desktop.interface ignoring all other settings, so the patch series were merged to duplicate some mate,intrface settings into gnome.desktop.interface. The theme and font settings are duplicated as a charm - but when the icon theme changed only mate dconf is updated.

When I change the teme as a whole - not just modifying the icon set - everything works ok, icon theme also get updated.

Is THAT why editing a theme has been such a problem? I have been trying to find that, it means there is another place where mate gsettings values are updated that I missed.

yes - seems that the case. I can not save the new theme with the changed icon set. I can apply old ones - but trying to change the theme in wayand keeps the icons and cursor unchanged. I can change it in dconf editor - no problem, it works. Bit the control center only change the org.mate keys. So far I am lost and have no idea what to do.

Found it: try
#757
which fixes this in my testing

757 works fine. But some new findings

monospaces-font-name (only this one - other 3 fonts are updated ok)
cursor-theme
cursor-size

not updated in gnome schema.

maybe it is buggy - but manually adding it in dconf does work. I had issues with it using Xorg/compiz bcz compiz has its own cursor settings and pointers were switching between compiz settings and mate settings depending over which window the pointer was hoovering. But in wayfire it seems that cursor is strictly obeying org.gnome key.

Latest force-push at
https://github.com/mate-desktop/mate-control-center/compare/b29a2e863965cea9f161221835b652758c95f80b..fc7ec90d9a28031334ccb4c11f16a086e1ed232a
should allow you to set the cursor theme etc. I think I have it hardcoded somewhere since a decade ago to kill an unwanted default that was forced by some kind of bug of that era, thus on my system I cannot test the cursor changes.

When I initially wrote the first round of wayland theming support, I tried to include the monospace fonts with the others, but got problems I wasn't able to find at that time with changing the monospace font also changing one of the other fonts. I will have to revisit that and try to get it to work cleanly. The code for that is commented out but otherwise present, along with a comment about the monospace font only applying cleanly if set only for MATE not GNOME. No idea why it acted like that so far.

See
#757 (comment)
it turns out that wayfire does not read cursor size or theme from gsettings but rather from its own .ini config file.
Some other compositors can read cursor size and theme from gsettings though, this explains why I could only testing changing them by keeping dconf-editor open to the relevent keys while making cursor changes from mate-appearance-properties

seems like gtk does not care about compositor settings and over gtk windows org.gnome cursor will be no matter what you set in compositor. Same story with compiz/Xorg

So there is a need to create mechanism to translate some Mate settings to Wayfire. I am not a good developer unfortunately - can do some POC dirty hacks and that's all I can so far. Anyway started conversation here

WayfireWM/wayfire#2373

Wayfire developers confirmed that IPC mechanism they introduced allows to change all the settings like cursor theme or dmps timeout. So with that it is possible to create something (wayfire plugin or extra code in mate-settings-daemon) that will synchronize certain settings between the DE and compositor.

With #757 merged to master (1.29 series) the icon theme problems in custom theme setting should be all the way fixed, and cursor theming fixed in GTK apps which is as far as we can easily change that with the existing wayfire code.

OK to close this? We can open a new issue about cursor theming in non-gtk applications but that would be one to open in wayfire rather than here