At the moment applications have to provide an icon >= 32x32px in size to be included in the AppStream metadata and shown in the software center. This is *tiny* on a HiDPI screen, so should I mandate that all applications ship a 64x64 (and ideally, 128x128/64x64@2 also) icon for the shell and gnome-software, or should I just pad+scale icons for the HiDPI case and make them look ridiculous?
I don't think we can, or should, design a software center to accept the lowest common denominator when it comes to icon sizes; we're doing really well now with AppData coverage[1] and I think we can raise the quality of upstream and packaged icons in the same way.
My proposal would make 64x64 the smallest icon size we show in the software center, and this will still be slightly blurry[2] in the HiDPI case. This would affect 539 (over half of all desktop applications) packaged in Fedora. It's clear we can't just do nothing, as more and more devices will have HiDPI screens, and more and more icons will look crazy small and fuzzy.
I don't think it's a good idea to mass-file 539 bugs, nor do I want to contact 539 upstream maintainers. 127 packages only ship a 32x32 icon, and that might be a good starting point for contacting upstreams or filing bugs.
Ideas? Comments? Affected packages attached as a text file.
Richard
[1] http://blogs.gnome.org/hughsie/2014/09/25/appstream-progress-in-september/ [2] https://ryanlerch.fedorapeople.org/software-blurry2.png
Hello, ----- Original Message -----
At the moment applications have to provide an icon >= 32x32px in size to be included in the AppStream metadata and shown in the software center. This is *tiny* on a HiDPI screen, so should I mandate that all applications ship a 64x64 (and ideally, 128x128/64x64@2 also) icon for the shell and gnome-software, or should I just pad+scale icons for the HiDPI case and make them look ridiculous?
This is $n-th gradual tightening of the rules, again affecting dozens if not hundreds of packages, and the “ideally” note suggests that you plan to make the rules even stricter in the future. Wouldn’t it be more efficient to try to look more into a future, and try to do _one_ icon improvement pass that could last us for at least, say, 3 or 5 years? Just ask for something like (1024x1024 bitmap or a SVG/PDF) by F22 Beta, to give us some future proofing, perhaps?
(And I always thought that HiDPI is trying to keep the screen size of elements the same and only add detail, which is inconsistent with displaying low-resolution icons in a smaller physical size, but what do I know…) Mirek
On Fri, Sep 26, 2014 at 1:36 PM, Miloslav Trmač mitr@redhat.com wrote:
(And I always thought that HiDPI is trying to keep the screen size of elements the same and only add detail, which is inconsistent with displaying low-resolution icons in a smaller physical size, but what do I know…)
No hidpi is about higher pixel destiny (i.e same as you get with phones today). So my 3200x1600 (14 inch) laptop is effectively just a 1600x900 screen with twice as high pixel destiny. So eveything gets render at twice the size to not be ridiculously small.
----- Original Message -----
On Fri, Sep 26, 2014 at 1:36 PM, Miloslav Trmač mitr@redhat.com wrote:
(And I always thought that HiDPI is trying to keep the screen size of elements the same and only add detail, which is inconsistent with displaying low-resolution icons in a smaller physical size, but what do I know…)
No hidpi is about higher pixel destiny (i.e same as you get with phones today). So my 3200x1600 (14 inch) laptop is effectively just a 1600x900 screen with twice as high pixel destiny. So eveything gets render at twice the size to not be ridiculously small.
It seems to me we are saying the same thing: if you have a 32×32 icon on 1600×900 taking 2%×3.6% of the screen, on 3200x1600 it should still be taking 2%×3.6%, i.e. be rendered as 64×64 pixels. Is that not the case? Mirek
On Fri, Sep 26, 2014 at 1:56 PM, Miloslav Trmač mitr@redhat.com wrote:
----- Original Message -----
On Fri, Sep 26, 2014 at 1:36 PM, Miloslav Trmač mitr@redhat.com wrote:
(And I always thought that HiDPI is trying to keep the screen size of elements the same and only add detail, which is inconsistent with displaying low-resolution icons in a smaller physical size, but what do I know…)
No hidpi is about higher pixel destiny (i.e same as you get with phones today). So my 3200x1600 (14 inch) laptop is effectively just a 1600x900 screen with twice as high pixel destiny. So eveything gets render at twice the size to not be ridiculously small.
It seems to me we are saying the same thing: if you have a 32×32 icon on 1600×900 taking 2%×3.6% of the screen, on 3200x1600 it should still be taking 2%×3.6%, i.e. be rendered as 64×64 pixels. Is that not the case?
Well almost that is the fallback way for non hidpi aware apps. If your application supports hidpi it won't render a 32x32 icon that way but use a 64x64 one instead and render it unscaled. Which looks better (i.e non blurry).
drago01 wrote on 2014-09-26 13:46 (UCT+0200):
hidpi is about higher pixel destiny (i.e same as you get with phones today). So my 3200x1600 (14 inch) laptop is effectively just a 1600x900 screen with twice as high pixel destiny. So eveything gets render at twice the size to not be ridiculously small.
4 1600x900 blocks fit in a 3200x1600 space without overlapping.
"Size" is a function of area, both height and width. Don't be mislead by "sizes" that are actually lengths, such font-size in CSS or toolkits.
Ergo, a 3200x1600 screen is not 2X pixel density, but 4X, given the two screens have the same physical dimensions.
Ergo, on any given display, a 64x64 icon is 4X the size (4X the pixels) of a 32x32 icon, 4096 vs. 1024.
Ergo, any size icon is rendered on a 3200x1600 screen at 1/4 the size of the same icon on a 1600x900 screen of same physical dimensions.
IOW, the nominal lengths associated with icon size and screen height and width understate the significance of pixel density on quality. That's why a relatively small nominal change in density, or icon "size", or text "size", produces a relatively larger apparent impact on quality, or lack thereof. It's why a modestly smaller "size" in any given physical space produces a large apparent reduction in legibility, and detail.
On 26 September 2014 12:36, Miloslav Trmač mitr@redhat.com wrote:
This is $n-th gradual tightening of the rules
Right, I think that's the only way to transition from having no rules of inclusion, to a large cohesive set of high quality applications. Dropping 95% of applications in the software center from F21 to F22 would be a very difficult thing for a lot of people to swallow.
Wouldn’t it be more efficient to try to look more into a future, and try to do _one_ icon improvement pass that could last us for at least, say, 3 or 5 years?
I think if I proposed 5 years ago that we'd be using 240 DPI screens and we should start shipping icons 16 times as large on disk for this case I don't think I would have achieved anything.
Just ask for something like (1024x1024 bitmap or a SVG/PDF) by F22 Beta, to give us some future proofing, perhaps?
SVG isn't a silver bullet. You need a very different source SVG for a 16px icon to a 256px icon just due to the amount of detail that has to be ommitted.
(And I always thought that HiDPI is trying to keep the screen size of elements
You can either sacrifice quality or size; padding a 32px icon to 128px with a giant white border would keep the icon crisp and sharp, but scaling it up *4 would make it the right size, but with awful quality.
Richard.
----- Original Message -----
On 26 September 2014 12:36, Miloslav Trmač mitr@redhat.com wrote:
This is $n-th gradual tightening of the rules
Right, I think that's the only way to transition from having no rules of inclusion, to a large cohesive set of high quality applications. Dropping 95% of applications in the software center from F21 to F22 would be a very difficult thing for a lot of people to swallow.
Doing the same kind of work over and over is also difficult to swallow. I don’t know what the right answer is, I am just concerned. (Or, to put it in personal terms, I have two packages that are so marginally used that I am on the fence between updating them and orphaning them; they don’t have any appdata file yet, and seeing the pattern, it is always just too easy to rationalize that waiting for the next rule update will save me work.)
Just ask for something like (1024x1024 bitmap or a SVG/PDF) by F22 Beta, to give us some future proofing, perhaps?
SVG isn't a silver bullet. You need a very different source SVG for a 16px icon to a 256px icon just due to the amount of detail that has to be ommitted.
The 256px icon doesn’t _have_ to have more detail to be sharp and look basically good (well, unless you decide to include complex real-world objects like a globe with all the continents), and do you expect to render them at 16px from the app data anywhere?
(And I always thought that HiDPI is trying to keep the screen size of elements
You can either sacrifice quality or size; padding a 32px icon to 128px with a giant white border would keep the icon crisp and sharp, but scaling it up *4 would make it the right size, but with awful quality.
It would at least be no worse than having the same physical-size non-HiDPI screen; showing a tiny icon on HiDPI may well cause the HiDPi display to be _less_ usable. Blurry is “just” ugly (more of an aesthetics issue), tiny is unrecognizable (more of an getting-the-job-done issue). Mirek
On Fri, Sep 26, 2014 at 12:56:47PM +0100, Richard Hughes wrote:
(And I always thought that HiDPI is trying to keep the screen size of elements
You can either sacrifice quality or size; padding a 32px icon to 128px with a giant white border would keep the icon crisp and sharp, but scaling it up *4 would make it the right size, but with awful quality.
Actually scaling icon by integer factor should not have noticable impact on quality. It's just drawing 4 or 8 pixels instead of one. The icons you are talking about were not only scaled, but also blurred (filtered?). That's blurring which is degrading quality. First step to improvement would be to disable blurring. Using appropiate scaling algorithm (like 2xSai) would help even more.
On 26 September 2014 13:57, Tomasz Torcz tomek@pipebreaker.pl wrote:
Actually scaling icon by integer factor should not have noticable impact on quality.
It really does, maybe not in an absolute way like you suggest, but in a subjective way. When you're used to everything being crisp and clear, suddenly a low resolution icon or screenshot sticks out like a sore thumb.
Richard
On 09/26/2014 12:19 PM, Richard Hughes wrote:
At the moment applications have to provide an icon >= 32x32px in size to be included in the AppStream metadata and shown in the software center. This is *tiny* on a HiDPI screen, so should I mandate that all applications ship a 64x64 (and ideally, 128x128/64x64@2 also) icon for the shell and gnome-software, or should I just pad+scale icons for the HiDPI case and make them look ridiculous?
I'd say we should definitely include 128x128 icons in the metadata for hidpi support -- one set of 64x64 icons for regular screens and another set of 128x128 icons for hidpi screens.
I don't think we can _require_ that every app ship a 128x128 icon at this point though. If they aren't available, we should just upscale the low res icons for hidpi screens and have appstream-builder emit a warning to make sure maintainers are aware that their apps are missing important icons.
I don't think we can, or should, design a software center to accept the lowest common denominator when it comes to icon sizes; we're doing really well now with AppData coverage[1] and I think we can raise the quality of upstream and packaged icons in the same way.
My proposal would make 64x64 the smallest icon size we show in the software center, and this will still be slightly blurry[2] in the HiDPI case. This would affect 539 (over half of all desktop applications) packaged in Fedora. It's clear we can't just do nothing, as more and more devices will have HiDPI screens, and more and more icons will look crazy small and fuzzy.
I don't think it's a good idea to mass-file 539 bugs, nor do I want to contact 539 upstream maintainers. 127 packages only ship a 32x32 icon, and that might be a good starting point for contacting upstreams or filing bugs.
Yes, I'd say it's time to cut off apps with 32x32 icons. Padding 48x48 icons to 64x64 might still be OK though, especially since the number of affected apps is quite large.
In any case, should emit warnings for missing 64x64 and 128x128 icons to make sure maintainers know there's something missing and have time to prepare.
On 26 September 2014 13:12, Kalev Lember kalevlember@gmail.com wrote:
Yes, I'd say it's time to cut off apps with 32x32 icons. Padding 48x48 icons to 64x64 might still be OK though, especially since the number of affected apps is quite large.
Right, this is probably the best course of action now.
In any case, should emit warnings for missing 64x64 and 128x128 icons to make sure maintainers know there's something missing and have time to prepare.
When to warn them? In rpmbuild? In the koji logs no human ever reads? You can get this kind of warning now, if you BR: libappstream-glib and then do a:
%check DESTDIR=$RPM_BUILD_ROOT appstream-util check-root
...but this requires the packager to actually add this manually.
Richard
On 09/26/2014 02:23 PM, Richard Hughes wrote:
When to warn them? In rpmbuild? In the koji logs no human ever reads? You can get this kind of warning now, if you BR: libappstream-glib and then do a:
%check DESTDIR=$RPM_BUILD_ROOT appstream-util check-root
...but this requires the packager to actually add this manually.
An option would be to add libappstream-glib to the minimal koji buildroot and run the check automatically for every package that's built in koji.
And same thing with desktop-file-validate, instead of manually adding it in every package's %check / %install, could just have rpmbuild automatically run it for all builds.
Of course, we'd need a way to opt out (something like %global _ignore_desktop_file_validate 1), but that should be easy to do as well.
Would something like that make sense?
On 26 September 2014 13:36, Kalev Lember kalevlember@gmail.com wrote:
An option would be to add libappstream-glib to the minimal koji buildroot and run the check automatically for every package that's built in koji.
If you know how to do that, that'd be awesome.
And same thing with desktop-file-validate, instead of manually adding it in every package's %check / %install, could just have rpmbuild automatically run it for all builds.
Right.
Of course, we'd need a way to opt out (something like %global _ignore_desktop_file_validate 1), but that should be easy to do as well.
I'd be happy to fix up any of the false-positive failures relating to this. In F21 there's only one known failure (dconf-editor) and that's fixed for F22.
Richard
On 09/26/2014 02:39 PM, Richard Hughes wrote:
On 26 September 2014 13:36, Kalev Lember kalevlember@gmail.com wrote:
An option would be to add libappstream-glib to the minimal koji buildroot and run the check automatically for every package that's built in koji.
If you know how to do that, that'd be awesome.
And same thing with desktop-file-validate, instead of manually adding it in every package's %check / %install, could just have rpmbuild automatically run it for all builds.
Right.
Here's a quick patch to redhat-rpm-config that makes it automatically run desktop-file-validate after %install. The appdata validation would be similar, just another 2 lines to the macro files. Alternatively, could also put it in desktop-file-utils-srpm-macros or something, but I think it's overkill for just two lines.
Any opinions / comments from the rpm maintainers?
From 69f1dddeed7c1e399e6a88f8adadfe98a1dd8f2b Mon Sep 17 00:00:00 2001
From: Kalev Lember kalevlember@gmail.com Date: Fri, 26 Sep 2014 15:25:53 +0200 Subject: [PATCH] Automatically run desktop-file-validate in %check
--- macros | 2 ++ redhat-rpm-config.spec | 6 +++++- 2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/macros b/macros index 6d855fa..464d549 100644 --- a/macros +++ b/macros @@ -19,6 +19,7 @@ %_fmoddir %{_libdir}/gfortran/modules
%_enable_debug_packages 1 +%_enable_desktop_file_validate 1 %_include_minidebuginfo 1
#============================================================================== @@ -94,6 +95,7 @@ /usr/lib/rpm/brp-python-bytecompile %{__python} %{?_python_bytecompile_errors_terminate_build} \ /usr/lib/rpm/brp-python-hardlink \ %{!?__jar_repack:/usr/lib/rpm/redhat/brp-java-repack-jars} \ + %{?_enable_desktop_file_validate:if ls -A %{buildroot}%{_datadir}/applications/ 2>/dev/null; then desktop-file-validate %{buildroot}%{_datadir}/applications/*.desktop; fi} \ %{nil}
# /usr/lib/rpm/redhat/brp-implant-ident-static diff --git a/redhat-rpm-config.spec b/redhat-rpm-config.spec index fa65527..609b5ff 100644 --- a/redhat-rpm-config.spec +++ b/redhat-rpm-config.spec @@ -6,7 +6,7 @@
Summary: Red Hat specific rpm configuration files Name: redhat-rpm-config -Version: 26 +Version: 27 Release: 1%{?dist} # No version specified. License: GPL+ @@ -62,6 +62,7 @@ Source602: libsymlink.attr
BuildArch: noarch Requires: coreutils +Requires: desktop-file-utils Requires: perl-srpm-macros Requires: ocaml-srpm-macros Requires: gnat-srpm-macros @@ -135,6 +136,9 @@ install -p -m 755 -t %{buildroot}%{_rpmconfigdir} kmod.prov %{_rpmconfigdir}/macros.d/macros.kmp
%changelog +* Fri Sep 26 2014 Kalev Lember kalevlember@gmail.com - 27-1 +- Automatically run desktop-file-validate in %%check + * Mon Sep 22 2014 Panu Matilainen pmatilai@redhat.com - 26-1 - Gnat macros are now in a package of their own (#1133632)
On 09/26/2014 05:20 PM, Kalev Lember wrote:
On 09/26/2014 02:39 PM, Richard Hughes wrote:
On 26 September 2014 13:36, Kalev Lember kalevlember@gmail.com wrote:
An option would be to add libappstream-glib to the minimal koji buildroot and run the check automatically for every package that's built in koji.
If you know how to do that, that'd be awesome.
And same thing with desktop-file-validate, instead of manually adding it in every package's %check / %install, could just have rpmbuild automatically run it for all builds.
Right.
Here's a quick patch to redhat-rpm-config that makes it automatically run desktop-file-validate after %install. The appdata validation would be similar, just another 2 lines to the macro files. Alternatively, could also put it in desktop-file-utils-srpm-macros or something, but I think it's overkill for just two lines.
Any opinions / comments from the rpm maintainers?
As a concept, I've no problem. This patch as-is wont quite do however, see below:
From 69f1dddeed7c1e399e6a88f8adadfe98a1dd8f2b Mon Sep 17 00:00:00 2001 From: Kalev Lember kalevlember@gmail.com Date: Fri, 26 Sep 2014 15:25:53 +0200 Subject: [PATCH] Automatically run desktop-file-validate in %check
macros | 2 ++ redhat-rpm-config.spec | 6 +++++- 2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/macros b/macros index 6d855fa..464d549 100644 --- a/macros +++ b/macros @@ -19,6 +19,7 @@ %_fmoddir %{_libdir}/gfortran/modules
%_enable_debug_packages 1 +%_enable_desktop_file_validate 1 %_include_minidebuginfo 1
#============================================================================== @@ -94,6 +95,7 @@ /usr/lib/rpm/brp-python-bytecompile %{__python} %{?_python_bytecompile_errors_terminate_build} \ /usr/lib/rpm/brp-python-hardlink \ %{!?__jar_repack:/usr/lib/rpm/redhat/brp-java-repack-jars} \
- %{?_enable_desktop_file_validate:if ls -A %{buildroot}%{_datadir}/applications/ 2>/dev/null; then desktop-file-validate %{buildroot}%{_datadir}/applications/*.desktop; fi} \ %{nil}
Please put the actual validation into an external script, brp-desktop-file-validate or whatever. That way its consistent with the other similar things, easier to test-run outside rpmbuild and unlike inlining, has room for future growth.
# /usr/lib/rpm/redhat/brp-implant-ident-static diff --git a/redhat-rpm-config.spec b/redhat-rpm-config.spec index fa65527..609b5ff 100644 --- a/redhat-rpm-config.spec +++ b/redhat-rpm-config.spec @@ -6,7 +6,7 @@
Summary: Red Hat specific rpm configuration files Name: redhat-rpm-config -Version: 26 +Version: 27 Release: 1%{?dist} # No version specified. License: GPL+ @@ -62,6 +62,7 @@ Source602: libsymlink.attr
BuildArch: noarch Requires: coreutils +Requires: desktop-file-utils
This is a problem, redhat-rpm-config is one of the distro bootstrap packages and we dont want any extra dependencies here. Plus there's no point dragging desktop-file-utils and its dependencies on every single build when its only useful for packages with .. well, desktop files.
I'd rather see this done in a way that it only executes when desktop-file-utils is installed, which should already be a buildrequire for all packages containing desktop files I think.
Requires: perl-srpm-macros Requires: ocaml-srpm-macros Requires: gnat-srpm-macros @@ -135,6 +136,9 @@ install -p -m 755 -t %{buildroot}%{_rpmconfigdir} kmod.prov %{_rpmconfigdir}/macros.d/macros.kmp
%changelog +* Fri Sep 26 2014 Kalev Lember kalevlember@gmail.com - 27-1 +- Automatically run desktop-file-validate in %%check
This is not related to %check, the build root policy scripts run at end of %install.
- Panu -
- Mon Sep 22 2014 Panu Matilainen pmatilai@redhat.com - 26-1
- Gnat macros are now in a package of their own (#1133632)
Hi
On Mon, Sep 29, 2014 at 7:19 AM, Panu Matilainen wrote:
I'd rather see this done in a way that it only executes when
desktop-file-utils is installed, which should already be a buildrequire for all packages containing desktop files I think.
Agreed. I would also like to see this be part of mock builds.
Rahul
On 09/29/2014 01:19 PM, Panu Matilainen wrote:
Please put the actual validation into an external script, brp-desktop-file-validate or whatever. That way its consistent with the other similar things, easier to test-run outside rpmbuild and unlike inlining, has room for future growth.
Thanks for the comments, Panu! I had a chat with releng in the mean time and they also preferred to not add anything more than absolutely necessary to the minimum koji buildroot.
So here comes next version. desktop-file-utils rpm would install the validation brp script in /usr/lib/rpm/ and if it's there, redhat-rpm-config macros run the script at the end of %install.
This is the script that desktop-file-utils rpm would install (appdata script would be analogous):
--------- #!/bin/bash
errors_terminate=$1
# If using normal root, return immediately if [ -z "$RPM_BUILD_ROOT" -o "$RPM_BUILD_ROOT" = "/" ]; then exit 0 fi
# If no desktop files are installed, return immediately if ! ls -A "$RPM_BUILD_ROOT"/usr/share/applications/ 2>/dev/null; then exit 0 fi
desktop-file-validate "$RPM_BUILD_ROOT"/usr/share/applications/*.desktop
if [ $? -ne 0 -a 0$errors_terminate -ne 0 ]; then # One or more of the files had a syntax error exit 1 fi exit 0 ---------
... and the redhat-rpm-config patch:
From d5f57dc742e7b71b5da7b7b2ecea3b30b155bed2 Mon Sep 17 00:00:00 2001
From: Kalev Lember kalevlember@gmail.com Date: Wed, 1 Oct 2014 12:13:01 +0200 Subject: [PATCH] Run desktop file and appdata validation scripts if they exist
This also adds two new macros that can be used from within individual spec files to make the validation errors non-fatal. To do that, use one of the following in spec files:
%global _desktop_file_validate_errors_terminate_build 0 %global _appdata_validate_errors_terminate_build 0
In F21, the default setting for both of the macros will be 0, but in F22 and above they'll default to 1. --- macros | 8 ++++++++ redhat-rpm-config.spec | 5 ++++- 2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/macros b/macros index 6d855fa..7c0e428 100644 --- a/macros +++ b/macros @@ -93,6 +93,8 @@ /usr/lib/rpm/brp-strip-static-archive %{__strip} \ /usr/lib/rpm/brp-python-bytecompile %{__python} %{?_python_bytecompile_errors_terminate_build} \ /usr/lib/rpm/brp-python-hardlink \ + [ -x /usr/lib/rpm/brp-desktop-file-validate ] && /usr/lib/rpm/brp-desktop-file-validate %{?_desktop_file_validate_errors_terminate_build} \ + [ -x /usr/lib/rpm/brp-appdata-validate ] && /usr/lib/rpm/brp-appdata-validate %{?_appdata_validate_errors_terminate_build} \ %{!?__jar_repack:/usr/lib/rpm/redhat/brp-java-repack-jars} \ %{nil}
@@ -112,6 +114,12 @@ # Should missing buildids terminate a build? %_missing_build_ids_terminate_build 1
+# Should desktop-file-validate errors terminate a build? +%_desktop_file_validate_errors_terminate_build 1 + +# Should appdata validate errors terminate a build? +%_appdata_validate_errors_terminate_build 1 + # ## Should python bytecompilation errors terminate a build? %_python_bytecompile_errors_terminate_build 1 diff --git a/redhat-rpm-config.spec b/redhat-rpm-config.spec index fa65527..bb15a8f 100644 --- a/redhat-rpm-config.spec +++ b/redhat-rpm-config.spec @@ -6,7 +6,7 @@
Summary: Red Hat specific rpm configuration files Name: redhat-rpm-config -Version: 26 +Version: 27 Release: 1%{?dist} # No version specified. License: GPL+ @@ -135,6 +135,9 @@ install -p -m 755 -t %{buildroot}%{_rpmconfigdir} kmod.prov %{_rpmconfigdir}/macros.d/macros.kmp
%changelog +* Wed Oct 01 2014 Kalev Lember kalevlember@gmail.com - 27-1 +- Run desktop file and appdata validation scripts if they exist + * Mon Sep 22 2014 Panu Matilainen pmatilai@redhat.com - 26-1 - Gnat macros are now in a package of their own (#1133632)
Kalev Lember kalevlember@gmail.com wrote:
# If no desktop files are installed, return immediately if ! ls -A "$RPM_BUILD_ROOT"/usr/share/applications/ 2>/dev/null; then exit 0 fi
That tests whether the directory exists, not whether it contains desktop files. If that's what you want, then «if [ -d "$RPM_BUILD_ROOT"/usr/share/applications/ ]; then» would be much less confusing code.
Björn Persson
On 10/01/2014 03:07 PM, Björn Persson wrote:
Kalev Lember kalevlember@gmail.com wrote:
# If no desktop files are installed, return immediately if ! ls -A "$RPM_BUILD_ROOT"/usr/share/applications/ 2>/dev/null; then exit 0 fi
That tests whether the directory exists, not whether it contains desktop files. If that's what you want, then «if [ -d "$RPM_BUILD_ROOT"/usr/share/applications/ ]; then» would be much less confusing code.
Yes indeed, I seem to have gotten it wrong. What I wanted to test was not for the directory, but for the files inside. Would something like this work better?
if ! ls "$RPM_BUILD_ROOT"/usr/share/applications/*.desktop &>/dev/null; then
Kalev Lember kalevlember@gmail.com wrote:
On 10/01/2014 03:07 PM, Björn Persson wrote:
Kalev Lember kalevlember@gmail.com wrote:
# If no desktop files are installed, return immediately if ! ls -A "$RPM_BUILD_ROOT"/usr/share/applications/ 2>/dev/null; then exit 0 fi
That tests whether the directory exists, not whether it contains desktop files. If that's what you want, then «if [ -d "$RPM_BUILD_ROOT"/usr/share/applications/ ]; then» would be much less confusing code.
Yes indeed, I seem to have gotten it wrong. What I wanted to test was not for the directory, but for the files inside. Would something like this work better?
if ! ls "$RPM_BUILD_ROOT"/usr/share/applications/*.desktop &>/dev/null; then
That should work, if you want to ignore files in subdirectories such as /usr/share/applications/kde4. Files without the .desktop suffix will of course also be ignored, should there be any.
Björn Persson
On 2014-09-26, 10:19 GMT, Richard Hughes wrote:
At the moment applications have to provide an icon >= 32x32px in size to be included in the AppStream metadata and shown in the software center. This is *tiny* on a HiDPI screen, so should I mandate that all applications ship a 64x64 (and ideally, 128x128/64x64@2 also) icon for the shell and gnome-software, or should I just pad+scale icons for the HiDPI case and make them look ridiculous?
I think this is the way to craziness ... KDE supported for its icons SVG sometimes in 3.* times (that’s before 2006). Couldn’t we just stop this madness of bitmaps?
Matěj
On 29 September 2014 12:23, Matěj Cepl mcepl@cepl.eu wrote:
Couldn’t we just stop this madness of bitmaps?
SVGs are not a silver bullet. You'd want a very different source SVG file for an icon that's designed to be displayed at 22x22, to an icon designed to be displayed at 256x256. Plus, rendering SVGs with inkscape and rsvg sometimes output *very* different results...
Richard
On 29 September 2014 12:40, Richard Hughes hughsient@gmail.com wrote:
On 29 September 2014 12:23, Matěj Cepl mcepl@cepl.eu wrote:
Couldn’t we just stop this madness of bitmaps?
SVGs are not a silver bullet. You'd want a very different source SVG file for an icon that's designed to be displayed at 22x22, to an icon designed to be displayed at 256x256. Plus, rendering SVGs with inkscape and rsvg sometimes output *very* different results...
Not necessarily. The strongest argument so far in this thread about not simply scaling up (in pixels) icons has been that it's noticeable in an environment where the other elements are crisp. Your point about SVGs is that larger icons can include more detail, but actually the icons are not supposed to be physically larger, so is adding more detail a good move? Who is using magnifying glasses to view icons? Is it a good idea taking into account visually impaired people to cram in more detail to the same screen area just because it's available?
On Mon, 2014-09-29 at 22:05 +0100, Ian Malone wrote:
Who is using magnifying glasses to view icons?
Icons are displayed far larger in GNOME Shell than in other desktop environments, and the difference between an SVG icon and a 256x256 icon (the mandatory minimum size for GNOME apps, and I'm definitely not the maintainer of several apps with only 128x128 icons, don't look at me) is fairly noticeable. 48x48 is really too low. 64x64 is too low....
On 30 September 2014 02:09, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Mon, 2014-09-29 at 22:05 +0100, Ian Malone wrote:
Who is using magnifying glasses to view icons?
Icons are displayed far larger in GNOME Shell than in other desktop environments, and the difference between an SVG icon and a 256x256 icon (the mandatory minimum size for GNOME apps, and I'm definitely not the maintainer of several apps with only 128x128 icons, don't look at me) is fairly noticeable. 48x48 is really too low. 64x64 is too low....
That might be a good reason, but it's not the one given at the start of this proposal, that was that larger icons are needed for the software centre (i.e. for applications to get included in the installer) due to higher resolution displays. In which case thinking of the level of detail that should be in an icon should not be in terms of 32x32, 64x64 etc., but in displayed sizes. Gnome Shell (last time I looked) displays what you might call large icons, where more detail is appropriate, those will have to get bigger (in pixel count) too by this reasoning, without increasing in detail.
On Wed, 2014-10-01 at 08:57 +0100, Ian Malone wrote:
That might be a good reason, but it's not the one given at the start of this proposal, that was that larger icons are needed for the software centre (i.e. for applications to get included in the installer) due to higher resolution displays.
I think the software center and shell display icons at the same size, so it matters equally to both.
On Wed, 2014-10-01 at 08:19 -0500, Michael Catanzaro wrote:
I think the software center and shell display icons at the same size, so it matters equally to both.
I would be smarter if I checked such facts BEFORE sending emails and not immediately AFTER. The icons in Software are indeed smaller.
On Monday 29 of September 2014 12:40:30 Richard Hughes wrote:
On 29 September 2014 12:23, Matěj Cepl mcepl@cepl.eu wrote:
Couldn’t we just stop this madness of bitmaps?
+10
SVGs are not a silver bullet.
Well, it's better than bitmaps.
You'd want a very different source SVG file for an icon that's designed to be displayed at 22x22, to an icon designed to be displayed at 256x256.
The point is that even if you have a "small" SVG, you can still scale it up to 256x256 without the icon being pixelated - yes, it will have fewer details, it will be obvious that it's not really aimed for the large resolution, but I think that's zillion times better than showing pixelated icons.
KDE apps sometimes provide different versions of SVG icons for different level of detail, but the cool thing here is that you only need to provide for example a small version - for 16x16 - 64x64 sizes, and a large version for 128x128 and above - no need to maintain 6 bitmaps or so. Also with SVGZ (gzipped SVG) this can save some space.
Plus, rendering SVGs with inkscape and rsvg sometimes output *very* different results...
Well, that's either bug in Inkscape or rsvg. Try Karbon (from the Calligra suite) :-)
Dan
Richard
On Fri, Sep 26, 2014 at 12:19 PM, Richard Hughes hughsient@gmail.com wrote:
At the moment applications have to provide an icon >= 32x32px in size to be included in the AppStream metadata and shown in the software center. This is *tiny* on a HiDPI screen, so should I mandate that all applications ship a 64x64 (and ideally, 128x128/64x64@2 also) icon for the shell and gnome-software, or should I just pad+scale icons for the HiDPI case and make them look ridiculous?
I don't think we can, or should, design a software center to accept the lowest common denominator when it comes to icon sizes; we're doing really well now with AppData coverage[1] and I think we can raise the quality of upstream and packaged icons in the same way.
My proposal would make 64x64 the smallest icon size we show in the software center, and this will still be slightly blurry[2] in the HiDPI case. This would affect 539 (over half of all desktop applications) packaged in Fedora. It's clear we can't just do nothing, as more and more devices will have HiDPI screens, and more and more icons will look crazy small and fuzzy.
I don't think it's a good idea to mass-file 539 bugs, nor do I want to contact 539 upstream maintainers. 127 packages only ship a 32x32 icon, and that might be a good starting point for contacting upstreams or filing bugs.
Ideas? Comments? Affected packages attached as a text file.
Richard
[1] http://blogs.gnome.org/hughsie/2014/09/25/appstream-progress-in-september/ [2] https://ryanlerch.fedorapeople.org/software-blurry2.png
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Is it only me, that is thinking, that all there rules to make things looks prettier in Gnome Software or you package will get excluded if you dont live up to the rules is a little hostile for packagers. It is good to have some guidelines to make your application present itself in the best possible way if you care, but may people are more interested in functionality and not so much about eyecandy. I understand that Richard, want his application to look so good as possible, but in the end it upstreams project there decides if they want to ship at buttugly icon in 16x16 and they should not be excluded for that. Gnome software could workaround it by have some kind of cool frame to put around the icons if they are to small to look good in the context of Gnome software.
Tim
On 1 October 2014 17:15, Tim Lauridsen tim.lauridsen@gmail.com wrote:
Is it only me, that is thinking, that all there rules to make things looks prettier in Gnome Software or you package will get excluded if you dont live up to the rules
It's probably not just you.
is a little hostile for packagers.
Actually, I'm trying to work upstream as much as possible. If you read my blog, I've been doing frequent updates on just how many upstream bugtrackers and maintainer emails I've sent. tl;dr: many hundreds. Packagers are going to have to get involved if upstream is dead, but that's the cost of being a package maintainer of obsolete or dead software without letting it die by obsoleting it and removing it from the distro.
I understand that Richard, want his application to look so good as possible, but in the end it upstreams project there decides if they want to ship at buttugly icon in 16x16
Yes, it's totally up to them, but this should not preclude us making rules for the workstation.
Gnome software could workaround it by have some kind of cool frame to put around the icons if they are to small to look good in the context of Gnome software.
Designing an application for the lowest common denominator does not give you a high-quality cohesive application that's easy to use and nice on the eye. It gives you a miss-mash of ugly noise that's hard to use. I think it's fine that we are essentially saying "you have to do X, Y, Z to be showcased on the workstation". I've essentially slipped into the role of the person making the decisions about the software installer on the workstation product, and also upstream maintainer of most of this stuff. If anybody wants to refer any of my decisions up to the workstation working group, I'd be happy to talk to them, but I've a feeling they would be *less* forgiving than I'm currently being.
Richard
On Thu, Oct 2, 2014 at 11:17 AM, Richard Hughes hughsient@gmail.com wrote:
Designing an application for the lowest common denominator does not give you a high-quality cohesive application that's easy to use and nice on the eye. It gives you a miss-mash of ugly noise that's hard to use. I think it's fine that we are essentially saying "you have to do X, Y, Z to be showcased on the workstation". I've essentially slipped into the role of the person making the decisions about the software installer on the workstation product, and also upstream maintainer of most of this stuff. If anybody wants to refer any of my decisions up to the workstation working group, I'd be happy to talk to them, but I've a feeling they would be *less* forgiving than I'm currently being.
I think that is a bad idea to exclude applications from a Software manager, because they don't live up to some visual quality guidelines. It don't benfit the endusers, if the software manager only shows 50% of the gui applications in the Fedora repositories. What about not showing the icons if they dont have the need size, just show a default icon based on the application category they you have both the good look and a lot of applications.
Tim
On 2 October 2014 15:17, Tim Lauridsen tim.lauridsen@gmail.com wrote:
I think that is a bad idea to exclude applications from a Software manager, because they don't live up to some visual quality guidelines.
There's actually a whole load of reasons why we'd blacklist applications: https://github.com/hughsie/appstream-glib#guidelines-for-applications for instance programs that identify themselves as "settings" or apps that haven't had an upstream release in 5 years.
Richard.
Am 02.10.2014 um 16:32 schrieb Richard Hughes:
On 2 October 2014 15:17, Tim Lauridsen tim.lauridsen@gmail.com wrote:
I think that is a bad idea to exclude applications from a Software manager, because they don't live up to some visual quality guidelines.
There's actually a whole load of reasons why we'd blacklist applications: https://github.com/hughsie/appstream-glib#guidelines-for-applications for instance programs that identify themselves as "settings" or apps that haven't had an upstream release in 5 years
don't get me wrong but "haven't had an upstream release in 5 years" is a silly reasoning - if an application works and has the feature set it was intended to provide upstream needs to open the changelog type there "to make some distribution clown happy", raise the version number and the maintainer in the distribution too has useless work?
On Thu, Oct 02, 2014 at 04:47:08PM +0200, Reindl Harald wrote:
Am 02.10.2014 um 16:32 schrieb Richard Hughes:
On 2 October 2014 15:17, Tim Lauridsen tim.lauridsen@gmail.com wrote:
I think that is a bad idea to exclude applications from a Software manager, because they don't live up to some visual quality guidelines.
There's actually a whole load of reasons why we'd blacklist applications: https://github.com/hughsie/appstream-glib#guidelines-for-applications for instance programs that identify themselves as "settings" or apps that haven't had an upstream release in 5 years
don't get me wrong but "haven't had an upstream release in 5 years" is a silly reasoning - if an application works and has the feature set it was intended to provide upstream needs to open the changelog type there "to make some distribution clown happy", raise the version number and the maintainer in the distribution too has useless work?
You may disagree and say so, but calling anyone a clown is not going to make your argument stronger, quite the contrary in fact. Please do not resolve to personal attack on this list.
Pierre
Am 02.10.2014 um 16:50 schrieb Pierre-Yves Chibon:
On Thu, Oct 02, 2014 at 04:47:08PM +0200, Reindl Harald wrote:
Am 02.10.2014 um 16:32 schrieb Richard Hughes:
On 2 October 2014 15:17, Tim Lauridsen tim.lauridsen@gmail.com wrote:
I think that is a bad idea to exclude applications from a Software manager, because they don't live up to some visual quality guidelines.
There's actually a whole load of reasons why we'd blacklist applications: https://github.com/hughsie/appstream-glib#guidelines-for-applications for instance programs that identify themselves as "settings" or apps that haven't had an upstream release in 5 years
don't get me wrong but "haven't had an upstream release in 5 years" is a silly reasoning - if an application works and has the feature set it was intended to provide upstream needs to open the changelog type there "to make some distribution clown happy", raise the version number and the maintainer in the distribution too has useless work?
You may disagree and say so, but calling anyone a clown is not going to make your argument stronger, quite the contrary in fact. Please do not resolve to personal attack on this list
you misunderstood me
*that* would be the exact message i would write in the log a upstream maintainer if someone tells me my application which works just fine needs a update because it otherwise is not displayed
Hi
On Thu, Oct 2, 2014 at 11:01 AM, Reindl Harald wrote:
you misunderstood me
I don't think anyone misunderstood that you have trouble disagreeing without also being insulting. You are pushing off people who might otherwise be sympathetic to your perspective by constantly engaging in a discussion the way you do it. Please stop.
*that* would be the exact message i would write in the log a upstream maintainer if someone tells me my application which works just fine needs a update because it otherwise is not displayed
Good thing that noone has asked for that. Please read the link
Rahul
Am 02.10.2014 um 17:34 schrieb Rahul Sundaram:
On Thu, Oct 2, 2014 at 11:01 AM, Reindl Harald wrote:
you misunderstood me
I don't think anyone misunderstood that you have trouble disagreeing without also being insulting
my god i brought an cynical example what upstream may write in the changelog and i doubt that you people are that hypersensitive about every single word in real life too
You are pushing off people who might otherwise be sympathetic to your perspective by constantly engaging in a discussion the way you do it. Please stop.
*that* would be the exact message i would write in the log a upstream maintainer if someone tells me my application which works just fine needs a update because it otherwise is not displayed
Good thing that noone has asked for that. Please read the link
if nobody asked for that then Richard better had just only posted that link and not written it word by word so people don't care at all for a grpical installer would have ignored it
"or apps that haven't had an upstream release in 5 years" is part of the mail i responded to *word by word* - no idea where that leaves space for interpretation independent how often quotes are stripped to lose context
-------- Weitergeleitete Nachricht -------- Betreff: Re: Proposal: Increasing application icon sizes to 64px Datum: Thu, 2 Oct 2014 15:32:02 +0100 Von: Richard Hughes hughsient@gmail.com Antwort an: Development discussions related to Fedora devel@lists.fedoraproject.org An: Development discussions related to Fedora devel@lists.fedoraproject.org
On 2 October 2014 15:17, Tim Lauridsen tim.lauridsen@gmail.com wrote:
I think that is a bad idea to exclude applications from a Software manager, because they don't live up to some visual quality guidelines.
There's actually a whole load of reasons why we'd blacklist applications: https://github.com/hughsie/appstream-glib#guidelines-for-applications for instance programs that identify themselves as "settings" or apps that haven't had an upstream release in 5 years
Hi
On Thu, Oct 2, 2014 at 11:44 AM, Reindl Harald wrote:
i doubt that you people are that hypersensitive about every single word in real life too
People wouldn't say this if it was the first time you wrote something like this. Also since you asked, I am usually *far* more curt generally to people in real life because I know them better but I go out of my way to avoid doing that here precisely because online communication is already devoid of lot of things including body language without adding random insults into the mix.
"or apps that haven't had an upstream release in 5 years"
is part of the mail i responded to *word by word* - no idea where that leaves space for interpretation independent how often quotes are stripped to lose context
You would know the context better if you had read the link that was right next to those words.
Rahul
Am 02.10.2014 um 18:04 schrieb Rahul Sundaram:
On Thu, Oct 2, 2014 at 11:44 AM, Reindl Harald wrote:
i doubt that you people are that hypersensitive about every single word in real life too
People wouldn't say this if it was the first time you wrote something like this
which would be in fact more a reason to start realize that people are different in how they express things and not all is that insulting meant as it could be taken
"or apps that haven't had an upstream release in 5 years" is part of the mail i responded to *word by word* - no idea where that leaves space for interpretation independent how often quotes are stripped to lose context
You would know the context better if you had read the link that was right next to those words
it's a useless dicussion, it it is not that way than it should not be written that way and only the link placed to avoid confusion
so what - mistakes und misunderstanding happen on all sides - that's life
Hi
On Thu, Oct 2, 2014 at 12:14 PM, Reindl Harald wrote:
which would be in fact more a reason to start realize that people are different in how they express things and not all is that insulting meant as it could be taken
https://fedoraproject.org/code-of-conduct
Please read the above link carefully and understand that this is a public forum with certain expectations on how you express yourself. Using words such as "clown" and "idiot" on a regular basis is insulting. You can try to shift the responsibility to others but the end result is you will be moderated again and have trouble providing the feedback or worse yet ignored entirely.
Rahul
On Thu, Oct 02, 2014 at 11:34:18AM -0400, Rahul Sundaram wrote:
I don't think anyone misunderstood that you have trouble disagreeing without also being insulting. You are pushing off people who might otherwise be sympathetic to your perspective by constantly engaging in a discussion the way you do it. Please stop.
Rahul, I read Harald's statement in the way he says it was intended here too, but, Harald, I can see how it could easily be misinterpreted. Please, everyone, be extra aware that when we're communicating in e-mail, tone, jokes, sarcasm, and hyperbole misfire more often than not. (And, as we've seen, tend to escalate into a horrible mess.)
On 2 October 2014 15:47, Reindl Harald h.reindl@thelounge.net wrote:
to make some distribution clown happy
If you read the link, if you ship an AppData file the 5 year rule doesn't kick in. That's something useful that the packager *can* do to the otherwise perfect desktop application.
Richard