Re: libkexiv2, libkdcraw (Re: Collection of packaging notes)
On Fri, Nov 3, 2023 at 12:57 PM Albert Astals Cid wrote: > El dimecres, 1 de novembre de 2023, a les 13:25:42 (CET), Friedrich W. H. > Kossebau va escriure: > > Am Mittwoch, 1. November 2023, 11:55:08 CET schrieb Christophe Marin: > > > With various alpha coming out soon, here are the notes added to my > > > packages > > > when I started packaging snapshots and still present. > > > > Thanks for the report. > > > > Everyone: > > Could we perhaps establish some wiki page where such things could be > > tracked? > > > I don't particularly think wiki pages are good for tracking issues, we > have > issue trackers for that ;) > > I've proposed elsewhere to re-use the release-service issue tracker, but > honestly I've no idea if anyone can create issues here > https://invent.kde.org/teams/release-service/issues/-/issues/ > or only team members, if it's only team members, it's not a great place to > put > things i guess unless we add lots of folks to the team (which i'm not > against > but they may be). > I have now created https://invent.kde.org/teams/release-service/qt6-mega-release to help keep the issues here separate from the ones you've been using to track and manage the Gear releases. Issues can be created by anyone, but certain actions on those issues - such as moving them around the board, labelling them, etc. do require membership of the group at the reporter or developer level. See https://docs.gitlab.com/ee/user/permissions.html for more information on this. Cheers, Ben > > Cheers, > Albert > > > > - Non frameworks modules installing libKF*.so > > > libkexiv2 (libKF6KExiv2.so) > > > > Any code ideas for naming it, given there is already a number suffix, > coming > > from the library that is wrapped? > > > > Similar need also for libkomparediff2, where the 2 is referring to > diffing 2 > > things, not a version number. > > > > > libkdcraw (libKF6KDcraw.so) > > > > I have an old patch locally somehow never finished, will brush up as MR > > tonight hopefully. (promised in > https://invent.kde.org/graphics/libkdcraw/-/ > > merge_requests/9#note_646025 ) > > > > Cheers > > Frriedrich > > > > >
Re: Breeze and ECM are incompatible for installing icons
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?
>
> 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.
Re: Breeze and ECM are incompatible for installing icons
On 3 November 2023 09:13:15 GMT, Carl Schwan 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.
> > 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
Re: Breeze and ECM are incompatible for installing icons
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 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?
Cheers,
Albert
> > > 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
Re: Breeze and ECM are incompatible for installing icons
On 3 November 2023 22:47:55 GMT, Albert Astals Cid 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 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
