Hi all.
Since apparently we can't remove anything from default without having a "policy", and we can't ask packagers to fix their software either, I have to write this message.
Apparently, not including a package by default is seen as "punishment". So, instead of doing actual work on bugfixing or debugging Fedora 21, or working on our website so it'll be ready for release time, I have to write this email message. I assumed the whole idea of Fedora.Next was to reduce bureaucracy and making sure we ship a high quality product. Apparently, I was wrong, and the point of Fedora.next seems to be *increasing* bureaucracy and having to discuss and write a policy for every one line commit we do.
If you are out of the loop of the recent events, look at this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1131248
--------- Now, enough bitter sarcasm, here is my draft:
In the following policy, I differentiate between "app launcher" and "app". An "app launcher" is a desktop file+icon that is shown in the application view, clicking on it would launch the app. An "app" is an application as defined by the GNOME 3 HIG (link TBD when HIG is published)
As always in policies, mandatory items are marked with the words "must" and "must not", the rest is nice-to-have.
App launchers in Fedora workstation *must*: * Have a unique 64x64 launcher icon (the same icon MUST NOT be used for one default launcher). * Have a matching High Contrast icon. * Have a name that is either short enough to not be elipsized by the shell or immediately recognizable even when elipsized. * Have a comment field in the desktop file with a one line summary of what the app is.
App launchers in Fedora workstation *should*: * Launch software that is an actual app - see the GNOME 3 HIG on the exact definition (link TBD when the HIG is published) * If the app is not an actual app, it should have the appropriate desktop file categories to be placed in the Sundry folder in GNOME Shell.
Apps in Fedora Workstation *must*: * Not depend on / pull in other apps OR app launchers. * Have exactly *one* app launcher - ie. two launchers to two separate parts of the same app is not allowed. * Be packaged separately (subpackages are okay) form other apps OR plugins. * Installable and removable independently from within GNOME Software, unless part of the "core applications" set, in which case they must NOT be removable.
Default apps in Fedora Workstation *should*: * Have appdata metadata (soon to be turned into a must). * Have a good reason for being included in the default set, especially if not considered part of the core desktop experience by the GNOME upstream. * Start in under than 10 seconds (on modern hardware).
An app or launcher that fails to complies with these guidelines MUST NOT be included in the default install.
Furthermore, if an app that doesn't follow this policy is include by default, it should be considered a Final Release blocker until the app is fixed to conform the policy or removed from the default install.
----
Each line in this policy has a very good reason behind it, and I hope I don't have to explain each one of them separately. Following this simple policy will ensure a polished and good user experience in viewing, launching and installing applications.
Note that I'm being a bit lax on the requirements here. I'd place "launch an actual app" in the "must" column but we tried that before and it didn't work due to (silly) internal project politics, as people want things like release notes have a launcher by default.
Feel free to reply with your opinion, and put it in the wiki somewhere when it's officially approved by the WG (which, to remind all involved parties, I'm not an official part of)
- -Elad Alfassa.
On Tue, Aug 19, 2014 at 3:51 PM, Elad Alfassa elad@fedoraproject.org wrote:
Hi all.
Since apparently we can't remove anything from default without having a "policy", and we can't ask packagers to fix their software either, I have to write this message.
Yeah, that's not true. We can remove things as we see fit without policy.
Apparently, not including a package by default is seen as "punishment". So, instead of doing actual work on bugfixing or debugging Fedora 21, or working on our website so it'll be ready for release time, I have to write this email message. I assumed the whole idea of Fedora.Next was to reduce bureaucracy and making sure we ship a high quality product. Apparently, I was wrong, and the point of Fedora.next seems to be *increasing* bureaucracy and having to discuss and write a policy for every one line commit we do.
You don't have to write a policy to justify a one line change. Writing a policy is helpful for issues beyond this specific problem. While you might view it as bureaucracy (which it is), if it's well written it will help avoid conflicts in the future.
In the following policy, I differentiate between "app launcher" and "app". An "app launcher" is a desktop file+icon that is shown in the application view, clicking on it would launch the app. An "app" is an application as defined by the GNOME 3 HIG (link TBD when HIG is published)
As always in policies, mandatory items are marked with the words "must" and "must not", the rest is nice-to-have.
App launchers in Fedora workstation *must*:
This doesn't really seem specific to Workstation. We should aim for distro-wide first, so other products have a similar look and feel. If they need to deviate, they can do so later.
- Have a unique 64x64 launcher icon (the same icon MUST NOT be used for one
default launcher).
I don't understand the "default launcher" follow on, nor why it isn't it's own bullet.
- Have a matching High Contrast icon.
- Have a name that is either short enough to not be elipsized by the shell
or immediately recognizable even when elipsized.
- Have a comment field in the desktop file with a one line summary of what
the app is.
App launchers in Fedora workstation *should*:
- Launch software that is an actual app - see the GNOME 3 HIG on the exact
definition (link TBD when the HIG is published)
- If the app is not an actual app, it should have the appropriate desktop
file categories to be placed in the Sundry folder in GNOME Shell.
Apps in Fedora Workstation *must*:
- Not depend on / pull in other apps OR app launchers.
- Have exactly *one* app launcher - ie. two launchers to two separate parts
of the same app is not allowed.
- Be packaged separately (subpackages are okay) form other apps OR plugins.
- Installable and removable independently from within GNOME Software,
unless part of the "core applications" set, in which case they must NOT be removable.
This last bullet seems product specific. That might be an addendum per-product, since the "core applications" are going to likely vary.
Default apps in Fedora Workstation *should*:
- Have appdata metadata (soon to be turned into a must).
- Have a good reason for being included in the default set, especially if
not considered part of the core desktop experience by the GNOME upstream.
Uh, I kind of object to this bullet. This is a Fedora policy/product, not a GNOME one. If Fedora sees a non-GNOME application as part of the core desktop experience, it shouldn't have to justify it based on what upstream GNOME thinks.
- Start in under than 10 seconds (on modern hardware).
That seems difficult to enforce/police. What happens if an app meets everything else but then fails to do this? Do we then yank it out? Who's going to sit there with a stopwatch and time every app? I realize this is a should, but it seems unnecessary.
josh
An app or launcher that fails to complies with these guidelines MUST NOT be included in the default install.
Furthermore, if an app that doesn't follow this policy is include by default, it should be considered a Final Release blocker until the app is fixed to conform the policy or removed from the default install.
Each line in this policy has a very good reason behind it, and I hope I don't have to explain each one of them separately. Following this simple policy will ensure a polished and good user experience in viewing, launching and installing applications.
Note that I'm being a bit lax on the requirements here. I'd place "launch an actual app" in the "must" column but we tried that before and it didn't work due to (silly) internal project politics, as people want things like release notes have a launcher by default.
Feel free to reply with your opinion, and put it in the wiki somewhere when it's officially approved by the WG (which, to remind all involved parties, I'm not an official part of)
-Elad Alfassa.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Tue, Aug 19, 2014 at 11:21 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Aug 19, 2014 at 3:51 PM, Elad Alfassa elad@fedoraproject.org wrote:
<snip>
As always in policies, mandatory items are marked with the words "must"
and
"must not", the rest is nice-to-have.
App launchers in Fedora workstation *must*:
This doesn't really seem specific to Workstation. We should aim for distro-wide first, so other products have a similar look and feel. If they need to deviate, they can do so later.
I do have other product specific things here. This policy is written with two facts in mind: 1) Fedora's default desktop offering is Fedora Workstation. 2) Fedora Workstation uses GNOME by default.
As such, if the WG would decide to switch desktops, this policy will need to be re-evaluated. Furthermore, this policy does not aim to apply to all applications in the distribution. It's meant to apply to anything we include by default in our default desktop product. If other applications want to follow it it'd be great, because it will improve user experience, but I can't force them to.
- Have a unique 64x64 launcher icon (the same icon MUST NOT be used for
one
default launcher).
I don't understand the "default launcher" follow on, nor why it isn't it's own bullet.
It's a typo. The same icon must not be used for more than one application launcher that is installed by default. We can't enforce non-default apps to have unique icons. This is there because it's clarifying on the word unique.
<snip>
- Installable and removable independently from within GNOME Software,
unless part of the "core applications" set, in which case they must NOT
be
removable.
This last bullet seems product specific. That might be an addendum per-product, since the "core applications" are going to likely vary.
Same comment as I said before. If other products or spins want to base on this policy, they can copy it and make the changes they need.
Default apps in Fedora Workstation *should*:
- Have appdata metadata (soon to be turned into a must).
- Have a good reason for being included in the default set, especially
if
not considered part of the core desktop experience by the GNOME upstream.
Uh, I kind of object to this bullet. This is a Fedora policy/product, not a GNOME one. If Fedora sees a non-GNOME application as part of the core desktop experience, it shouldn't have to justify it based on what upstream GNOME thinks.
If we install it by default and GNOME thinks it's core then having it removable would hurt our user experience. We can't have users removing Software itself, for example.
- Start in under than 10 seconds (on modern hardware).
That seems difficult to enforce/police. What happens if an app meets everything else but then fails to do this? Do we then yank it out? Who's going to sit there with a stopwatch and time every app? I realize this is a should, but it seems unnecessary.
It's a "should" item. It will make UX better. It's not something you can enforce, and therefor it's not in the must column. It's included because it's something many people don't pay much attention to, and if an app takes a long time to start (that is, show any UI, in case of libreoffice or similar big apps, a splash screen is fine) we should consider removing it from the default set or at least prioritize fixing it.
On Aug 19, 2014 1:52 PM, "Elad Alfassa" elad@fedoraproject.org wrote:
Hi all.
Since apparently we can't remove anything from default without having a
"policy", and we can't ask packagers to fix their software either, I have to write this message.
Apparently, not including a package by default is seen as "punishment".
So, instead of doing actual work on bugfixing or debugging Fedora 21, or working on our website so it'll be ready for release time, I have to write this email message. I assumed the whole idea of Fedora.Next was to reduce bureaucracy and making sure we ship a high quality product. Apparently, I was wrong, and the point of Fedora.next seems to be *increasing* bureaucracy and having to discuss and write a policy for every one line commit we do.
If you are out of the loop of the recent events, look at this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1131248
Now, enough bitter sarcasm, here is my draft:
In the following policy, I differentiate between "app launcher" and
"app".
An "app launcher" is a desktop file+icon that is shown in the application
view, clicking on it would launch the app.
An "app" is an application as defined by the GNOME 3 HIG (link TBD when
HIG is published)
As always in policies, mandatory items are marked with the words "must"
and "must not", the rest is nice-to-have.
App launchers in Fedora workstation *must*:
- Have a unique 64x64 launcher icon (the same icon MUST NOT be used for
one default launcher).
- Have a matching High Contrast icon.
- Have a name that is either short enough to not be elipsized by the
shell or immediately recognizable even when elipsized.
- Have a comment field in the desktop file with a one line summary of
what the app is.
App launchers in Fedora workstation *should*:
- Launch software that is an actual app - see the GNOME 3 HIG on the
exact definition (link TBD when the HIG is published)
- If the app is not an actual app, it should have the appropriate
desktop file categories to be placed in the Sundry folder in GNOME Shell.
Apps in Fedora Workstation *must*:
- Not depend on / pull in other apps OR app launchers.
- Have exactly *one* app launcher - ie. two launchers to two separate
parts of the same app is not allowed.
- Be packaged separately (subpackages are okay) form other apps OR
plugins.
- Installable and removable independently from within GNOME Software,
unless part of the "core applications" set, in which case they must NOT be removable.
Default apps in Fedora Workstation *should*:
- Have appdata metadata (soon to be turned into a must).
- Have a good reason for being included in the default set, especially
if not considered part of the core desktop experience by the GNOME upstream.
- Start in under than 10 seconds (on modern hardware).
An app or launcher that fails to complies with these guidelines MUST NOT
be included in the default install.
Furthermore, if an app that doesn't follow this policy is include by
default, it should be considered a Final Release blocker until the app is fixed to conform the policy or removed from the default install.
Each line in this policy has a very good reason behind it, and I hope I
don't have to explain each one of them separately. Following this simple policy will ensure a polished and good user experience in viewing, launching and installing applications.
Note that I'm being a bit lax on the requirements here. I'd place "launch
an actual app" in the "must" column but we tried that before and it didn't work due to (silly) internal project politics, as people want things like release notes have a launcher by default.
Feel free to reply with your opinion, and put it in the wiki somewhere
when it's officially approved by the WG (which, to remind all involved parties, I'm not an official part of)
-Elad Alfassa.
--
First, your approach here comes across as punitive. Maybe that's just frustrated delivery tainting good intentions, but between this post and the bug that prompted it, the connotation is there. There's an effort going to improve and create AppData files - a similar approach of offering guidance and contributions is sure to get more traction.
Back to the issue, you have:
1. A UI that shows all known (via .desktop file) graphical applications, without restrictions, to the user.
2. Some packages provide graphical applications of a class that you don't want to show in the UI by default.
So you have at least two avenues to deal with the situation:
1. Filter or categorize into submenus the applications you don't want to show in the default UI based on the existing desktop file metadata.
2. Draft a complex and subjective exclusion policy that targets applications you don't want to present to users, requiring a lot of packaging effort that may adversely affect other environments.
Okay, maybe *I'm* sounding a little bitter now, but come on. If something needs to change to meet your design goals, you can still be considerate and cooperative, and allow the possibility that the design might need to change to accommodate the software it presents.
--Pete
On Tue, 2014-08-19 at 22:51 +0300, Elad Alfassa wrote:
Apps in Fedora Workstation *must*:
Not depend on / pull in other apps OR app launchers.
Have exactly *one* app launcher - ie. two launchers to two separate
parts of the same app is not allowed.
- Be packaged separately (subpackages are okay) form other apps OR
plugins.
- Installable and removable independently from within GNOME Software,
unless part of the "core applications" set, in which case they must NOT be removable.
I think we need to get this into the packaging guidelines so that it applies to all packages in Fedora, not just those we choose to install by default.
On 19 August 2014 20:51, Elad Alfassa elad@fedoraproject.org wrote:
In the following policy, I differentiate between "app launcher" and "app".
Lots of good stuff here. I wonder if your list and my list (used for including apps in the AppStream metadata) could be merged or pull parts from each other? https://github.com/hughsie/appstream-glib/blob/master/README.md#what-is-an-a...
Richard
On Wed, Aug 20, 2014 at 10:13 AM, Richard Hughes hughsient@gmail.com wrote:
On 19 August 2014 20:51, Elad Alfassa elad@fedoraproject.org wrote:
In the following policy, I differentiate between "app launcher" and
"app".
Lots of good stuff here. I wonder if your list and my list (used for including apps in the AppStream metadata) could be merged or pull parts from each other?
https://github.com/hughsie/appstream-glib/blob/master/README.md#what-is-an-a...
Richard
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
While your policy is good, I couldn't find stuff we could merge, I mean, it makes sense to require all default apps to have 64x64 icons, but it might not make sense to force this on all apps we show on Software. Also, since my list says an app must be removable / installable from GNOME Software it means apps must conform with your list to conform with mine.
Either way, I copied it over to the wiki with minor edits and fixes: https://fedoraproject.org/wiki/User:Elad/Draft_app_guidelines#Policy
Feel free to merge these lists as you see fit.
On Tue, Aug 19, 2014 at 9:51 PM, Elad Alfassa elad@fedoraproject.org wrote:
Hi all.
Since apparently we can't remove anything from default without having a "policy", and we can't ask packagers to fix their software either, I have to write this message.
Apparently, not including a package by default is seen as "punishment". So, instead of doing actual work on bugfixing or debugging Fedora 21, or working on our website so it'll be ready for release time, I have to write this email message. I assumed the whole idea of Fedora.Next was to reduce bureaucracy and making sure we ship a high quality product. Apparently, I was wrong, and the point of Fedora.next seems to be *increasing* bureaucracy and having to discuss and write a policy for every one line commit we do.
If you are out of the loop of the recent events, look at this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1131248
Now, enough bitter sarcasm, here is my draft:
In the following policy, I differentiate between "app launcher" and "app". An "app launcher" is a desktop file+icon that is shown in the application view, clicking on it would launch the app. An "app" is an application as defined by the GNOME 3 HIG (link TBD when HIG is published)
As always in policies, mandatory items are marked with the words "must" and "must not", the rest is nice-to-have.
App launchers in Fedora workstation *must*:
- Have a unique 64x64 launcher icon (the same icon MUST NOT be used for one
default launcher).
64x64 is too small for high dpi screens (its the same as 32x32 for non hidpi screen) if "64x64" is your aim ask for 128x128.
On Wed, Aug 20, 2014 at 8:45 PM, drago01 drago01@gmail.com wrote:
64x64 is too small for high dpi screens (its the same as 32x32 for non hidpi screen) if "64x64" is your aim ask for 128x128. -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Okay. hidpi support is important. 128x128 it is!
On 20 August 2014 18:45, drago01 drago01@gmail.com wrote:
64x64 is too small for high dpi screens (its the same as 32x32 for non hidpi screen) if "64x64" is your aim ask for 128x128.
That would push the icon tarball from 6Mb to over 25Mb. I'm happy doing both sizes for hidpi, but I think an easier fix is just to scale the icons double size in the hidpi case in the client.
Richard.
On 08/20/2014 08:44 PM, Richard Hughes wrote:
On 20 August 2014 18:45, drago01 drago01@gmail.com wrote:
64x64 is too small for high dpi screens (its the same as 32x32 for non hidpi screen) if "64x64" is your aim ask for 128x128.
That would push the icon tarball from 6Mb to over 25Mb. I'm happy doing both sizes for hidpi, but I think an easier fix is just to scale the icons double size in the hidpi case in the client.
Perhaps hidpi icons might be something gnome-software could download on demand, similar to screenshots. First show scaled-up icons and then, on the background, download better images and replace the low-res images once the download is completed?
On Wed, Aug 20, 2014 at 9:44 PM, Richard Hughes hughsient@gmail.com wrote:
On 20 August 2014 18:45, drago01 drago01@gmail.com wrote:
64x64 is too small for high dpi screens (its the same as 32x32 for non hidpi screen) if "64x64" is your aim ask for 128x128.
That would push the icon tarball from 6Mb to over 25Mb. I'm happy doing both sizes for hidpi, but I think an easier fix is just to scale the icons double size in the hidpi case in the client.
Richard.
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
I think apps should ship with both 64x64 and 128x128, and Software should use the 64x64 ones still.
On Wed, 2014-08-20 at 22:13 +0300, Elad Alfassa wrote:
I think apps should ship with both 64x64 and 128x128, and Software should use the 64x64 ones still.
From our draft HIG [1]: "It is essential your application has a 256x256px size. With the advent of high-DPI displays, a 512x512px variant is recommended." So it probably makes sense to require 256x256 for applications installed by default. (The software center can be way more lenient.)
On Wed, Aug 20, 2014 at 11:51 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Wed, 2014-08-20 at 22:13 +0300, Elad Alfassa wrote:
I think apps should ship with both 64x64 and 128x128, and Software should use the 64x64 ones still.
From our draft HIG [1]: "It is essential your application has a 256x256px size. With the advent of high-DPI displays, a 512x512px variant is recommended." So it probably makes sense to require 256x256 for applications installed by default. (The software center can be way more lenient.)
[1] https://wiki.gnome.org/Design/HIG/IconsAndArtwork
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
That's getting bigger and bigger as we speak!
I'm okay with requiring 128x128 for default applications, but 256x256 might be asking too much... I'm not sure what to do. I guess have 256x256 as MUST and 512x512 as SHOULD?
Do you have statistics on apps shipping 256x256 icons in Fedora right now? How many are there? How many non-gnome apps do that?
On Wed, Aug 20, 2014 at 10:59 PM, Elad Alfassa elad@fedoraproject.org wrote:
On Wed, Aug 20, 2014 at 11:51 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Wed, 2014-08-20 at 22:13 +0300, Elad Alfassa wrote:
I think apps should ship with both 64x64 and 128x128, and Software should use the 64x64 ones still.
From our draft HIG [1]: "It is essential your application has a 256x256px size. With the advent of high-DPI displays, a 512x512px variant is recommended." So it probably makes sense to require 256x256 for applications installed by default. (The software center can be way more lenient.)
[1] https://wiki.gnome.org/Design/HIG/IconsAndArtwork
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
That's getting bigger and bigger as we speak!
I'm okay with requiring 128x128 for default applications, but 256x256 might be asking too much... I'm not sure what to do. I guess have 256x256 as MUST and 512x512 as SHOULD?
Do you have statistics on apps shipping 256x256 icons in Fedora right now? How many are there? How many non-gnome apps do that?
That's overkill imo. The biggest icons we show in the UI are 96x96 (192x192 on hidpi) so 128x128 must with 256x256 as should is good enough.
On Thu, Aug 21, 2014 at 12:07 AM, drago01 drago01@gmail.com wrote:
That's overkill imo. The biggest icons we show in the UI are 96x96 (192x192 on hidpi) so 128x128 must with 256x256 as should is good enough.
Sounds reasonable. I'll revise the draft accordingly.
On Thu, 2014-08-21 at 00:08 +0300, Elad Alfassa wrote:
On Thu, Aug 21, 2014 at 12:07 AM, drago01 drago01@gmail.com wrote: That's overkill imo. The biggest icons we show in the UI are 96x96
(192x192 on hidpi) so 128x128 must with 256x256 as should is good enough.
Sounds reasonable. I'll revise the draft accordingly.
OK. If we don't show anything bigger, then it doesn't matter if the HIG are more strict. Thanks!
On Thu, Aug 21, 2014 at 1:24 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Thu, 2014-08-21 at 00:08 +0300, Elad Alfassa wrote:
On Thu, Aug 21, 2014 at 12:07 AM, drago01 drago01@gmail.com wrote: That's overkill imo. The biggest icons we show in the UI are 96x96
(192x192 on hidpi) so 128x128 must with 256x256 as should is good enough.
Sounds reasonable. I'll revise the draft accordingly.
OK. If we don't show anything bigger, then it doesn't matter if the HIG are more strict. Thanks!
Now that this issue is solved, what is the next step? (assuming people have no more issues with my draft) I assume the next step would be if someone would edit my draft to sound more official-like, and then I'll post it again to the list for final approval?
On Wed, Aug 20, 2014 at 8:44 PM, Richard Hughes hughsient@gmail.com wrote:
On 20 August 2014 18:45, drago01 drago01@gmail.com wrote:
64x64 is too small for high dpi screens (its the same as 32x32 for non hidpi screen) if "64x64" is your aim ask for 128x128.
That would push the icon tarball from 6Mb to over 25Mb.
Why is this a problem?
I'm happy doing both sizes for hidpi, but I think an easier fix is just to scale the icons double size in the hidpi case in the client.
Sure can do that but they do look worse this way.
Perhaps he is referring to vector icons, where upscaling does not have such a destructive effect as bitmaps
On Wed, 20 Aug, 2014 at 8:45 PM, drago01 drago01@gmail.com wrote:
On Wed, Aug 20, 2014 at 8:44 PM, Richard Hughes hughsient@gmail.com wrote:
On 20 August 2014 18:45, drago01 drago01@gmail.com wrote:
64x64 is too small for high dpi screens (its the same as 32x32 for non hidpi screen) if "64x64" is your aim ask for 128x128.
That would push the icon tarball from 6Mb to over 25Mb.
Why is this a problem?
I'm happy doing both sizes for hidpi, but I think an easier fix is just to scale the icons double size in the hidpi case in the client.
Sure can do that but they do look worse this way.
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Aug 20, 2014, at 12:44 PM, Richard Hughes hughsient@gmail.com wrote:
On 20 August 2014 18:45, drago01 drago01@gmail.com wrote:
64x64 is too small for high dpi screens (its the same as 32x32 for non hidpi screen) if "64x64" is your aim ask for 128x128.
That would push the icon tarball from 6Mb to over 25Mb. I'm happy doing both sizes for hidpi, but I think an easier fix is just to scale the icons double size in the hidpi case in the client.
Most icons appear to be originally created as vector graphics. Does making the icon format SVG solve both the need for hires icons and keeping file size down?
The resampling method makes a huge difference. Conventional nearest neighbor, bilinear, and bicubic on 64x64 scaled up will either be jaggy, somewhat jaggy and soft, somewhat less jaggy and almost blurry – on hires displays, and it also depends on the artwork. This would probably do a better job: https://code.google.com/p/hqx/
On OS X Firefox went to 512x512 ic09 in firefox.icns in 2007. I'm not sure when they started to include the 1024x1024 ic10 in firefox.icns, but it's in Firefox 31. This firefox.icns file is 809KB and includes maybe 1/2 dozen icons of various resolutions and bitdepths. I don't know why they wouldn't just include 1024x1024 and expect the client to downsample.
Chris Murphy
On Wed, 20 Aug, 2014 at 9:01 PM, Chris Murphy lists@colorremedies.com wrote:
On Aug 20, 2014, at 12:44 PM, Richard Hughes hughsient@gmail.com wrote:
On 20 August 2014 18:45, drago01 drago01@gmail.com wrote:
64x64 is too small for high dpi screens (its the same as 32x32 for non hidpi screen) if "64x64" is your aim ask for 128x128.
That would push the icon tarball from 6Mb to over 25Mb. I'm happy doing both sizes for hidpi, but I think an easier fix is just to scale the icons double size in the hidpi case in the client.
Most icons appear to be originally created as vector graphics. Does making the icon format SVG solve both the need for hires icons and keeping file size down?
As you may know, one SVG to cover all resolutions is not ideal, since scaling the icon up would result in things like outlines that are too thick, lack of detail, etc, and downscaling would in most cases just result in a blurry icons...
On 08/20/2014 10:01 PM, Chris Murphy wrote:
Most icons appear to be originally created as vector graphics. Does making the icon format SVG solve both the need for hires icons and keeping file size down?
It helps a bit, but does unfortunately not go all the way.
https://cloud.gnome.org/public.php?service=files&t=97a8ee113b3600bc8c949... In the screenshot above the 48x48 canvas svg icons used for PDF Mod and Meld app icons certainly look better than the Pulseaudio prefs and Scribus icons (48x48 png's). It does give the icons very fat borders though.
The 256x256 png's used for the rest renders best out of the 3 variants. - Andreas
On Tue, 2014-08-19 at 22:51 +0300, Elad Alfassa wrote:
- Have a name that is either short enough to not be elipsized by the
shell or immediately recognizable even when elipsized.
This seems to vary based on screen resolution; the LibreOffice applications are not ellipsized on my desktop, but (without checking) I'm pretty sure they are on my laptop.
On Aug 21, 2014 5:59 AM, "Michael Catanzaro" mcatanzaro@gnome.org wrote:
On Tue, 2014-08-19 at 22:51 +0300, Elad Alfassa wrote:
- Have a name that is either short enough to not be elipsized by the
shell or immediately recognizable even when elipsized.
This seems to vary based on screen resolution; the LibreOffice applications are not ellipsized on my desktop, but (without checking) I'm pretty sure they are on my laptop.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Indeed, it does depend on screen resolution. The GNOME 3 HIG draft says app launcher names should be shorter than 15 characters, and I think that's what we should have in our policy too.
Hello all. I have updated the policy draft on the wiki. I've reworded it and reordered it to look and sound more official, and incorporated feedback I got from all of you on this list.
https://fedoraproject.org/wiki/User:Elad/Draft_app_guidelines
I now consider it the final draft of the policy/guidelines.
It is now up to the WG to decide if this policy is approved (with our without changes).
Thanks.
desktop@lists.fedoraproject.org