xdgiconloader: Puts the hicolor at the end of the theme hierarchy

[luis-pereira]

The hicolor theme is the ultimate resort. It should be allowed only at the
end of the fallback hierarchy. We are allowing the hicolor theme to be in
the middle of the theme hierarchy. Schematically:
X -> hicolor -> Y -> Z -> hicolor
If an icon exists in the hicolor and Y theme the hicolor one, is wrongly
used.

This commit does four things:
* Stops adding the hicolor theme to each theme as a fallback.
* Stops adding the hicolor as a parent theme, even if added by the
index.theme Inherits key. The oxygen theme does it.
* Stops return the hicolor theme in the fallbackTheme().
* Adds the hicolor theme to the end of the fallback hierarchy list.

[palinek]

GTM

[agaida]

If i understand this right #116 and #125 should go in with #116 first? With #125 instead of #126?

[luis-pereira]

@agaida It goes like this:
During my "investigations" of #116 performance I found several bugs in the already existing code. They had nothing to do with #116.
The hicolor also affects Qt's QIconLoader.

To be able to compare the performance of #116 I "ported" it to master (a simple rebase produces merge conflicts).

I already measured the performance. Will post it ASAP.

[agaida]

@luis-pereira any news?

[luis-pereira]

@agaida It's ready.

[agaida]

cool, thanks

[agaida]

@luis-pereira - would you be so kind and rebase?

[luis-pereira]

@agaida Rebased.

[agaida]

@luis-pereira sometimes i hate git - could you rebase another time?

[luis-pereira]

@agaida git has no fault. The code changed in a way that can't be automatically rebased.

@palinek @tsujan
Does it make sense to use theme.followsColorScheme()) while searching for in /usr/share/pixmaps or for unthemed icons at /usr/share/icons ?

To allow the hicolor theme only at the end of the search hierarchy I move code from XdgIconLoader::findIconHelper() to XdgIconLoader::unthemedFallback() and XdgIconLoader::pixmapFallback().
When you guys did the followsColorScheme stuff you also used the theme.followsColorScheme()) on unthemed icons. Was this intended ?

[palinek]

Does it make sense to use theme.followsColorScheme()) while searching for in /usr/share/pixmaps or for unthemed icons at /usr/share/icons ?

You're right.... it is used wrongly there. ... and all the copy-paste snippets if (currentDir.exists(iconName + pngext)) { should be unified and put into one function (and this should be called on those 3 places).

[agaida]

@luis-pereira - i know :P

[luis-pereira]

@agaida @palinek Done.
This is more than a rebase tough.

[agaida]

Looks great, compile, work as expected - GTM