# Rocky + KDE -- broken colors.css

**URL:** <https://forums.rockylinux.org/t/rocky-kde-broken-colors-css/4219>\
**Category:** Rocky Linux Help & Support\
**Created:** [October 5, 2021, 2:16pm UTC](https://forums.rockylinux.org/t/rocky-kde-broken-colors-css/4219 "2021-10-05T14:16:29Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![SomervilleTom](https://avatars.discourse-cdn.com/v4/letter/s/8797f3/32.png) [@SomervilleTom](https://forums.rockylinux.org/u/SomervilleTom)\
**Post date:** [October 5, 2021, 2:16pm UTC](https://forums.rockylinux.org/t/rocky-kde-broken-colors-css/4219/1 "2021-10-05T14:16:29Z")

</div>

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:

```auto
(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:

```auto
/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:

```auto
@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:

```auto
@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.

---

<div class="post-metadata">

**Author:** ![harleyb](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/harleyb/32/1666_2.png) [@harleyb](https://forums.rockylinux.org/u/harleyb)\
**Post date:** [January 30, 2022, 12:56am UTC](https://forums.rockylinux.org/t/rocky-kde-broken-colors-css/4219/2 "2022-01-30T00:56:51Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![desercat](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/desercat/32/1192_2.png) [@desercat](https://forums.rockylinux.org/u/desercat)\
**Post date:** [January 30, 2022, 2:14am UTC](https://forums.rockylinux.org/t/rocky-kde-broken-colors-css/4219/3 "2022-01-30T02:14:56Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![SomervilleTom](https://avatars.discourse-cdn.com/v4/letter/s/8797f3/32.png) [@SomervilleTom](https://forums.rockylinux.org/u/SomervilleTom)\
**Post date:** [January 30, 2022, 4:30am UTC](https://forums.rockylinux.org/t/rocky-kde-broken-colors-css/4219/4 "2022-01-30T04:30:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![desercat](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/desercat/32/1192_2.png) [@desercat](https://forums.rockylinux.org/u/desercat)\
**Post date:** [January 30, 2022, 8:13am UTC](https://forums.rockylinux.org/t/rocky-kde-broken-colors-css/4219/5 "2022-01-30T08:13:16Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![brian](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/brian/32/5777_2.png) [@brian](https://forums.rockylinux.org/u/brian)\
**Post date:** [August 25, 2023, 3:56am UTC](https://forums.rockylinux.org/t/rocky-kde-broken-colors-css/4219/6 "2023-08-25T03:56:16Z")

</div>

Closed on August 25, 2023, 3:56am UTC


