xfconf does not set appearance properties on XScreens correctly

changed the description

Since xfconf is the configuration storage system and not responsible for applying settings, I think that we have to look at xfsettingsd (the Xfce settings daemon).

Probably relevant: https://gitlab.xfce.org/xfce/xfce4-settings/-/blob/master/xfsettingsd/xsettings.c#L1092

added 5. Xfsettingsd label

Thanks for moving and denoting what the culprate may be. Sadly with a lot of this stuff not knowing the inner workings of who passes what and who does what is an issue when trying to report accurately.

So many questions looking at what you've highlighted. I'll stick to what seems to be the most glaring one (outside hard coding a count) shouldn't that loop at least do the first two XScreens? [0.0 and 0.1]

closed

reopened

Maybe this xfwm4 commit could help to resolve the issue: xfwm4@b52c2f5b

I hope so. I may try to replace with the commit and build later. The system says that was authored 3 years ago and never used? Also curious if gdk_display_get_n_screens is querying "screens" as in monitors or defined XScreens since everyone seems to be moving to xrandr setups and ignoring xorg.conf. Perhaps simply due to the goal of moving to a more wayland style config.

Well I tried to build but I'm stuck. Followed the build guide but I'm clearly missing something and sadly some sinus issues have me in that "head full of cotton balls - can't focus" zone.

The linked commit shows how gdk_display_get_n_screens was replaced in xfwm4, so maybe the code could be reused in our case. Regarding the concept of multiple XScreens (nvidia?), I cannot say if it still supported. Perhaps @olivier has some insight on that matter.

This is part of the problem. I know there is a lot of upheaval right now as XOrg is on its way out and Wayland to step in but there have been a lot of changes in how displays are set over the last few years but not a lot said/documented on it. I mean hell the current xorg docs are like from 2012 haha. Even the Ubuntu docs are ancient and often times syntax based on 12.04 release.

Xrandr can configure and define screens across more than one GPU but then if you try to actually use them things go nuts. Hard lockups, crashes, nothing actually draws to screen. Normally you define an XScreen per GPU so things are contained within the feature set of that GPU. I'm not sure how xrandr handles this in the sense of mixed brands or models and I'd like to keep the GPU and it's child screens separate. I spoke with one of the Wayland devs and it sounds (to me) almost like a frame buffer sharing system. Flexible but possibly wasting GPU power and adding a titch of copy latency for the sake of flexability. However I could also be talking out my arse...this week I was set to start a new project and was thrust into trying to find out what the hell is causing all this, kernel, xorg, drivers, DE's... so much outside my normal wheel house and I feel like I've gone over so much it's all just an incoherent blur.

Yeah running Dual nVidia though I just tossed together a Frankenstein AMD + nVidia machine to test with because I got sick of butchering my workstation then having to research or do stuff on the crippled broken install while I try to figure out why everything is borked on newer releases.

I noted Kubuntu 21.04 of all things seems to work and I eventually got an Xubuntu install working but then I can't theme or control things correctly. I'm fairly sure I can deal with the UI problems but staring at that brutal white default theme I can't do. There are a ton of UI / Input issues on top of this where for example you need to right click your desktop to set wallpaper etc but you can't right click on the XScreens outside 0.0. Everything was/is fine in 16.04, was good in 18.04 but then I noticed a few updates and things started to break. Panels went crazy, I had to develop work arounds for bad behaviors. It's like everything is getting worse.

As an example in 18.04 XFCE 4.12 originally I could say run xfconf-query -c xsettings -p /Net/ThemeName -s "myCoolTheme" and everything would be uniform. I noticed after a few updates all the sudden that wasn't working and it would only set the theme on 0.0. So then I had to run DISPLAY=:0.0 xfconf-query -c xsettings -p /Net/ThemeName -s "myCoolTheme" DISPLAY=:0.1 xfconf-query -c xsettings -p /Net/ThemeName -s "myCoolTheme" However the first 0.1 would also set the theme on 0.2 (I figured because they were technically on the same GPU)

I think we can close this. Zaphod mode is not supported anymore by GTK (since 3.10) and there are many other places in Xfce code base where this feature is broken.

closed

added 3. Won't Fix label

mentioned in issue #151 (closed)

marked this issue as related to #151 (closed)

Yeah, making this work is quite a bit harder nowadays with GTK deciding that multi-xscreen doesn't exist anymore, even though people do use it.

I think the easiest way to fix these sorts of issues is to run multiple instances of the apps, one on each screen. So you'd do

DISPLAY=:0.0 xfsettingsd --daemon
DISPLAY=:0.1 xfsettingsd --daemon

As long as the app uses gdk_display_get_default_screen(), I think it should work properly, and the deprecated gdk_screen_get_number() should return the correct information.

However, xfsettingsd will refuse to start if another is running (enforced via owning a dbus name), so that would need to be changed, perhaps by adding a command-line option to relax that requirement.

Feel free to open a feature request if you think it's worth it, but I think it's better to leave this issue closed.

Nah, I think this is such a minority use-case these days that it would likely be up to a user from the community who cares to implement it.

Anyone with accessibility issues will also be a minority use-case...so screw the handicapped? ;p

I've left XFCE (or anything GTK) since opening this post since Gnome is pulling an Apple and seems the community as a whole is cool with that...sad.

Anyone with accessibility issues will also be a minority use-case...so screw the handicapped?

Please don't casually toss around bad-faith arguments. Obviously I don't think all minority use-cases are equivalent; that's absurd.

seems the community as a whole is cool with that

I'm not "cool with it", but we're stuck with what GTK gives us, and we're a small, all-volunteer team. Porting to a different toolkit or spending a bunch of time finding workarounds for things most of our users don't care about isn't something we're ready or able to sign up for.

This is a clear case of "if you need it, patches accepted".

Also if you think "not supporting multi-xscreen" is "pulling an Apple", you should probably re-calibrate your expectations.

xfconf does not set appearance properties on XScreens correctly

Designs

Child items ...

Activity