Did this in /.profile . What it did is, after logout or reboot, Garuda assistant will open with the dark theme (Sweet in my case) but won’t load XFCE desktop.
Restoring snapshot won’t help obviously.
Anyways , don’t bother about the issue. I’m currently installing your Sway latest 
Good thing I backed up my PDFs just minutes before doing this 
I did this with several themes and it worked…
…but there was an identical error in the terminal for all themes tried:
(garuda-assistant:3511): Gtk-WARNING **: 09:29:25.253: Theme parsing error: gtk.css:4283:35: '-2px' is not a valid color name
(garuda-assistant:3511): Gtk-WARNING **: 09:29:25.253: Theme parsing error: gtk.css:4287:35: '-1px' is not a valid color name
QMetaObject::connectSlotsByName: No matching signal for on_checkBox_clicked(QWidget*)
There are always many Gtk warnings, just ignore them or fix the invalid values in line 4283 and 4287 in the gtk.css file 
I have no idea how to do this, and I’m somewhat dubious about setting an environment variable after seeing the experience of IUSELINUX
I cannot imagine any possible way these two things could be related. My guess is this was only a coincidence, and some other configuration change was responsible for the issue you encountered.
As a side note, restoring a snapshot would not be needed to revert a change to ~/.profile; instead, you could just edit the file from a TTY before signing in if it were causing a problem.
I believe these errors are related to some messiness in the actual code of the application. It should be cleaned up at some point, but that would be more appropriate to raise as an issue on GitLab. If everything is working normally I wouldn’t worry about it too much for now.
I don’t think this particular environment variable is risky to set. It just announces how Qt apps should be themed.
Gnome sets this same variable in /etc/profile.d/environment.sh, see here: Add /etc/profile.d/environment.sh (9ee76c9f) · Commits · Garuda Linux 🦅 / Themes and Settings / Settings / Garuda GNOME settings · GitLab. You could pretty easily create a similar file with just the one line if you wanted to.
micro /etc/profile.d/qt_override.sh
#!/bin/bash
export QT_STYLE_OVERRIDE=kvantum
sudo chmod +x /etc/profile.d/qt_override.sh
Log out and back in to test.
I did a lot of digging around with regard to the above, and in the end I added QT_STYLE_OVERRIDE=kvantum to /etc/environment.
The result:
Thanks for the info @BluishHumility
Added QT_STYLE_OVERRIDE to guide along with screenshots.
Is there a way to install Stacer without installing things like Yay (i.e. with Pacman)? It worked flawlessly on Gnome and I miss it.
Like this:
sudo pacman -S stacer-git
Unfortunately this didn’t work…
sudo pacman -S stacer-git
[sudo] password for colin:
error: target not found: stacer-git
stacer-bin and use paru.
Ah, seems it was removed from the Chaotic repo recently. If you want to keep using it you’ll have to install from the AUR.
I was looking to not have to install helpers.
Is Stacer something that could be put in the Chaotic AUR?
If not I’ll I’ll install a helper.
They just took it out of the Chaotic repo.
[Remove] stacer, stacer-git · Issue #1013 · chaotic-aur/packages · GitHub
Dropping because last release was May 2019. Upstream repo has notice: This project has been abandoned. There will be no further releases.
It seems Stacer is no longer maintained, for quite some time now. You can still install it from the AUR but I wouldn’t recommend it.
OK, thanks for the info.
My apologies for the delayed reply - my internet connection is currently horrendous.
I will add a piece showing how to add new items to the panel, and I’ll give the eyes a mention
Just a quick note to say the guide at the top of the page has now been completed. A ton of stuff has been added and it now provides a unique take on an Xfce desktop. A brief video has been added to the end of the guide to demonstrate some of the aspects.
I have moved the video to the top of the article and added a couple of pieces at the bottom which help to remove unused data.
Unfortunately I’ve found that the tip for /etc/systemd/journald.conf isn’t working and I’m wondering if anyone knows the reason why as these files can take up a huge amount of drive space. If it could be kept to 50 MB it would be much better.
If it can’t be made to work I’ll remove it.
The instructions you posted above look fine, however I would say you can scrap it anyway because on Garuda Linux the 50M journal size limit is already in use due to a drop-in file in /usr/lib/systemd/journald.conf.d/00-journal-size.conf: usr/lib/systemd/journald.conf.d/00-journal-size.conf · master · Garuda Linux 🦅 / Themes and Settings / Settings / Garuda common settings · GitLab
File: /usr/lib/systemd/journald.conf.d/00-journal-size.conf
[Journal]
SystemMaxUse=50M
If you are just looking at the size of the /var/log/journal directory in a file manager or something, you should be aware that the file sizes here are not actually reported in an accurate way. That may be why you are thinking it is not working, when really it probably is.
The journal files are often sparse, meaning they take up less space on disk than their reported size, and they are also compressed but may be reporting their uncompressed size. There is also metadata in these directories which does not count against the total journal size, and probably other factors contribute to it as well.
If you look inside the actual directory you will see it is kind of weird looking. Here is mine, which shows I have 31 journal files that are oddly each 6.6M in size:
❯ exa -TalL2 --total-size /var/log/journal/
drwxr-sr-x@ 203M root 14 Dec 2023 /var/log/journal
drwxr-sr-x@ 203M root 21 Feb 21:26 ├── 541b848588a74934987d67f2c44000df
.rw-r-----@ 6.6M root 21 Feb 22:25 │ ├── system.journal
.rw-r-----@ 6.6M root 21 Feb 21:26 │ ├── system@1fd05eb187d048e5a11d8fc9aa0e2a02-000000000002e31a-000611ef21361cd9.journal
.rw-r-----@ 6.6M root 18 Feb 11:21 │ ├── system@9a96cbd3c9c64fc0b259df06e3fc37b2-0000000000026b6b-000611aa5c15cf29.journal
.rw-r-----@ 6.6M root 18 Feb 11:21 │ ├── system@9a96cbd3c9c64fc0b259df06e3fc37b2-0000000000027424-000611aa5d242f28.journal
.rw-r-----@ 6.6M root 18 Feb 11:46 │ ├── system@9a96cbd3c9c64fc0b259df06e3fc37b2-00000000000276f6-000611aa6036c6ab.journal
.rw-r-----@ 6.6M root 18 Feb 12:10 │ ├── system@9a96cbd3c9c64fc0b259df06e3fc37b2-0000000000028a48-000611aab6f559b6.journal
.rw-r-----@ 6.6M root 18 Feb 21:17 │ ├── system@9a96cbd3c9c64fc0b259df06e3fc37b2-0000000000029700-000611ab0c71e096.journal
.rw-r-----@ 6.6M root 19 Feb 07:20 │ ├── system@24a8e91d09474308b46685c8fa69f110-000000000002a624-000611b2b5e703c4.journal
.rw-r-----@ 6.6M root 18 Feb 21:18 │ ├── system@24a8e91d09474308b46685c8fa69f110-0000000000029d68-000611b2b2f205dc.journal
.rw-r-----@ 6.6M root 20 Feb 20:40 │ ├── system@55a4ca6a66f249f1a5680e615d48ddf2-000000000002cf68-000611da669c1292.journal
.rw-r-----@ 6.6M root 21 Feb 21:23 │ ├── system@55a4ca6a66f249f1a5680e615d48ddf2-000000000002d83f-000611da68beab36.journal
.rw-r-----@ 6.6M root 19 Feb 20:51 │ ├── system@473ef83cc7774f5796f8a3ee026131c2-000000000002bc0f-000611c67067cd09.journal
.rw-r-----@ 6.6M root 20 Feb 20:39 │ ├── system@473ef83cc7774f5796f8a3ee026131c2-000000000002c4dd-000611c674aa9f39.journal
.rw-r-----@ 6.6M root 17 Feb 20:03 │ ├── system@c498f41a2b914240ad883bf7edb5e11b-0000000000024a01-00061197fba82c3a.journal
.rw-r-----@ 6.6M root 17 Feb 13:25 │ ├── system@c498f41a2b914240ad883bf7edb5e11b-00000000000240cc-00061197b3b6bcf0.journal
.rw-r-----@ 6.6M root 18 Feb 11:20 │ ├── system@c498f41a2b914240ad883bf7edb5e11b-0000000000025a74-0006119d8d46ddd1.journal
.rw-r-----@ 6.6M root 19 Feb 07:21 │ ├── system@d7e867ad0f344459a458bfe19394bde3-000000000002aab1-000611bb1f0637fb.journal
.rw-r-----@ 6.6M root 19 Feb 20:50 │ ├── system@d7e867ad0f344459a458bfe19394bde3-000000000002b35d-000611bb2108f6b8.journal
.rw-r-----@ 6.6M root 21 Feb 22:20 │ ├── user-1000.journal
.rw-r-----@ 6.6M root 18 Feb 11:21 │ ├── user-1000@9a96cbd3c9c64fc0b259df06e3fc37b2-0000000000027423-000611aa5d23f3f7.journal
.rw-r-----@ 6.6M root 18 Feb 11:46 │ ├── user-1000@9a96cbd3c9c64fc0b259df06e3fc37b2-0000000000027792-000611aa633b2f68.journal
.rw-r-----@ 6.6M root 18 Feb 21:18 │ ├── user-1000@9a96cbd3c9c64fc0b259df06e3fc37b2-0000000000029bcb-000611ab33cd5666.journal
.rw-r-----@ 6.6M root 18 Feb 12:10 │ ├── user-1000@9a96cbd3c9c64fc0b259df06e3fc37b2-0000000000029147-000611aae79e5fba.journal
.rw-r-----@ 6.6M root 19 Feb 07:21 │ ├── user-1000@24a8e91d09474308b46685c8fa69f110-000000000002a623-000611b2b5e6cb03.journal
.rw-r-----@ 6.6M root 21 Feb 21:26 │ ├── user-1000@55a4ca6a66f249f1a5680e615d48ddf2-000000000002d83e-000611da68be6942.journal
.rw-r-----@ 6.6M root 20 Feb 20:40 │ ├── user-1000@473ef83cc7774f5796f8a3ee026131c2-000000000002c4dc-000611c674aa5f7f.journal
.rw-r-----@ 6.6M root 17 Feb 13:05 │ ├── user-1000@c498f41a2b914240ad883bf7edb5e11b-0000000000023dcb-000611979b1eedea.journal
.rw-r-----@ 6.6M root 17 Feb 20:03 │ ├── user-1000@c498f41a2b914240ad883bf7edb5e11b-0000000000024f18-0006119825571d1a.journal
.rw-r-----@ 6.6M root 17 Feb 13:25 │ ├── user-1000@c498f41a2b914240ad883bf7edb5e11b-000000000002440d-00061197cfb6118f.journal
.rw-r-----@ 6.6M root 18 Feb 11:21 │ ├── user-1000@c498f41a2b914240ad883bf7edb5e11b-0000000000025b67-0006119d8da38134.journal
.rw-r-----@ 6.6M root 19 Feb 20:51 │ └── user-1000@d7e867ad0f344459a458bfe19394bde3-000000000002b35c-000611bb2108ba12.journal
drwxr-sr-x 0 root 14 Dec 2023 └── remote
According to that, this directory weighs in at a whopping 203M, which is obviously way over the 50M limit.
To get a more accurate picture of the journal’s disk usage, run journalctl --disk-usage. Here is mine, on the same system:
❯ journalctl --disk-usage
Archived and active journals take up 43.7M in the file system.