Re: gtk3 broken/missing icons on kde
On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote: On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson awill...@redhat.com wrote: On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote: Adam Williamson wrote: I don't think we'd really be correct in blocking the release for such issues - especially not Beta. We used to have 'polish' criteria for Final which at least required the icons used in the system menus - i.e. what's specified in the app's .desktop file - to be sane for all installed applications, but we dropped that (and other polish criteria) with the F19/F20 criteria re-write on the basis that they were really stretching a bit too far and would be unlikely to hold up to a 'last blocker before release' acid test. Stuff like this doesn't break anyone's use of the system catastrophically and can reasonably be fixed with updates. But it also affects the live images (making them look very unpolished) and we don't respin those. That's why I said 'reasonably' not 'perfectly' :) I can see an argument for blocking Final, though in practice, I don't think our current standards are such that it really makes sense to claim our final releases are so smooth as to be worth enforcing a high standard of polish via the blocker mechanisms Then we should that. There is a difference between perfect and something that looks obviously broken. Are we really fighting about the classification of fixed bugs here, or is there a new issue that I am not aware of ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gtk3 broken/missing icons on kde
On Tuesday, November 5, 2013, Matthias Clasen wrote: On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote: On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson awill...@redhat.comjavascript:; wrote: On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote: Adam Williamson wrote: I don't think we'd really be correct in blocking the release for such issues - especially not Beta. We used to have 'polish' criteria for Final which at least required the icons used in the system menus - i.e. what's specified in the app's .desktop file - to be sane for all installed applications, but we dropped that (and other polish criteria) with the F19/F20 criteria re-write on the basis that they were really stretching a bit too far and would be unlikely to hold up to a 'last blocker before release' acid test. Stuff like this doesn't break anyone's use of the system catastrophically and can reasonably be fixed with updates. But it also affects the live images (making them look very unpolished) and we don't respin those. That's why I said 'reasonably' not 'perfectly' :) I can see an argument for blocking Final, though in practice, I don't think our current standards are such that it really makes sense to claim our final releases are so smooth as to be worth enforcing a high standard of polish via the blocker mechanisms Then we should that. There is a difference between perfect and something that looks obviously broken. Are we really fighting about the classification of fixed bugs here, Yes ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gtk3 broken/missing icons on kde
On Tue, 2013-11-05 at 11:19 -0500, Matthias Clasen wrote: On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote: On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson awill...@redhat.com wrote: On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote: Adam Williamson wrote: I don't think we'd really be correct in blocking the release for such issues - especially not Beta. We used to have 'polish' criteria for Final which at least required the icons used in the system menus - i.e. what's specified in the app's .desktop file - to be sane for all installed applications, but we dropped that (and other polish criteria) with the F19/F20 criteria re-write on the basis that they were really stretching a bit too far and would be unlikely to hold up to a 'last blocker before release' acid test. Stuff like this doesn't break anyone's use of the system catastrophically and can reasonably be fixed with updates. But it also affects the live images (making them look very unpolished) and we don't respin those. That's why I said 'reasonably' not 'perfectly' :) I can see an argument for blocking Final, though in practice, I don't think our current standards are such that it really makes sense to claim our final releases are so smooth as to be worth enforcing a high standard of polish via the blocker mechanisms Then we should that. There is a difference between perfect and something that looks obviously broken. Are we really fighting about the classification of fixed bugs here, or is there a new issue that I am not aware of ? It's become a question of whether there should be a Beta or Final requirement for icons to be present / look good, I think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gtk3 broken/missing icons on kde
On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote: Adam Williamson wrote: I don't think we'd really be correct in blocking the release for such issues - especially not Beta. We used to have 'polish' criteria for Final which at least required the icons used in the system menus - i.e. what's specified in the app's .desktop file - to be sane for all installed applications, but we dropped that (and other polish criteria) with the F19/F20 criteria re-write on the basis that they were really stretching a bit too far and would be unlikely to hold up to a 'last blocker before release' acid test. Stuff like this doesn't break anyone's use of the system catastrophically and can reasonably be fixed with updates. But it also affects the live images (making them look very unpolished) and we don't respin those. That's why I said 'reasonably' not 'perfectly' :) I can see an argument for blocking Final, though in practice, I don't think our current standards are such that it really makes sense to claim our final releases are so smooth as to be worth enforcing a high standard of polish via the blocker mechanisms. But certainly for Beta it seems too trivial. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gtk3 broken/missing icons on kde
On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson awill...@redhat.com wrote: On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote: Adam Williamson wrote: I don't think we'd really be correct in blocking the release for such issues - especially not Beta. We used to have 'polish' criteria for Final which at least required the icons used in the system menus - i.e. what's specified in the app's .desktop file - to be sane for all installed applications, but we dropped that (and other polish criteria) with the F19/F20 criteria re-write on the basis that they were really stretching a bit too far and would be unlikely to hold up to a 'last blocker before release' acid test. Stuff like this doesn't break anyone's use of the system catastrophically and can reasonably be fixed with updates. But it also affects the live images (making them look very unpolished) and we don't respin those. That's why I said 'reasonably' not 'perfectly' :) I can see an argument for blocking Final, though in practice, I don't think our current standards are such that it really makes sense to claim our final releases are so smooth as to be worth enforcing a high standard of polish via the blocker mechanisms Then we should that. There is a difference between perfect and something that looks obviously broken. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gtk3 broken/missing icons on kde
Adam Williamson wrote: I don't think we'd really be correct in blocking the release for such issues - especially not Beta. We used to have 'polish' criteria for Final which at least required the icons used in the system menus - i.e. what's specified in the app's .desktop file - to be sane for all installed applications, but we dropped that (and other polish criteria) with the F19/F20 criteria re-write on the basis that they were really stretching a bit too far and would be unlikely to hold up to a 'last blocker before release' acid test. Stuff like this doesn't break anyone's use of the system catastrophically and can reasonably be fixed with updates. But it also affects the live images (making them look very unpolished) and we don't respin those. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gtk3 broken/missing icons on kde
On Sat, 2013-10-19 at 14:01 -0500, Rex Dieter wrote: Adam Williamson wrote: Hi folks, and welcome to the Fedora 20 Beta blocker bug news... can't find any criteria currently that covers application icons (though do mention it if such a thing exists)... At issue here are gtk3 applications that use non-standard (e.g. symbolic) icons look particularly bad on kde (or any desktop that doesn't use an icon theme that has does not have a fallback to gnome icon theme). See: https://bugzilla.redhat.com/show_bug.cgi?id=1018390 (*) (includes screenshot), reported over a week ago without comment yet, so here am, soliciting feedback. If gtk applications need a gnome-icon-theme fallback to be fully functional, then depending on the currently configured icon theme to do it feels like the wrong approach to me. Kevin (Kofler) and I provided what I think are constructive and not unreasonable suggestions: * restore Net/FallbackIconTheme support * use a hard-coded gnome-icons fallback (instead of hicolor) In particular, adding a hard-coded fallback to gnome-icons in kde is not a particularly pleasing option (as mentioned in the bug already). I don't think we'd really be correct in blocking the release for such issues - especially not Beta. We used to have 'polish' criteria for Final which at least required the icons used in the system menus - i.e. what's specified in the app's .desktop file - to be sane for all installed applications, but we dropped that (and other polish criteria) with the F19/F20 criteria re-write on the basis that they were really stretching a bit too far and would be unlikely to hold up to a 'last blocker before release' acid test. Stuff like this doesn't break anyone's use of the system catastrophically and can reasonably be fixed with updates. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gtk3 broken/missing icons on kde
On Sat, 2013-10-19 at 14:01 -0500, Rex Dieter wrote: Adam Williamson wrote: Hi folks, and welcome to the Fedora 20 Beta blocker bug news... can't find any criteria currently that covers application icons (though do mention it if such a thing exists)... At issue here are gtk3 applications that use non-standard (e.g. symbolic) icons look particularly bad on kde (or any desktop that doesn't use an icon theme that has does not have a fallback to gnome icon theme). See: https://bugzilla.redhat.com/show_bug.cgi?id=1018390 (*) (includes screenshot), reported over a week ago without comment yet, so here am, soliciting feedback. If gtk applications need a gnome-icon-theme fallback to be fully functional, then depending on the currently configured icon theme to do it feels like the wrong approach to me. Kevin (Kofler) and I provided what I think are constructive and not unreasonable suggestions: * restore Net/FallbackIconTheme support * use a hard-coded gnome-icons fallback (instead of hicolor) In particular, adding a hard-coded fallback to gnome-icons in kde is not a particularly pleasing option (as mentioned in the bug already). Did you try with gtk 3.10.1 ? We've fixed the 'generic fallback' to drop -symbolic after exhausting other possibilities. E.g. for drive-harddisk-usb-symbolic we're now looking for drive-harddisk-usb-symbolic drive-harddisk-symbolic drive-symbolic drive-harddisk-usb drive-harddisk drive in that order. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gtk3 broken/missing icons on kde
Adam Williamson wrote: Hi folks, and welcome to the Fedora 20 Beta blocker bug news... can't find any criteria currently that covers application icons (though do mention it if such a thing exists)... At issue here are gtk3 applications that use non-standard (e.g. symbolic) icons look particularly bad on kde (or any desktop that doesn't use an icon theme that has does not have a fallback to gnome icon theme). See: https://bugzilla.redhat.com/show_bug.cgi?id=1018390 (*) (includes screenshot), reported over a week ago without comment yet, so here am, soliciting feedback. If gtk applications need a gnome-icon-theme fallback to be fully functional, then depending on the currently configured icon theme to do it feels like the wrong approach to me. Kevin (Kofler) and I provided what I think are constructive and not unreasonable suggestions: * restore Net/FallbackIconTheme support * use a hard-coded gnome-icons fallback (instead of hicolor) In particular, adding a hard-coded fallback to gnome-icons in kde is not a particularly pleasing option (as mentioned in the bug already). -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
