[Breeze] [Bug 355906] Please consider unification for themes' data paths.

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=355906

--- Comment #2 from vladimir-csp at yandex.ru ---
> what exactly falls under themes? Icon themes? Qt styles? Plasma themes? GTK themes? Firefox themes? (I could go on, this list is almost endless.)

Well, everything you've listed, except icon themes, because they are
conceptually different. And I can not tell anything about Firefox, but it seems
to fit.

> These things are quite specific, dumping them all into a common directory will increase lookup times and make it harder to tell a GTK engine from a Qt style.

Specificity and lookup times are preserved perfectly, since every engine still
looks for data in it's own directory and needs not to look anywhere else.
But integration benefits, since data dirs for engines reside inside theme's
directory.
For example, GTK3 and Openbox - completely different things. The former is a
toolkit, the latter is a toolkit-independent window manager. But themes are
being created to cover both of them.

Take the famous Numix theme. When installed globally, it has:
/usr/share/themes/Numix/unity # contains data for Unity shell
/usr/share/themes/Numix/gtk-3.0 # contains data for GTK3 engine
/usr/share/themes/Numix/gtk-2.0 # contains data for GTK2 engine
/usr/share/themes/Numix/xfwm4 # contains data for XFWM window manager
/usr/share/themes/Numix/openbox-3 # contains data for Openbox window manager
/usr/share/themes/Numix/xfce-notify-4.0 # contains data for XFCE notification
daemon. NOTIFICATION DAEMON DAMMIT!
/usr/share/themes/Numix/metacity-1 # contains data for Metacity window manager

All in one package. Such themes usually being distributed in archives which can
be just unpacked in /usr/share/themes/ or ~/.themes/ or ~/.local/share/themes/
and everything 'just works'. Single accessible location to rule 'em all. 

The tool which governs the appearance of various stuff that DE is composed of
needs to know only theme name and tell it to known engines and apps.

Theme authors get predictablility, ability to link stuff inside the theme to
deduplicate, distribute themes in 'download>unpack>works' manner.

This is not just a random idea which popped into my mind yesterday. This
concept is being continiously embodied for more than a decade in thouthands of
themes, used by dozen of software titles.

I see no reason why, for example, Qtcurve theme has to put its data into
/usr/share/kde4/apps/QtCurve/ and Breeze theme has to put its data to
/usr/share/kstyle/themes/. No logic here.

If Qtcurve and Breeze engines would join theme convention used by other
engines, themes for them would nicely pack into:
/usr/share/themes/$THEME_NAME/Breeze
/usr/share/themes/$THEME_NAME/Qtcurve

Clear benefit for theme creators to create themes - easier to accommodate
multiple engines.
Clear benefit for users to download and install themes - no need to think about
the engines.

I suppose, some of the potential questions may had already been answered here:
https://github.com/lxde/lxqt/issues/572

-- 
You are receiving this mail because:
You are the assignee for the bug.