On 23 September 2015 at 22:55, Albert Astals Cid <aa...@kde.org> wrote:
> El Dimecres, 23 de setembre de 2015, a les 22:12:39, Jaroslaw Staniek va
> escriure:
>> On 23 September 2015 at 09:31, Harald Sitter <sit...@kde.org> wrote:
>> >> You mean if {appname} and {appname}-foo doesn't right?
>> >>
>> >> the XDG icon spec has some kind of inheritance built into the name so
>> >>
>> >> someaction.png
>> >>
>> >> is chosen if you don't have
>> >>
>> >> someaction-veryspecific.png
>> >>
>> >> So you may want to use another way of prefixing that doesn't mess with
>> >> that
>> >> like and _ or just nothing at all.
>> >
>> > I seem to recall this actually coming up in Randa. IIRC the icon theme
>> > artists would very much prefer if custom icons you want to provide are
>> > using the specification system outlined by the theme spec and are
>> > installed to hicolor. Which then behaves exactly as Albert outlined,
>> > when QIcon resolves for "icon-specific-very" the following order
>> > applies:
>> >
>> > icon.png < icon-specific.png < icon-specific-very.png
>> >
>> > So you could have places/database-implode-kexi.png which makes the
>> > icon you installed themable as database-implode.png, but at the same
>> > time makes it non-conflicting with other applications that may want to
>> > install database-implode to hicolor.
>> >
>> > On a related note, since it came up in the original mail: yes, breeze
>> > is a default fallback in kf5 applications *as long as the
>> > frameworkintegration platformtheme is installed and loaded* [1].
>> > Additionally breeze currently inherits from oxygen, through the theme
>> > config itself, this might go away at some point though. So right now
>> > the effective resolution order is userTheme > breeze > (oxygen) >
>> > hicolor.
>>
>> Thanks for this info Harald and Albert!
>>
>> Some background about motivation.
>> My idea is to default to breeze on non-Plasma platform and on without
>> the frameworkintegration platformtheme.
>> And avoid surprising on Windows and Mac. Silently hoping that some
>> reasonable habits could help to convince someone to use KF5 for
>> general cross platform apps developments.
>>
>> Related thing: I don't expect new app-specific icons/emblems will be
>> prepared for oxygen or various themes.
>> Surely it's better for _truly_ 3rd-party plugins (that I expect to
>> appear more one day) to know the theme recommendations and defaults --
>> I see consistency as more valuable than freedom of theming for complex
>> apps.
>> For some time I was also wondering that documentation's screenshots
>> have to pick one theme anyway, so better not to confuse users...
>>
>> Another thing: should I wonder that in my strace logs, for icons that
>> exist for hicolor only, the "userTheme > breeze > (oxygen) > hicolor"
>> scheme results in 4 * 'dozens of lookups'? Because of the fallback
>> strategies this cannot be cached I guess, only actual content is
>> cached. A simple filesystem stat() may be cheap but there are lots of
>> it. For example a custom file that sits in hicolor only when I have
>> breeze theme selected calls stat() 515 times. (there's no the
>> 'userTheme' step). To get just a simple and single 4KiB icon, n*515
>> memory (re)allocations are needed.
>
> Yes, see the "QIcon::fromTheme(xxx, someFallback)" thread in kde-frameworks-
> devel
>
>>
>> As I mentioned in this thread quite a few KDE apps use .qrc for custom
>> icons but no idea if this intentional or rather a convenient approach
>> well supported by Qt Designer and .ui files.
>
> Do they? I've never seen any :DYes, And I don't mean qml components but C++ apps/libs. http://lxr.kde.org/search?_filestring=.*\.qrc&_advanced=1&_string= >> Thirdly, I suppose it's possible to indicate in the code that I am >> looking for a "place" icon group for example. That would slash the >> number of lookups and also limit conflicts. Maybe that would be a >> violation of behaviour required by fd.o? No idea. >> >> My fresh test results in one observation, network-server-database-kexi >> which causes the above 515 stat()'s >> sits in share/icons/hicolor/22x22/places/network-server-database-kexi.svg. >> It is not found, instead >> share/icons/breeze/places/22/network-server-database.svg is returned. >> This is maybe because network-server-database is a prefix equal to an >> existing icon? Why is it of higher priority than the exact match? > > You mean that breeze/network-server-database.svg is picked over > hicolor/network-server-database-kexi.svg when requesting network-server- > database-kexi ? Yes. Strace shows no attempts to find network-server-database-kexi from hicolor. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
