Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 17:56:38, Eike Hein wrote: On 11.09.2014 17:22, Kevin Krammer wrote: Hicolor is there for cases where the setup fails to provide any workspace or distribution specific theme. Yes. So I'm thinking ahead and telling you how that setup looks like for a workspace: - Write a Qt platform plugin. Needs coding chops. We have them. What about workspaces which don't? What about all the other toolkits be- sides Qt? - Swap out icons in hicolor. Which do you think happens? Depends on the wanted results. A platform plugin provide platform integration which icons are only a small part of. If the platform vendor wants Qt application to properly integrate with their choice of workspace, they will have a platform integration plugins. If they just want to have icons, they are very well able to ship their own version of hicolor fallback icons. This does not conflict with having a non-broken hicolor theme package to start with. But why not just have your theme as an explicit theme like everyone else and only get your theme in case the fallback path is triggered? Because making Qt aware of an explicit theme involves writing a Qt platform plugin. It means if you're a sys admin / distro you can no longer solve your problem on the spec level (unless you swap out icons in hicolor), you need to be aware Qt exists. Seems like a layering violation to me. As I said above, it depends on the level of integration you'd like to achieve. There are lots of integration points provided by said plugin. Sharing a setting that indicates a default theme name is of course a good goal, doesn't however fix the problem of the fallback being incomplete. No, but it makes it a lot easier for distros to provide a complete fallback (- installing Oxygen or something else, setting it as preferred fallback). It's less work than maintaining a complete hi- color no one can agree on. I don't see why it would be difficult to agree on having a non-broken fallback. Or do you mean install the custom theme twice, once as itself and once as hicolor? Wait - I think I now understand why we're having trouble communicating about this. You think a distro has the option to install Oxygen *as* hicolor, right, making my preferred fallback thing seem redundant? That's not so - because numerous apps install app icons *into* the hicolor folder structure, including KDE apps, and those can conflict with the icons in a theme. For distro packagers that means they'd have to fix numerous package installs to eliminate those conflicts. No, I mean providing their own hicolor theme if they want to (ab)use the fallback as their integration point. I really have to read the spec soon, but I have my doubt that it lists any app specific icons. Thus installing such into its paths should not conflict with anything already there. So using any given theme *as* hicolor doesn't fly without manual merging/maintenance work for packagers, which is what I suggest to avoid with a 'preferred system fallback' config knob. Assuming that a vendor wants to override the default hicolor package, then yes that will obviously require maintenance. This is no different with any other deviation from upstream. Again, having a shared setting, exposed via whatever mechanism (env variable, X11 property, file, ) is orthogonal to having a working fallback. The fallback is hit when no other means of lookup, whether configurable or hardcoded, resulted in a matching icon. So it *must* at least contain all icons that are specified in the spec, it is an icon loader's last resort. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Wednesday 03 September 2014, Albert Astals Cid wrote: Porting guide lies in saying that KIcon should be replaced with QIcon::fromTheme since KIcon defauted to oxygen icon theme and obviously QIcon::fromTheme doesn't do that. Please someone provide a solution for this problem or undeprecate KIcon. This is blocking the porting of my applications. Is there a problem with using QIcon::setThemeName(Oxygen)? It you want to use the system defined theme Qt needs to detect the desktop platform and at least the KDE platform theme already defaults to Oxygen. If that is not enough, it might be possible to add some kind of QIcon fallback theme setting. `Allan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
El Divendres, 12 de setembre de 2014, a les 12:04:38, Allan Sandfeld Jensen va escriure: On Wednesday 03 September 2014, Albert Astals Cid wrote: Porting guide lies in saying that KIcon should be replaced with QIcon::fromTheme since KIcon defauted to oxygen icon theme and obviously QIcon::fromTheme doesn't do that. Please someone provide a solution for this problem or undeprecate KIcon. This is blocking the porting of my applications. Is there a problem with using QIcon::setThemeName(Oxygen)? It you want to use the system defined theme Qt needs to detect the desktop platform and at least the KDE platform theme already defaults to Oxygen. If that is not enough, it might be possible to add some kind of QIcon fallback theme setting. Read the rest of the thread, it's not that simple :) Cheers, Albert `Allan ___ 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: There's no proper replacement for KIcon
On Wednesday, 2014-09-10, 23:43:15, Albert Astals Cid wrote: El Dimarts, 9 de setembre de 2014, a les 16:25:26, Kevin Krammer va escriure: On Sunday, 2014-09-07, 10:27:06, Albert Astals Cid wrote: So as I see it, there's three options: * Do nothing, and expect that people have to set one of XDG_CURRENT_DESKTOP, KDE_FULL_SESSION, GNOME_DESKTOP_SESSION_ID or DESKTOP_SESSION environment variables to get icons * Do the change/hack to QGenericUnixTheme::themeHint return any of the themes in xdgIconThemePaths that is not hicolor * Talk to the xdg-people to include a way to get the current icon theme and use that in QGenericUnixTheme::themeHint Wouldn't a fourth option be to make sure that hicolor is actually a proper fallback as specified? Applications already are more or less required to install their fallbacks in hicolor, so the shared icons should be there as well, no? I don't think it makes sense, i mean who would install stuff to hicolor/actions/document-open.png ? oxygen? breeze? tango? someothericonset? For applications it makes sense tha application to install to hicolor since the application owns the name for that icon, but noone actually owns the document-open.png action so that's why i think it makes no sense for it to be there. The rule to always also install an application icon into Hicolor was meant as an example of a general intent that Hicolor be fully usable. I don't know the details of the icon spec but my understanding was that document-open was a specified standard name. Assuming that is the case it would have implied for me that an icon of this name is always present. If not in the current theme then at least in the fallback Hicolor theme. Again based on these prior assumptions on the spec, not having that icon in Hicolor would constitute a bug in the Hicolor theme and should be fixed by adding the icon there,no? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
El Dijous, 11 de setembre de 2014, a les 08:46:11, Kevin Krammer va escriure: On Wednesday, 2014-09-10, 23:43:15, Albert Astals Cid wrote: El Dimarts, 9 de setembre de 2014, a les 16:25:26, Kevin Krammer va escriure: On Sunday, 2014-09-07, 10:27:06, Albert Astals Cid wrote: So as I see it, there's three options: * Do nothing, and expect that people have to set one of XDG_CURRENT_DESKTOP, KDE_FULL_SESSION, GNOME_DESKTOP_SESSION_ID or DESKTOP_SESSION environment variables to get icons * Do the change/hack to QGenericUnixTheme::themeHint return any of the themes in xdgIconThemePaths that is not hicolor * Talk to the xdg-people to include a way to get the current icon theme and use that in QGenericUnixTheme::themeHint Wouldn't a fourth option be to make sure that hicolor is actually a proper fallback as specified? Applications already are more or less required to install their fallbacks in hicolor, so the shared icons should be there as well, no? I don't think it makes sense, i mean who would install stuff to hicolor/actions/document-open.png ? oxygen? breeze? tango? someothericonset? For applications it makes sense tha application to install to hicolor since the application owns the name for that icon, but noone actually owns the document-open.png action so that's why i think it makes no sense for it to be there. The rule to always also install an application icon into Hicolor was meant as an example of a general intent that Hicolor be fully usable. I don't know the details of the icon spec but my understanding was that document-open was a specified standard name. Correct. Assuming that is the case it would have implied for me that an icon of this name is always present. Should be always present in valid themes, yes. If not in the current theme then at least in the fallback Hicolor theme. Again based on these prior assumptions on the spec, not having that icon in Hicolor would constitute a bug in the Hicolor theme and should be fixed by adding the icon there,no? There's no hicolor theme per se. Only a bunch of empty folders http://www.freedesktop.org/software/icon-theme/releases/hicolor-icon-theme-0.5.tar.gz Cheers, Albert Cheers, Kevin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 09:33:23, Albert Astals Cid wrote: El Dijous, 11 de setembre de 2014, a les 08:46:11, Kevin Krammer va escriure: The rule to always also install an application icon into Hicolor was meant as an example of a general intent that Hicolor be fully usable. I don't know the details of the icon spec but my understanding was that document-open was a specified standard name. Correct. Assuming that is the case it would have implied for me that an icon of this name is always present. Should be always present in valid themes, yes. If not in the current theme then at least in the fallback Hicolor theme. Again based on these prior assumptions on the spec, not having that icon in Hicolor would constitute a bug in the Hicolor theme and should be fixed by adding the icon there,no? There's no hicolor theme per se. Only a bunch of empty folders http://www.freedesktop.org/software/icon-theme/releases/hicolor-icon-theme-0 .5.tar.gz Is there a maintainer for this package? IMHO the only sensible solution is to make sure that it actually contains the icons specified. Without it is rather useless as a specification base line. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
El Dijous, 11 de setembre de 2014, a les 10:57:17, Kevin Krammer va escriure: On Thursday, 2014-09-11, 09:33:23, Albert Astals Cid wrote: El Dijous, 11 de setembre de 2014, a les 08:46:11, Kevin Krammer va escriure: The rule to always also install an application icon into Hicolor was meant as an example of a general intent that Hicolor be fully usable. I don't know the details of the icon spec but my understanding was that document-open was a specified standard name. Correct. Assuming that is the case it would have implied for me that an icon of this name is always present. Should be always present in valid themes, yes. If not in the current theme then at least in the fallback Hicolor theme. Again based on these prior assumptions on the spec, not having that icon in Hicolor would constitute a bug in the Hicolor theme and should be fixed by adding the icon there,no? There's no hicolor theme per se. Only a bunch of empty folders http://www.freedesktop.org/software/icon-theme/releases/hicolor-icon-theme -0 .5.tar.gz Is there a maintainer for this package? I have no idea IMHO the only sensible solution is to make sure that it actually contains the icons specified. Without it is rather useless as a specification base line. By reading http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html i think they disagree with you as they mention hicolor for icon apps and not for general icons. Cheers, Albert Cheers, Kevin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 02:06:02, Albert Astals Cid wrote: El Dijous, 11 de setembre de 2014, a les 10:57:17, Kevin Krammer va escriure: On Thursday, 2014-09-11, 09:33:23, Albert Astals Cid wrote: El Dijous, 11 de setembre de 2014, a les 08:46:11, Kevin Krammer va escriure: The rule to always also install an application icon into Hicolor was meant as an example of a general intent that Hicolor be fully usable. I don't know the details of the icon spec but my understanding was that document-open was a specified standard name. Correct. Assuming that is the case it would have implied for me that an icon of this name is always present. Should be always present in valid themes, yes. If not in the current theme then at least in the fallback Hicolor theme. Again based on these prior assumptions on the spec, not having that icon in Hicolor would constitute a bug in the Hicolor theme and should be fixed by adding the icon there,no? There's no hicolor theme per se. Only a bunch of empty folders http://www.freedesktop.org/software/icon-theme/releases/hicolor-icon-the me -0 .5.tar.gz Is there a maintainer for this package? I have no idea IMHO the only sensible solution is to make sure that it actually contains the icons specified. Without it is rather useless as a specification base line. By reading http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html i think they disagree with you as they mention hicolor for icon apps and not for general icons. Ok, I'll try to read the spec and ask for clarification on the XDG list. From my point of view there is little use case of having a fallback if it does not allow one to fall back to it. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On 11.09.2014 11:11, Kevin Krammer wrote: From my point of view there is little use case of having a fallback if it does not allow one to fall back to it. Check out the chat log for the idea of enhancing the spec to add some sort of system-level configuration scheme to set a fallback one level higher than hicolor (to avoid a namespace fight over hicolor). I imagine that will come up in the xdg thread. Cheers, Kevin Cheers, Eike ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 15:29:13, Eike Hein wrote: On 11.09.2014 11:11, Kevin Krammer wrote: From my point of view there is little use case of having a fallback if it does not allow one to fall back to it. Check out the chat log for the idea of enhancing the spec to add some sort of system-level configuration scheme to set a fallback one level higher than hicolor (to avoid a namespace fight over hicolor). I imagine that will come up in the xdg thread. Sounds interesting, but checkout where? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On 11.09.2014 15:33, Kevin Krammer wrote: Sounds interesting, but checkout where? In this thread, where I've posted it and encouraged reading it a few times :). Cheers, Kevin Cheers, Eike ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 15:40:14, Eike Hein wrote: On 11.09.2014 15:33, Kevin Krammer wrote: Sounds interesting, but checkout where? In this thread, where I've posted it and encouraged reading it a few times :). Ah :) I thought you were referring to some XDG discussion. Having a configurable fallback before the final fallback can't hurt, but that doesn't solve the actual problem of hicolor being incomplete. It is just a work around. Might be the only way if the other participants in the icon spec standard want the fallback to be broken. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On 11.09.2014 15:43, Kevin Krammer wrote: Having a configurable fallback before the final fallback can't hurt, but that doesn't solve the actual problem of hicolor being incomplete. It is just a work around. Sort of, except I think the outcome is more or less the same - either a distro/ISV decides on a particular set of icons to roll into hicolor to make things look good (which means work) or they get an explicit config knob to do that merging. I don't think you really get out of distributed work in either scenario - in the fix hicolor scenario you have many distros replicating the work (because no, deciding on a single hicolor isn't going to happen, if only because theming is one of the things distros do to differentiate themselves), in the fix the spec scenario you need to fix many implementations of the spec. The advantage of the latter is that it happens once and is done; new distros (and new icons) will be made for a long time to come. Another trick that came up would be to enhance the lookup algo in the spec to allow one level of inheritance for hicolor ... Cheers, Eike ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 15:53:57, Eike Hein wrote: On 11.09.2014 15:43, Kevin Krammer wrote: Having a configurable fallback before the final fallback can't hurt, but that doesn't solve the actual problem of hicolor being incomplete. It is just a work around. Sort of, except I think the outcome is more or less the same - either a distro/ISV decides on a particular set of icons to roll into hicolor to make things look good (which means work) or they get an explicit config knob to do that merging. Why would hicolor be distro/ISV specific? I don't think you really get out of distributed work in either scenario - in the fix hicolor scenario you have many distros replicating the work (because no, deciding on a single hicolor isn't going to happen, if only because theming is one of the things distros do to differentiate themselves), I am afraid I can't follow. No distro would be involved in that, I am talking about a hicolor package that is provided alongside the spec. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On 11.09.2014 16:09, Kevin Krammer wrote: Why would hicolor be distro/ISV specific? Because a hicolor theme everyone likes visually isn't going to happen. People will want to modify what's in that fall- back for theming reasons, and distros theme to differentiate themselves. In the hicolor as fallback scheme, there are two ways to affect what icons actually show in KF5 apps outside Plasma: - Make sure this environment outside Plasma, whatever it is, has a Qt platform plugin available that reads some setting somewhere that overrides hicolor by specifying a theme. (This is how Plasma itself solves this.) - Manipulate what icons are actually in hicolor. If we introduce a preferred system fallback theme config option in the spec that overrides hicolor, and make Qt aware of it, that avoids either work, which is more extensible to new environments. Cheers, Kevin Cheers, Eike ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thursday, 2014-09-11, 17:05:43, Eike Hein wrote: On 11.09.2014 16:09, Kevin Krammer wrote: Why would hicolor be distro/ISV specific? Because a hicolor theme everyone likes visually isn't going to happen. People will want to modify what's in that fall- back for theming reasons, and distros theme to differentiate themselves. Why would anyone want to change the fallback? The fallback is something you never ever want to see, it is a worst case scenario puffer. Like the safety net in a circus arena. I think what you mean is a default, like us using Oxygen/whatever, GNOME using Tango/whatever, etc. Hicolor is there for cases where the setup fails to provide any workspace or distribution specific theme. Its purpose (I have still not read the spec but that is the only thing that makes sense to me) is to make sure there is an icon if anything else has failed. A shared resource to avoid every application having to ship fallbacks for each used icon. In the hicolor as fallback scheme, there are two ways to affect what icons actually show in KF5 apps outside Plasma: - Make sure this environment outside Plasma, whatever it is, has a Qt platform plugin available that reads some setting somewhere that overrides hicolor by specifying a theme. Right, this is what a distributor or other workspace would do if they care about theming as a means of differentiation. (This is how Plasma itself solves this.) Exactly. - Manipulate what icons are actually in hicolor. Sure, if somebody wants to install their icon theme instead of hicolor, why not. But why not just have your theme as an explicit theme like everyone else and only get your theme in case the fallback path is triggered? Or do you mean install the custom theme twice, once as itself and once as hicolor? If we introduce a preferred system fallback theme config option in the spec that overrides hicolor, and make Qt aware of it, that avoids either work, which is more extensible to new environments. Sharing a setting that indicates a default theme name is of course a good goal, doesn't however fix the problem of the fallback being incomplete. I read that non Qt based systems use XSettings to exchange that information (on X11 only of course) so maybe we can have that in Qt as well? And come up with a way to do something equivalent on Wayland? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On 11.09.2014 17:22, Kevin Krammer wrote: Hicolor is there for cases where the setup fails to provide any workspace or distribution specific theme. Yes. So I'm thinking ahead and telling you how that setup looks like for a workspace: - Write a Qt platform plugin. Needs coding chops. We have them. What about workspaces which don't? What about all the other toolkits be- sides Qt? - Swap out icons in hicolor. Which do you think happens? But why not just have your theme as an explicit theme like everyone else and only get your theme in case the fallback path is triggered? Because making Qt aware of an explicit theme involves writing a Qt platform plugin. It means if you're a sys admin / distro you can no longer solve your problem on the spec level (unless you swap out icons in hicolor), you need to be aware Qt exists. Seems like a layering violation to me. Sharing a setting that indicates a default theme name is of course a good goal, doesn't however fix the problem of the fallback being incomplete. No, but it makes it a lot easier for distros to provide a complete fallback (- installing Oxygen or something else, setting it as preferred fallback). It's less work than maintaining a complete hi- color no one can agree on. Cheers, Kevin Cheers, Eike ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On 11.09.2014 17:22, Kevin Krammer wrote: Or do you mean install the custom theme twice, once as itself and once as hicolor? Wait - I think I now understand why we're having trouble communicating about this. You think a distro has the option to install Oxygen *as* hicolor, right, making my preferred fallback thing seem redundant? That's not so - because numerous apps install app icons *into* the hicolor folder structure, including KDE apps, and those can conflict with the icons in a theme. For distro packagers that means they'd have to fix numerous package installs to eliminate those conflicts. This is what Albert pointed out earlier - hicolor is a multi-stakeholder namespace, so you need to be very careful to only install icons there that you can reason- nably assume no one else wants to install. In practice that means apps only put app icons there, but plenty of explicit themes also include app icons. So using any given theme *as* hicolor doesn't fly without manual merging/maintenance work for packagers, which is what I suggest to avoid with a 'preferred system fallback' config knob. Cheers, Eike ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Tuesday 09 September 2014 16:25:26 Kevin Krammer wrote: Wouldn't a fourth option be to make sure that hicolor is actually a proper fallback as specified? Applications already are more or less required to install their fallbacks in hicolor, so the shared icons should be there as well, no? +1. It seems to me that the best solution is to actually use hicolor in the first place, for application icons. Possibly with an oxygen or breeze variant as well, but that's the optional part. I think we're dealing with a not-well-thought-out migration from years ago when we switched from hicolor to oxygen and just renamed every icon without thinking much about interoperability. -- 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: There's no proper replacement for KIcon
El Dimecres, 10 de setembre de 2014, a les 16:38:55, David Faure va escriure: On Tuesday 09 September 2014 16:25:26 Kevin Krammer wrote: Wouldn't a fourth option be to make sure that hicolor is actually a proper fallback as specified? Applications already are more or less required to install their fallbacks in hicolor, so the shared icons should be there as well, no? +1. It seems to me that the best solution is to actually use hicolor in the first place, for application icons. We're not speaking about application icons here but about KStandardAction icons. Cheers, Albert Possibly with an oxygen or breeze variant as well, but that's the optional part. I think we're dealing with a not-well-thought-out migration from years ago when we switched from hicolor to oxygen and just renamed every icon without thinking much about interoperability. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
El Dimarts, 9 de setembre de 2014, a les 16:25:26, Kevin Krammer va escriure: On Sunday, 2014-09-07, 10:27:06, Albert Astals Cid wrote: So as I see it, there's three options: * Do nothing, and expect that people have to set one of XDG_CURRENT_DESKTOP, KDE_FULL_SESSION, GNOME_DESKTOP_SESSION_ID or DESKTOP_SESSION environment variables to get icons * Do the change/hack to QGenericUnixTheme::themeHint return any of the themes in xdgIconThemePaths that is not hicolor * Talk to the xdg-people to include a way to get the current icon theme and use that in QGenericUnixTheme::themeHint Wouldn't a fourth option be to make sure that hicolor is actually a proper fallback as specified? Applications already are more or less required to install their fallbacks in hicolor, so the shared icons should be there as well, no? I don't think it makes sense, i mean who would install stuff to hicolor/actions/document-open.png ? oxygen? breeze? tango? someothericonset? For applications it makes sense tha application to install to hicolor since the application owns the name for that icon, but noone actually owns the document-open.png action so that's why i think it makes no sense for it to be there. Cheers, Albert Cheers, Kevin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Sunday, 2014-09-07, 10:27:06, Albert Astals Cid wrote: So as I see it, there's three options: * Do nothing, and expect that people have to set one of XDG_CURRENT_DESKTOP, KDE_FULL_SESSION, GNOME_DESKTOP_SESSION_ID or DESKTOP_SESSION environment variables to get icons * Do the change/hack to QGenericUnixTheme::themeHint return any of the themes in xdgIconThemePaths that is not hicolor * Talk to the xdg-people to include a way to get the current icon theme and use that in QGenericUnixTheme::themeHint Wouldn't a fourth option be to make sure that hicolor is actually a proper fallback as specified? Applications already are more or less required to install their fallbacks in hicolor, so the shared icons should be there as well, no? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
El Dijous, 4 de setembre de 2014, a les 14:04:04, Kevin Ottens va escriure: On Thursday 04 September 2014 11:36:38 Martin Klapetek wrote: On Wed, Sep 3, 2014 at 10:10 PM, Eike Hein h...@kde.org wrote: On 09/03/2014 10:07 PM, Nicolás Alvarez wrote: So if I'm not in a Plasma session I get no icons? If you're not in a Plasma session you don't get the Plasma platform plugin. Other platform plugins can drive this as they prefer. Isn't that the task of the given platform plugin? Eg. if I run my app in Gnome, there should be a Gnome plugin which provides its own icon plugin and loads Gnome icons (well in an ideal world, anyway) and thus making the app actually look more integrated...in other words, shouldn't this problem be moved there? Spot on. And such a plugin is in fact shipped with Qt, but for some reason isn't loaded in Albert's case. That awfully sounds like a bug to me, hence why my line of argument is that it should be investigated and fixed. My setup investigation: * Plasma 4 logged in with tsdgeos * konsole logged in to kdeunstable via su - kdeunstable * I'm using the QGenericUnixTheme QPT (aka PlatformTheme) * QGenericUnixTheme uses XDG_CURRENT_DESKTOP, KDE_FULL_SESSION, GNOME_DESKTOP_SESSION_ID or DESKTOP_SESSION environment variables to decide in which desktop environment you are * Since none of those environment variables are defined in my kdeunstable user it falls back to the UNKNOWN desktop environment * Then it goes to QGenericUnixTheme::themeNames and since it's not a known desktop it will default to QGenericUnixTheme as QPT instead of to QKdeTheme or QGnomeTheme for icon theme handling * Then QGenericUnixTheme::themeHint does not implement QPlatformTheme::SystemIconThemeName and QPlatformTheme::SystemIconFallbackThemeName defaults to hicolor * And hicolor is not a proper theme, just a fallback theme, so it is not designed to hold icons for the majority of icons. One could say the bug is in QGenericUnixTheme::themeHint that should actually provide a meaningul icon theme instead of hicolor as default. The problem is that there is not (or I could not find it) a xdg-way to set/get the current icon theme so it's hard not to default to something different than hicolor, one possibility would be making QGenericUnixTheme::themeHint default to say the first icon theme in xdgIconThemePaths, but that's obviously not that great either. So as I see it, there's three options: * Do nothing, and expect that people have to set one of XDG_CURRENT_DESKTOP, KDE_FULL_SESSION, GNOME_DESKTOP_SESSION_ID or DESKTOP_SESSION environment variables to get icons * Do the change/hack to QGenericUnixTheme::themeHint return any of the themes in xdgIconThemePaths that is not hicolor * Talk to the xdg-people to include a way to get the current icon theme and use that in QGenericUnixTheme::themeHint Cheers, Albert P.S: Sorry it took that much to answer, akademy+travel kept me busy. Regards. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
El Dijous, 4 de setembre de 2014, a les 01:04:11, Aleix Pol va escriure: On Wed, Sep 3, 2014 at 10:01 PM, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 3 de setembre de 2014, a les 21:42:24, Mark Gaiser va escriure: On Wed, Sep 3, 2014 at 7:16 PM, Albert Astals Cid aa...@kde.org wrote: Porting guide lies in saying that KIcon should be replaced with QIcon::fromTheme since KIcon defauted to oxygen icon theme and obviously QIcon::fromTheme doesn't do that. Please someone provide a solution for this problem or undeprecate KIcon. This is blocking the porting of my applications. I've seen that issue before. The thing that fixed it for me was setting the environment variable: export KDE_FULL_SESSION=true I hope it still works :) That's not a fix, that's a workaround, we can't ask all the users out there to export that variable. Cheers, Albert It's a workaround only for non-Plasma setups, but agreed. What about documenting that if Oxygen is a hard dependency then a call to QIcon::setThemeSearchPaths should be made? QIcon::setThemeSearchPaths won't help, the paths are fine, it's the theme that is wrong (hicolor or empty string depending on which Qt version). Cheers, Albert We could even use KIconThemes for figuring out what's the Oxygen path. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
El Dijous, 4 de setembre de 2014, a les 14:21:04, Luigi Toscano va escriure: Il 04.09.2014 14:15 Martin Klapetek ha scritto: On Thu, Sep 4, 2014 at 2:04 PM, Kevin Ottens wrote: Spot on. And such a plugin is in fact shipped with Qt, but for some reason isn't loaded in Albert's case. That awfully sounds like a bug to me, hence why my line of argument is that it should be investigated and fixed. Maybe it's also related to this: http://igurublog.wordpress.com/2014/03/22/gtk-3-10-drops-menu-icons-and-mnem onics/ [2] ...in which case, if that's true and actually the case here, I think it's actually better to have our apps in Gnome without those icons as it simply integrates better and doesn't look all out of place (in Gnome and/or others, obviously). Albert uses Unity, I think. Nope. It's Plasma 4, just not the logged in user. What I don't understand here: is this Qt plugin a GNOME-specific one, or the generic default one? The generic one. Cheers, Albert This is not (only) a GNOME issue; replace GNOME with generic unknown window manager. I think we need a sane default, if the default is there and it is broken, the solution as pointed out is to fix it; if not, I think we should investigate how to have it. Ciao ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Wed, Sep 3, 2014 at 10:10 PM, Eike Hein h...@kde.org wrote: On 09/03/2014 10:07 PM, Nicolás Alvarez wrote: So if I'm not in a Plasma session I get no icons? If you're not in a Plasma session you don't get the Plasma platform plugin. Other platform plugins can drive this as they prefer. Isn't that the task of the given platform plugin? Eg. if I run my app in Gnome, there should be a Gnome plugin which provides its own icon plugin and loads Gnome icons (well in an ideal world, anyway) and thus making the app actually look more integrated...in other words, shouldn't this problem be moved there? Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thursday 04 September 2014 11:36:38 Martin Klapetek wrote: On Wed, Sep 3, 2014 at 10:10 PM, Eike Hein h...@kde.org wrote: On 09/03/2014 10:07 PM, Nicolás Alvarez wrote: So if I'm not in a Plasma session I get no icons? If you're not in a Plasma session you don't get the Plasma platform plugin. Other platform plugins can drive this as they prefer. Isn't that the task of the given platform plugin? Eg. if I run my app in Gnome, there should be a Gnome plugin which provides its own icon plugin and loads Gnome icons (well in an ideal world, anyway) and thus making the app actually look more integrated...in other words, shouldn't this problem be moved there? Spot on. And such a plugin is in fact shipped with Qt, but for some reason isn't loaded in Albert's case. That awfully sounds like a bug to me, hence why my line of argument is that it should be investigated and fixed. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Thu, Sep 4, 2014 at 2:04 PM, Kevin Ottens er...@kde.org wrote: Spot on. And such a plugin is in fact shipped with Qt, but for some reason isn't loaded in Albert's case. That awfully sounds like a bug to me, hence why my line of argument is that it should be investigated and fixed. Maybe it's also related to this: http://igurublog.wordpress.com/2014/03/22/gtk-3-10-drops-menu-icons-and-mnemonics/ ...in which case, if that's true and actually the case here, I think it's actually better to have our apps in Gnome without those icons as it simply integrates better and doesn't look all out of place (in Gnome and/or others, obviously). Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
Il 04.09.2014 14:15 Martin Klapetek ha scritto: On Thu, Sep 4, 2014 at 2:04 PM, Kevin Ottens wrote: Spot on. And such a plugin is in fact shipped with Qt, but for some reason isn't loaded in Albert's case. That awfully sounds like a bug to me, hence why my line of argument is that it should be investigated and fixed. Maybe it's also related to this: http://igurublog.wordpress.com/2014/03/22/gtk-3-10-drops-menu-icons-and-mnemonics/ [2] ...in which case, if that's true and actually the case here, I think it's actually better to have our apps in Gnome without those icons as it simply integrates better and doesn't look all out of place (in Gnome and/or others, obviously). Albert uses Unity, I think. What I don't understand here: is this Qt plugin a GNOME-specific one, or the generic default one? This is not (only) a GNOME issue; replace GNOME with generic unknown window manager. I think we need a sane default, if the default is there and it is broken, the solution as pointed out is to fix it; if not, I think we should investigate how to have it. Ciao -- Luigi Scopri istella, il nuovo motore per il web italiano. Istella garantisce risultati di qualità e la possibilità di condividere, in modo semplice e veloce, documenti, immagini, audio e video. Usa istella, vai su http://www.istella.it?wtk=amc138614816829636 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On 04.09.2014 14:21, Luigi Toscano wrote: What I don't understand here: is this Qt plugin a GNOME-specific one, or the generic default one? This is not (only) a GNOME issue; replace GNOME with generic unknown window manager. I think we need a sane default, if the default is there and it is broken, the solution as pointed out is to fix it; if not, I think we should investigate how to have it. Please also check out the chat log I posted - I realize it's not as convenient to read as a proper write-up and I apologize for not having the time to compose one, but it went over a lot of this ground in a pretty condensed manner and should help with syncing us up. (Not specifically you, Luigi.) Ciao Cheers, Eike ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Wed, Sep 3, 2014 at 7:16 PM, Albert Astals Cid aa...@kde.org wrote: Porting guide lies in saying that KIcon should be replaced with QIcon::fromTheme since KIcon defauted to oxygen icon theme and obviously QIcon::fromTheme doesn't do that. Please someone provide a solution for this problem or undeprecate KIcon. This is blocking the porting of my applications. I've seen that issue before. The thing that fixed it for me was setting the environment variable: export KDE_FULL_SESSION=true I hope it still works :) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
El Dimecres, 3 de setembre de 2014, a les 21:42:24, Mark Gaiser va escriure: On Wed, Sep 3, 2014 at 7:16 PM, Albert Astals Cid aa...@kde.org wrote: Porting guide lies in saying that KIcon should be replaced with QIcon::fromTheme since KIcon defauted to oxygen icon theme and obviously QIcon::fromTheme doesn't do that. Please someone provide a solution for this problem or undeprecate KIcon. This is blocking the porting of my applications. I've seen that issue before. The thing that fixed it for me was setting the environment variable: export KDE_FULL_SESSION=true I hope it still works :) That's not a fix, that's a workaround, we can't ask all the users out there to export that variable. Cheers, Albert ___ 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: There's no proper replacement for KIcon
On Wed, Sep 3, 2014 at 10:01 PM, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 3 de setembre de 2014, a les 21:42:24, Mark Gaiser va escriure: On Wed, Sep 3, 2014 at 7:16 PM, Albert Astals Cid aa...@kde.org wrote: Porting guide lies in saying that KIcon should be replaced with QIcon::fromTheme since KIcon defauted to oxygen icon theme and obviously QIcon::fromTheme doesn't do that. Please someone provide a solution for this problem or undeprecate KIcon. This is blocking the porting of my applications. I've seen that issue before. The thing that fixed it for me was setting the environment variable: export KDE_FULL_SESSION=true I hope it still works :) That's not a fix, that's a workaround, we can't ask all the users out there to export that variable. Wasn't that one supposed to be exported by default in a KDE/Plasma 5 session? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
2014-09-03 17:05 GMT-03:00 Mark Gaiser mark...@gmail.com: On Wed, Sep 3, 2014 at 10:01 PM, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 3 de setembre de 2014, a les 21:42:24, Mark Gaiser va escriure: On Wed, Sep 3, 2014 at 7:16 PM, Albert Astals Cid aa...@kde.org wrote: Porting guide lies in saying that KIcon should be replaced with QIcon::fromTheme since KIcon defauted to oxygen icon theme and obviously QIcon::fromTheme doesn't do that. Please someone provide a solution for this problem or undeprecate KIcon. This is blocking the porting of my applications. I've seen that issue before. The thing that fixed it for me was setting the environment variable: export KDE_FULL_SESSION=true I hope it still works :) That's not a fix, that's a workaround, we can't ask all the users out there to export that variable. Wasn't that one supposed to be exported by default in a KDE/Plasma 5 session? So if I'm not in a Plasma session I get no icons? -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On 09/03/2014 10:07 PM, Nicolás Alvarez wrote: So if I'm not in a Plasma session I get no icons? If you're not in a Plasma session you don't get the Plasma platform plugin. Other platform plugins can drive this as they prefer. Cheers, Eike ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
El Dimecres, 3 de setembre de 2014, a les 22:10:52, Eike Hein va escriure: On 09/03/2014 10:07 PM, Nicolás Alvarez wrote: So if I'm not in a Plasma session I get no icons? If you're not in a Plasma session you don't get the Plasma platform plugin. Other platform plugins can drive this as they prefer. Are you suggesting it is acceptable for my apps to regress (compared to their kdelibs4 version) and have no icons because they are not being run under a Plasma session? Cheers, Albert Cheers, Eike ___ 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: There's no proper replacement for KIcon
On 09/03/2014 10:14 PM, Albert Astals Cid wrote: Are you suggesting it is acceptable for my apps to regress (compared to their kdelibs4 version) and have no icons because they are not being run under a Plasma session? No, I'm not. The context my reply is about was quoted in my email. I honestly didn't even understand your initial mail to the list. There's a vague claim about QIcon::fromTheme obviously not doing something, but I guess it's not obvious enough for me. So no, I: a) Did not kill your puppy. Puppies are awesome. Mostly. b) Think your attack tone has no place on this list. Some advice: Your inquiry could have been phrased as a question instead (am I getting this right? if so, any help?). Or it could have provided a little more analysis of the problem you're seeing at least. This is what common ownership on http://manifesto.kde.org/ is about, BTW. Here's my understanding of how this works, which may be wrong: QIcon::fromTheme() ends up calling into the currently active platform plugin when it needs to access the fallback theme. Which platform plugin gets loaded depends on the environment. Our platform plugin returns a KIconEngine, which I'm guessing has a reasonable default for Plasma. I think there are other platform plugins for other prominent workspace environments. I don't know how the ultimate fallback works when there's no suitable plugin. I think the fd.o spec pro- scribes the hicolor theme then? In that case it would be up to the distro to make sure this works out. I'm not sure what alternatives we have here. It's not reasonable for KF5 to override the platform plugin re- gardless of environment, and I don't think duplicating the platform plugin system inside KIcon or writing a wrapper around QIcon::fromTheme seems sensible. Cheers, Albert Cheers, Eike ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
On Wed, Sep 3, 2014 at 10:26 PM, Eike Hein h...@kde.org wrote: I think the fd.o spec pro- scribes the hicolor theme then? ^ this In that case it would be up to the distro to make sure this works out. That wouldn't help the original issue that we previously had a hardcoded fallback to oxygen, in fact we still do as far as the platform plugin is concerned [1]. So IIRC the effective lookup order was user_theme (which in turn may have internal fallbacks defined) default_theme (oxygen) hicolor. So even on windows you'd get oxygen icons I suppose, without the user or the developer doing anything. I'm not sure what alternatives we have here. It's not reasonable for KF5 to override the platform plugin re- gardless of environment, and I don't think duplicating the platform plugin system inside KIcon or writing a wrapper around QIcon::fromTheme seems sensible. To be honest I think this might be considered intentional compatibility breakage because the original assumption that installing something to oxygen and it will be available in the app regardless of what the user configured seems wrong to me. The icon theme spec outlines one solid fallback and that is hicolor. *Assuming* as an application developer that KIcon/QIcon will also look in oxygen in addition to hicolor seems an awful lot like writing against the implementation rather than the API (the API in this case being the spec I guess ;)). So, IMO the correct solution to this is to install the icons one needs to hicolor so that they are picked up unless provided by a user configured theme, as outlined by the spec. NB: I have no idea how this would or should work on windows or osx, so this approach might be entirely pointless and non-functional there, which in turn might actually be a reason to bring back something like KIcon as to provide a grand unified way of getting 'the right' icon looked up. [1] https://bugs.kde.org/show_bug.cgi?id=336739 HS ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
El Dimecres, 3 de setembre de 2014, a les 22:26:22, Eike Hein va escriure: On 09/03/2014 10:14 PM, Albert Astals Cid wrote: Are you suggesting it is acceptable for my apps to regress (compared to their kdelibs4 version) and have no icons because they are not being run under a Plasma session? No, I'm not. The context my reply is about was quoted in my email. I honestly didn't even understand your initial mail to the list. There's a vague claim about QIcon::fromTheme obviously not doing something, but I guess it's not obvious enough for me. So no, I: a) Did not kill your puppy. Puppies are awesome. Mostly. b) Think your attack tone has no place on this list. Which attack tone? I merely did a question. Some advice: Your inquiry could have been phrased as a question instead (am I getting this right? if so, any help?). Why would i make a question when i know the answer? Or it could have provided a little more analysis of the problem you're seeing at least. What more analysis you want besides QIcon::fromTheme can never default to oxygen as KIcon did so it's not a proper replacement? Here's my understanding of how this works, which may be wrong: QIcon::fromTheme() ends up calling into the currently active platform plugin when it needs to access the fallback theme. Both current and fallback theme, yes. Which platform plugin gets loaded depends on the environment. Our platform plugin returns a KIconEngine, which I'm guessing has a reasonable default for Plasma. I think there are other platform plugins for other prominent workspace environments. I don't know how the ultimate fallback works when there's no suitable plugin. I think the fd.o spec pro- scribes the hicolor theme then? Correct, it defaults to hicolor (well there's a bug right now that defaults to empty, but that's a different story) In that case it would be up to the distro to make sure this works out. What would a distro do? I'm not sure what alternatives we have here. It's not reasonable for KF5 to override the platform plugin re- gardless of environment, and I don't think duplicating the platform plugin system inside KIcon or writing a wrapper around QIcon::fromTheme seems sensible. I don't know, i tried fixing the problem by myself presented a review that was approved (common ownersip!) but my code has been accused of bastardization so i had to revert it. Cheers, Albert Cheers, Albert Cheers, Eike ___ 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: There's no proper replacement for KIcon
On 09/03/2014 11:12 PM, Albert Astals Cid wrote: Which attack tone? I merely did a question. Yes, a Did you stop beating your wife?-type loaded question casting me as an ally to evil app-breaking perpetrators, while answering a specific technical question someone had. What more analysis you want besides QIcon::fromTheme can never default to oxygen as KIcon did so it's not a proper replacement? Why this is a problem for you and others, and why you feel it needs to be solved at the level you suggest. Since you expect others to do this work for you as per your mail, that would help in enabling them to do so. What would a distro do? A distro or system administrator would make sure that either a suitable Qt platform plugin exists and works, or that a suitable 'hicolor' theme is installed, for the environment they expect users to use. I don't see how Qt can solve this for all scenarios, or needs to when the spec already specifies a fall- back. I don't see why KF5 should override this fall- back, or why the fallback should be Oxygen. Oxygen is not a part of KF5, it's just an fd.o-compliant icon theme. KF5 and Qt target the fd.o spec. Qt provides mechanisms to adapt the behavior to the environment etc etc. Can I think up scenarios where the ball gets dropped? Yes. I'm not sure those scenarios are relevant because all the options seem to be there to fix them. So don't see where the loophole is. I don't know, i tried fixing the problem by myself presented a review that was approved (common ownersip!) but my code has been accused of bastardization so i had to revert it. I didn't see that review. Maybe linking to it in your mail would have provided some useful context. Cheers, Albert Cheers, Eike ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
El Dimecres, 3 de setembre de 2014, a les 23:12:58, Albert Astals Cid va escriure: El Dimecres, 3 de setembre de 2014, a les 22:26:22, Eike Hein va escriure: I don't know how the ultimate fallback works when there's no suitable plugin. I think the fd.o spec pro- scribes the hicolor theme then? Correct, it defaults to hicolor (well there's a bug right now that defaults to empty, but that's a different story) For those interested here's a large strace with the lots of stats trying to find all the missing icons http://paste.ubuntu.com/8226923/ Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
El Dimecres, 3 de setembre de 2014, a les 23:23:37, Eike Hein va escriure: On 09/03/2014 11:12 PM, Albert Astals Cid wrote: Which attack tone? I merely did a question. Yes, a Did you stop beating your wife?-type loaded question casting me as an ally to evil app-breaking perpetrators, while answering a specific technical question someone had. I already explained on IRC why my question has nothing to do with Did you stop beating your wife?, let me explain why. Did you stop beating your wife? has two answers: No - means you did and do beat your wife Yes - means you did beat your wife and do not anymore So whatever you answer Yes or No it carries the information that you did beat your wife. That's why it's called a loaded question. Are you suggesting it is acceptable for my apps to regress more stuff? has two answers: No - you think it's not ok for apps to regress Yes - you think it's ok for apps to regress. In this question both answers provide a separate set of values, so it is not a loaded question. What more analysis you want besides QIcon::fromTheme can never default to oxygen as KIcon did so it's not a proper replacement? Why this is a problem for you and others, and why you feel it needs to be solved at the level you suggest. Since you expect others to do this work for you as per your mail, that would help in enabling them to do so. It is a problem because you have no icons anymore since oxygen is no longer the default theme (and hicolor is not really a theme just a default). What would a distro do? A distro or system administrator would make sure that either a suitable Qt platform plugin exists and works, or that a suitable 'hicolor' theme is installed, for the environment they expect users to use. No distro provides any suitable hicolor theme. As far as i understand from reading the spec that's even discouraged. I don't see how Qt can solve this for all scenarios, or needs to when the spec already specifies a fall- back. I don't see why KF5 should override this fall- back, or why the fallback should be Oxygen. Oxygen is not a part of KF5, it's just an fd.o-compliant icon theme. KF5 and Qt target the fd.o spec. Qt provides mechanisms to adapt the behavior to the environment etc etc. Can I think up scenarios where the ball gets dropped? Yes. I'm not sure those scenarios are relevant because all the options seem to be there to fix them. So don't see where the loophole is. I don't care where and how it's fixed, but i have apps that had icons and now don't, in my opinion we need to get them back. I don't know, i tried fixing the problem by myself presented a review that was approved (common ownersip!) but my code has been accused of bastardization so i had to revert it. I didn't see that review. Maybe linking to it in your mail would have provided some useful context. https://git.reviewboard.kde.org/r/119713/ http://lists.kde.org/?l=kde-commitsm=140950097506983w=2 And a discussion this morning in that channel that does not exist. Cheers, Albert Cheers, Albert Cheers, Eike ___ 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: There's no proper replacement for KIcon
For the list's benefit, here's a log of a technical discussion we had in #kde-devel as an extension of this thread that went over various aspects of the problem and possible solutions (I've removed some unrelated parts): [23:33] tosky uhm, I have no idea of how it works in details, but I understood it's about missing icon if you use a normal KF5 application outside Plasma [23:35] hein tosky: and solving that by adding an API to KF5 that overrides the spec fallback with a random other icon theme that isn't a dependency of KF5 seems like a layering violation to me [23:35] hein tosky: it also means KF5 apps would behave differently from Qt apps, which wasn't the goal [23:36] tosky hein: are you saying that setting those icons as part of the hicolor theme should solve the problem? [23:37] hein tosky: no, that's what the fd.o spec says [23:37] hein tosky: which is what KF5 targets [23:38] hein tosky: having a fetchIconFromWellKnownThemeThatMayOrMayNotBeInstalled() API doesn't seem like a solution to me [23:40] hein tosky: if an app really really wants some sort of private overlay they could also use QIcon::setThemeSearchPaths and QIcon::setThemeName [23:40] tsdgeos better than fetchIconFromThemeThatIsNotATheme [23:40] tsdgeos at least if you're lucky you'll get an icon :D [23:43] tsdgeos hein: apachelogger actually said that yes, he is ok with the regression, and i actually am not sure i disagree with it [...] [23:46] apachelogger FWIW as I noted, I think windows and osx is the bigger question mark [23:46] hein apachelogger: I think I vaguely vaguely vaguely remember Pov talking about this re KF5 on Windows [23:46] apachelogger in particular since the docs say terrible things about fromTheme - Note: By default, only X11 will support themed icons. In order to use themed icons on Mac and Windows, you will have to bundle a compliant theme in one of your themeSearchPaths() and set the appropriate themeName(). [23:46] hein apachelogger: I think their copy of Qt hardcodes the KDE platform plugin [23:46] hein or something like that [23:47] apachelogger sounds scary xD [23:47] hein but I still think that this stuff needs to happen on the Qt level instead of saying KF5 apps should use a different API and behave differently from Qt apps again is the right fix [23:50] apachelogger *nod* [23:51] jpwhiting hein: that may be, but what should such an api at the Qt level look like ? [23:51] hein it could be as easy as adding a QIcon::setFallbackThemeName [23:51] jpwhiting which probably wont work on win/osx, right ? [23:51] hein or a list of fallback theme names [23:51] jpwhiting since they don't use icon themes, etc. [23:51] jpwhiting or do they [23:51] hein this sounds horrible, but is effectively what tsdgeos wants if i understand him right [23:51] jpwhiting but QIcon::fromTheme doesn't recognize/work with those [23:51] hein tsdgeos' stance comes down to I'm the app dev and i know these icons i want are only in oxygen [23:51] hein which is implicitly a per-app thing [23:52] jpwhiting yep [23:52] jpwhiting hein: the porting guide for porting applications to android/etc. suggests including all assets like that inside a qrc, I wonder if we should adopt that practice on desktop also [23:53] jpwhiting the drawback to that approach is that the assets can't be shared between different applications [23:53] jpwhiting i.e. the flags kgeography uses/ships can't be used in other places that also want to display flags, etc. [23:53] hein jpwhiting: that's what i meant with the private overlay thing earlier and setThemeSearchPaths/setThemeName [23:54] hein jpwhiting: the problem with using setThemeName is that then you override the QPA mechanism [23:54] frinring also means that one needs to know all icons/resources that the used (framework) libs use [23:54] hein jpwhiting: so semantically it would need to be a setFallbackThemeName that just adds one more thing between QPA + hicolor or sth [23:54] tsdgeos note i'm not speaking about any app specific icon [23:54] tsdgeos have a look at the strace [23:54] tsdgeos it's document-open [23:54] hein jpwhiting: which is effectively what KIcon does [23:54] tsdgeos and those things [23:54] tsdgeos hicolor is not a theme and is not supposed to be [23:54] tsdgeos i guess it's just that linux sucks [23:54] hein tsdgeos: in what DE? [23:54] tsdgeos and what i want can't be solved [23:55] hein unity? why does unity not install a QPA plugin if it's using Qt anyway? [23:55] apachelogger hein: an intermediate fallback might be cheating [23:55] tsdgeos hein: what does it matter which DE it is? [23:55] tsdgeos hein: unity is not using Qt yet [23:55] hein tsdgeos: because Qt's platform abstraction mechanism cares [23:55] hein what DE it is [23:55] jpwhiting yeah, it shouldn't matter which DE we are using to run our application [23:55] hein jpwhiting: then convince Qt of that [23:55] hein QPA plugins is the integration mechanism it provides to ISVs [23:55]
Re: There's no proper replacement for KIcon
On Wed, Sep 3, 2014 at 10:01 PM, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 3 de setembre de 2014, a les 21:42:24, Mark Gaiser va escriure: On Wed, Sep 3, 2014 at 7:16 PM, Albert Astals Cid aa...@kde.org wrote: Porting guide lies in saying that KIcon should be replaced with QIcon::fromTheme since KIcon defauted to oxygen icon theme and obviously QIcon::fromTheme doesn't do that. Please someone provide a solution for this problem or undeprecate KIcon. This is blocking the porting of my applications. I've seen that issue before. The thing that fixed it for me was setting the environment variable: export KDE_FULL_SESSION=true I hope it still works :) That's not a fix, that's a workaround, we can't ask all the users out there to export that variable. Cheers, Albert It's a workaround only for non-Plasma setups, but agreed. What about documenting that if Oxygen is a hard dependency then a call to QIcon::setThemeSearchPaths should be made? We could even use KIconThemes for figuring out what's the Oxygen path. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
