Re: Icons installed by apps
On Wed, Sep 23, 2015 at 12:17 AM, Albert Astals Cid wrote:
> El Dimarts, 22 de setembre de 2015, a les 23:01:06, Jaroslaw Staniek va
> escriure:
>> On 22 September 2015 at 22:55, Matthias Klumpp
> wrote:
>> > Am 22.09.2015 10:32 nachm. schrieb "Albert Astals Cid" :
>> >> El Dimarts, 22 de setembre de 2015, a les 14:17:28, Jaroslaw Staniek va
>> >>
>> >> escriure:
>> >> > Hello,
>> >> > A couple of related questions while wrestling with issues such as [1].
>> >> >
>> >> > Let's assume Kexi app installs some icons to
>> >> > PREFIX/share/kexi/icons/oxygen/32x32/places/ or
>> >> > PREFIX/share/kexi/icons/breeze/32x32/places.
>> >> > Can these be searched by the icon engine?
>> >> >
>> >> > In kdelibs4 times PREFIX/share/apps/kexi/icons/oxygen/ was searched at
>> >> > least and icons were used if names were globally unique (overriding
>> >> > mimetype icons did not work).
>> >> >
>> >> > Now in kf5 times I guess I shouldn't install to
>> >> > PREFIX/share/icons/breeze? I do not feel safe with this. I don't even
>> >> > know if it's breeze/ subdir or some other name is guaranteed to exist
>> >> > on a kf5 installation. However if I have guarantees, I am fine with
>> >> > any solution.
>> >>
>> >> Install to hicolor?
>> >
>> > Indeed. If you want to follow the freedesktop spec, hicolor is the place
>> > to
>> > store these icons.
>> > Other tools, like AppStream, will also be able to find the icons then, and
>> > so do all other desktop environments supporting the xdg spec.
>>
>> That's good. Thanks. Now if I try to make icon name unique, I am
>> adding {appname}- prefix.
>> But then {appname} icon (if exists) is used instead. Ideas?
>
> 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.
HS
[1]
http://lxr.kde.org/search?_filestring=&_string=QPlatformTheme%3A%3ASystemIconThemeName
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Icons installed by apps
On Wed, Sep 23, 2015 at 11:27 PM, Jaroslaw Staniek wrote: >>> 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. This is absolutely intentional and in fact why you ought to use the suffix notation. The idea behind this and really the entire fd.o specs regarding icons is that your application can be themed to match its environment 100%. network-server-database[breeze] outranks network-server-database-kexi[hicolor] because breeze > hicolor. In GTKish environments it would use whatever icon theme is set there. If one were to provide a platformtheme for OSX to resolve icons with that would then outscore hicolor, and so on and so forth. The resolution order: - network-server-database-kexi[breeze] - network-server-database[breeze] - network-server[breeze] - network[breeze] [...fallbacks of breeze...] - network-server-database-kexi[hicolor] - network-server-database[hicolor] - network-server[hicolor] - network[hicolor] You get the idea. As for why that matters have a look at https://mail.kde.org/pipermail/amarok-devel/2015-July/013499.html for some thoughts on the theming problem. So, I will wholeheartedly encourage you to install hicolor icons as a platform independent fallback in case the QPA platform theme for frameworks is not installed. BUT do so using the suffix notation so that the VDG can fully icon theme Kexi to visually integrate with the Breeze style if the theme plugin is available, otherwise the application will look foreign and partly themed in hicolor and breeze at the same time (as seen with Amarok above). HS ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: kexi, kdb, kproperty, kreport ready to translate
FWIW unrelated to this ... kexi at least doesn't seem to use the podir variable from https://websvn.kde.org/trunk/l10n-kf5/scripts/extract-messages.sh?revision=1463478&view=markup not sure if it should? On Tue, Sep 13, 2016 at 1:32 AM, Luigi Toscano wrote: > Il 13 settembre 2016 00:53:44 CEST, Jaroslaw Staniek ha > scritto: >>Hi Luigi, >>kexi, kdb, kproperty, kreport are ready to translate, string freeze is >>on. >> >> >>PS: The releaseme tool gives no translations for Kexi (so tarballs I'll >>upload soon won't include translation files). >>kdb, kproperty, kreport tarballs include them. > > I can only tell you again to talk with Harald; I could not check how > releaseme works. > Or please use create_tarball_kf5 (see the example config) in the meantime. > >>I am wondering if this is because >>repo-metadata/projects/calligra/kexi/metadata.yaml contains this: >> >>projectpath: calligra/kexi >> >>.. while the messages are still in calligra/? >>I am experiencing the same issue is with Krita but maybe that's not >>noticed >>only because the Krita Team does not seem to use releaseme for >>packaging. >> >>Another reason for having a kexi/ subdir would be: the .po files from >>various apps and plugins are too a bit too mixed within >>messages/calligra/ >>so maybe some hierarchy would be good? > > No, no, the structure of translation files has nothing to do with it. Proof: > the existing tarballs of other projects. > > -- > Luigi
Re: kexi, kdb, kproperty, kreport ready to translate
On Tue, Sep 13, 2016 at 10:53 AM, Pino Toscano wrote: > On Tuesday, 13 September 2016 10:40:35 CEST Harald Sitter wrote: >> FWIW unrelated to this ... kexi at least doesn't seem to use the podir >> variable from >> https://websvn.kde.org/trunk/l10n-kf5/scripts/extract-messages.sh?revision=1463478&view=markup >> not sure if it should? > > It does, see kexi_xgettext.sh. nevermind then > Please don't switch topic, and help debugging your own scripts. I can't help but find this passive aggressive.
Re: KDiagram - Persistent FTBFS for stable branch on Windows
On 12.10.20 11:23, Milian Wolff wrote: > On Montag, 12. Oktober 2020 11:11:22 CEST Ben Cooksley wrote: >> Hi KDiagram Developers, >> >> The stable branch of KDiagram has been persistently failing to build from >> source now on Windows for a period greater than 5 days. > > Hey Ben, > > can you link me to such a CI failure? Then I could try to blind-fix it, as I > don't have a KDE-on-windows setup here. But maybe it's simple enough to fix > even without that. Just FTR for everyone's benefit: https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Windows#Virtual_Machines Ever so useful to have if one deals with windows breakage more than once a year ;) HS signature.asc Description: OpenPGP digital signature
