9:41 a.m.
XPM is an old standard for icons used by a very small number of
desktop packages in Fedora. The XPM icons are normally small, mostly 8
bit, and usually without an alpha channel and look very bad in the
software center.
I'm going to propose for F21 that we drop support for XPM in the
metadata extractor and only show apps with GIF, PNG and SVG icons. The
list of affected GUI applications is here:
TeXmacs
cycle
flamerobin
gnurobots
linsmith
mup
pari-gp
pgadmin3
qtel
qucs
xsensors
As usual, I'd like to push packagers to get upstream to ship a more
modern (and high resolution, *with* alpha channel) icon in PNG or SVG
format, but packagers can also just replace the icon referenced in the
.desktop file if upstream is unwilling / dead and a good replacement
is available.
Comments welcome,
Richard
12:51 p.m.
Not showing app, because they have bad looking icons, seems like a bad idea
to me.
what about using some cairo magic to merge the .xpm icon with some other
.png frame to make it look better
http://stackoverflow.com/questions/10983739/how-to-composite-multiple-png...
cairo should be able to load XPM, as far as I know
Or just show some standard icon base on the app category
Tim
On Thu, Mar 6, 2014 at 4:41 PM, Richard Hughes <hughsient(a)gmail.com> wrote:
XPM is an old standard for icons used by a very small number of
desktop packages in Fedora. The XPM icons are normally small, mostly 8
bit, and usually without an alpha channel and look very bad in the
software center.
I'm going to propose for F21 that we drop support for XPM in the
metadata extractor and only show apps with GIF, PNG and SVG icons. The
list of affected GUI applications is here:
TeXmacs
cycle
flamerobin
gnurobots
linsmith
mup
pari-gp
pgadmin3
qtel
qucs
xsensors
As usual, I'd like to push packagers to get upstream to ship a more
modern (and high resolution, *with* alpha channel) icon in PNG or SVG
format, but packagers can also just replace the icon referenced in the
.desktop file if upstream is unwilling / dead and a good replacement
is available.
Comments welcome,
Richard
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
11:50 p.m.
Apps with ugly icons and ugly design results in bad user experience
IMO. They should not be displayed in the software center. If devs want
an icon, there are lots of icon designers out there who can contribute
one. You just need to ask.
On 7 March 2014 00:21, Tim Lauridsen <tim.lauridsen(a)gmail.com> wrote:
Not showing app, because they have bad looking icons, seems like a
bad idea
to me.
what about using some cairo magic to merge the .xpm icon with some other
.png frame to make it look better
http://stackoverflow.com/questions/10983739/how-to-composite-multiple-png...
cairo should be able to load XPM, as far as I know
Or just show some standard icon base on the app category
Tim
On Thu, Mar 6, 2014 at 4:41 PM, Richard Hughes <hughsient(a)gmail.com> wrote:
>
> XPM is an old standard for icons used by a very small number of
> desktop packages in Fedora. The XPM icons are normally small, mostly 8
> bit, and usually without an alpha channel and look very bad in the
> software center.
>
> I'm going to propose for F21 that we drop support for XPM in the
> metadata extractor and only show apps with GIF, PNG and SVG icons. The
> list of affected GUI applications is here:
>
> TeXmacs
> cycle
> flamerobin
> gnurobots
> linsmith
> mup
> pari-gp
> pgadmin3
> qtel
> qucs
> xsensors
>
> As usual, I'd like to push packagers to get upstream to ship a more
> modern (and high resolution, *with* alpha channel) icon in PNG or SVG
> format, but packagers can also just replace the icon referenced in the
> .desktop file if upstream is unwilling / dead and a good replacement
> is available.
>
> Comments welcome,
>
> Richard
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Satyajit Sahoo
Profile - Facebook, Google+
Artwork - DeviantArt
5:57 a.m.
On Fri, Mar 7, 2014 at 6:50 AM, Satyajit Sahoo <satyajit.happy(a)gmail.com>wrote:
Apps with ugly icons and ugly design results in bad user experience
IMO. They should not be displayed in the software center
The quaility of an application has nothing todo, with at fancy icon, not
showning the icon is ok, but don't show the application is not IMO
what will be the next ? qt apps ? gtk2 apps
I agree with Richard that it would be very bad to set the bar to high, no
user want a software center there only shows 5% of the available apps
no matter, how slick it looks
Tim
6:13 a.m.
New subject: Proposal: Don't show applications in the software center with XPM icons
Am 07.03.2014 12:57, schrieb Tim Lauridsen:
On Fri, Mar 7, 2014 at 6:50 AM, Satyajit Sahoo
<satyajit.happy(a)gmail.com <mailto:satyajit.happy@gmail.com>> wrote:
Apps with ugly icons and ugly design results in bad user experience
IMO. They should not be displayed in the software center
The quaility of an application has nothing todo, with at fancy icon, not showning the
icon is ok, but don't show the application is not IMO what will be the next?
qt apps? gtk2 apps
+1000
this new age "function follows form" is ridiculous, some people seems really
to prefer a horrible buggy but shiny application to a perfect working one
6:19 a.m.
New subject: Proposal: Don't show applications in the software center with XPM icons
Am 07.03.2014 13:15, schrieb Richard Hughes:
On 7 March 2014 11:57, Tim Lauridsen <tim.lauridsen(a)gmail.com>
wrote:
> what will be the next ? qt apps ? gtk2 apps
No, because that would be ridiculous. Hiding applications using GTK1
would of course be okay
says who?
as long GTK1 is not forbidden in Fedora there is no valid
reason for that statement - you may prefer not having a
function at all if it is not beautiful enough for you
*but*
* beautiful is in the eye of the beholder
* you should hestitate make such proposals based on your eyes
8:08 a.m.
New subject: Proposal: Don't show applications in the software center with XPM icons
On Fri, 2014-03-07 at 13:19 +0100, Reindl Harald wrote:
says who?
as long GTK1 is not forbidden in Fedora there is no valid
reason for that statement - you may prefer not having a
function at all if it is not beautiful enough for you
*but*
* beautiful is in the eye of the beholder
* you should hestitate make such proposals based on your eyes
Microsoft, Apple, and Google set requirements that apps must follow if
they want to appear in the software center in order to ensure a good
user experience. I absolutely think we need to do the same to be
competitive. Ancient icons are a good heuristic that the app is
unmaintained and not something the user really wants to install.
8:12 a.m.
New subject: Proposal: Don't show applications in the software center with XPM icons
Am 07.03.2014 15:08, schrieb Michael Catanzaro:
On Fri, 2014-03-07 at 13:19 +0100, Reindl Harald wrote:
> says who?
>
> as long GTK1 is not forbidden in Fedora there is no valid
> reason for that statement - you may prefer not having a
> function at all if it is not beautiful enough for you
>
> *but*
>
> * beautiful is in the eye of the beholder
> * you should hestitate make such proposals based on your eyes
Microsoft, Apple, and Google set requirements that apps must follow if
they want to appear in the software center in order to ensure a good
user experience. I absolutely think we need to do the same to be
competitive. Ancient icons are a good heuristic that the app is
unmaintained and not something the user really wants to install
if i want it the Apple and Microsoft way i just install Windows
or go out an buy a Mac - i am using Linux because it is *not*
Windows and *not *OSX*
speaking of freedom and freedom of choice and then come with
restrictions here and there is somehow strange
you hardly can call "i do not show an app because i do not like
the icon" a good user expierience - where do you draw the line?
that may end in "there is no app for what i current need to do
and so i can't use that operating system at all" while the app
was there but someone decided to hide it
8:14 a.m.
New subject: Proposal: Don't show applications in the software center with XPM icons
Am 07.03.2014 15:08, schrieb Michael Catanzaro:
Ancient icons are a good heuristic that the app is unmaintained
and not something the user really wants to install
Ancient icons are a good heuristic that a app if it does what i
need the next week or month does not get a complete rewrite
with a total different UI and that i want to use it *because*
of that to prevent my personal workflow changing all the time
by random decisions
10:21 a.m.
On 7 March 2014 14:08, Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
Microsoft, Apple, and Google set requirements that apps must follow
if
they want to appear in the software center in order to ensure a good
user experience.
This is something I absolutely want to do. We already rate the
applications in GNOME 3.12 depending on how many positive attributes
they have (the star ratings) and I think it's fine to set a minimum
standard and slowly raise the bar over time. Showing 500 applications
that hits some absolute minimum level is much better than showing an
additional 500 basically crap applications.
Richard.
1:42 p.m.
On 03/07/2014 11:21 AM, Richard Hughes wrote:
On 7 March 2014 14:08, Michael Catanzaro <mcatanzaro(a)gnome.org>
wrote:
> Microsoft, Apple, and Google set requirements that apps must follow if
> they want to appear in the software center in order to ensure a good
> user experience.
This is something I absolutely want to do. We already rate the
applications in GNOME 3.12 depending on how many positive attributes
they have (the star ratings) and I think it's fine to set a minimum
standard and slowly raise the bar over time. Showing 500 applications
that hits some absolute minimum level is much better than showing an
additional 500 basically crap applications.
This decision should belong to the user, though. It's one thing to
default to showing only five-star applications (GTK2, icon with
transparency, AppData with translations) while allowing the user to
widen the criteria to show more applications. It is quite another thing
to make an unilateral decision to take out an entire class that fails to
satisfy some arbitrary requirement.
I do realize that the app installer becomes more complex, with the
'number of stars' selector, and having to make up application data that
the app itself failed to provide, but I think cost/benefit justifies
that effort.
I feel old and cranky arguing this point but the app markets for
portable devices are a _counterexample_ to a thesis that pretty metadata
guarantees better application quality. At least on portable devices the
old-line stuff simply does not install so it is irrelevant; on Fedora it
can be installed and would be useful to someone, if only they can
discover its existence when using the pretty, default application
installer. As another data point, I just introduced 'units' to another
person that missed it in spite of being in the business of scientific
data/calculations. Fedora should make it easier, not more difficult, for
people to discover such useful things.
2:14 p.m.
Am 07.03.2014 20:42, schrieb Przemek Klosowski:
On 03/07/2014 11:21 AM, Richard Hughes wrote:
> On 7 March 2014 14:08, Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
>> Microsoft, Apple, and Google set requirements that apps must follow if
>> they want to appear in the software center in order to ensure a good
>> user experience.
> This is something I absolutely want to do. We already rate the
> applications in GNOME 3.12 depending on how many positive attributes
> they have (the star ratings) and I think it's fine to set a minimum
> standard and slowly raise the bar over time. Showing 500 applications
> that hits some absolute minimum level is much better than showing an
> additional 500 basically crap applications.
>
This decision should belong to the user, though. It's one thing to default to showing
only five-star applications
(GTK2, icon with transparency, AppData with translations) while allowing the user to
widen the criteria to show
more applications. It is quite another thing to make an unilateral decision to take out
an entire class that fails
to satisfy some arbitrary requirement.
I do realize that the app installer becomes more complex, with the 'number of
stars' selector, and having to make
up application data that the app itself failed to provide, but I think cost/benefit
justifies that effort.
I feel old and cranky arguing this point but the app markets for portable devices are a
_counterexample_ to a
thesis that pretty metadata guarantees better application quality. At least on portable
devices the old-line stuff
simply does not install so it is irrelevant; on Fedora it can be installed and would be
useful to someone, if only
they can discover its existence when using the pretty, default application installer. As
another data point, I just
introduced 'units' to another person that missed it in spite of being in the
business of scientific
data/calculations. Fedora should make it easier, not more difficult, for people to
discover such useful things.
*exactly* my point and even if i do not use any GUI for install/update
packages i care about because others should have the same options as
i had many years ago to find their *alternative* to Windows/OSX
10:56 a.m.
On 7 March 2014 16:21, Richard Hughes <hughsient(a)gmail.com> wrote:
On 7 March 2014 14:08, Michael Catanzaro <mcatanzaro(a)gnome.org>
wrote:
> Microsoft, Apple, and Google set requirements that apps must follow if
> they want to appear in the software center in order to ensure a good
> user experience.
This is something I absolutely want to do.
I've started this process here:
https://github.com/hughsie/createrepo_as#guidelines-for-applications
-- it's work in progress so comments welcome.
Richard
9:55 a.m.
On Fri, 2014-03-07 at 12:57 +0100, Tim Lauridsen wrote:
The quaility of an application has nothing todo, with at fancy icon,
not showning the icon is ok, but don't show the application is not IMO
what will be the next ? qt apps ? gtk2 apps
Consider the option of assuming good faith.
- ajax
5:35 a.m.
On 6 March 2014 18:51, Tim Lauridsen <tim.lauridsen(a)gmail.com> wrote:
Not showing app, because they have bad looking icons, seems like a
bad idea
to me.
I'm not sure anyone will be surprised in my goal of making the
applications we show users have high quality content. XPM icons are a
good first step, then it'll be things like missing icon transparency,
AppData, translated AppData over the next few releases. The
alternative is we set the bar so high that only a dozen or so apps are
visible at first and the software center is useless for most users. I
also hope people are noticing the *hundreds* of upstream bugs I've
opened trying to raise the bar for all applications, rather than just
a "thou shall do X, Y, Z".
I'm working at the moment on a tool that packagers and upstreams can
use to find out issues and recommendations. When it's finished enough
for some feedback I'll post some links.
Richard
8:05 a.m.
2014-03-07 12:35 GMT+01:00 Richard Hughes <hughsient(a)gmail.com>:
I'm not sure anyone will be surprised in my goal of making the
applications we show users have high quality content. XPM icons are a
good first step, then it'll be things like missing icon transparency,
AppData, translated AppData over the next few releases.
I don't think such technological restrictions will achieve your goal.
If you really want "nice" screenshots and well-written descriptions, just
do it and propose a manually-curated application list.[1]
If you want the application packagers and upstreams to be responsible for
the content so that you don't have to, with the associated pride or shame
about the content falling on the individual author of that content, that's
also an option.
AFAICS having the application packagers and upstreams to be responsible for
the content, but still reviewing it and looking for technological
indications that the content is sub-par, and adding code and rules to
enforce technological restrictions, has the disadvantages of both - you are
still doing manual reviews and extra work complicating the software by
adding technological restrictions[2], but you don't actually have the power
to avoid low-quality content.
Mirek
[1] We haven't had a good flamewar this week :)
[2] XPM is an indication of "poor" quality only because there's such a
correlation within the current appdata collection; this correlation may go
away in a month (The technological response to "XPM is no longer supported"
is clearly to take the existing XPM picture and convert it into something
else.)
10:06 a.m.
Richard Hughes (hughsient(a)gmail.com) said:
On 6 March 2014 18:51, Tim Lauridsen <tim.lauridsen(a)gmail.com>
wrote:
> Not showing app, because they have bad looking icons, seems like a bad idea
> to me.
I'm not sure anyone will be surprised in my goal of making the
applications we show users have high quality content. XPM icons are a
good first step, then it'll be things like missing icon transparency,
AppData, translated AppData over the next few releases. The
alternative is we set the bar so high that only a dozen or so apps are
visible at first and the software center is useless for most users. I
also hope people are noticing the *hundreds* of upstream bugs I've
opened trying to raise the bar for all applications, rather than just
a "thou shall do X, Y, Z".
So, perhaps this is just window dressing, but I wonder if this can be
messaged better as "change all XPM icons to nicer formats", "add
translated
AppData for all apps", etc.
It may not make much difference in the end, but it might be read better as
"Here's how we can help make your app more awesome by fixing XYZ" as opposed
to "We're
going to stop showing your app because of XYZ."
And, to be fair, I suspect that's what all these upstream bugs are.
Bill
11:16 a.m.
On 06/03/14 13:51, Tim Lauridsen wrote:
Not showing app, because they have bad looking icons, seems like a
bad
idea to me.
what about using some cairo magic to merge the .xpm icon with some
other .png frame to make it look better
http://stackoverflow.com/questions/10983739/how-to-composite-multiple-png...
cairo should be able to load XPM, as far as I know
Or just show some standard icon base on the app category
Tim
IMHO, the proposal was less of
"let's remove ugly icons"
and more
"lets hide applications that use icons in this particular format that
doesn't support the features of the software application"
It is still possible to have ugly icons, they just have to be in PNG,
GIF or SVG format.
cheers,
ryanlerch
11:53 a.m.
Am 07.03.2014 18:16, schrieb Ryan Lerch:
IMHO, the proposal was less of
"let's remove ugly icons"
and more
"lets hide applications that use icons in this particular format that doesn't
support the features of the software
application"
IMHO you did not read the proposal itself
scroll down - i pasted it again in this message
It is still possible to have ugly icons, they just have to be in PNG,
GIF or SVG format
and that is why "and look very bad" defined by the format is flawed
-------- Original-Nachricht --------
Betreff: Proposal: Don't show applications in the software center with XPM icons
Datum: Thu, 6 Mar 2014 15:41:00 +0000
Von: Richard Hughes <hughsient(a)gmail.com>
An: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>
XPM is an old standard for icons used by a very small number of
desktop packages in Fedora. The XPM icons are normally small, mostly 8
bit, and usually without an alpha channel and look very bad in the
software center.
I'm going to propose for F21 that we drop support for XPM in the
metadata extractor and only show apps with GIF, PNG and SVG icons. The
list of affected GUI applications is here:
TeXmacs
cycle
flamerobin
gnurobots
linsmith
mup
pari-gp
pgadmin3
qtel
qucs
xsensors
As usual, I'd like to push packagers to get upstream to ship a more
modern (and high resolution, *with* alpha channel) icon in PNG or SVG
format, but packagers can also just replace the icon referenced in the
.desktop file if upstream is unwilling / dead and a good replacement
is available.
Comments welcome,
1:34 p.m.
On Fri, Mar 7, 2014 at 12:53 PM, Reindl Harald <h.reindl(a)thelounge.net>wrote:
Am 07.03.2014 18:16, schrieb Ryan Lerch:
> IMHO, the proposal was less of
>
> "let's remove ugly icons"
>
> and more
>
> "lets hide applications that use icons in this particular format that
doesn't support the features of the software
> application"
IMHO you did not read the proposal itself
scroll down - i pasted it again in this message
IMHO Ryan is exactly correct - and you're coming off as a bit
condescending. The proposal is about a particular image format which
doesn't scale well to the size we need in the software center and doesn't
have an alpha channel. It's not a judgement on the design of the icon.
> It is still possible to have ugly icons, they just have to be in PNG,
GIF or SVG format
and that is why "and look very bad" defined by the format is flawed
if you take a small bitmap and scale it up it will look bad, no matter how
well it's designed otherwise. That's just a limitation of the format, and
saying so is not flawed.
-------- Original-Nachricht --------
Betreff: Proposal: Don't show applications in the software center with XPM
icons
Datum: Thu, 6 Mar 2014 15:41:00 +0000
Von: Richard Hughes <hughsient(a)gmail.com>
An: Development discussions related to Fedora <
devel(a)lists.fedoraproject.org>
XPM is an old standard for icons used by a very small number of
desktop packages in Fedora. The XPM icons are normally small, mostly 8
bit, and usually without an alpha channel and look very bad in the
software center.
I'm going to propose for F21 that we drop support for XPM in the
metadata extractor and only show apps with GIF, PNG and SVG icons. The
list of affected GUI applications is here:
TeXmacs
cycle
flamerobin
gnurobots
linsmith
mup
pari-gp
pgadmin3
qtel
qucs
xsensors
As usual, I'd like to push packagers to get upstream to ship a more
modern (and high resolution, *with* alpha channel) icon in PNG or SVG
format, but packagers can also just replace the icon referenced in the
.desktop file if upstream is unwilling / dead and a good replacement
is available.
Comments welcome,
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
5:42 a.m.
On 2014-03-06, Richard Hughes <hughsient(a)gmail.com> wrote:
XPM is an old standard for icons used by a very small number of
desktop packages in Fedora. The XPM icons are normally small, mostly 8
bit, and usually without an alpha channel and look very bad in the
software center.
I'm going to propose for F21 that we drop support for XPM in the
metadata extractor and only show apps with GIF, PNG and SVG icons. The
list of affected GUI applications is here:
GIF is an old standard for icons used by a very small number of
desktop packages in Fedora. The GIF icons are normally small, mostly 8
bit, and usually without an alpha channel and look very bad in the
software center.
-- Petr
6:07 p.m.
On Thu, 2014-03-06 at 15:41 +0000, Richard Hughes wrote:
XPM is an old standard for icons used by a very small number of
desktop packages in Fedora. The XPM icons are normally small, mostly 8
bit, and usually without an alpha channel and look very bad in the
software center.
I'm going to propose for F21 that we drop support for XPM in the
metadata extractor and only show apps with GIF, PNG and SVG icons. The
list of affected GUI applications is here:
TeXmacs
cycle
flamerobin
gnurobots
linsmith
mup
pari-gp
pgadmin3
qtel
qucs
xsensors
As usual, I'd like to push packagers to get upstream to ship a more
modern (and high resolution, *with* alpha channel) icon in PNG or SVG
format, but packagers can also just replace the icon referenced in the
.desktop file if upstream is unwilling / dead and a good replacement
is available.
Comments welcome,
Richard
-1
I vote against
reading http://en.wikipedia.org/wiki/XPM_%28image_format%29
your arguments about transparent pixels is wrong, and XPM is more
flexible than the others one.
- i do not want to break with the unix tradition of supporting legacy
applications
- are xpm icons still allow in default icon directories
- what will be the beahavior if included
- i do not agree with the pejorative used of old standard
- xpm is still the only way to include raster images in "C" programs
example #include "xicon64" directives
- is the proposition include commenting xlib library manuals for fedora
particular used of icons.
- xbitmap is the only mechanism to specify 15 bits display screen,
or dispaly with depth different from 8,16,24
- xbitmap can be 32 bits deep
- xbitmap may have alpha channels specified has masks
- xbitmap allow compositing more complex icons
and obviously bitmap is also implied, since they are XPM of depth one
12:06 a.m.
Gilles J. Seguin wrote:
-1
I vote against
reading http://en.wikipedia.org/wiki/XPM_%28image_format%29
your arguments about transparent pixels is wrong, and XPM is more
flexible than the others one.
Me too.
- i do not want to break with the unix tradition of supporting
legacy
applications
- are xpm icons still allow in default icon directories
- what will be the beahavior if included
- i do not agree with the pejorative used of old standard
- xpm is still the only way to include raster images in "C" programs
example #include "xicon64" directives
- is the proposition include commenting xlib library manuals for fedora
particular used of icons.
- xbitmap is the only mechanism to specify 15 bits display screen,
or dispaly with depth different from 8,16,24
- xbitmap can be 32 bits deep
- xbitmap may have alpha channels specified has masks
- xbitmap allow compositing more complex icons
and obviously bitmap is also implied, since they are XPM of depth one
Good points there.
In addition, I don't think it is the software center's job to arbitrarily
restrict allowed icon types beyond what freedesktop.org specifies.
Kevin Kofler
3718
days inactive
3728
days old
24 comments
14 participants
participants (14)
-
Adam Jackson -
Bill Nottingham -
Emily Dirsh -
Gilles J. Seguin -
Kevin Kofler -
Michael Catanzaro -
Miloslav Trmač -
Petr Pisar -
Przemek Klosowski -
Reindl Harald -
Richard Hughes -
Ryan Lerch -
Satyajit Sahoo -
Tim Lauridsen