[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: Re: Breeze and ECM are incompatible for installing icons
From: David Jarvie <djarvie () kde ! org>
Date: 2023-11-04 0:25:07
Message-ID: 96D07D96-8636-419D-AC05-69C41BBFD1C8 () kde ! org
[Download RAW message or body]
On 3 November 2023 22:47:55 GMT, Albert Astals Cid <aacid@kde.org> wrote:
> El divendres, 3 de novembre de 2023, a les 13:15:37 (CET), David Jarvie va
> escriure:
> > On 3 November 2023 09:13:15 GMT, Carl Schwan <carl@carlschwan.eu> wrote:
> > > On Friday, November 3, 2023 12:46:20 AM CET Albert Astals Cid wrote:
> > > > El dijous, 2 de novembre de 2023, a les 14:36:16 (CET), David Jarvie va
> > > >
> > > > escriure:
> > > > > Breeze installs its icons in a different directory structure from
> > > > > other
> > > > > icon themes, with the result that the ECM cmake command
> > > > > ecm_install_icons
> > > > > doesn't work for Breeze icons. The only way to install an application
> > > > > specific Breeze icon is to hard code its location, for example
> > > > > "${KDE_INSTALL_ICONDIR}/breeze/actions/22/".
> > > >
> > > > Why are you installing icons in breeze icon theme if you're not the
> > > > breeze
> > > > icon theme?
> >
> > I wanted to provide an icon that is visually compatible with the Breeze
> > theme, and Breeze doesn't supply it.
>
> What if another application wants to supply an icon with the same name that is
> also visually compatible with the Breeze theme?
>
> Should it overwrite the one that your application provides?
Perhaps I should rename the icon to include the application name to avoid possible \
conflicts.
There is always the potential for name conflicts, but that doesn't change the issue, \
which is that applications (KDE or third party) should be able to correctly install \
icons for any icon theme which is known to KDE, at least, using ecm_install_icons.
> > > > Seems wrong to me.
> > >
> > > Yes, it's wrong. We made the same mistake in Tokodon and the correct way
> > > to do it is to install in the hicolor theme. This allow the theme to
> > > overwrite the icon if they want and don't force you to hardcode the
> > > breeze icon theme.
> > Third party applications are quite entitled to install their own icons in
> > the Breeze theme, and currently this won't work using the ECM function.
> > This issue doesn't just apply to applications which are part of KDE.
--
David Jarvie
KAlarm author, KDE developer
[Attachment #3 (text/html)]
<!DOCTYPE html><html><body><div dir="auto"><br><br>On 3 November 2023 22:47:55 GMT, \
Albert Astals Cid <aacid@kde.org> wrote:<br>> El divendres, 3 de novembre de \
2023, a les 13:15:37 (CET), David Jarvie va <br>> escriure:<br>> > On 3 \
November 2023 09:13:15 GMT, Carl Schwan <carl@carlschwan.eu> wrote:<br>> \
> > On Friday, November 3, 2023 12:46:20 AM CET Albert Astals Cid \
wrote:<br>> > > > El dijous, 2 de novembre de 2023, a les 14:36:16 (CET), \
David Jarvie va<br>> > > > <br>> > > > escriure:<br>> > \
> > > Breeze installs its icons in a different directory structure \
from<br>> > > > > other<br>> > > > > icon themes, with \
the result that the ECM cmake command<br>> > > > > \
ecm_install_icons<br>> > > > > doesn't work for Breeze icons. The only \
way to install an application<br>> > > > > specific Breeze icon is to \
hard code its location, for example<br>> > > > > \
"${KDE_INSTALL_ICONDIR}/breeze/actions/22/".<br>> > > > <br>> > \
> > Why are you installing icons in breeze icon theme if you're not the<br>> \
> > > breeze<br>> > > > icon theme?<br>> > <br>> > I \
wanted to provide an icon that is visually compatible with the Breeze<br>> > \
theme, and Breeze doesn't supply it.<br>> <br>> What if another application \
wants to supply an icon with the same name that is <br>> also visually compatible \
with the Breeze theme?<br>> <br>> Should it overwrite the one that your \
application provides?<br><br>Perhaps I should rename the icon to include the \
application name to avoid possible conflicts.<br><br>There is always the potential \
for name conflicts, but that doesn't change the issue, which is that applications \
(KDE or third party) should be able to correctly install icons for any icon theme \
which is known to KDE, at least, using ecm_install_icons.<br><br>> > > > \
Seems wrong to me.<br>> > > <br>> > > Yes, it's wrong. We made the \
same mistake in Tokodon and the correct way<br>> > > to do it is to install \
in the hicolor theme. This allow the theme to<br>> > > overwrite the icon if \
they want and don't force you to hardcode the<br>> > > breeze icon \
theme.<br>> > Third party applications are quite entitled to install their own \
icons in<br>> > the Breeze theme, and currently this won't work using the ECM \
function.<br>> > This issue doesn't just apply to applications which are part \
of KDE.<br></div><div dir="auto">--<br>David Jarvie<br>KAlarm author, KDE \
developer<br></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic