Re: oxygen icon name clasheroo
On Friday 01 April 2016 11:21:12 Harald Sitter wrote: > > Moving forward we could be pro-active WRT this. I am thinking: > 1) Make ECMInstallIcons have a hardcoded list of cmake projects that > may install to breeze (namely: breeze-icons). CMake warn vigorously if > a project that isn't one of those hardcoded ones wants to install to > breeze. > 2) Have build.kde.org check installed files and make sure nothing is > installed to share/icons/breeze either. Sounds good to me, please do :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: oxygen icon name clasheroo
On Thu, Mar 31, 2016 at 9:47 AM, David Faure wrote: > On Monday 21 March 2016 09:30:02 Harald Sitter wrote: >> On Sun, Mar 20, 2016 at 10:08 AM, David Faure wrote: >> > On Wednesday 16 March 2016 15:57:45 Harald Sitter wrote: >> >> Hola! >> >> >> >> Our most awesome icon maintainers wanted to carry over icon symlinking >> >> from breeze to oxygen, alas that turned up a whole slew of >> >> compatibility problems. >> >> >> >> examples: >> >> https://bugs.kde.org/show_bug.cgi?id=360605 >> >> https://bugs.kde.org/show_bug.cgi?id=360510 >> >> >> >> # Problem >> >> In kde4 software people used oxygen as the standard icon set and >> >> installed their own icons there. Since breeze covers all icons ever, >> >> replicating its coverage into oxygen means we have a million conflicts >> >> with (older?) tarballs of existing software that also install icons >> >> into oxygen under the same name. >> >> >> >> # Proposal >> >> We could get rid of this and all future conflicts if we shift the >> >> default oxygen icons into a subdirectory. >> >> >> >> So, we install the default icons to >> >> >> >> $prefix/share/icons/oxygen/base/22x22 >> >> $prefix/share/icons/oxygen/base/32x32 >> >> $prefix/share/icons/oxygen/base/... >> >> >> >> applications can thus continue to install to >> >> >> >> $prefix/share/icons/oxygen/22x22 >> >> $prefix/share/icons/oxygen/32x32 >> >> $prefix/share/icons/oxygen/... >> >> >> >> without conflicting with our base files what so ever. >> >> >> >> Downside of this is that the index.theme basically needs to list >> >> everything twice (once for base and once for main directory), which >> >> unfortunately incurs a bit of a runtime overhead. This is a bit of a >> >> crap situation we are in and I can't think of another solution to >> >> this. >> > >> > This doesn't sound like it matches the freedesktop.org icon theme spec. >> >> How so? >> https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html >> >> Directories >> list of subdirectories for this theme. For every subdirectory there >> must be a section in the index.theme file describing that directory. >> >> e.g. Directories=base/32x32/actions,32x32/actions >> >> and then Table 2. Per-Directory Keys >> >> [base/32x32/actions] >> Size=32 >> Context=Actions >> >> [32x32/actions] >> Size=32 >> Context=Actions > > Ah, OK, I didn't know the spec allowed such things. > >> > But if you rename oxygen/base/ to oxygen, and oxygen/ to hicolor, then it >> > does, AFAIK >> >> We can't really change oxygen/ at all, that's kind of the problem. >> Since existing apps install stuff into oxygen/ and expect it to be >> used by default in a kdelibs4 context. > > Right. I think we're still paying the price for an earlier mistake. > Apps should have kept installing their icons into hicolor rather than oxygen. Yes, absolutely. This should resolve with KF5 porting though. > AFAIU it's what the spec intended. But then when KDE switched to oxygen > the apps did the same, and this is what put us in the mess we're in right now. > I just wonder if we shouldn't pick a solution that transitions back into > something sane, where all apps (made by KDE or not) install into hicolor > again. > > It makes no sense to have no icon for KDE apps in an environment which doesn't > use the oxygen icon theme... > > But yeah this is more long term thinking. Short term your solution sounds like > it would work. I just worry that long term it only makes things worse. Every > 5 years > we add another layer of complexity > (hicolor, then hicolor+oxygen, then hicolor+oxygen+breeze, now > hicolor+oxygen+oxygen-base+breeze) Ah! We've learned though. Breeze does not actually inherit from Oxygen anymore. Breeze is a completely standalone theme at this point and only inherits from hicolor. The VDG purposefully made the breeze theme have 99.9% coverage across pretty much all our applications (and third party ones), it fully themes all icons we had in kdelibs4 times (regardless of whether they were in oxygen or the applications). So we'd have to continue compatibility for Oxygen, but it ends there. > Now some apps will start installing some stuff into breeze, right? ;) > And in 5 years we'll add another layer on top, and we'll have to keep all of > these existing 4 layers > for compatibility, because apps will start to install stuff into any of these > 4. Moving forward we could be pro-active WRT this. I am thinking: 1) Make ECMInstallIcons have a hardcoded list of cmake projects that may install to breeze (namely: breeze-icons). CMake warn vigorously if a project that isn't one of those hardcoded ones wants to install to breeze. 2) Have build.kde.org check installed files and make sure nothing is installed to share/icons/breeze either. This way we could discourage everyone from doing it and double sure that we don't do it in our own applications. Right now I have no app that actually installs to breeze at all, so perhaps we have a globally better understandi
Re: oxygen icon name clasheroo
https://git.reviewboard.kde.org/r/127537/ Yes applications should install to hicolor or to app local data directory to stop this in future Jonathan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: oxygen icon name clasheroo
On Monday 21 March 2016 09:30:02 Harald Sitter wrote: > On Sun, Mar 20, 2016 at 10:08 AM, David Faure wrote: > > On Wednesday 16 March 2016 15:57:45 Harald Sitter wrote: > >> Hola! > >> > >> Our most awesome icon maintainers wanted to carry over icon symlinking > >> from breeze to oxygen, alas that turned up a whole slew of > >> compatibility problems. > >> > >> examples: > >> https://bugs.kde.org/show_bug.cgi?id=360605 > >> https://bugs.kde.org/show_bug.cgi?id=360510 > >> > >> # Problem > >> In kde4 software people used oxygen as the standard icon set and > >> installed their own icons there. Since breeze covers all icons ever, > >> replicating its coverage into oxygen means we have a million conflicts > >> with (older?) tarballs of existing software that also install icons > >> into oxygen under the same name. > >> > >> # Proposal > >> We could get rid of this and all future conflicts if we shift the > >> default oxygen icons into a subdirectory. > >> > >> So, we install the default icons to > >> > >> $prefix/share/icons/oxygen/base/22x22 > >> $prefix/share/icons/oxygen/base/32x32 > >> $prefix/share/icons/oxygen/base/... > >> > >> applications can thus continue to install to > >> > >> $prefix/share/icons/oxygen/22x22 > >> $prefix/share/icons/oxygen/32x32 > >> $prefix/share/icons/oxygen/... > >> > >> without conflicting with our base files what so ever. > >> > >> Downside of this is that the index.theme basically needs to list > >> everything twice (once for base and once for main directory), which > >> unfortunately incurs a bit of a runtime overhead. This is a bit of a > >> crap situation we are in and I can't think of another solution to > >> this. > > > > This doesn't sound like it matches the freedesktop.org icon theme spec. > > How so? > https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html > > Directories > list of subdirectories for this theme. For every subdirectory there > must be a section in the index.theme file describing that directory. > > e.g. Directories=base/32x32/actions,32x32/actions > > and then Table 2. Per-Directory Keys > > [base/32x32/actions] > Size=32 > Context=Actions > > [32x32/actions] > Size=32 > Context=Actions Ah, OK, I didn't know the spec allowed such things. > > But if you rename oxygen/base/ to oxygen, and oxygen/ to hicolor, then it > > does, AFAIK > > We can't really change oxygen/ at all, that's kind of the problem. > Since existing apps install stuff into oxygen/ and expect it to be > used by default in a kdelibs4 context. Right. I think we're still paying the price for an earlier mistake. Apps should have kept installing their icons into hicolor rather than oxygen. AFAIU it's what the spec intended. But then when KDE switched to oxygen the apps did the same, and this is what put us in the mess we're in right now. I just wonder if we shouldn't pick a solution that transitions back into something sane, where all apps (made by KDE or not) install into hicolor again. It makes no sense to have no icon for KDE apps in an environment which doesn't use the oxygen icon theme... But yeah this is more long term thinking. Short term your solution sounds like it would work. I just worry that long term it only makes things worse. Every 5 years we add another layer of complexity (hicolor, then hicolor+oxygen, then hicolor+oxygen+breeze, now hicolor+oxygen+oxygen-base+breeze) Now some apps will start installing some stuff into breeze, right? ;) And in 5 years we'll add another layer on top, and we'll have to keep all of these existing 4 layers for compatibility, because apps will start to install stuff into any of these 4. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: oxygen icon name clasheroo
I'm coming across more of these clashes. Just had one in Calligra. So yes I think it's a good idea to move the frameworks Oxygen icons to a new path. Jonathan On 21 March 2016 at 08:30, Harald Sitter wrote: > On Sun, Mar 20, 2016 at 10:08 AM, David Faure wrote: >> On Wednesday 16 March 2016 15:57:45 Harald Sitter wrote: >>> Hola! >>> >>> Our most awesome icon maintainers wanted to carry over icon symlinking >>> from breeze to oxygen, alas that turned up a whole slew of >>> compatibility problems. >>> >>> examples: >>> https://bugs.kde.org/show_bug.cgi?id=360605 >>> https://bugs.kde.org/show_bug.cgi?id=360510 >>> >>> # Problem >>> In kde4 software people used oxygen as the standard icon set and >>> installed their own icons there. Since breeze covers all icons ever, >>> replicating its coverage into oxygen means we have a million conflicts >>> with (older?) tarballs of existing software that also install icons >>> into oxygen under the same name. >>> >>> # Proposal >>> We could get rid of this and all future conflicts if we shift the >>> default oxygen icons into a subdirectory. >>> >>> So, we install the default icons to >>> >>> $prefix/share/icons/oxygen/base/22x22 >>> $prefix/share/icons/oxygen/base/32x32 >>> $prefix/share/icons/oxygen/base/... >>> >>> applications can thus continue to install to >>> >>> $prefix/share/icons/oxygen/22x22 >>> $prefix/share/icons/oxygen/32x32 >>> $prefix/share/icons/oxygen/... >>> >>> without conflicting with our base files what so ever. >>> >>> Downside of this is that the index.theme basically needs to list >>> everything twice (once for base and once for main directory), which >>> unfortunately incurs a bit of a runtime overhead. This is a bit of a >>> crap situation we are in and I can't think of another solution to >>> this. >> >> This doesn't sound like it matches the freedesktop.org icon theme spec. > > How so? > https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html > > Directories > list of subdirectories for this theme. For every subdirectory there > must be a section in the index.theme file describing that directory. > > e.g. Directories=base/32x32/actions,32x32/actions > > and then Table 2. Per-Directory Keys > > [base/32x32/actions] > Size=32 > Context=Actions > > [32x32/actions] > Size=32 > Context=Actions > >> But if you rename oxygen/base/ to oxygen, and oxygen/ to hicolor, then it >> does, AFAIK > > We can't really change oxygen/ at all, that's kind of the problem. > Since existing apps install stuff into oxygen/ and expect it to be > used by default in a kdelibs4 context. What we could do is make > oxygen-base a standalone theme and link "oxygen" with "oxygen-base" > through inheritance. > That's not quite as good though because we want to override > application icons through the actual theme. So what we would need is > "oxygen-base" to be the selected theme and then inherit "oxygen" > (where apps install icons) to be the fallback. Since the uid of a > theme is its folder name and we can't feasibly change that without > breaking something that's not really useful either. > > That said, we could go down the two theme route and simply accept that > applications that install to "oxygen" will be overriding consistent > theme icons from "oxygen-base". I'd rather deal with the directories > approach outlined above. > > HS > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: oxygen icon name clasheroo
On Sun, Mar 20, 2016 at 10:08 AM, David Faure wrote: > On Wednesday 16 March 2016 15:57:45 Harald Sitter wrote: >> Hola! >> >> Our most awesome icon maintainers wanted to carry over icon symlinking >> from breeze to oxygen, alas that turned up a whole slew of >> compatibility problems. >> >> examples: >> https://bugs.kde.org/show_bug.cgi?id=360605 >> https://bugs.kde.org/show_bug.cgi?id=360510 >> >> # Problem >> In kde4 software people used oxygen as the standard icon set and >> installed their own icons there. Since breeze covers all icons ever, >> replicating its coverage into oxygen means we have a million conflicts >> with (older?) tarballs of existing software that also install icons >> into oxygen under the same name. >> >> # Proposal >> We could get rid of this and all future conflicts if we shift the >> default oxygen icons into a subdirectory. >> >> So, we install the default icons to >> >> $prefix/share/icons/oxygen/base/22x22 >> $prefix/share/icons/oxygen/base/32x32 >> $prefix/share/icons/oxygen/base/... >> >> applications can thus continue to install to >> >> $prefix/share/icons/oxygen/22x22 >> $prefix/share/icons/oxygen/32x32 >> $prefix/share/icons/oxygen/... >> >> without conflicting with our base files what so ever. >> >> Downside of this is that the index.theme basically needs to list >> everything twice (once for base and once for main directory), which >> unfortunately incurs a bit of a runtime overhead. This is a bit of a >> crap situation we are in and I can't think of another solution to >> this. > > This doesn't sound like it matches the freedesktop.org icon theme spec. How so? https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html Directories list of subdirectories for this theme. For every subdirectory there must be a section in the index.theme file describing that directory. e.g. Directories=base/32x32/actions,32x32/actions and then Table 2. Per-Directory Keys [base/32x32/actions] Size=32 Context=Actions [32x32/actions] Size=32 Context=Actions > But if you rename oxygen/base/ to oxygen, and oxygen/ to hicolor, then it > does, AFAIK We can't really change oxygen/ at all, that's kind of the problem. Since existing apps install stuff into oxygen/ and expect it to be used by default in a kdelibs4 context. What we could do is make oxygen-base a standalone theme and link "oxygen" with "oxygen-base" through inheritance. That's not quite as good though because we want to override application icons through the actual theme. So what we would need is "oxygen-base" to be the selected theme and then inherit "oxygen" (where apps install icons) to be the fallback. Since the uid of a theme is its folder name and we can't feasibly change that without breaking something that's not really useful either. That said, we could go down the two theme route and simply accept that applications that install to "oxygen" will be overriding consistent theme icons from "oxygen-base". I'd rather deal with the directories approach outlined above. HS ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: oxygen icon name clasheroo
On Wednesday 16 March 2016 15:57:45 Harald Sitter wrote: > Hola! > > Our most awesome icon maintainers wanted to carry over icon symlinking > from breeze to oxygen, alas that turned up a whole slew of > compatibility problems. > > examples: > https://bugs.kde.org/show_bug.cgi?id=360605 > https://bugs.kde.org/show_bug.cgi?id=360510 > > # Problem > In kde4 software people used oxygen as the standard icon set and > installed their own icons there. Since breeze covers all icons ever, > replicating its coverage into oxygen means we have a million conflicts > with (older?) tarballs of existing software that also install icons > into oxygen under the same name. > > # Proposal > We could get rid of this and all future conflicts if we shift the > default oxygen icons into a subdirectory. > > So, we install the default icons to > > $prefix/share/icons/oxygen/base/22x22 > $prefix/share/icons/oxygen/base/32x32 > $prefix/share/icons/oxygen/base/... > > applications can thus continue to install to > > $prefix/share/icons/oxygen/22x22 > $prefix/share/icons/oxygen/32x32 > $prefix/share/icons/oxygen/... > > without conflicting with our base files what so ever. > > Downside of this is that the index.theme basically needs to list > everything twice (once for base and once for main directory), which > unfortunately incurs a bit of a runtime overhead. This is a bit of a > crap situation we are in and I can't think of another solution to > this. This doesn't sound like it matches the freedesktop.org icon theme spec. But if you rename oxygen/base/ to oxygen, and oxygen/ to hicolor, then it does, AFAIK -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
oxygen icon name clasheroo
Hola! Our most awesome icon maintainers wanted to carry over icon symlinking from breeze to oxygen, alas that turned up a whole slew of compatibility problems. examples: https://bugs.kde.org/show_bug.cgi?id=360605 https://bugs.kde.org/show_bug.cgi?id=360510 # Problem In kde4 software people used oxygen as the standard icon set and installed their own icons there. Since breeze covers all icons ever, replicating its coverage into oxygen means we have a million conflicts with (older?) tarballs of existing software that also install icons into oxygen under the same name. # Proposal We could get rid of this and all future conflicts if we shift the default oxygen icons into a subdirectory. So, we install the default icons to $prefix/share/icons/oxygen/base/22x22 $prefix/share/icons/oxygen/base/32x32 $prefix/share/icons/oxygen/base/... applications can thus continue to install to $prefix/share/icons/oxygen/22x22 $prefix/share/icons/oxygen/32x32 $prefix/share/icons/oxygen/... without conflicting with our base files what so ever. Downside of this is that the index.theme basically needs to list everything twice (once for base and once for main directory), which unfortunately incurs a bit of a runtime overhead. This is a bit of a crap situation we are in and I can't think of another solution to this. Input welcome HS ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
