Overview of Issues with // Potential Changes to GNOME-related Garuda Stuff

Issues & Assistance GNOME
1

I'd like to preface this by saying I'll be putting in my own merge requests in the coming days as suggested by @dr460nf1r3 here and this is a pared-down version of the ~2000 word document I put together in the |redacted| hours of research I've done in the time since that original post went up. @librewish may also be interested in this based on recent contributions to the repos mentioned.

The Issues At Hand

Overall, the Garuda GNOME edition has a handful of quirks/oddities/issues brought about in the way garuda-gnome-settings and garuda-common-setting are configured, as well as the implementation of gdmwayland-on.sh in garuda-assistant. It's possible that garuda-bash-config and somewhere else a handful of GNOME files are getting configured(?) are tangentially related here. What follows is mostly a thoroughly-updated re-hash of my previous post

  1. The most primary breakage is that of Qt-based apps failing to launch, GNOME extensions being disabled, and GNOME user application themes failing to apply when logging back in under "GNOME on Xorg" after enabling the "GDM Wayland" option in Garuda Assistant.
    • This occurs because the gdmwayland-on.sh pipes a number of Wayland-specific environment variables into /etc/environment which then clash with X11 and are not fully overwritten by any file sourced for vars under exclusively under "GNOME on Xorg"
    • The relevant variables are QT_QPA_PLATFORM=wayland, QT_QPA_PLATFORMTHEME=qt5ct, and XDG_SESSION_TYPE=wayland, although I have not tested if _JAVA_AWT_WM_NONREPARENTING=1 and MOZ_ENABLE_WAYLAND=1 cause any additional problems. Under X11 where it is sourced, ~/.profile does set QT_QPA_PLATFORMTHEME="gnome" but makes no changes to the other two.
    • More specifically, XDG_SESSION_TYPE=wayland appears to be responsible for the extension and theme breakage, while QT_QPA_PLATFORM=wayland (or some combination of its interface with the other relevant variables) causes the Qt issue.
    • As I've noted before, it seems weird to me that a handful of other variables are also included in the gdmwayland-on.sh, but they're not breaking anything so I haven't touched them.
    • NOTE: the checks in Garuda Assistant and the related operations don't work if WaylandEnable in /etc/gdm/custom.conf has been edited to true. This isn't really an issue though.
  2. Qt-based applications do not use GNOME native titlebars, regardless of whether "GDM Wayland" is enabled, if a user theme has been applied, and they only sort of use the default theme OOTB because of QT_QPA_PLATFORMTHEME="gnome".
    • This is achievable, although I'm unclear exactly why the fix below works. There may also be a reason this is disabled or the existing Qt configuration is preferred.
  3. Both the Wayland backend for GDM itself, and the option to choose between Wayland and Xorg for the GNOME shell are disabled OOTB, which is atypical for GNOME installations in general. The existing configuration is already dependent on both the Wayland and X display servers and under vanilla installs both are enabled by default.
    • The checks made in /usr/lib/udev/rules.d/61-gdm.rules seem set appropriately to disable GDM's Wayland backend in favor of X when it's called for, and set Xorg as the preferred GNOME Shell session regardless.
  4. Despite GNOME fully implementing XDG Autostart and the files being correctly placed, the initial-user-setup.desktop from garuda-common-settings and the bashrc-setup.desktop from garuda-bash-config don't work, while the dconf-load.desktop and it's associated scripts from garuda-gnome-settings do execute appropriately on first run.
    • I have no idea why this is the case, but if they do work on the dragonized edition it's probably something weird and GNOME-specific.
    • Said dconf script applies a couple keys for GNOME Terminal that don't exist anymore.

I noticed some other issues/oddities in the course of all this, but they appear unrelated. I can provide them if anyone would like, but won't be addressed in my own immediate work.

Possible Fixes

  • A few tiny changes to gdmwayland-on.sh and the ~/.profile supplied by garuda-gnome-settings could fix issues 1-3 without affecting non-GNOME editions. However, there are other possibly better/cleaner solutions. I have these changes ready but would like to check a few more things.
  • Lines to also edit ~/.profile could be added to gdmwayland-on.sh. This fix requires the least changes to solve the most issues while keeping Garuda's default behaviors if that is desired.
  • According to the Wayland Session Start Docs and this section of the environment variables Archwiki page, it seems possible to have Wayland source files that X11 will not. This means that a better implementation of gdmwayland-on.sh could fix issue 1 by enabling Wayland and setting the appropriate vars separately for Wayland and X11 without messing with /etc/environment at all.
  • Alternatively, the default custom.conf and .profile could be changed in conjunction with the addition of the appropriate Wayland .conf to fix 1-3 OOTB.
  • To fix 2 by itself or in addition to anything else here, some combination of setting QT_QPA_PLATFORMTHEME=gtk3 and QT_QPA_PLATFORM=xcb globally does the trick. Garuda ships with a gtk3 platform plugin for Qt, and using the X backend even under Wayland is (I'm guessing) making the apps just use Xwayland so the native decorations get applied? No idea quite how this works or if =gtk3 is actually necessary.
    • Worth noting here that there are a handful of other things that seem to be leftovers of some point when Garuda GNOME shipped with qt5ct and/or kvantum.
  • I'm still working on a fix for issue 4. A couple deletions in garuda-dconf.ini would fix issue 4.2, but I'm waiting until I have an overall picture of my garuda-gnome-settings changes before opening a merge.
  • The first-run .desktop scripts could be consolidated into one GNOME-specific solution to fix issue 4 and cleanup some of the KDE-specific leftovers from garuda-common-settings, but this change could put the GNOME Edition out of sync with the other editions and their respective garuda-desktop-settings providers.

Closing Notes

In addition to the listed fixes, any of which I could implement and merge, I'm personally putting together a more thorough re-work of the GNOME situation in general, but that's much further from being ready to merge. At this point, I've probably also put together enough to contribute a bit to the wiki so I'll use the appropriate channels for that.

If anyone would like the larger // messier // more technical research doc I made that includes all of the potentially relevant external documentation I can drop that as well.

Thanks again to the devs, much love :peace:

5 Likes
2

For your interest: QT_QPA_PLATFORM=wayland can break some QT applications (ie Virtualbox) regardless of the DE.

1 Like
3

Ah, good to know, thank you!

This, plus what I've already learned, seems to indicate that (at least for GNOME) this QT_QPA_PLATFORM should just always be set to xcb since it's what should get used anyway under GNOME on Xorg and seems to make Qt apps play nicer running under Wayland.

I also don't think XDG_SESSION_TYPE should be set at all, or at least not globally, since some apps appear to check this and get confused if it's wayland when logged into GNOME on Xorg.

1 Like
4

Holy shit...why are you wasting spending your time and talent with us? Straight-up.

3 Likes
5

@SonarMonkey I would have to discuss this with the team, but would you be interested in taking over the gnome edition potentially? To my understanding, we don't have an active maintainer for that edition. You would be free to make it whatever you want, for all intents and purposes (as long as basic software compatibility is preserved).

5 Likes
6

Oh man, I would definitely need a little assistance getting started as a maintainer, but I’d love the opportunity! I must say up-front that taking this on would be decently beyond the scope of anything I’ve been the sole maintainer for, but I’m loving this project/team/community and personally using the edition, so I’d be happy to work on it. Let me know if there’s anything further I need to do right now, or any prep I can get started on beyond my current work here.

As for @Bro

Even sinking some time after missing some obvious stuff at a couple stages of the stuff I’ve done so far has, if nothing else, been a lovely learning experience, so I’d never consider it wasted time. In the past, most of my more in-depth work like this has been for my personal machine or hobby projects. I have a good handful of docs like this that have never gone anywhere but my drives. (would you believe me if i told you the last thing i publicly maintained was for the Nexus 5X ? :rofl:)

It recently occurred to me how long I’ve used Linux and how little I’ve really given back. Contributing to big, well-established projects has always intimidated me, but I’ve found something remarkable and approachable with Garuda. And (relatively) way back GNOME was my first love DE-wise, so it was easy to spark up a passion again.

8 Likes
7

Awesome, I’ll get in touch with some core team members and ask them what they think, alright?

I didn’t think me saying you would get help if you need it would be necessary :wink:

Well, basically you would get access to all gnome related repos for now. We can see about teaching you a trick or 2 more later on, like maintaining/deploying the packages yourself. All has to be discussed with the team first, tho. I shouldn’t be making executive decisions here :stuck_out_tongue:

5 Likes
8

Awesome, thank you! :smile:

Figured as much based on all I’ve seen so far, but worth mentioning and very much appreciated nonetheless :person_shrugging:

Of course, no rush. Besides pushing to my fork vs. main all the work I’m doing right now is the same and there’s plenty of it (+more with the prospect of greater control/flex) :call_me_hand:

I’ll list my GitLab on my account here (although nothing new is pushed yet), and my messages should be open but I can direct you other contact info if necessary.

3 Likes
9

I was also quite astonished by the in-depth research you did on these topics. Personally, I don’t have any objections against you contributing as GNOME maintainer in the future. Don’t worry about not knowing much about maintenance, I guess most of us started that way (personally I started by taking responsibility for maintaining GNOME at the very beginning, focus has shifted towards servers and Chaotic-AUR since that time though), having fun in learning new things and being able to work in a team are pretty much the only things required here I guess. After all, things you are uncertain about can always be discussed in the team :wink:

6 Likes
10

Wow, thank you! Can’t say how gratifying just the work of it has been even in the few days I’ve been going at it properly, and this feedback is even more encouraging.

Sounds like a plan :sunglasses: Should have some changes live on my fork(s) later today, then I’ll be remote for a couple days so work on this will slow a bit over the weekend. I’ll keep up to speed at least here on the forum and hopefully in the Matrix though.

5 Likes
11

Made a lil merge just to make sure everything is screwed on right.

Also, as is the way of things, GNOME 42 dropped while I was deep in the midst of compiling docs and notes for immediate fixes and longer plans :rofl: As usual it looks like it might break a couple things, and even before it hit the repos I was already leaning towards work on a more comprehensive overhaul to the current state of GNOME on Garuda.

This seems achievable mostly within the scope of just gardua-gnome-settings, although I am also toying with the concept of trying to pull off a GNOME-specific garuda-common-settings provider in the same manner as the WM/DE garuda-desktop-settings. Lots to know first. :person_shrugging:

Those with feelings of any kind on GNOME might get a kick out of the closest thing there is to a "changelog" and also this article.

3 Likes
12

I was wondering about that! The whole time I’ve been following this thread I’ve had my fingers crossed for you, that the upgrade to 42 wouldn’t take a match to all the research you’ve put in recently.

The Jupiter Broadcasting guys have been gushing over Gnome 42 since the beta came out; hopefully it lives up to the hype.

3 Likes
13

I must say, where it is actually applied, the UI refresh is quite nice IMO. Most of the listed backend changes and performance improvements also seem quite cool. I've played with it a bit and it doesn't seem to have screwed me too badly, just tacked on a little more time in a little more documentation (if you're familiar with the general state of GNOME documentation, well... :person_shrugging:) And it's probably best that this happened now given what I'm considering longer-term.

GNOME 42 does unfortunately fragment theming even within the GNOME standard apps, as some still pull gtk3 titlebars/decorations/themes while those ported to gtk4 conform to the updated style. It also seems to transition confusingly away from the prior GNOME shell and GTK themes in the same system and user dirs, to "libadawaita" themes in ~/.config/gtk4.0 for the re-named "Legacy Apps" option in Tweaks, while keeping shell themes the same. But, this is unsurprising with the move into the whole "libadawaita" in 40 and the whole light/dark GTK4 situation. Existing 41 GTK themes aren't read by Tweaks at all as far as I can tell but I may see about manually enabling one just to prod it a bit.

Sadly, one of my goals was a comprehensive solution to apply consistent styling across Qt/GTK3/4 under both Wayland and X11, and I noticed 42 right about when I realized exactly one(1) global environment variable apparently did the trick. Seems to suggest it is still possible if I manage to sort out the implications of the shift in theming.

The knowledge base I've built in the course of all this is lightyears more valuable than this little setback and I've been in a flirtatious on/off with GNOME for a long time so I knew what I was getting into :rofl:

5 Likes
14

I guess that is probably the main thang. I’ve been staying away from GNOME ever since that Shell-bitch and I broke up a couple years back. She broke my heart when she refused the clothes I’d tailored just for her.

Forewarned is forearmed. :wink:

1 Like
15

Perhaps you're better off than I - after every steamy niche-WM tryst, it's GNOME's familiar yet strangely ever-different arms I find myself coming back to. We work it out, for a time - "maybe nth time's the charm" I'll say - until an off-hand suggestion from me has GNOME throwing all my clothes into the street after me yet again.

It seems a shame that KDE and I never got along, but I was never one for the steadier types.

On a slightly more actual note, once existing gtk4 themes get ported (there are already a couple) I do think it is sort of cool, if still a bit of a pain. Some of my notes in this initial post don't seem to apply (Qt is loading gtk3 themes for titlebars under Wayland now???) but :person_shrugging: Still much to figure out.

1 Like
16

Environment variables in Linux and with DEs thinking they are alone is the greatest mess IMHO.
IMO,

  • these vars should be applied locally (user), when needed to be set.
    /etc/environment and few other files cannot be scripted, so they are inconvenient for user friendly approach, as a majority of users do change session type and DEs, either for testing/curiosity, or their personal requirements and needs have changed, while DEs continue to improve(?) with wayland (the future).
    In short, I use ~/.profile and ~/.bash_profile to script environment assignement, depending on session type and $XDG_SESSION_DESKTOP/$DESKTOP_SESSION or whatever each DE prefers to fill.
  • Don’t forget the changing $SHELLs issue.
  • Other script-compatible methods are the local systemd environment section (~/.config/environment.d/*.conf), which uses scripts to echo env-vars assignments (awkward way but what can you do…).
  • The ultimate method IMO would be to unify all those (their results), by symlinking and/or sourcing or other scripting.
    I hope I am understood, since I am no native English person… :slightly_smiling_face:

I am working on these issues for personal interest and have started coding a utility to unify the control, mostly for WM type of sessions, but the playground is huge. If you need to discuss or have ideas to test, I am available (on my available time, as always :wink: ).

Welcome to the team BTW! :+1:

6 Likes
17

Oh, that’s amazing, I appreciate the reply!

Yeah, 100%

It was my understanding that Wayland doesn’t run a login shell in the same way that X11 does, so I didn’t think that ~/.bash_profile got sourced under Wayland until you actually run an interactive shell? If that impression was wrong then yeah I’d imagine it’d be best practice to use this, but as you mentioned there’s the issue of changing shells. ~/.profile doesn’t get sourced at all by Wayland unless you add some kind of hook(?) or do it manually, right?

My research seemed to indicate that there was maybe a place adjacent to /etc/environment that was Wayland-specific, but the documentation was a little confusing because it conflicted between sources as to where this actually was, and I figured out the issues at play here before I got to messing with it.

Oh, interesting, I had no idea about this approach. Does sound a bit awkward but yeah :person_shrugging: I may hit you up about this!

I’m of the opinion that symlinking tends to get messy fast, and personally only do it if it’s really necessary. But, that opinion is sort of unfounded and used judicially it could be a valid approach. I think scripting would be better? But you’ve done more work on this it seems, I’d trust your judgement here.

:eyes: I’d love to take a look at this utility when it’s in a state you’d be willing to share it, I’d be happy to contribute what I can too! I’ll certainly have more questions in the future since you’ve done a good bit of work here already.

Ultimately, yeah, I think most approaches besides piping vars right into /etc/environment are probably better, but I do understand why it was done in the context of the whole GNOME-Wayland thing.

All clear to me! And, honestly, it’s been my experience that non-native speakers usually put more effort into being coherent in places like this than many native ones, and are often more successful :rofl:

Thank you! :peace_symbol:

Messages here and Telegram always open!

2 Likes
18

I was just refering to my personal method. I use Xorg and bash for the moment.
The rest you say is correct.
The problems to devs begin when users change their OOTB environment, like from wayland to X11 and back, or from DE/WM to another. Then, whatever is setup by OOTB defaults get scrambled, the depth of which depends on the elements they changed.

I just read archwiki and man pages on this. I also experimented, but not much enough, because of time…
I think everything can be done, but there is so much to read and test, that takes long time (if you are as slow as myself… :laughing: ).

Not sooner than a couple of weeks from now… :person_shrugging: I"ll inform you of course. Who says no to a willing guinea pig tester? :joy:

4 Likes
19

I'm understanding you clearly & learning along with you. Running gnome edition & LXQT kwin in dual boot in search for an idea for learning to run different news feeds simultaneously on, what for me is a huge screen. Thank you @petsam @SonarMonkey I will be taking a look at files you mention and following closely.

20

Please avoid necrobumping threads unless you have any new information or a novel solution to add to an old thread.

3 Likes