Symbolic icons in app menu -- not ready for F22
Hi, Currently, half our apps use nice symbolic icons in the app menu, while the other half use shrunken hicolor icons. This inconsistency is a poor user experience, and not something that should happen in a serious operating system. Progress is being tracked at [1] under the column 3.16 status, but it's clearly not going to be finished prior to the F22. I don't think this change is ready for Fedora (or other distros -- the change should have been delayed until GNOME 3.18). We should wait until at least all the apps we install by default have symbolic icons before making this switch. Ideally [1] would be completed as well. I propose either: a) Reverting the change to use symbolic icons for the app menu in a downstream patch. This would involve reverting upstream commit [2]. b) Integrating symbolic icons for those apps in downstream patches. This would be more work, but at least patches already exist (thanks Jakub!) for nearly all GNOME apps, even though a few have been rejected upstream. We would still need icons for devassistant and setroubleshoot, though. [1] https://wiki.gnome.org/Initiatives/GnomeGoals/HighContrastAppIcons [2] https://git.gnome.org/browse/gnome-shell/commit/?id=a0df7aa2b800a2f4a71bcf208e9480d7f21500e0 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
In the old days of mainframe computers, each application had a messages and codes manual. Each application received a three character prefix, followed 5 digit number beginning at 0, followed by one of I (informative), W(warning), E(error) and Q(question). We don't have to stick to three characters,for example, gedit00012Q Save or Quit? The use of the code allows for rapid search for debugging (bugzilla) and for user to perform corrective action, or even a disregard (in the case of I type messages). Perhaps the code could be displayed at the tail end of the message. Its just an idea to consider and to possibly implement over time. Regards Leslie Mr. Leslie Satenstein Montréal Québec, Canada From: Allan Day allanp...@gmail.com To: Alexandre Franke alexandre.fra...@gmail.com Cc: desktop-devel-list desktop-devel-list@gnome.org Sent: Monday, April 20, 2015 12:02 PM Subject: Re: GNOME HIG: Feedback Wanted Alexandre Franke alexandre.fra...@gmail.com wrote: ... https://developer.gnome.org/hig/stable/writing-style.html.en has nothing on error messages. Can we have guidelines on what is preferred between Cannot…, Could not…, Failed to…, etc. for a bit more consistency? Sure thing - can you file a bug for that? I'm hoping to get some time for the HIG at some point this cycle. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Symbolic icons in app menu -- not ready for F22
Oops, I meant to send this to desk...@lists.fedoraproject.org. Um, whatever, it's relevant to this list too. :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Alexandre Franke alexandre.fra...@gmail.com wrote: ... https://developer.gnome.org/hig/stable/writing-style.html.en has nothing on error messages. Can we have guidelines on what is preferred between Cannot…, Could not…, Failed to…, etc. for a bit more consistency? Sure thing - can you file a bug for that? I'm hoping to get some time for the HIG at some point this cycle. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Symbolic icons in app menu -- not ready for F22
I'm disappointed in this change. I'm not sure why it was even made in the first place. Why do Alt-Tab, Dash, and the launcher get the full-color app icon, but the window menu gets a symbolic icon? For me, one of the biggest things GNOME did was establish a consistent brand for an app *everywhere* an app is, no matter where it is in the OS. I'm unhappy with this change because it's actually impairing my recognition -- in some places, I see a full-color terminal icon, and in others, I see a symbolic icon, and it's thrown me a few times to figure out if I'm running the same application or not. On Mon, Apr 20, 2015 at 7:48 AM, Michael Catanzaro mcatanz...@gnome.org wrote: Hi, Currently, half our apps use nice symbolic icons in the app menu, while the other half use shrunken hicolor icons. This inconsistency is a poor user experience, and not something that should happen in a serious operating system. Progress is being tracked at [1] under the column 3.16 status, but it's clearly not going to be finished prior to the F22. I don't think this change is ready for Fedora (or other distros -- the change should have been delayed until GNOME 3.18). We should wait until at least all the apps we install by default have symbolic icons before making this switch. Ideally [1] would be completed as well. I propose either: a) Reverting the change to use symbolic icons for the app menu in a downstream patch. This would involve reverting upstream commit [2]. b) Integrating symbolic icons for those apps in downstream patches. This would be more work, but at least patches already exist (thanks Jakub!) for nearly all GNOME apps, even though a few have been rejected upstream. We would still need icons for devassistant and setroubleshoot, though. [1] https://wiki.gnome.org/Initiatives/GnomeGoals/HighContrastAppIcons [2] https://git.gnome.org/browse/gnome-shell/commit/?id=a0df7aa2b800a2f4a71bcf208e9480d7f21500e0 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On Mon, Apr 20, 2015 at 6:02 PM, Allan Day allanp...@gmail.com wrote: Sure thing - can you file a bug for that? I'm hoping to get some time for the HIG at some point this cycle. https://bugzilla.gnome.org/show_bug.cgi?id=748197 :) -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Symbolic icons in app menu -- not ready for F22
On Mon, Apr 20, 2015 at 5:24 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: I'm disappointed in this change. I'm not sure why it was even made in the first place. Why do Alt-Tab, Dash, and the launcher get the full-color app icon, but the window menu gets a symbolic icon? For me, one of the biggest things GNOME did was establish a consistent brand for an app *everywhere* an app is, no matter where it is in the OS. I'm unhappy with this change because it's actually impairing my recognition -- in some places, I see a full-color terminal icon, and in others, I see a symbolic icon, and it's thrown me a few times to figure out if I'm running the same application or not. The idea was afaik to have the topbar monochrome and the app icon was the only colored item there. But that aside I also don't like this change for both the inconsistency and the reasons you outlined above. We should really reconsider it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Software and fwupd
I've just merged a patch to gnome-software which adds an optional (but default enabled) dependency on fwupd[1]. The fwupd project just provides a DBus interface for applying low-level firmware to various types of devices. I don't know if this makes sense for the continuous integration server. I don't know if it makes sense to enable by default. Installing firmware on more devices would be awesome (and make them more secure) but it is Yet Another Dep. Comments welcome, Richard [1] https://github.com/hughsie/fwupd ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Software and fwupd
Hi Richard Richard Hughes wrote: I've just merged a patch to gnome-software which adds an optional (but default enabled) dependency on fwupd[1]. The fwupd project just provides a DBus interface for applying low-level firmware to various types of devices. I don't know if this makes sense for the continuous integration server. I don't know if it makes sense to enable by default. Installing firmware on more devices would be awesome (and make them more secure) but it is Yet Another Dep. Comments welcome, If it stays enabled by default it would have to be added to jhbuild (or the moduleset changed to disable it forcefully, but that's not nice), and this would work as long as fwupdate is installed system-wide, right? Release-team-hat-on, in time of releases it would help to have tarballs created with 'make dist(check)' (I think github allows this, but if that was not the case they could certainly be pushed onto the GNOME ftp server). Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
