Rocky + KDE -- broken colors.css

Rocky Linux General
1

Something in the Rocky + KDEPlasma ISO causes colors.css to have invalid values.

These may be introduced by changing the theme of konsole, but I’m not sure.

The symptom is the following complaint after running either emacs or vmware from a command line:

(emacs:22358): Gtk-WARNING **: 09:10:21.260: Theme parsing error: colors.css:71:44: Invalid number for color value

(emacs:22358): Gtk-WARNING **: 09:10:21.260: Theme parsing error: colors.css:72:44: Invalid number for color value

(emacs:22358): Gtk-WARNING **: 09:10:21.260: Theme parsing error: colors.css:74:53: Invalid number for color value

(emacs:22358): Gtk-WARNING **: 09:10:21.260: Theme parsing error: colors.css:75:53: Invalid number for color value

(emacs:22358): Gtk-WARNING **: 09:10:21.260: Theme parsing error: colors.css:76:56: Invalid number for color value

(emacs:22358): Gtk-WARNING **: 09:10:21.260: Theme parsing error: colors.css:77:65: Invalid number for color value

According to find, there is just one colors.css file on the system, with the following full path:

/root/.config/gtk-3.0/colors.css

The last few lines of this file contain the values that seem to break the apps that attempt to use this:

@define-color theme_titlebar_background rgb();
@define-color theme_titlebar_foreground rgb();
@define-color theme_titlebar_background_light #eff0f1;
@define-color theme_titlebar_foreground_backdrop rgb();
@define-color theme_titlebar_background_backdrop rgb();
@define-color theme_titlebar_foreground_insensitive rgb();
@define-color theme_titlebar_foreground_insensitive_backdrop rgb();

The calls to rgb() are invalid because they lack an argument.

I’ve edited this file so that those lines contain the following:

@define-color theme_titlebar_background rgb(71,80,87);
@define-color theme_titlebar_foreground rgb(252,252,252);
@define-color theme_titlebar_background_light #eff0f1;
@define-color theme_titlebar_foreground_backdrop rgb(189,195,199);
@define-color theme_titlebar_background_backdrop rgb(239,240,241);
@define-color theme_titlebar_foreground_insensitive rgb(189,195,199);
@define-color theme_titlebar_foreground_insensitive_backdrop rgb(189,195,199);

This silences the complaint(s), but doesn’t address the underlying question of how colors.css was broken in the first place. I suspect it is some KDE/plasma issue, but I know little or nothing about those components.

I’m surfacing this in hopes that it is helpful to those who know more all this.

2

Hi Tom,

For what it’s worth, I’ve experienced the same issue with a Linux 20.3 Cinnamon DE install. $HOME (separate partition) still had vestiges of the previous OpenSuSE Leap 15.3, which may have contributed to the problem. I only experienced it when opening the terminal and xcowsay ran to show something from the fortune files. It didn’t occur with the Leap install.

If you wouldn’t mind me asking, where did you get the replacement values for the rgb() calls? I was more of a database guy in my sysadmin days and never got into the style sheet arena.

Cheers!

Michael

3

Who knows WHY?? KDE 5.x was, is, and will be a problem from the start. You have to now hack KDE 5.x to solve a problem that did not exist in KDE 4.14. For one thing when I now login I have a choice of KDE Plasma Wayland and KDE Plasma X11. Nor is this problem restricted to KDE but applies to every other DE. but is most prevalent in KDE Plasma – hangs, login loops etc., etc. etc. The way I have sort of got around it is to get rid of SDDM, and use LightDM.

If you have an adventuresome soul, install sublime and see if you still have the same problem.

D’Cat

4

My most recent install of RL v8.5 + Plasma locks up during login if I make the mistake of choosing “Wayland”. It seems to work fine with “Xll”.

I haven’t dug into it yet, and probably wont. It’s just a file server, I need only occasional desktop access.

5

Ah!!! This is a problem of RHEL and all its siblings. For reasons unknown RHEL decides to give you a “choice” of Wayland & X11 be it for GNOME, MATE, Xfce, et al. always a choice of the two. “Wayland” is still “experimental”. In KDE the problems you will encounter are more pronounced in KDE than any other DE. Thus if you choose say KDE Plasma X11 you might get into a login loop — it comes up you enter your Password, and then it loops back to asking you for your Password. Now you choose KDE Plasma Wayland,this time it sails through the login your desktop pops up, and then the screen freezes – no mouse, no keyboard, no nothing . Now you reboot and you choose KDE Plasma X11 again, but NOW it sails right through the login and you end up with a working desktop. I suspect that the problem of Wayland not playing nice with X11, plus SDDM . X11 seems to be GNOME centric and is meant to run with GDM, but GDM does not play well with KDE, hence SDDM which does (with GDM you end up with runaway processes which is “solved” by running SDDM rather than GDM. But KDE is so committed to Wayland rather than choosing one or the other and making the various apps to run like a fine Swiss Watch you get a lot of conflicts between X11 and Wayland. The best way to “solve” the problem to say pox on both your houses and run LiightDM rather than SDDM, and run KDE Plasma X11.