Could you tell us what benefit this brings? 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. Change in itself isn't useful, and just changing the location of files may induce breakage without obvious gain.

Also, what exactly falls under themes? Icon themes? Qt styles? Plasma themes? GTK themes? Firefox themes? (I could go on, this list is almost endless.)

Could you point out which files you are specifically referring to? Your request is pretty fuzzy in that regard.

> 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

It's going to vastly increase lookup time in many cases, namely any time you look up a specific theme or a list of themes. (You now have to dive into subdirectories.) Currently, we can (more or less) just list a subdirectory with e.g. all plasma themes, and then we have our list of themes. Some bits need metadata files installed so the "theme" (in the widest sense of the word) simply cannot be contained to some directory under /usr/share/themes.

The logic you're missing between QtCurve (obviously you're looking for the KDE4 version) and Breeze (apparently Frameworks 5 based version) is that they're simply doing entirely different things.

What you're missing is that "themes" is a concept that makes sense to the user, for developers and system integrators, you need the type of theme, they can be collections of images (icons), SVGs (icons, Plasma themes), stylesheets (QtCurve, new-style GNOME), or C++ code (Qt styles), QML (Plasma look and feel packages), binary plugins (window decorations) which means they need different treatment.

Now ask around distros how happily they put compiled binaries into /usr/share (they belong under /lib or /usr/lib, depending).

"Please put all themes under /usr/share/themes" is ignoring that complexity, therefore it's not feasible to do so as the bug potential, performance penalty and work involved does IMO not justify the benefit you lined out.

Note that if you include subdirectories in your zip of themes, anyway, you're not bound to one directory under /usr/share/themes, you can do the exact same thing and put it into different directories (that's what package managers such as RPM actually do, they unzip a directory structure to system directories).

That said, it sounds like a recipe for disaster to encourage theme editors to do this. Let distros handle it, or tools like plasmapkg (which has all the logic to figure what to install where, and it's not simple logic that can easily be replaced with "well, put everything there, in subdirectories").

for instance themes of some things (Qt, KWin, GTK2, ...) are binary plugins, that can't go in /usr/share as no binary libraries are allowed there.

here there are two completely different problems:
what the user is presented with (and I agree, a more unified list and experience  should be presented)
and how everything is implemented and organized on the disk, that doesn't and must not have any relation on how is presented to the user

Sorry, but I have to agree with sebas here. If I consider this for kwin, I must say it's horrible from the lookup perspective as we need to be fast at startup. With the proposal we cannot easily check whether a theme is there and where to get a fallback. It would require stating multiple directories. That's causing significant slow down during startup which we currently don't need. It's not much each single time, but it sums up. Here a few milliseconds, there a few and soon you have a second of waiting for nothing.

> it sounds like a recipe for disaster to encourage theme editors to do this.

No disaster has ever happened for software and themes that follow this convention. 

> What you're missing is that "themes" is a concept that makes sense to the user, for developers and system integrators, you need the type of theme, they can be collections of images (icons), SVGs (icons, Plasma themes), stylesheets (QtCurve, new-style GNOME), or C++ code (Qt styles), QML (Plasma look and feel packages), binary plugins (window decorations) which means they need different treatment.
> for instance themes of some things (Qt, KWin, GTK2, ...) are binary plugins, that can't go in /usr/share as no binary libraries are allowed there.

I'm not missing this. Binary plugins are usually part of engines, and that is completely different story. To clarify, Qt styles are analogous to GTK engines and are NOT themes. Themes are data.

> I'm not missing this. Binary plugins are usually part of engines, and that
> is completely different story. To clarify, Qt styles are analogous to GTK
> engines and are NOT themes. Themes are data.

You reported this here in the breeze component. Breeze consists of multiple binary plugins - way more than no binary plugins aspects. So this seems a rather relevant thing to point out in this feature request that it's irrelevant to the component you propose it to.

Themes can be distributed by distributions, but distributions usually do not have enough resources to maintain thousands of themes. That is why themes are usually distributed by authors in distribution-independent ways.

Another example:
...GTK2 themes are data which is being shipped in $THEME_NAME/gtk-2.0. This data is being used by GTK2 engine which is usually shipped by distribution. (handful of engines, thousands of themes)
Example: Numix theme contains Numix/gtk-2.0 directory with data. It is used by Murrine GTK2 engine which usually is already in distribution (gtk2-engines-murrine in case of Debian). 

Theme author makes a theme named Foo which could include data for Plasma (svg stuff), Qt5 Breeze engine (colors, images, whatever), Qtcurve (stylesheets)... etc.

@Martin Gräßlin, I wonder how the lookup is done in Metacity, Compiz, Openbox and XFWM which are using the themes convention.

> You reported this here in the breeze component.

Oh, sorry, my bad! I see, this caused some misunderstanding, and I did not clarify why I picked Breeze. Well, I did it because I did not find a component that would conceptually cover themes in general, but Breeze is the dominant widget engine in KDE, so I picked it. Please reassign this request to a more appropriate component. Please ask any questions if you want me to elaborate something.

>  I wonder how the lookup is done in Metacity, Compiz, Openbox and XFWM which are using the themes convention.

honestly: I doubt they do. At least Metacity and Compiz have been dead for years. Openbox and XFWM are compared to KWin erm stagnating. Maybe we are comparing apples and oranges here? For them the one look up simple might not matter, but KWin has more than just one look up for themed elements.

> honestly: I doubt they do.

What do you mean?

> Openbox and XFWM are compared to KWin erm stagnating.

I do not know about XFWM, but Openbox is just feature-complete and almost bug-free, so the term 'stagnating' hardly applies. It is being maintained successfully. Anyway, I doubt that stagnation has anything to do here.

Sorry you misunderstood. My point is rather that KWin and those WMs are not comparable due to size of project. An openbox theme is not comparable to the theming KWin has in place, because that's areas openbox doesn't even have. Neither openbox nor xfwm support OpenGL compositing with themeable desktop effects (yes the close button in Present Windows is themeable, each overlay in effects is themeable, the +/- button in DesktopGrid is themeable, etc. etc.). So this is a completely different ball park. Here performance matters, because each theme element needs to be looked up and it's slowing down the startup.

Kwin's complexity is understandable. But I suppose that it can still be boiled down to:
1. Something that renders (engine part)
2. Something that is being rendered (theme data part)
Is that correct, or am I completely misunderstanding Kwin's take on theming?

If path to the data is predetermined anyway, why there would be slower or more numerous lookups? Would that be caused by additional lookups in $XDG_DATA_HOME or ~/.themes? Is that what you mean?

The problem with the proposed change is how we look up stuff.

Currently we use an approach of one directory for a "theme element" and all themes install there. We can do a simple list of it. So we can easily see whether $theme supports the theme element and we can easily fall back to $default if it's not present.

With the proposed change we need to go into the directory of the theme, look up there whether the element is present, if not go to system variant of the theme, look up there whether the element is present, then start the whole process again for the default theme. Because in that setup we don't even know whether the default theme is supported.

You gave the answer yourself in the description, have another look at https://github.com/tsujan/Kvantum/commit/17a41413263dc546fac816ae1eb43aceb6366eb4 .

If we added support for another path / directory scheme, we'd have to do these things:

- change the lookup logic (from listing a directory to also looking into the /usr/share/themes subdirectory you propose
- change the installation logic, adding installation to /usr/share/themes *and* checking if a suitable candidate is already installed, overwriting or overriding that one; for every single type of theme we use
- defining which one overrides which, so the lookup order matters here as well (you can't just append the paths, because you want the more local lookups done first (so the user can override system-installed themes)

This would duplicate all of the lookup logic, so the code in a whole number of applications becomes more error-prone, costlier to maintain and slower. 

For performance, the bottom line is that even if we manage to look up themes just as fast as we currently do in the new path (I doubt that's easily possible), in order to remain backwards-compatible, we'd have to do that additionally to the current mechanism. We're never going to be able to do less or even the same amount of lookups, it will be at least twice the amount of work to what we currently do.

Well, thanks for your response!
If anyone has some input on theme handling in general or in specifics, please consider sharing it in this issue: https://github.com/lxde/lxqt/issues/572

I'll mark this bug as invalid for now, if anything new comes up, we can change the status again, but for now, I'd rather not like it to clutter our overviews.

Hope you don't mind, as it's mainly an administrative change.