[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: .desktop files need better categories

On Wed, Jul 24, 2002 at 11:01:16AM +0200, Claes Holmerson wrote:
> > > Consider the simple case that you want to mandate that one of the keywords
> > > KDE, QT, GNOME, GTK, Motif etc should aways be present in a .desktop file.
> >
> > We don't mandate because we need to read older desktop files.  Plus then what
> > about if a new toolkit comes around.  You can't add an 'Other' category for
> > just this reason.
> If a new toolkit comes around it should be added to the list.  And if it
> is not available, it could be left out of the .desktop file. However,

Yes it should be

> there is no difference in principle between our two suggestions in this
> case, although I think it is easier to find the relevant keywords in many
> smaller lists than in one huge one.

So then it's jsut a matter of how the structure of the standards document is
done.  We can divide the list into several different ones grouped by their

> > We can't mandate because we need to read old .desktops as well.  And if we
> > could mandate there is no difference between adding Toolkit-Category and
> > Category, all you are doing is making it less likely people will actually do
> > it and less likely people will implement the readers correctly.
> Hmm I am not sure about this.
> However, you seem to have thought much about backward compatibility in
> your spec. This is good, and something I have not considered
> really as I am not sure what demands old .desktops put on a new spec.

Backwards compatibility is essential, as is being able to deal with people
not following the spec 100% as that WILL happen no matter how you look at it.
There will be people that won't follow the spec almost at all since they'll
never read it.  We need to be able to somehow deal with this as well.  The
user should not be punished by not seeing an icon, but the developper should
be punished by getting annoying emails from people that go around checking
for conformity to standards.

> > > Without knowing what octave is (I don't) I can't tell if this program is
> > > for teaching purposes or for making calculations, what audience it targets
> > > (students or scientists) and how complex it is, for example. Well, I can
> > > perhaps guess that it targets scientists rather than students, but only
> > > because the Education keyword is missing, on the other hand, Scientific
> > > does not even exist in the current spec, so it is hard to tell exactly
> >
> > Sorry I added Scientific in my own copy that I haven't posted yet (I was
> > waiting for more suggestions, but I suppose I will post it as it is)
> This is ok, just shows that a list like this has to be constantly
> maintained and updated.

Yes, although I think we will get to some point where adding new keywords
will be a rarity.  I think we now have a good general list of keywords such
that additions will not be required so often.

> I think this problem is not as big as you make it here. If keywords are
> well defined with good descriptions that is. If a program belongs to
> several categories it should use several keywords. The maintainer of the
> specific has to make a careful choice, but if the spec is clear and
> consise, this should work out ok.

Yes, so your suggestion is to perhaps organize the list of keywords in the
spec better and add better descriptions of each keyword?  I agree this would
be good.

> But notice the difference. Audience describes a certain target user, while
> domain describes in what the field the program is useful (works on math).
> They describe different things.
> Examples of audience could be consumer, student, developer, artist,
> scientist etc
> while domain could be math, music, economy, physics.
> audience=artist and domain=music would be a program that is used
> to create music with (used by a creative artist) while audience=consumer
> and domain=musice would be a program to enjoy and listen to music.

But note that you can do this with both approaches, imagine we had two
keywords 'ArtistOriented AND Music' then it would be the same as looking for
something 'audience=artist' and 'domain=music'.  However in the end I don't
think we should really cut up the audience too much, if at all.  The problem
is that this is very subjective.

In any case if a project like debian wants to do different vfolders that are
also based on audience they can add X-Debian-ArtistOriented to their
packages.  And use that.  Then they would require debian packages to include
such keywords in the .desktops.  Other systems that would use the same
.desktops would just not notice as they would not query for this keyword,
but would find the .desktop using it's other keywords.

> This is different from describing a program as Scientific and Math, since
> math is a field of science. But perhaps I am missing the point here?
> Scientific is an adjective while Math is a noun, so is there some
> hidden meaning that is unexplained in your list? Does Scientific describe
> audience or domain? If yes, then it should be explained. If not, there are
> inconsistenices in your list, and that is one reason why I think it could
> be improved.

No, the idea is that perhaps you don't want to have a LOT of categories, you
have only a few scientific apps installed, you do a query on 'Scientific' and
you get ALL the scientific oriented math, physics, astronomy, or whatever
apps in one directory.  Or you could cut it up further if you needed (such as
if you have too many of them installed).  You could also query for all those
keywords with an OR to get all say Math apps that don't really qualify as
Scientific as well.

> > > Having both a simple calculator and Matlab showing up in the same menu is
> > > not very user friendly for a novice user (although great for the
> >
> > Why would it be not very user friendly?
> There is no point in showing Matlab in a menu for a user that would never
> use it, like my mom. It would only confuse her, making it harder for her
> to focus on what is usable to her. There is value in reducing choice.

Yes of course, So you can still do that.  Gcalc would not really qualify as
'Scientific' I don't think, so for your directory do a query like

NOT Scientific AND Math

Or some such.

> Don't you think there should be a way to reduce the set of editors shown
> in a menu, so that vi does not show up for beginners? I would like the
> metadata in the .desktop files help with this.

There was some discussion about adding keywords for 'user levels' we just
need to get consensus.  And these need good descriptions.  Then you could do
a beginner menu with:

Math AND NOT Intermediate AND NOT Advanced

It is then up to the query.

Another option would be to first assume that all apps are 'Easy', so we would
only have Intermediate and Advanced keywords.  If an author doesn't specify
the level it would be more prudent to SHOW the icon rather then not (this
could be a third party app where they just didn't read the spec)

> > But you also make things more complex and much less likely that you will
> > actually get useful information.  The standard should be so easy it is easily
> > followable.  Note that people DO NOT read standards (as I have found out by
> > some people who flamed me about the vfolder spec).  They read a few
> > paragraphs maybe, they will read easy to follow directions or use a GUI.  A
> > complicated system would be great if everyone learned it and used it
> > correctly, but they won't.
> Yes they become a little more complex for the developer creating the
> .desktop files in order to create less complexity for the end user. I
> think the developer should be able to deal with this.

SHOULD be able to deal with it and WILL deal with it are two different things
entierly.  Just because you think it's not hard, or even if it in fact isn't
hard to follow, it must be a standard that is somewhat more tolerant of
people not following it, because people WONT follow it completely.  The more
complex it is, the less people will follow it, because less people will ever
bother to read it.  I would say that the vast majority of people creating
.desktop files have never read the .desktop file standard.  This is by
reading .desktop files that come with many packages, even new ones.  However
the .desktop file standard is fairly tolerant of people not really following
it too well.  Also it is not hard to understand how this works by looking at
other .desktop files.  If you get complex enough that this will not be
possible, we'll get a flood of completely unusable .desktop files.

> Last, even though we disagree on how to define metadata, I want to thank
> you for the work that you put into the spec. Implemented, it will greatly
> improve integration of the desktop and ease the problem of finding out
> what applications are available. But it can be improved, of course :-)


Note that there is already an implementation in GNOME2 and RedHat has already
chosen to use this for their menus apparently.  Of course it's not really
widely deployed yet and that will take a year or two if people start
implementing it everywhere.


George <jirka 5z com>
   When they kick at your front door, how're you gonna come?
   With your hands on your head or on the trigger of your gun?
                                         -- The Clash

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]