Re: adding desktop files to misc packages

[Bill Allombert]

On Mon, Jul 16, 2007 at 12:40:28PM +0200, Raphael Hertzog wrote:
> Bill, you haven't participated in this discussion, what's your opinion?
> Would you like to do that work?

I stated my opinion an hundred time already, here a quick summary:

1) There is a place for two menu structure in Debian: an omnibus one
(Debian menu) and a Desktop-oriented one (XDG menu) where only 
desktop relevant apps would be mentioned.

2) The XDG menu entries suffers from lack of clear policy about what
software should go in the menu and in which categories.
For example should asciijump provide a .desktop file ? xdvi ? gv ?
lilo ? etc.

3) The XDG menu entries suffers from general lack on maintainance.  A
lot of upstream-provided ".desktop" files outside native KDE/GNOME
packages are wrong, and never fixed. At the very least compliance with
the standard should be checked. 

4) Bugs with Debian menu under GNOME were actually bugs in the XDG menu
implementation in GNOME. The KDE implementation was much better. Blaming
Debian menu for them is unfair. 

5) There are dozen of ways to not display the Debian menu under GNOME.
What is lacking is an easy interface beside "do not install menu".
Maybe the d-i team could propose an interface and I will see how it
can be implemented.

> Would it be helpful to have the technical committee decide on this
> topic?

It would not. Instead please write a policy about what softwares
are worthy to appear in the XDG menu and get it accepted by the
debian-desktop participants, and start to report bugs.

I am not interested in maintaining the XDG menu myself. I do not use 
desktop environment. I am interested to maintain Debian menu, however.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Bill Allombert]

On Mon, Jul 16, 2007 at 08:07:05PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Mon, Jul 16, 2007 at 04:12:02AM -0700, Don Armstrong wrote:
> > So it seems like we should do the following:
> (...)
> 
> 4. Add i18n support to menu so that it can generate localised menu names,
>entries and tooltips both when converting desktop -> menu (for WM !=
>KDE/GNOME/Xfce) and when converting menu -> desktop (for WM ==
>KDE/GNOME/Xfce). As WM might not have i18n support for their menu, this
>should be based on the system's /etc/default/locale setting when
>converting from desktop -> menu to select a single text string there.

As hinted in my d-d-a post, lenny menu will provide full translations
of the menu under the condition that the translatable strings (title
and longtitle) reach an acceptable quality level. We are working on
it.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le samedi 28 juillet 2007 à 04:36 -0500, Manoj Srivastava a écrit :
> So, if you want to keep you menu small and non-comprehensive,
>  you should not be pushing for f.d.o formatting. :)

But I am not pushing it. I am trying to prevent the mess that will be if
that actually happens.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le jeudi 26 juillet 2007 08:25 +0200, Frank Küster a écrit :
>
>> Could you give guidelines how a maintainer of an application should
>> classify their app,
>
> Using categories described in [0] is a good start. The maintainers would
> also have to agree on new categories if the ones listed are not
> sufficient.

To me, these categories look very poor, I really wouldn't want the
well-structured debian menu (note that I'm talking about the new Debian
menu, not the default menu for etch) to be replaced by anything like
this.  To me, it rather looks like it doesn't make sense to add
additional ones, given that we already have something much better.

Moreover, this doesn't answer my question at all, but I was probably
unclear.  What I meant was "How (do you think) should a maintainer
decide whether a particular application is marked as "not for Gnome", or
"not for desktop environments", or such.  I wanted something more
general than "Python should be hidden", "switching windowmanagers should
be hidden", because it's hard to discuss whether this hiding thing makes
sense when I have no idea what you think should be hidden, except some
special examples.

> On the
> contrary, NotShowIn should be used if similar functionality is available
> in one or several environments and displaying an icon would only be a
> source of confusion.

Okay, that makes sense - a frontend to setxkbmap shouldn't have a menu
entry when there's a specific tool for customizing the keyboard for the
desktop environement.

That's the type of general guideline I'd like to see, but this
particular one won't catch many applications.

> For applications that aren't useful in the general case, NoDisplay=3Dtrue
> should be set. Let me show an example: gstreamer-properties used to have
> an icon in the menu. In current releases, the appropriate sinks to use
> (esd, alsa, etc.) are autodetected which means there is no *need* for
> users to launch it, and this allowed us to set NoDisplay=3Dtrue. The same
> should hold for configuration dialogs that are specific to an
> application and already available from it.

That also makes sense, but here I would argue that those shouldn't have
a menu entry at all.

>> and how Gnome would decide which classes to hide?
>
> ConsoleOnly, Shell, Screensaver, X-WindowManager are good candidates. We
> could also exclude things like FileManager as nautilus is always
> launched, for example.=20

ACK

> Sound judgement should do the rest.

I'm sceptical about that.  Up to this discussion I didn't even have an
idea that people might want to hide things from the menu, and I still
don't feel I understand exactly what and why you want to hide.  But it's
going to be the package maintainers like me who assign these classes, so
we'd better give them some guidelines.


One guideline could be "if there's an application for doing $foo that's
provided by the desktop environment, only show this one".  Maybe that is
what you applied when you suggested to not display other file managers
besides Nautilus.

However, I don't think this is a good rule in general: If both
$gnome_wordprocessor and openoffice.org-writer are installed, I'm sure
it would confuse users if there was no menu entry for
openoffice.org-writer.  Or, nearer to my own packaging work, if someone
starts to learn LaTeX, and all they find in the menu to look at DVI
files is evince or kdvi or similar, while everyone in the LaTeX
community only talks about xdvi (and for a reason).

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Andreas Tille <[EMAIL PROTECTED]> wrote:

> I really wonder whether this concept of user roles are really that strange
> or stupid that all posters seem to ignore this idea.  (Feel free to teach
> me in private to keep silent with those stupid ideas.)

Personally, I think it's probably a very good idea.  Maybe I'd even like
to switch between different types of users (oh, ideally even different
users in different workspaces at the same time).

I imagine that the reason why no one responds to this suggestion is that
the discussion is very focused:  The friends of the complete Debian menu
on the one hand, and the advocates of a "newbie friendly" desktop
environment - and those newbies (I think) are generally believed to use
their computer for "home office" work, from writing a letter and web
browsing to listening to music and managing their photos.

But in fact, I think a user can both be a newbie to Linux (and even to
serious computer usage) and still have a quite focused interest, be it
"administration of a non-profit organization", a particular field of
science, game development, ...

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le vendredi 27 juillet 2007 03:52 -0700, Steve Langasek a écrit :
>> > In the end, the people who know whether an application should be given
>> > tags that will exclude it from certain menus are the application's
>> > maintainers, not the menu systems maintainers. So far they have been
>> > reasonable about what is included in the menu, and I have no reason to
>> > think this wouldn't remain like that.
>>
>> In that case, I guess I'm confused, because I had the impression that you
>> were still opposed to migrating the existing Debian menu to use the
>> freedesktop standard.
>
> Sorry, that wasn't clear: people are currently reasonable with what they
> include in the *freedesktop* menu.

Do you mean the menu as shown by desktop environments like gnome, or the
menu as specified by the set of .desktop files?

> I'm not fond of the idea of
> converting the Debian menu entries because it will lead to including all
> that's currently in the *Debian* menu, which is not reasonable.

I still don't understand what you want:  Is it particular categories
that you want to hide, or is it the sheer number of applications, and
the fact that there are going to be multiple applications for
(approximately) the same task, that bothers you?

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le vendredi 27 juillet 2007 à 03:52 -0700, Steve Langasek a écrit :
>> > In the end, the people who know whether an application should be given
>> > tags that will exclude it from certain menus are the application's
>> > maintainers, not the menu systems maintainers. So far they have been
>> > reasonable about what is included in the menu, and I have no reason to
>> > think this wouldn't remain like that.
>> 
>> In that case, I guess I'm confused, because I had the impression that you
>> were still opposed to migrating the existing Debian menu to use the
>> freedesktop standard.
>
> Sorry, that wasn't clear: people are currently reasonable with what they
> include in the *freedesktop* menu. 

Do you mean the menu as shown by desktop environments like gnome, or the
menu as specified by the set of .desktop files?  

> I'm not fond of the idea of
> converting the Debian menu entries because it will lead to including all
> that's currently in the *Debian* menu, which is not reasonable.

I still don't understand what you want:  Is it particular categories
that you want to hide, or is it the sheer number of applications, and
the fact that there are going to be multiple applications for
(approximately) the same task, that bothers you?

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Ben Hutchings]

On Sat, 2007-07-28 at 04:47 -0500, Manoj Srivastava wrote:
> On Wed, 25 Jul 2007 19:22:11 +0200, Frank Küster <[EMAIL PROTECTED]> said: 
> 
> > Josselin Mouette <[EMAIL PROTECTED]> wrote:
> >> As long as it is not shown, it doesn't matter, so I guess we can
> >> agree on this matter.
> 
> > No, not at all.  I have not yet seen a convincing argument for hiding
> > menu entries.  The only ones were "less is more", which is to vague to
> > get one much further, and "we need to hide stuff like python", which
> > is plain wrong IMHO because I think python shouldn't have a menu entry
> > at all.
> 
> Actually, microsoft (which seems to be what GNOME folk are
>  trying ever so  hard to emulate) came up with a decent solution -- they
>  added shaded areas to menus to indicate that something is hidden from
>  the user, and the user can just hover over the are to open up the
>  hidden entries.


That's actually terrible for usability.  First, any UI feature that
involves hovering is hostile both to novices, because it's effectively
hidden, and to experienced users, because they know where they're going
and don't want to wait.  Second, users cannot learn where menu entries
are if they keep moving around.

Windows XP and later versions don't hide anything in the Programs
sub-menu but they try to duplicate the most commonly used programs
directly on the Start menu, with the option of explicitly "pinning" them
in place.  This works pretty well, though there are some difficulties in
working out which are most commonly used (see the series of articles
beginning with
).

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily Tomlin


signature.asc
Description: This is a digitally signed message part

Re: adding desktop files to misc packages

[Eduard Bloch]

#include 
* Florent Rougon [Thu, Jul 26 2007, 02:55:16PM]:
> Mike Hommey <[EMAIL PROTECTED]> wrote:
> 
> >> >> Witness:
> >> >>   - usable completion in the File Open dialog   -> gone
> 
> [...]
> 
> > Note that AFAIK, completion never disappeared from the file open dialogs.
> > You just have to enable it with a keystroke.
> 
> I know that; the shortcut is Ctrl-L. But I wrote "usable completion"
> because even after hitting Ctrl-L, the kind of completion you get is
> *much* less efficient than that you got for free in the good old days of
> GTK+ 1.2. IOW, there is no usable completion in GNOME's current File
> Open/Save dialogs (neither in Qt, for that matter :-/).
> 
> > Even if not, it is a problem with gimp if it refuses to set menu shortcuts
> > if you change gtk-can-change-accels in your config.
> 
> OK, it's not GNOME. But I had the impression that the original feature,
> which was accessible out-of-the-box, was removed/made inaccessible
> *because* of GNOME's concerns about "usability". That is why I brought
> this point here.

This my impression as well, the idioticy of the current file-open dialog
behaviour perfectly matches the GNOME "development". And the performance
is still flawed, the dialog (here: Iceweasel) keeps reading data of each
and every file when doing completion. For what? It has never to display
the type and icon, I wanna enter this filename manually.

I wonder what the people are smoking anyway. Few years ago, performance
of kfm in KDE 1.x sucked because it tried to read every file. Looks like
GNOME people urge to repeat their mistakes.

Eduard.
-- 
 Ich find die Domain auch scheisse, aber nem geschenkten Gaul schaut man
nicht ins Maul oder wie war das?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Ross Burton]

On Sat, 2007-07-28 at 04:39 -0500, Manoj Srivastava wrote:
> > If you don't use nautilus, why not remove the package?  If you want to
> > keep the package installed but never use it, why not remove it from
> > the session?
> 
> Because other users of the machine might want to? Or is Gnome
>  only useful on the subset of single user machines?

Session-removal is per-user.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part

Re: adding desktop files to misc packages

[Manoj Srivastava]

On Wed, 25 Jul 2007 19:22:11 +0200, Frank Küster <[EMAIL PROTECTED]> said: 

> Josselin Mouette <[EMAIL PROTECTED]> wrote:
>> As long as it is not shown, it doesn't matter, so I guess we can
>> agree on this matter.

> No, not at all.  I have not yet seen a convincing argument for hiding
> menu entries.  The only ones were "less is more", which is to vague to
> get one much further, and "we need to hide stuff like python", which
> is plain wrong IMHO because I think python shouldn't have a menu entry
> at all.

Actually, microsoft (which seems to be what GNOME folk are
 trying ever so  hard to emulate) came up with a decent solution -- they
 added shaded areas to menus to indicate that something is hidden from
 the user, and the user can just hover over the are to open up the
 hidden entries.

So, for people with a phobia of information, the "bad" extra
 information is hidden; but it is easy enough to unhide, without
 having to remember which menu one needed to go to to do so.

manoj
-- 
Goals... Plans... they're fantasies, they're part of a dream
world... Wally Shawn
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Manoj Srivastava]

On Fri, 27 Jul 2007 14:07:16 +0200, Josselin Mouette <[EMAIL PROTECTED]> said: 

> Le vendredi 27 juillet 2007 à 03:52 -0700, Steve Langasek a écrit :
>> > In the end, the people who know whether an application should be
>> > given tags that will exclude it from certain menus are the
>> > application's maintainers, not the menu systems maintainers. So far
>> > they have been reasonable about what is included in the menu, and I
>> > have no reason to think this wouldn't remain like that.
>> 
>> In that case, I guess I'm confused, because I had the impression that
>> you were still opposed to migrating the existing Debian menu to use
>> the freedesktop standard.

> Sorry, that wasn't clear: people are currently reasonable with what
> they include in the *freedesktop* menu. I'm not fond of the idea of
> converting the Debian menu entries because it will lead to including
> all that's currently in the *Debian* menu, which is not reasonable.

> If desktop entries are not generated automatically, and if there are
> clear rules on how they should be tagged, I think only a small number
> of maintainers wouldn't follow them.

Hmm.  I am not sure that the results shall be what you think
 they will be. Take for example, someone who packages something that has
 menu entries (me, for example).  Well, such people, like, evidently
 think the package enahnces the menu; and thus, if we swithc to using
 desktop format by default, I would still want to see my package on the
 menu.

So, if you want to keep you menu small and non-comprehensive,
 you should not be pushing for f.d.o formatting. :)

manoj
-- 
Weekend, where are you?
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Manoj Srivastava]

On Thu, 26 Jul 2007 12:49:34 +0100, Ross Burton <[EMAIL PROTECTED]> said: 

> On Thu, 2007-07-26 at 13:33 +0200, Andreas Tille wrote:
>> I was even not able to get rid of this nautilus thingy at all because
>> killing it opens a new one.  I just renamed it and killed it to get
>> rid of.

> If you don't use nautilus, why not remove the package?  If you want to
> keep the package installed but never use it, why not remove it from
> the session?

Because other users of the machine might want to? Or is Gnome
 only useful on the subset of single user machines?

manoj
-- 
A pencil with no point needs no eraser.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le vendredi 27 juillet 2007 à 03:52 -0700, Steve Langasek a écrit :
> > In the end, the people who know whether an application should be given
> > tags that will exclude it from certain menus are the application's
> > maintainers, not the menu systems maintainers. So far they have been
> > reasonable about what is included in the menu, and I have no reason to
> > think this wouldn't remain like that.
> 
> In that case, I guess I'm confused, because I had the impression that you
> were still opposed to migrating the existing Debian menu to use the
> freedesktop standard.

Sorry, that wasn't clear: people are currently reasonable with what they
include in the *freedesktop* menu. I'm not fond of the idea of
converting the Debian menu entries because it will lead to including all
that's currently in the *Debian* menu, which is not reasonable.

If desktop entries are not generated automatically, and if there are
clear rules on how they should be tagged, I think only a small number of
maintainers wouldn't follow them.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Steve Langasek]

On Fri, Jul 27, 2007 at 12:29:35PM +0200, Josselin Mouette wrote:
> Le vendredi 27 juillet 2007 à 02:44 -0700, Steve Langasek a écrit :
> > So far, the only proposal I've seen for allowing users to get access to the
> > "non-default" menu entries, after they've been hidden in GNOME, is by
> > letting them hunt down a config option in a settings menu /which is nowhere
> > near the menu itself/.

> Right-clicking on the menu isn't near the menu itself? If you have
> better suggestions to make it accessible, please don't hesitate.

It wasn't clear to me that this would be togglable from right-clicking on
the menu.

Although my above criticism wouldn't apply, I'm still not altogether happy
with this prospect because you're not just hiding the applications, you're
effectively /hiding the fact that they're hidden/, by giving no UI hint that
brings this information to your attention.  (If your response to this is
"but all you have to do is right click", well - I think that supports *my*
position rather well, since that's an instance where you're giving a
/verbal/ hint because there's no visual indicator in the interface itself.)

Context menus are great for operations that you know you want to perform on
the current data/window/interface element.  Unhiding menu entries isn't an
operation that you know you want to perform, if you don't know that menu
entries are being hidden in the first place!  So it's imperative that hiding
menu entries in this way is only used for *very* esoteric tools that are
just plain incompatible with the environment; not just for applications that
don't meet some aesthetic standard, or that you (or someone else) think are
unlikely to be used.

(I guess it's reasonable to consider console applications "incompatible with
the environment", but then, hasn't GNOME itself supported, since long before
.desktop files existed, marking apps as "runs in xterm" in launchers?)

> You make it sound like somehow I would dictate what would be in the menu
> by removing any application I don't like or use. This has never been my
> intent. I have quoted window managers and console applications as
> examples because they are the only identified classes so far; it is hard
> to tell what will need to be excluded until the desktop files are
> actually created and we can start seeing what the menu looks like.

Why is this hard to tell?  Are the kinds of things that would need to be
suppressed not evident from the menu policy?

> In the end, the people who know whether an application should be given
> tags that will exclude it from certain menus are the application's
> maintainers, not the menu systems maintainers. So far they have been
> reasonable about what is included in the menu, and I have no reason to
> think this wouldn't remain like that.

In that case, I guess I'm confused, because I had the impression that you
were still opposed to migrating the existing Debian menu to use the
freedesktop standard.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le vendredi 27 juillet 2007 à 02:44 -0700, Steve Langasek a écrit :
> So far, the only proposal I've seen for allowing users to get access to the
> "non-default" menu entries, after they've been hidden in GNOME, is by
> letting them hunt down a config option in a settings menu /which is nowhere
> near the menu itself/.

Right-clicking on the menu isn't near the menu itself? If you have
better suggestions to make it accessible, please don't hesitate.

> That's a bad UI; it might be ok for novices, but
> it's not ok for non-novices *or for novices who aren't looking to be novices
> for all eternity*.  Making "advanced" configuration options available only
> to those who already know where to look ensures that there will always be a
> large gap between the knowledgeable elite, and the uninformed consumers.

Despite not being, I think, a novice user, I almost never crave in the
advanced configuration options. They are advanced because there is no
need for them in the general case, novice user or not.

> > I have no business into changing other environments' menus.
> 
> If you're going to be making unilateral decisions about classes of graphical
> applications that shouldn't be shown in the menu because they don't fit with
> your ideal of what a desktop menu should look like, I don't think you have
> any business changing GNOME's menu either.
> 
> Identifying, as a project, classes of applications that aren't appropriate
> for inclusion in the menu of a desktop environment at all, and excluding
> those, is perfectly reasonable; but you appear to insist on referring to the
> classes identified so far, such as console apps and language interpreters,
> as *examples* of things you would trim from the GNOME menu, reserving for
> yourself the right to make the final decisions about what else you'll decide
> to cut.  As a user of GNOME in Debian, I'm not at all ok with that.

You make it sound like somehow I would dictate what would be in the menu
by removing any application I don't like or use. This has never been my
intent. I have quoted window managers and console applications as
examples because they are the only identified classes so far; it is hard
to tell what will need to be excluded until the desktop files are
actually created and we can start seeing what the menu looks like.

In the end, the people who know whether an application should be given
tags that will exclude it from certain menus are the application's
maintainers, not the menu systems maintainers. So far they have been
reasonable about what is included in the menu, and I have no reason to
think this wouldn't remain like that.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Steve Langasek]

On Thu, Jul 26, 2007 at 11:37:33AM +0200, Josselin Mouette wrote:
> Le jeudi 26 juillet 2007 à 10:54 +0200, Wouter Verhelst a écrit :
> > One thing I do not like about the GNOME usability philosophy is
> > precisely this: catering for the novice user is great, but the GNOME
> > usability philosophy caters for novice users *at the expense of
> > experienced users*. 

> This widespread belief is entirely untrue.

It is true, and your posts in this thread are the evidence of it.

So far, the only proposal I've seen for allowing users to get access to the
"non-default" menu entries, after they've been hidden in GNOME, is by
letting them hunt down a config option in a settings menu /which is nowhere
near the menu itself/.  That's a bad UI; it might be ok for novices, but
it's not ok for non-novices *or for novices who aren't looking to be novices
for all eternity*.  Making "advanced" configuration options available only
to those who already know where to look ensures that there will always be a
large gap between the knowledgeable elite, and the uninformed consumers.

> I have no business into changing other environments' menus.

If you're going to be making unilateral decisions about classes of graphical
applications that shouldn't be shown in the menu because they don't fit with
your ideal of what a desktop menu should look like, I don't think you have
any business changing GNOME's menu either.

Identifying, as a project, classes of applications that aren't appropriate
for inclusion in the menu of a desktop environment at all, and excluding
those, is perfectly reasonable; but you appear to insist on referring to the
classes identified so far, such as console apps and language interpreters,
as *examples* of things you would trim from the GNOME menu, reserving for
yourself the right to make the final decisions about what else you'll decide
to cut.  As a user of GNOME in Debian, I'm not at all ok with that.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Joey Hess]

Steve Greenland wrote:
> 1. The format that will be used by Debian packages to specify their menu
> entry. I think the consensus in this thread is that the FDo format is
> better and more flexible than the current Debian menu system format.

I wouldn't argue that it's better or more flexible. It is, however, a
broadly accepted standard, and quite likely "good enough".

> Transitioning to the FDo format is doable by coding a menu-method for
> each WM/panel/whatever that does not currently support the FDo format
> directly, and adjusting the menu package to prefer FDo format entries
> over the current format.

Once menu is able to read .desktop files, and extract the same
information from them that it extracts from menu file, there should be
no need of any new menu-methods.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: adding desktop files to misc packages

[Joey Hess]

Frank Küster wrote:
> > Window managers?
> 
> Yes, in an appropriate category.  *That* one could be a candidate for
> hiding.  If I'm not mistaken KDE, Gnome and friends only work with
> certain window managers, so switching doesn't make sense.

Window managers are already not displayed on the gnome or kde menus.
Hiding all text-mode programs from those menus could be accomplished
trivially:

[EMAIL PROTECTED]:~>diff -u /etc/menu-methods/xdg-desktop-entry-spec-apps 
xdg-desktop-entry-spec-apps 
--- /etc/menu-methods/xdg-desktop-entry-spec-apps   2006-03-20 
08:44:23.0 -0500
+++ xdg-desktop-entry-spec-apps 2007-07-26 18:35:53.0 -0400
@@ -25,7 +25,6 @@
 
 supported;
  x11 = AppEntry("false");
- text = AppEntry("true");
 endsupported;
 
 startmenu = "";

-- 
see shy jo


signature.asc
Description: Digital signature

Re: adding desktop files to misc packages

[Steve Greenland]

On 26-Jul-07, 13:41 (CDT), Russ Allbery <[EMAIL PROTECTED]> wrote: 
> Steve Greenland <[EMAIL PROTECTED]> writes:
> 
> > 3. The actual contents and structure of the default menu in each WM etc.
> > This is a matter of Policy and ENTIRELY orthogonal to issues 1 and 2.
> > In particular, just saying "we're going to use the FDo format now" does
> > nothing to prevent the kind of mess you see in the Debian menu. OTOH,
> > setting an acceptable policy would clean up not only the GNOME menu but
> > all the other menu systems.
> 
> Except that the freedesktop.org specification comes with its own set of
> categories, registration system, and classification system, which does not
> match the Debian system.  I suppose we could use the format without using
> its categorization system, but that seems a bit strange and Debian's
> current menu structure doesn't have the concept of primary and additional
> categories the way that the freedesktop.org specification does.

That's okay. It's just a simple matter of policy making :-)

Or, the Debian GNOME maintainers (and KDE maintainers, etc.) can just
ignore the Debian menu entries and make a package of FDo menu entries
for all the packages they want in their menu. 

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Steve Greenland]

On 26-Jul-07, 04:37 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> I have no business into changing other environments' menus. This is why
> I suggested that we keep the Debian menu as it is for those who prefer
> it. As people seem to want to switch to the freedesktop menu given its
> superiority, I only want to ensure the GNOME menu is improved by the
> process rather than being turned into garbage.

Sigh. You're still conflating 3 issues: 

1. The format that will be used by Debian packages to specify their menu
entry. I think the consensus in this thread is that the FDo format is
better and more flexible than the current Debian menu system format.
Transitioning to the FDo format is doable by coding a menu-method for
each WM/panel/whatever that does not currently support the FDo format
directly, and adjusting the menu package to prefer FDo format entries
over the current format.

2. Whether or not we can just dump the Debian menu system in favor of
the FDo system. IMPORTANT: by "Debian menu system" I mean the ability to
support the same menu entry (as specified by the package, in whatever
format we choose) in a variety of WMs, menu systems, etc. I don't think
this is acceptable to most of the participants in this thread. (Which
doesn't keep the GNOME desktop maintainers from ignoring the Debian menu
entries.)

3. The actual contents and structure of the default menu in each WM etc.
This is a matter of Policy and ENTIRELY orthogonal to issues 1 and 2.
In particular, just saying "we're going to use the FDo format now" does
nothing to prevent the kind of mess you see in the Debian menu. OTOH,
setting an acceptable policy would clean up not only the GNOME menu but
all the other menu systems.

Regards,
Steve


-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Russ Allbery]

Steve Greenland <[EMAIL PROTECTED]> writes:

> 3. The actual contents and structure of the default menu in each WM etc.
> This is a matter of Policy and ENTIRELY orthogonal to issues 1 and 2.
> In particular, just saying "we're going to use the FDo format now" does
> nothing to prevent the kind of mess you see in the Debian menu. OTOH,
> setting an acceptable policy would clean up not only the GNOME menu but
> all the other menu systems.

Except that the freedesktop.org specification comes with its own set of
categories, registration system, and classification system, which does not
match the Debian system.  I suppose we could use the format without using
its categorization system, but that seems a bit strange and Debian's
current menu structure doesn't have the concept of primary and additional
categories the way that the freedesktop.org specification does.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Wouter Verhelst]

On Thu, Jul 26, 2007 at 04:33:17PM +0200, Josselin Mouette wrote:
> Le jeudi 26 juillet 2007 à 12:59 +0200, Wouter Verhelst a écrit :
> > You do not remove the need for some functionality by simply removing the
> > functionality itself altogether, which is what I see GNOME developers do
> > more often than other developers.
> 
> This seems to be based solely on hearsay. 

No, this is based on me using GNOME for about nine months in 2005 until
I got fed up with the behaviour I described.

[...]
> The Debian menu in GNOME has been secondary for quite some time, and the
> source of confusion is rather having two menus than having a menu which
> isn't the same as WindowMaker's.

I'm not saying there isn't confusion in having two menu systems.

I'm saying there's *also* confusion in having a menu which isn't the
same as WindowMaker's, but for a different class of users than the ones
that will get confused by having two menu systems.

> > I think one of the great selling points of Debian is precisely this
> > unified menu system: no matter what window manager or graphical
> > environment you use, there is still this single menu system that will be
> > there, and that will contain all these applications; it is one of the
> > few things that distinguishes Debian from other distributions.
> 
> This used to be true five years ago. Now, other distributions have moved
> and worked on their menu systems, and Debian has not.

Hmm. I must admit I haven't tried another distribution in years.

[...]
-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Meanwhile, real world people have moved to the freedesktop menu, which
> despite its flaws is more flexible, more beautiful and allows a better
> structure designed for each environment.

Tell me, in which world do I live if its not the real world?

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Josselin Mouette]

Le jeudi 26 juillet 2007 à 12:59 +0200, Wouter Verhelst a écrit :
> You do not remove the need for some functionality by simply removing the
> functionality itself altogether, which is what I see GNOME developers do
> more often than other developers.

This seems to be based solely on hearsay. 

> Anyway, this thread is not about GNOME, but about the menu system, so
> let's keep it at that.

Well, I'm interested in a menu system which is usable for GNOME; which
means if it has to be shared with other environments with different
paradigms, the system has to be flexible enough.

> > I have no business into changing other environments' menus.
> 
> If you are going to modify the menu system, then that is exactly what
> you're doing, even if you want to modify it so that the changes remain
> mostly limited to GNOME: by removing the Debian menu from GNOME or
> modifying it so that it doesn't show what's available in all other
> graphical environments that are available in Debian, you're confusing
> users. Users who have used Debian (but not GNOME) before, users who
> use Debian with GNOME on one machine and a lightweight window manager on
> another (because, say, that other machine has less resources), and so
> on.

The Debian menu in GNOME has been secondary for quite some time, and the
source of confusion is rather having two menus than having a menu which
isn't the same as WindowMaker's.

> I think one of the great selling points of Debian is precisely this
> unified menu system: no matter what window manager or graphical
> environment you use, there is still this single menu system that will be
> there, and that will contain all these applications; it is one of the
> few things that distinguishes Debian from other distributions.

This used to be true five years ago. Now, other distributions have moved
and worked on their menu systems, and Debian has not.

> Throwing it out because you don't like the way it is structured just as
> it's about to be restructured seems like throwing out the kid along with
> the bath water to me. The right way would be to improve the menu system,
> so that you can be happy with it. After all, I'll be the first to agree
> that the way the menu system is structured currently is suboptimal.
> Having it everywhere, with all applications visible, *except* in GNOME,
> would be a big, big shame.

Show me the code. If this wonderful menu system existed somewhere
outside your imagination, I guess we could happily used it.

Meanwhile, real world people have moved to the freedesktop menu, which
despite its flaws is more flexible, more beautiful and allows a better
structure designed for each environment.

> > I don't think anyone claimed that nobody does modify their interface.
> > The problem is that the very idea of modifying it is not intuitive.
> 
> Then you need to work on that.

Work on brainwashing users so that they want to modify their interface?
What if they don't care and just want something working out of the box?

> > > Adding an icon to the panel or the desktop should be a drag-and-drop
> > > operation.
> > 
> > It is.
> 
> Not in my experience. I'll be happy to provide details if you want me
> to.

Please file a bug with details, yes.

> > And that's for the complicated way; otherwise it's just a matter of
> > right-clicking on the picture in epiphany and selecting "use as
> > background".
> 
> This should also be possible in nautilus, IMO.

This is already the case in eog (which is the default image viewer).

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Florent Rougon]

Mike Hommey <[EMAIL PROTECTED]> wrote:

>> >> Witness:
>> >>   - usable completion in the File Open dialog   -> gone

[...]

> Note that AFAIK, completion never disappeared from the file open dialogs.
> You just have to enable it with a keystroke.

I know that; the shortcut is Ctrl-L. But I wrote "usable completion"
because even after hitting Ctrl-L, the kind of completion you get is
*much* less efficient than that you got for free in the good old days of
GTK+ 1.2. IOW, there is no usable completion in GNOME's current File
Open/Save dialogs (neither in Qt, for that matter :-/).

> Even if not, it is a problem with gimp if it refuses to set menu shortcuts
> if you change gtk-can-change-accels in your config.

OK, it's not GNOME. But I had the impression that the original feature,
which was accessible out-of-the-box, was removed/made inaccessible
*because* of GNOME's concerns about "usability". That is why I brought
this point here.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Florent Rougon]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> For your information, this was ironic. There is no compositing manager
> in metacity as no one seemed interested enough in developing it.

Ah, I see. Not everyone follows the development of every window manager
on earth, so you couldn't really expect me to get your irony. Anyway...

> Another unfounded assumption: that you need to configure your shortcuts
> to be more productive.

Err, did you ever wonder why Emacs is so popular among people who
actually use their computer?

> A good application should come up with good shortcuts already
> configured. Plus, they should be similar across applications. This is so
> that you don't get lost in front of another account or a new
> application.

I disagree. Applications are different; they provide different features,
and therefore cannot have the same shortcuts except for a handful of
things, such as copy, paste and quit. If you only accept "standard
shortcuts", then all other features are not accessible from the
keyboard, with the result that in most cases, the app won't be very
usable, unless there are means to customize one's own shortcuts.

> The GTK+ development used to be close to that of GIMP, but now it is
> sticking to the GNOME releases and is mostly done by GNOME developers.
> GIMP has still its own team, working with its insane development process
> with one release each time hell freezes.

Okay, so at least this confirms my impression that the GTK+ development
is heavily influenced by the GNOME project.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Mike Hommey]

On Thu, Jul 26, 2007 at 02:07:17PM +0200, Josselin Mouette <[EMAIL PROTECTED]> 
wrote:
> Le jeudi 26 juillet 2007 à 13:35 +0200, Florent Rougon a écrit :
> > > Eye candy... oh right, this must be why there are so many people
> > > interested in bringing a compositing manager to metacity, rather than
> > > improving performance or rendering quality.
> 
> For your information, this was ironic. There is no compositing manager
> in metacity as no one seemed interested enough in developing it.

Actually, there is one.

> > YMMV, but IMHO, I don't think compositing will much improve my
> > efficiency at using a computer (and that's precisely where I measure
> > "usability").
> 
> Exactly my point, thanks.

Actually, it can help improve usability, but that is OT.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le jeudi 26 juillet 2007 à 13:35 +0200, Florent Rougon a écrit :
> > Eye candy... oh right, this must be why there are so many people
> > interested in bringing a compositing manager to metacity, rather than
> > improving performance or rendering quality.

For your information, this was ironic. There is no compositing manager
in metacity as no one seemed interested enough in developing it.

> YMMV, but IMHO, I don't think compositing will much improve my
> efficiency at using a computer (and that's precisely where I measure
> "usability").

Exactly my point, thanks.

> > This feature, despite its coolness, was more a source of annoyance by
> > setting shortcuts by mistake than anything else.
> 
> I don't remember having been bitten by it (it might be, but at least if
> it did happen, it didn't leave any bad sequels ;-). And anyway, if
> you're bitten once, you learn; it takes you, what, one minute? And then
> you'll be more productive. Not during one minute, *always* (well, until
> they remove said feature...).

Another unfounded assumption: that you need to configure your shortcuts
to be more productive.

A good application should come up with good shortcuts already
configured. Plus, they should be similar across applications. This is so
that you don't get lost in front of another account or a new
application.

> > The software you are talking about was rejected for inclusion in GNOME
> > 2.18, and is not part of the GNOME 2.19 desktop.
> 
> Err, but didn't Mike write:
> 
>   IIRC, gnome is going to switch to gnome-main-menu.
> 
> So? It is not (currently) part of the GNOME 2.19 desktop, you say, but
> it is just a matter of time? i.e., are you playing on words, or actually
> contradicting Mike?

I'm not aware of such a move. Currently gnome-main-menu is not part of
the proposed modules for 2.20. This could still change, of course, but
last time it was proposed there was a strong opposition among
developers.

> > This is a problem in GIMP, not in GNOME.
> 
> Hmmm. GOTO my-answer-to-mike. Nothing to add here.

The GTK+ development used to be close to that of GIMP, but now it is
sticking to the GNOME releases and is mostly done by GNOME developers.
GIMP has still its own team, working with its insane development process
with one release each time hell freezes.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Ross Burton]

On Thu, 2007-07-26 at 13:33 +0200, Andreas Tille wrote:
> I found (at least one) counter example:  I never managed to get rid
> of the stupid nautilus behavour to open new windows.

In Nautilus enable Edit -> Preferences -> Behaviour -> Always open in
browser windows.

> I was even not
> able to get rid of this nautilus thingy at all because killing it opens
> a new one.  I just renamed it and killed it to get rid of.

If you don't use nautilus, why not remove the package?  If you want to
keep the package installed but never use it, why not remove it from the
session?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part

Re: adding desktop files to misc packages

[Mike Hommey]

On Thu, Jul 26, 2007 at 01:13:13PM +0200, Florent Rougon <[EMAIL PROTECTED]> 
wrote:
> Hi,
> 
> Mike Hommey <[EMAIL PROTECTED]> wrote:
> 
> >> Witness:
> >>   - usable completion in the File Open dialog   -> gone
> >>   - customizable keyboard shortcuts in apps[1]  -> gone
> >
> > Both are due to gtk, not gnome.
> 
> From my limited end-user POV (a user who used to like GTK+ and GNOME in
> the old days), I had the impression that it is the GNOME project that
> influenced the GTK+ team in this way. Do you think this is wrong?

There might be influence, but not every change in gtk is due to gnome.
Note that AFAIK, completion never disappeared from the file open dialogs.
You just have to enable it with a keystroke.

> >>   [1] No, don't tell me that it is a simple matter of adding
> >>   "gtk-can-change-accels=1" to ~/.gtkrc-2.0. This simply *does*
> >>   *not* *work*. For instance, even with this, you have to go hunt
> >>   for the specific option in Gimp's Preferences menu before you can
> >>   at last add your own keyboard shortcuts. Ugh.
> >
> > Gimp is not a gnome application.
> 
> Hmmm. If GTK+ decisions are not influenced by the GNOME project, fair
> enough. But I doubt this is the case...

Even if not, it is a problem with gimp if it refuses to set menu shortcuts
if you change gtk-can-change-accels in your config.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le jeudi 26 juillet 2007 à 13:33 +0200, Andreas Tille a écrit :
> I found (at least one) counter example:  I never managed to get rid
> of the stupid nautilus behavour to open new windows.  

Edit -> Preferences -> Behaviour -> Always open in navigation windows

If the option name isn't clear enough, feel free to propose an alternate
wording; there's definitely room for improvement here.

> I was even not
> able to get rid of this nautilus thingy at all because killing it opens
> a new one.  

This is intentional, nautilus is a fundamental piece of the desktop. You
can remove it by editing the session, still.

> So the proposition was disproved by a counter example and thus is not true.

This is because of wrong assertions on your side: that you need nautilus
not to run, for example.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Florent Rougon]

Hi,

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Eye candy... oh right, this must be why there are so many people
> interested in bringing a compositing manager to metacity, rather than
> improving performance or rendering quality.

YMMV, but IMHO, I don't think compositing will much improve my
efficiency at using a computer (and that's precisely where I measure
"usability").

To be efficient, I don't need *one* desktop with little miniatures of
windows I don't currently work with, because these windows, even if
small, take up useful screen space. My efficient way of working is to
have each major app (which requires almost the full screen, programs
running in xterms are different) in its own workspace, and to be able to
reach each of them *directly* with one keystroke (where "directly"
means: not having to hit Alt-right-arrow or whatever and needing to
check each time, until the desired workspace appears).

To switch to the workspace where Galeon usually runs, I hit Alt-1.
To switch to the workspace where Emacs usually runs, I hit Alt-2.
To switch to the workspace where I put my first xterms, I hit Alt-3.

...

If I want to do work as root, this is Alt-6.

Every task has a *direct* shortcut that brings me right there in a
fraction of a second. /That/ is efficient. And I don't see how
compositing will improve that. Sure, it's nice, but for me, this mostly
counts as eye-candy.

(for those who're wondering: I'm using WindowMaker; which does have its
flaws, but has a simple and quite efficient workspace handling)

>> Witness:
>>   - usable completion in the File Open dialog   -> gone
>
> And back in GTK 2.10.

Oh, dear, how many years have we been waiting for this? I'm longing to
see it. :)

> This feature, despite its coolness, was more a source of annoyance by
> setting shortcuts by mistake than anything else.

I don't remember having been bitten by it (it might be, but at least if
it did happen, it didn't leave any bad sequels ;-). And anyway, if
you're bitten once, you learn; it takes you, what, one minute? And then
you'll be more productive. Not during one minute, *always* (well, until
they remove said feature...).

> Plus, as you wrote later, it is hidden, not removed.

It was quite convenient to use. Now, it is relatively difficult to use,
if not impossible (do all GNOME apps support it nowadays?). And it's
even more difficult to discover if nobody tells you about it, since you
can't find it "by mistake" anymore.

> The software you are talking about was rejected for inclusion in GNOME
> 2.18, and is not part of the GNOME 2.19 desktop.

Err, but didn't Mike write:

  IIRC, gnome is going to switch to gnome-main-menu.

So? It is not (currently) part of the GNOME 2.19 desktop, you say, but
it is just a matter of time? i.e., are you playing on words, or actually
contradicting Mike?

> This is a problem in GIMP, not in GNOME.

Hmmm. GOTO my-answer-to-mike. Nothing to add here.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Andreas Tille]

On Thu, 26 Jul 2007, Josselin Mouette wrote:


Le jeudi 26 juillet 2007 à 10:54 +0200, Wouter Verhelst a écrit :

One thing I do not like about the GNOME usability philosophy is
precisely this: catering for the novice user is great, but the GNOME
usability philosophy caters for novice users *at the expense of
experienced users*.


This widespread belief is entirely untrue.


This is the proposition.


It is all about making things
understandable for the novice user without reducing functionality for
experienced users; that doesn't mean removing functionality, but rather
removing the *need* for some functionality or configurability.

Many Unix users are used to a high level of configurability, and it is
definitely frustrating not to encounter it when you are used to. But in
the end I find myself gaining a lot of time, because the only things
that are shown in the interface are the things I actually need.


I found (at least one) counter example:  I never managed to get rid
of the stupid nautilus behavour to open new windows.  I was even not
able to get rid of this nautilus thingy at all because killing it opens
a new one.  I just renamed it and killed it to get rid of.

So the proposition was disproved by a counter example and thus is not true.

q.e.d.

  Andreas.

--
http://fam-tille.de

Re: adding desktop files to misc packages

[Wouter Verhelst]

On Thu, Jul 26, 2007 at 11:37:33AM +0200, Josselin Mouette wrote:
> Le jeudi 26 juillet 2007 à 10:54 +0200, Wouter Verhelst a écrit :
> > One thing I do not like about the GNOME usability philosophy is
> > precisely this: catering for the novice user is great, but the GNOME
> > usability philosophy caters for novice users *at the expense of
> > experienced users*. 
> 
> This widespread belief is entirely untrue.

If it is widespread, then there must be at least some truth to that
statement.

> It is all about making things understandable for the novice user
> without reducing functionality for experienced users;

Personally, I feel that you succeed in the first but not in the last.
You may disagree, but it's still why I don't like the GNOME philosophy
about usability: in my opinion, many of the decisions that are made
under the pretext of being good for the novice user have a number of
seriously negative and problematic repercussions to the experienced
user.

Of course, it's okay for GNOME people to do that, as long as they don't
expect me to use their system :-)

> that doesn't mean removing functionality, but rather removing the
> *need* for some functionality or configurability.

You do not remove the need for some functionality by simply removing the
functionality itself altogether, which is what I see GNOME developers do
more often than other developers.

Anyway, this thread is not about GNOME, but about the menu system, so
let's keep it at that. I'll be happy to bash about GNOME on IRC, if you
want me to :-)

[...]
> > If you want to do that in GNOME, go ahead, be my
> > guest; I couldn't care less anyway. And in fact, I installed GNOME on my
> > parent's machine, since I don't want to have to repeatedly explain them
> > too much, so your philosophy has some uses. But please don't expand that
> > philosophy to the rest of the Debian system, where it is totally
> > useless.
> 
> I have no business into changing other environments' menus.

If you are going to modify the menu system, then that is exactly what
you're doing, even if you want to modify it so that the changes remain
mostly limited to GNOME: by removing the Debian menu from GNOME or
modifying it so that it doesn't show what's available in all other
graphical environments that are available in Debian, you're confusing
users. Users who have used Debian (but not GNOME) before, users who
use Debian with GNOME on one machine and a lightweight window manager on
another (because, say, that other machine has less resources), and so
on.

I think one of the great selling points of Debian is precisely this
unified menu system: no matter what window manager or graphical
environment you use, there is still this single menu system that will be
there, and that will contain all these applications; it is one of the
few things that distinguishes Debian from other distributions.

Throwing it out because you don't like the way it is structured just as
it's about to be restructured seems like throwing out the kid along with
the bath water to me. The right way would be to improve the menu system,
so that you can be happy with it. After all, I'll be the first to agree
that the way the menu system is structured currently is suboptimal.
Having it everywhere, with all applications visible, *except* in GNOME,
would be a big, big shame.

However, I can agree that the menu system can use some improvements, and
that some things (the Python example came up, but surely more can be
found) simply don't belong in the menu. If you can come up with some
examples, I'm sure we can discuss them, do a mass bug filing, and/or
update the menu policy to reflect the stuff we agree on.

[...]
> > I'll agree that some things could be finetuned, and that some things
> > simply don't belong in the menu system. But these things are exceptions,
> > and I think most of the applications that are in the menu system
> > currently do belong there.
> > 
> > Speaking of "modifying the interface", one reason why I think the GNOME
> > people have the idea that nobody ever modifies their interface is that
> > it is simply too hard to modify the interface in GNOME. 
> 
> I don't think anyone claimed that nobody does modify their interface.
> The problem is that the very idea of modifying it is not intuitive.

Then you need to work on that.

> > Adding an icon to the panel or the desktop should be a drag-and-drop
> > operation.
> 
> It is.

Not in my experience. I'll be happy to provide details if you want me
to.

> > Changing the desktop background should not require me to add the
> > image to a list of background images first before I can pick it from
> > that list. 
> 
> Whoa? The background properties capplet features a button that spawns a
> file chooser in which you can choose a picture and get done with it.

I've had to explain that point to my dad far too often.

> And that's for the complicated way; otherwise it's just a matter of
> right-clicking on the picture in epiphany and selecting "use a

Re: adding desktop files to misc packages

[Josselin Mouette]

Le jeudi 26 juillet 2007 à 08:25 +0200, Frank Küster a écrit :
> > A window manager choice has nothing to do in an application menu, as it
> > is not an application. This is a matter for a configuration tool,
> > whatever form it takes.
> 
> The Debian menu has more Categories than just applications.  In
> particular, it has a category for window managers.
> 
> If you desktop environment guys want to go a different way and hide this
> category (and instead allow for window manager switching somewhere else,
> like some control center) that's fine.  But that doesn't say that window
> managers shouldn't have a menu file, or .desktop if that is going to be
> its successor.

As long as they are consistently tagged, I have nothing against .desktop
files for window managers.

This category doesn't exist in the freedesktop specification, but you
can add new categories, like X-WindowManager.

> Could you give guidelines how a maintainer of an application should
> classify their app,

Using categories described in [0] is a good start. The maintainers would
also have to agree on new categories if the ones listed are not
sufficient.

Also, the OnlyShowIn field is a good one for applications that are
really too KDE- or GNOME-specific to be shown in other menus. On the
contrary, NotShowIn should be used if similar functionality is available
in one or several environments and displaying an icon would only be a
source of confusion.

For applications that aren't useful in the general case, NoDisplay=true
should be set. Let me show an example: gstreamer-properties used to have
an icon in the menu. In current releases, the appropriate sinks to use
(esd, alsa, etc.) are autodetected which means there is no *need* for
users to launch it, and this allowed us to set NoDisplay=true. The same
should hold for configuration dialogs that are specific to an
application and already available from it.

> and how Gnome would decide which classes to hide?

ConsoleOnly, Shell, Screensaver, X-WindowManager are good candidates. We
could also exclude things like FileManager as nautilus is always
launched, for example. Sound judgement should do the rest.

 [0] http://standards.freedesktop.org/menu-spec/latest/apa.html

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Wouter Verhelst]

On Wed, Jul 25, 2007 at 06:57:54PM +0200, Josselin Mouette wrote:
> Le mercredi 25 juillet 2007 à 08:54 -0400, Marvin Renich a écrit :
> > Gnome and KDE are targeted primarily at desktop users, not servers.  If,
> > as a desktop user, I install a graphical app on my machine, I *expect*
> > to see that app in the main menu.  The place where I put important
> > and/or frequently used apps is on a panel/toolbar.
> 
> Do you expect to see console applications in the menu as well?

Some of them. The ``mc'' file manager is an example of a console
application that I expect to find in the menu. So are the games from the
``bsdgames'' package. The ``fortune'' program is an example of something
I do not expect to find there.

> All interpreters and shells?

No, certainly not.

> Window managers?

Yes. Some window managers support starting another window manager
without terminating the X session, which is an interesting feature. The
"window managers" menu entry is only shown in those window managers that
have this feature, anyway, so I don't see why it should be hidden in
others.

Perhaps a menu method implementation should be allowed to place the
"Window Managers" menu someplace else than right along with the other
menu entries (the "logout" menu in IceWM, or the "System" menu in GNOME
spring to mind), but that's about it.

> > If a novice user installs an app and then goes to the menu and doesn't
> > find it, how is this user supposed to know what to do?
> 
> This bit is correct: someone installing an app can reasonably expect to
> see it in the menu. However you are drawing wrong conclusions:
> 
> >   This is
> > completely *un*usable.  The more novice the user, the more important it
> > is for the *default* to be for all graphical apps to be shown.  Then let
> > the individual user decide which ones are important to him/her.
> 
> If the users installs the distribution with default settings or starts a
> session on a multi-user setup, he should find a usable menu, not a menu
> with all possible applications he never wanted to install.

I think you are mixing two distinct matters in this argument.

If a user installs the distribution with default settings and finds that
too much software is available in the menu, then this is an indication
of there being too much software being installed by default. Rather than
aiming to reduce the usefulness of the menu system, you should be aiming
to reduce the number of useless applications installed by default.

If the user starts a session on a multi-user setup that has way too many
entries in the menu, then this is an indication of a sysadmin not doing
their job properly. Not much we can do about that, except properly
documenting (with examples) how a sysadmin can modify the menu system so
that they can hide certain classes of applications to certain classes of
users.

> > Menus, by their nature, are inherently unusable for the most frequently
> > used apps, and we should not be trying to make them more usable at the
> > expense of making less frequently used apps harder to access.
> 
> Why shouldn't we attempt to make menus usable?

Because by making them more usable for the frequent user in the way you
are suggesting, you make them *less* usable for the casual user. This is
a tradeoff; and since I believe the menu system is mainly meant for the
casual user (frequent users have scripts or panel shortcuts or desktop
icons anyway, or they know the menu system by heart and don't care how
much applications there are), I don't think we should be reducing the
usefulness of the menu system for the casual user.

> > Menus make less frequently used apps easy to get at, while toolbars make
> > frequently used apps even easier; use the right tool for the right job.
> 
> Guess what, toolbars are not used by a good share of users.

Guess what, toolbars are used by most users I know of.

> Toolbars sound obvious for experienced users, but a novice will never
> have the idea to modify the interface that is shown to him;

One thing I do not like about the GNOME usability philosophy is
precisely this: catering for the novice user is great, but the GNOME
usability philosophy caters for novice users *at the expense of
experienced users*. If you want to do that in GNOME, go ahead, be my
guest; I couldn't care less anyway. And in fact, I installed GNOME on my
parent's machine, since I don't want to have to repeatedly explain them
too much, so your philosophy has some uses. But please don't expand that
philosophy to the rest of the Debian system, where it is totally
useless.

I'll agree that some things could be finetuned, and that some things
simply don't belong in the menu system. But these things are exceptions,
and I think most of the applications that are in the menu system
currently do belong there.

Speaking of "modifying the interface", one reason why I think the GNOME
people have the idea that nobody ever modifies their interface is that
it is simply too hard to modify the interface in GN

Re: adding desktop files to misc packages

[Josselin Mouette]

Le jeudi 26 juillet 2007 à 11:38 +0200, Florent Rougon a écrit :
> Seems very clear to me: it has been almost a decade now since the GNOME
> project tries hard to get rid of every feature that makes their software
> more usable (I'm speaking here about real usability, not about
> eye-candy).

Eye candy... oh right, this must be why there are so many people
interested in bringing a compositing manager to metacity, rather than
improving performance or rendering quality.

> Witness:
>   - usable completion in the File Open dialog   -> gone

And back in GTK 2.10.

>   - customizable keyboard shortcuts in apps[1]  -> gone

This feature, despite its coolness, was more a source of annoyance by
setting shortcuts by mistake than anything else. Plus, as you wrote
later, it is hidden, not removed.

> And now, a usable menu listing available applications is going to be
> replaced by a "thing" where you have to find your casually-used app in a
> 300-entries unstructered list after clicking on "More applications..."
> (exactly as the "Open With..." in MS Windows works, no wonder where they
> got the idea).
> 
> So, yes, there *is* a reason GNOME is going to switch to
> gnome-main-menu: the previous menu still had a little remainder of
> (real) usability.

The software you are talking about was rejected for inclusion in GNOME
2.18, and is not part of the GNOME 2.19 desktop.

>   [1] No, don't tell me that it is a simple matter of adding
>   "gtk-can-change-accels=1" to ~/.gtkrc-2.0. This simply *does*
>   *not* *work*. For instance, even with this, you have to go hunt
>   for the specific option in Gimp's Preferences menu before you can
>   at last add your own keyboard shortcuts. Ugh.

This is a problem in GIMP, not in GNOME.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Mike Hommey]

On Thu, Jul 26, 2007 at 11:38:59AM +0200, Florent Rougon <[EMAIL PROTECTED]> 
wrote:
> SCNR...
> 
> Frank Küster <[EMAIL PROTECTED]> wrote:
> 
> Frank> That turns out not to be the case. If I use an app frequently, then it
> Frank> goes on the toolbar. The menu is for finding infrequently used apps. 
> For
> Frank> a lot of users, browsing the menu is how they find out what's 
> available.
> 
> Mike> IIRC, gnome is going to switch to gnome-main-menu. There is a reason for
> Mike> this.
> 
> [...]
> 
> Frank> I haven't watched the whole video (it being boring to me), but from the
> Frank> reading I still don't understand which of my statements you want to
> Frank> contradict, let alone why.
> 
> Seems very clear to me: it has been almost a decade now since the GNOME
> project tries hard to get rid of every feature that makes their software
> more usable (I'm speaking here about real usability, not about
> eye-candy).
> 
> Witness:
>   - usable completion in the File Open dialog   -> gone
>   - customizable keyboard shortcuts in apps[1]  -> gone

Both are due to gtk, not gnome.

> And now, a usable menu listing available applications is going to be
> replaced by a "thing" where you have to find your casually-used app in a
> 300-entries unstructered list after clicking on "More applications..."
> (exactly as the "Open With..." in MS Windows works, no wonder where they
> got the idea).
> 
> So, yes, there *is* a reason GNOME is going to switch to
> gnome-main-menu: the previous menu still had a little remainder of
> (real) usability.
> 
> 
>   [1] No, don't tell me that it is a simple matter of adding
>   "gtk-can-change-accels=1" to ~/.gtkrc-2.0. This simply *does*
>   *not* *work*. For instance, even with this, you have to go hunt
>   for the specific option in Gimp's Preferences menu before you can
>   at last add your own keyboard shortcuts. Ugh.

Gimp is not a gnome application.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Florent Rougon]

SCNR...

Frank Küster <[EMAIL PROTECTED]> wrote:

Frank> That turns out not to be the case. If I use an app frequently, then it
Frank> goes on the toolbar. The menu is for finding infrequently used apps. For
Frank> a lot of users, browsing the menu is how they find out what's available.

Mike> IIRC, gnome is going to switch to gnome-main-menu. There is a reason for
Mike> this.

[...]

Frank> I haven't watched the whole video (it being boring to me), but from the
Frank> reading I still don't understand which of my statements you want to
Frank> contradict, let alone why.

Seems very clear to me: it has been almost a decade now since the GNOME
project tries hard to get rid of every feature that makes their software
more usable (I'm speaking here about real usability, not about
eye-candy).

Witness:
  - usable completion in the File Open dialog   -> gone
  - customizable keyboard shortcuts in apps[1]  -> gone

And now, a usable menu listing available applications is going to be
replaced by a "thing" where you have to find your casually-used app in a
300-entries unstructered list after clicking on "More applications..."
(exactly as the "Open With..." in MS Windows works, no wonder where they
got the idea).

So, yes, there *is* a reason GNOME is going to switch to
gnome-main-menu: the previous menu still had a little remainder of
(real) usability.


  [1] No, don't tell me that it is a simple matter of adding
  "gtk-can-change-accels=1" to ~/.gtkrc-2.0. This simply *does*
  *not* *work*. For instance, even with this, you have to go hunt
  for the specific option in Gimp's Preferences menu before you can
  at last add your own keyboard shortcuts. Ugh.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le jeudi 26 juillet 2007 à 10:54 +0200, Wouter Verhelst a écrit :
> One thing I do not like about the GNOME usability philosophy is
> precisely this: catering for the novice user is great, but the GNOME
> usability philosophy caters for novice users *at the expense of
> experienced users*. 

This widespread belief is entirely untrue. It is all about making things
understandable for the novice user without reducing functionality for
experienced users; that doesn't mean removing functionality, but rather
removing the *need* for some functionality or configurability.

Many Unix users are used to a high level of configurability, and it is
definitely frustrating not to encounter it when you are used to. But in
the end I find myself gaining a lot of time, because the only things
that are shown in the interface are the things I actually need.

> If you want to do that in GNOME, go ahead, be my
> guest; I couldn't care less anyway. And in fact, I installed GNOME on my
> parent's machine, since I don't want to have to repeatedly explain them
> too much, so your philosophy has some uses. But please don't expand that
> philosophy to the rest of the Debian system, where it is totally
> useless.

I have no business into changing other environments' menus. This is why
I suggested that we keep the Debian menu as it is for those who prefer
it. As people seem to want to switch to the freedesktop menu given its
superiority, I only want to ensure the GNOME menu is improved by the
process rather than being turned into garbage.

> I'll agree that some things could be finetuned, and that some things
> simply don't belong in the menu system. But these things are exceptions,
> and I think most of the applications that are in the menu system
> currently do belong there.
> 
> Speaking of "modifying the interface", one reason why I think the GNOME
> people have the idea that nobody ever modifies their interface is that
> it is simply too hard to modify the interface in GNOME. 

I don't think anyone claimed that nobody does modify their interface.
The problem is that the very idea of modifying it is not intuitive.

> Adding an icon
> to the panel or the desktop should be a drag-and-drop operation.

It is.

> Changing the desktop background should not require me to add the
> image to a list of background images first before I can pick it from
> that list. 

Whoa? The background properties capplet features a button that spawns a
file chooser in which you can choose a picture and get done with it. And
that's for the complicated way; otherwise it's just a matter of
right-clicking on the picture in epiphany and selecting "use as
background".

> These are useless hoops to jump through; and even Windows has
> been doing this correctly for about 10 years.

Talking about Windows in a thread about menus sounds... well, no
comment.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Bruce Sass]

On Thu July 26 2007 01:02:57 am Frank Küster wrote:
> Josselin Mouette <[EMAIL PROTECTED]> wrote:
> > If an application is used so infrequently, it shouldn't have its
> > place in a menu.
>
> It seems we have a very different notion of what a menu is.  To me,
> the reply "Exactly because it is used infrequently it should have its
> place" is obvious and follows strictly from my understanding of a
> menu, I don't even need an argument for that.  To you, it seems to be
> the contrary.

I'm with Frank; what Josselin said only makes sense to me if 
s/menu/panel or quicklauncher/

> > This is also my usage scheme: everyday apps in the session, less
> > frequently used apps in the menu, rarely used apps in a terminal or
> > a launching tool.
>
> I don't make this distinction between "less used" and "rarely used",
> and I'm not even sure what a launching tool is.  I nearly never start
> a graphical application from the terminal, and I don't need to be
> able to start terminal applications from the menu: For me that is the
> only reason for deciding whether something should have a (possibly
> hidden) menu entry.

I don't think there is any clear dividing line between graphical and 
terminal based apps as far as menus go. I routinely use text based apps 
in a windowed environment and if they didn't have a menu entry I would 
make one because having to open up a term and type in a command or 
start pdmenu is kinda silly when there is a menu system a click away.


The only thing I'm getting outta this round of the discussion is that 
anything less than complete flexibility with respect to which items get 
placed in whatever menus would be a mistake. I.e., code the thing up so 
that it is easy to tell it how to build menus instead of writing it to 
conform to any particular idea of how menus are used.


- Bruce

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le mercredi 25 juillet 2007 à 19:35 +0200, Frank Küster a écrit :
>> >> Menus, by their nature, are inherently unusable for the most frequently
>> >> used apps, and we should not be trying to make them more usable at the
>> >> expense of making less frequently used apps harder to access.
>> >
>> > Why shouldn't we attempt to make menus usable?
>> 
>> Because, as Marvin wrote in the text you cite, the drawback is that it
>> makes less frequently used applications harder to access.
>
> If an application is used so infrequently, it shouldn't have its place
> in a menu. 

It seems we have a very different notion of what a menu is.  To me, the
reply "Exactly because it is used infrequently it should have its place"
is obvious and follows strictly from my understanding of a menu, I don't
even need an argument for that.  To you, it seems to be the contrary.

> Furthermore, in the case a user needs it more often, he can
> add it to the menu. This becomes even easier if the menu entry is only
> hidden, not absent.

But it seems to be harder than adding it to the toolbar/dock/whatever.

>> But I agree with Marvin (and that's also my usage scheme) that menus
>> should provide access to the less frequently used applications, not the
>> ones started very often.  I don't have toolbars in my WM, but it starts
>> the frequently used apps without asking me, so I use the menu for the
>> rare ones.
>
> This is also my usage scheme: everyday apps in the session, less
> frequently used apps in the menu, rarely used apps in a terminal or a
> launching tool.

I don't make this distinction between "less used" and "rarely used", and
I'm not even sure what a launching tool is.  I nearly never start a
graphical application from the terminal, and I don't need to be able to
start terminal applications from the menu: For me that is the
only reason for deciding whether something should have a (possibly
hidden) menu entry.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Gabor Gombas <[EMAIL PROTECTED]> wrote:

> IMHO the best would be a uniof of the two viewpoints: show everything by
> default, and gradually hide entries that were not used for some time. Or
> did Microsoft patent that?

The result being that if I use the application again for work of type B
after only using it for type A for three weeks, everything that is only
used for B will be hidden.

No, thanks.

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le mercredi 25 juillet 2007 à 16:17 -0400, Marvin Renich a écrit :
>> My original message was specifically concerned with graphical apps.  I'm
>> not sure which console apps should be displayed; for the most part, I
>> think the Debian maintainer should decide whether it deserves to be
>> displayed by default.
>
> I still disagree. The policy should enforce detailed tagging that allows
> window managers and menu systems maintainers to filter out entries they
> don't want to display.

ACK

>> Window managers *definitely* should be displayed.  If I went to the
>> trouble of installing sawfish in addition to metacity, I would like to
>> be able to use both.  Yes, from the menu.
>
> Sorry, but the menu is not a holdall where we put all functionality that
> we don't know where to put without thinking a few minutes.
>
> A window manager choice has nothing to do in an application menu, as it
> is not an application. This is a matter for a configuration tool,
> whatever form it takes.

The Debian menu has more Categories than just applications.  In
particular, it has a category for window managers.

If you desktop environment guys want to go a different way and hide this
category (and instead allow for window manager switching somewhere else,
like some control center) that's fine.  But that doesn't say that window
managers shouldn't have a menu file, or .desktop if that is going to be
its successor.

>> > Why shouldn't we attempt to make menus usable?
>> 
>> I didn't say we should not make them usable, I said we should not try to
>> make them more usable *by reducing access to less frequently used apps*.
>
> As things are, even with the best possible menu system one can imagine,
> you won't manage to make a menu with 500 entries as usable as one with
> 100.

Could you give guidelines how a maintainer of an application should
classify their app, and how Gnome would decide which classes to hide?

>> > Guess what, toolbars are not used by a good share of users.
>
>> Also, my experience is that a good share of less-technically-oriented-
>> but-comfortable-using-a-computer users actually do use toolbars.
>
> These affirmations are not contradictory. I don't deny that many users
> make use of their toolbar, but I think we should keep the menu usable
> for users who don't.

I don't use a toolbar, but for me "usable" means that everything is
there... 

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Mike Hommey <[EMAIL PROTECTED]> wrote:

> On Wed, Jul 25, 2007 at 09:56:11PM +0200, Frank Küster <[EMAIL PROTECTED]> 
> wrote:
>> Mike Hommey <[EMAIL PROTECTED]> wrote:
>> 
>> > On Wed, Jul 25, 2007 at 01:50:20PM -0500, Steve Greenland <[EMAIL 
>> > PROTECTED]> wrote:
>> >> On 25-Jul-07, 13:28 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
>> >> > If an application is used so infrequently, it shouldn't have its place
>> >> > in a menu.
>> >> 
>> >> That turns out not to be the case. If I use an app frequently, then it
>> >> goes on the toolbar. The menu is for finding infrequently used apps. For
>> >> a lot of users, browsing the menu is how they find out what's available.
>> >
>> > IIRC, gnome is going to switch to gnome-main-menu. There is a reason for
>> > this.
>> 
>> What does that mean?  What is gnome-main-menu?
>
> apt-get install gnome-main-menu.

That won't help unless I start Gnome, which I won't.

> http://reverendted.wordpress.com/2007/02/14/show-me-that-updated-gnome-main-menu/

I haven't watched the whole video (it being boring to me), but from the
reading I still don't understand which of my statements you want to
contradict, let alone why.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Mike Hommey]

On Wed, Jul 25, 2007 at 09:56:11PM +0200, Frank Küster <[EMAIL PROTECTED]> 
wrote:
> Mike Hommey <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Jul 25, 2007 at 01:50:20PM -0500, Steve Greenland <[EMAIL 
> > PROTECTED]> wrote:
> >> On 25-Jul-07, 13:28 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> >> > If an application is used so infrequently, it shouldn't have its place
> >> > in a menu.
> >> 
> >> That turns out not to be the case. If I use an app frequently, then it
> >> goes on the toolbar. The menu is for finding infrequently used apps. For
> >> a lot of users, browsing the menu is how they find out what's available.
> >
> > IIRC, gnome is going to switch to gnome-main-menu. There is a reason for
> > this.
> 
> What does that mean?  What is gnome-main-menu?

apt-get install gnome-main-menu.

http://reverendted.wordpress.com/2007/02/14/show-me-that-updated-gnome-main-menu/

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: adding desktop files to misc packages

[Cliffton Beach]

>That's a good reason to improve the menu system, but not really a good
>reason to just go ahead and ship two versions of basically the same
>information, IMO.

Recent version(s) of lynx have an icon in my KDE menu.  I'd really rather not 
have it there, and was curious if anyone had filed a bugreport about it.  I can 
remove it manually of course, but by default I feel rather strongly it should 
not be there.  It is a console app, and people who are interested in using it 
can presumably launch it from there.  People like me, when I am on a console.

Reading some of the mails in this thread, there are people who feel everything 
should be in the menu.  These people aren't typical KDE/Gnome users.  

I think it's a fine idea to have two menu systems, one including the kitchen 
sink and one catering to more standard desktop use and excluding lynx, window 
managers etc.

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mercredi 25 juillet 2007 à 16:17 -0400, Marvin Renich a écrit :
> My original message was specifically concerned with graphical apps.  I'm
> not sure which console apps should be displayed; for the most part, I
> think the Debian maintainer should decide whether it deserves to be
> displayed by default.

I still disagree. The policy should enforce detailed tagging that allows
window managers and menu systems maintainers to filter out entries they
don't want to display.

> Window managers *definitely* should be displayed.  If I went to the
> trouble of installing sawfish in addition to metacity, I would like to
> be able to use both.  Yes, from the menu.

Sorry, but the menu is not a holdall where we put all functionality that
we don't know where to put without thinking a few minutes.

A window manager choice has nothing to do in an application menu, as it
is not an application. This is a matter for a configuration tool,
whatever form it takes.

> > Why shouldn't we attempt to make menus usable?
> 
> I didn't say we should not make them usable, I said we should not try to
> make them more usable *by reducing access to less frequently used apps*.

As things are, even with the best possible menu system one can imagine,
you won't manage to make a menu with 500 entries as usable as one with
100.

> > Guess what, toolbars are not used by a good share of users.

> Also, my experience is that a good share of less-technically-oriented-
> but-comfortable-using-a-computer users actually do use toolbars.

These affirmations are not contradictory. I don't deny that many users
make use of their toolbar, but I think we should keep the menu usable
for users who don't.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: adding desktop files to misc packages

[Gabor Gombas]

On Wed, Jul 25, 2007 at 06:57:54PM +0200, Josselin Mouette wrote:

> If the users installs the distribution with default settings or starts a
> session on a multi-user setup, he should find a usable menu, not a menu
> with all possible applications he never wanted to install.

So the menu system should know if an application was explicitely
selected by the user during installation or it was pulled in due to some
strange dependency? And in the latter case, the menu system should know
that the user _wanted_ the application to be installed regardless (and
therefore he/she expects to see a menu entry by default)?

> Why shouldn't we attempt to make menus usable?

IMHO the best would be a uniof of the two viewpoints: show everything by
default, and gradually hide entries that were not used for some time. Or
did Microsoft patent that?

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Andreas Tille]

On Wed, 25 Jul 2007, Andreas Tille wrote:


I'm open to any propositions to make it better,


Well, I made the suggestion of user roles which was more or less ignored
in this thread.


While beeing uncomfortable to reply to my own mail it seems that the
proposal is quite to abstract to get any comment, perhaps a screenshot
I'm using in my talks makes clear what I mean.  Here you can see a
menu of a user that is in the role "med" (for "medicine") and has for
testing purpose also added to the role "junior" (there are no offcial
packages that feature the Dabian-Jr. menu.

http://people.debian.org/~tille/talks/img/menu-en.png

Those users that are not in role "med" do not see the "Med" menu entry
(resp. for "Junior" or whatever menu structure is used).  Currently the
implementation of roles is done as UNIX groups which is suboptimal and
thus the implementation is realised as a plugin system.  Perhaps some
LDAP plugin could be written.

I really wonder whether this concept of user roles are really that strange
or stupid that all posters seem to ignore this idea.  (Feel free to teach
me in private to keep silent with those stupid ideas.)

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Marvin Renich]

* Josselin Mouette <[EMAIL PROTECTED]> [070725 12:57]:
> Le mercredi 25 juillet 2007 à 08:54 -0400, Marvin Renich a écrit :
> > Gnome and KDE are targeted primarily at desktop users, not servers.  If,
> > as a desktop user, I install a graphical app on my machine, I *expect*
> > to see that app in the main menu.  The place where I put important
> > and/or frequently used apps is on a panel/toolbar.
> 
> Do you expect to see console applications in the menu as well? All
> interpreters and shells? Window managers?

My original message was specifically concerned with graphical apps.  I'm
not sure which console apps should be displayed; for the most part, I
think the Debian maintainer should decide whether it deserves to be
displayed by default.

Window managers *definitely* should be displayed.  If I went to the
trouble of installing sawfish in addition to metacity, I would like to
be able to use both.  Yes, from the menu.

> > If a novice user installs an app and then goes to the menu and doesn't
> > find it, how is this user supposed to know what to do?
> 
> This bit is correct: someone installing an app can reasonably expect to
> see it in the menu. However you are drawing wrong conclusions:
> 
> >   This is
> > completely *un*usable.  The more novice the user, the more important it
> > is for the *default* to be for all graphical apps to be shown.  Then let
> > the individual user decide which ones are important to him/her.
> 
> If the users installs the distribution with default settings or starts a
> session on a multi-user setup, he should find a usable menu, not a menu
> with all possible applications he never wanted to install.

Usable, yes; minimal, no.  See the next paragraph:

> > Menus, by their nature, are inherently unusable for the most frequently
> > used apps, and we should not be trying to make them more usable at the
> > expense of making less frequently used apps harder to access.
> 
> Why shouldn't we attempt to make menus usable?

I didn't say we should not make them usable, I said we should not try to
make them more usable *by reducing access to less frequently used apps*.

> > Menus make less frequently used apps easy to get at, while toolbars make
> > frequently used apps even easier; use the right tool for the right job.
> 
> Guess what, toolbars are not used by a good share of users. Toolbars
> sound obvious for experienced users, but a novice will never have the
> idea to modify the interface that is shown to him; which is why this
> interface must be as straightforward as possible - and that also
> includes good default shortcuts in the toolbar.

That a novice will not know that he can change the interface is even
more reason to make sure the (graphical) app that he installed is in the
menu.  A good system of hints that includes one about putting
applications on the toolbar would be very helpful.

Also, my experience is that a good share of less-technically-oriented-
but-comfortable-using-a-computer users actually do use toolbars.

Josselin, we have not met face-to-face, and email does not convey
emotion very well, so I want to make sure you know that this is not a
personal attack.  Your contribution to Debian is significant, and I
appreciate it (along with that of the many other DD's).  I respect the
technical opinions that you have expressed on the debian mailing lists,
and agree with many of them.  But I strongly disagree with you on this
issue.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Frank Küster]

Mike Hommey <[EMAIL PROTECTED]> wrote:

> On Wed, Jul 25, 2007 at 01:50:20PM -0500, Steve Greenland <[EMAIL PROTECTED]> 
> wrote:
>> On 25-Jul-07, 13:28 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
>> > If an application is used so infrequently, it shouldn't have its place
>> > in a menu.
>> 
>> That turns out not to be the case. If I use an app frequently, then it
>> goes on the toolbar. The menu is for finding infrequently used apps. For
>> a lot of users, browsing the menu is how they find out what's available.
>
> IIRC, gnome is going to switch to gnome-main-menu. There is a reason for
> this.

What does that mean?  What is gnome-main-menu?

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Mike Hommey]

On Wed, Jul 25, 2007 at 01:50:20PM -0500, Steve Greenland <[EMAIL PROTECTED]> 
wrote:
> On 25-Jul-07, 13:28 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> > If an application is used so infrequently, it shouldn't have its place
> > in a menu.
> 
> That turns out not to be the case. If I use an app frequently, then it
> goes on the toolbar. The menu is for finding infrequently used apps. For
> a lot of users, browsing the menu is how they find out what's available.

IIRC, gnome is going to switch to gnome-main-menu. There is a reason for
this.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Bruce Sass]

On Wed July 25 2007 10:57:54 am Josselin Mouette wrote:
> If the users installs the distribution with default settings or
> starts a session on a multi-user setup, he should find a usable menu,
> not a menu with all possible applications he never wanted to install.

Well, if there is stuff he never wanted to install then his first clue 
they are cluttering up his system will be their appearance in the 
menus. It also gives him an opportunity to easily fire them up to see 
what the ones he's never heard of are so he can decide if they should 
be purged or kept. If they are not in the menus then he either tracks 
them down manually and starts them from the commandline, or notices 
them if he pays close enough attention to upgrades.

I think you've hit on a good reason to default to including everything 
in the menus.


- Bruce


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Steve Greenland]

On 25-Jul-07, 13:28 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> If an application is used so infrequently, it shouldn't have its place
> in a menu.

That turns out not to be the case. If I use an app frequently, then it
goes on the toolbar. The menu is for finding infrequently used apps. For
a lot of users, browsing the menu is how they find out what's available.

No, I'm not arguing every shell, interpeter, or other text app needs a
menu a entry, I agree with you on that.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Marvin Renich]

* Frank Küster <[EMAIL PROTECTED]> [070725 10:08]:
> Mike Hommey <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster <[EMAIL PROTECTED]> 
> > wrote:
> >> Mike Hommey <[EMAIL PROTECTED]> wrote:
> >> 
> >> > On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL 
> >> > PROTECTED]> wrote:
> >> >> Absolutely *wrong*.
> >> >> 
> >> >> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
> >> >> as a desktop user, I install a graphical app on my machine, I *expect*
> >> >> to see that app in the main menu.  The place where I put important
> >> >> and/or frequently used apps is on a panel/toolbar.
> >> >
> >> > If you install the python interpreter on your machine, do you also 
> >> > expect it
> >> > to appear in the main menu ?
> >> 
> >> No, why do you ask?  The python interpreter isn't a graphical
> >> application.  It also doesn't have a menu entry, so there's nothing to
> >> hide. 
> >
> > You obviously never looked at the Debian menu.
> 
> How do you come to that conclusion?  On the contrary, I use it
> frequently (there's other menu in my WM).  
> 
> But from Marvin's sentence (which I think is right) 
> 
> ,
> | If, as a desktop user, I install a graphical app on my machine, I
> | *expect* to see that app in the main menu
> `
> 
> you cannot conclude on his (or my) expectations regarding python, because
> python is not a graphical application.
> 

Thanks Frank; that is exactly what I meant.

...Marvin

PS  Please do not CC me when replying to the list, I am subscribed.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mercredi 25 juillet 2007 à 19:35 +0200, Frank Küster a écrit :
> >> Menus, by their nature, are inherently unusable for the most frequently
> >> used apps, and we should not be trying to make them more usable at the
> >> expense of making less frequently used apps harder to access.
> >
> > Why shouldn't we attempt to make menus usable?
> 
> Because, as Marvin wrote in the text you cite, the drawback is that it
> makes less frequently used applications harder to access.

If an application is used so infrequently, it shouldn't have its place
in a menu. Furthermore, in the case a user needs it more often, he can
add it to the menu. This becomes even easier if the menu entry is only
hidden, not absent.

> There are other ways to make menus usable even for frequently used
> applications, without these drawbacks:  For example, if a user can
> influence the order of entries, that would help much more.

Or that could be even more confusing.

> But I agree with Marvin (and that's also my usage scheme) that menus
> should provide access to the less frequently used applications, not the
> ones started very often.  I don't have toolbars in my WM, but it starts
> the frequently used apps without asking me, so I use the menu for the
> rare ones.

This is also my usage scheme: everyday apps in the session, less
frequently used apps in the menu, rarely used apps in a terminal or a
launching tool.

> I have little experience with such users; the ones I know and would call
> "computer illiterate" use the windows desktop or the Mac dock for
> starting their pet applications.  If there's actually a considerable
> number of people who don't even get that far, I'm not sure how to help
> them.  Maybe you are right, and hiding stuff is a possibility.
> Automatically moving the often-used entries to a well-visible toolbar is
> an alternative; I generally don't like if computers change their
> appearance based on what they perceive my usage patterns, but maybe it's
> the better choice here than hiding.

Things like slab are an attempt in this direction, by making frequently
used applications automatically directly accessible, but last time I
looked at it I was not convinced at all by the result. I also agree that
changing the appearance depending on usage is not a good idea.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le mercredi 25 juillet 2007 à 08:54 -0400, Marvin Renich a écrit :
>> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
>> as a desktop user, I install a graphical app on my machine, I *expect*
>> to see that app in the main menu.  The place where I put important
>> and/or frequently used apps is on a panel/toolbar.
>
> Do you expect to see console applications in the menu as well? 

With some exceptions, no.

> All
> interpreters and shells? 

No.

> Window managers?

Yes, in an appropriate category.  *That* one could be a candidate for
hiding.  If I'm not mistaken KDE, Gnome and friends only work with
certain window managers, so switching doesn't make sense.

>>   This is
>> completely *un*usable.  The more novice the user, the more important it
>> is for the *default* to be for all graphical apps to be shown.  Then let
>> the individual user decide which ones are important to him/her.
>
> If the users installs the distribution with default settings or starts a
> session on a multi-user setup, he should find a usable menu, 

ACK

> not a menu
> with all possible applications he never wanted to install.

That depends...  But indeed, on a multi-user system the local admin
should be able to taylor the default menu according to their
expectations of the users.  In the same line, a maintainer of a desktop
environment might do the same.  I don't like the latter, but it would be
just one *more* reason for me not to use a desktop environment, so I
don't care much.

>> Menus, by their nature, are inherently unusable for the most frequently
>> used apps, and we should not be trying to make them more usable at the
>> expense of making less frequently used apps harder to access.
>
> Why shouldn't we attempt to make menus usable?

Because, as Marvin wrote in the text you cite, the drawback is that it
makes less frequently used applications harder to access.

There are other ways to make menus usable even for frequently used
applications, without these drawbacks:  For example, if a user can
influence the order of entries, that would help much more.

But I agree with Marvin (and that's also my usage scheme) that menus
should provide access to the less frequently used applications, not the
ones started very often.  I don't have toolbars in my WM, but it starts
the frequently used apps without asking me, so I use the menu for the
rare ones.

>> Menus make less frequently used apps easy to get at, while toolbars make
>> frequently used apps even easier; use the right tool for the right job.
>
> Guess what, toolbars are not used by a good share of users. Toolbars
> sound obvious for experienced users, but a novice will never have the
> idea to modify the interface that is shown to him; which is why this
> interface must be as straightforward as possible - and that also
> includes good default shortcuts in the toolbar.

I have little experience with such users; the ones I know and would call
"computer illiterate" use the windows desktop or the Mac dock for
starting their pet applications.  If there's actually a considerable
number of people who don't even get that far, I'm not sure how to help
them.  Maybe you are right, and hiding stuff is a possibility.
Automatically moving the often-used entries to a well-visible toolbar is
an alternative; I generally don't like if computers change their
appearance based on what they perceive my usage patterns, but maybe it's
the better choice here than hiding.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le mercredi 25 juillet 2007 à 16:40 +0200, Frank Küster a écrit :
>> Michael Biebl <[EMAIL PROTECTED]> wrote:
>> 
>> > Actually, it's not. That's Joss' whole point. We should hide entries,
>> > such as the python interpreter for novice users (at least in
>> > environments like KDE/GNOME/XFCE, which target the novice users).
>> > If the Debian menu is too overloaded, it becomes less useful.
>> > Sometimes, less is more imho.
>> 
>> I tend to disagree, simply because I think that python shouldn't have a
>> menu entry at all.  Who wants to convince me (or give me an URL to an
>> archived discussion) that it should have one?
>
> As long as it is not shown, it doesn't matter, so I guess we can agree
> on this matter.

No, not at all.  I have not yet seen a convincing argument for hiding
menu entries.  The only ones were "less is more", which is to vague to
get one much further, and "we need to hide stuff like python", which is
plain wrong IMHO because I think python shouldn't have a menu entry at
all. 

In particular, nobody has yet answered Marvin's argument about not
mixing up the purpose of the menu and the toolbar,

,
| Gnome and KDE are targeted primarily at desktop users, not servers.  If,
| as a desktop user, I install a graphical app on my machine, I *expect*
| to see that app in the main menu.  The place where I put important
| and/or frequently used apps is on a panel/toolbar.
`

Mike overlooked the word "graphical", and since then we are discussing
python, not menu/.desktop.


Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mercredi 25 juillet 2007 à 16:40 +0200, Frank Küster a écrit :
> Michael Biebl <[EMAIL PROTECTED]> wrote:
> 
> > Actually, it's not. That's Joss' whole point. We should hide entries,
> > such as the python interpreter for novice users (at least in
> > environments like KDE/GNOME/XFCE, which target the novice users).
> > If the Debian menu is too overloaded, it becomes less useful.
> > Sometimes, less is more imho.
> 
> I tend to disagree, simply because I think that python shouldn't have a
> menu entry at all.  Who wants to convince me (or give me an URL to an
> archived discussion) that it should have one?

As long as it is not shown, it doesn't matter, so I guess we can agree
on this matter.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mercredi 25 juillet 2007 à 08:54 -0400, Marvin Renich a écrit :
> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
> as a desktop user, I install a graphical app on my machine, I *expect*
> to see that app in the main menu.  The place where I put important
> and/or frequently used apps is on a panel/toolbar.

Do you expect to see console applications in the menu as well? All
interpreters and shells? Window managers?

> If a novice user installs an app and then goes to the menu and doesn't
> find it, how is this user supposed to know what to do?

This bit is correct: someone installing an app can reasonably expect to
see it in the menu. However you are drawing wrong conclusions:

>   This is
> completely *un*usable.  The more novice the user, the more important it
> is for the *default* to be for all graphical apps to be shown.  Then let
> the individual user decide which ones are important to him/her.

If the users installs the distribution with default settings or starts a
session on a multi-user setup, he should find a usable menu, not a menu
with all possible applications he never wanted to install.

> Menus, by their nature, are inherently unusable for the most frequently
> used apps, and we should not be trying to make them more usable at the
> expense of making less frequently used apps harder to access.

Why shouldn't we attempt to make menus usable?

> Menus make less frequently used apps easy to get at, while toolbars make
> frequently used apps even easier; use the right tool for the right job.

Guess what, toolbars are not used by a good share of users. Toolbars
sound obvious for experienced users, but a novice will never have the
idea to modify the interface that is shown to him; which is why this
interface must be as straightforward as possible - and that also
includes good default shortcuts in the toolbar.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Frank Küster]

Michael Biebl <[EMAIL PROTECTED]> wrote:

> Actually, it's not. That's Joss' whole point. We should hide entries,
> such as the python interpreter for novice users (at least in
> environments like KDE/GNOME/XFCE, which target the novice users).
> If the Debian menu is too overloaded, it becomes less useful.
> Sometimes, less is more imho.

I tend to disagree, simply because I think that python shouldn't have a
menu entry at all.  Who wants to convince me (or give me an URL to an
archived discussion) that it should have one?

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Michael Biebl]

Frank Küster schrieb:
> Frank Küster <[EMAIL PROTECTED]> wrote:
> 
>> Mike Hommey <[EMAIL PROTECTED]> wrote:
>>
>>> On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster <[EMAIL PROTECTED]> 
>>> wrote:
 Mike Hommey <[EMAIL PROTECTED]> wrote:

> On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL 
> PROTECTED]> wrote:
>> Absolutely *wrong*.
>>
>> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
>> as a desktop user, I install a graphical app on my machine, I *expect*
>> to see that app in the main menu.  The place where I put important
>> and/or frequently used apps is on a panel/toolbar.
> If you install the python interpreter on your machine, do you also expect 
> it
> to appear in the main menu ?
 No, why do you ask?  The python interpreter isn't a graphical
 application.  It also doesn't have a menu entry, so there's nothing to
 hide. 
>>> You obviously never looked at the Debian menu.
>> How do you come to that conclusion?  
> 
> Well, that's clear, since it actually has a menu entry.  I looked in
> /usr/share/menu but overlooked it.  But that's still completely
> irrelevant for the question at hand.
> 

Actually, it's not. That's Joss' whole point. We should hide entries,
such as the python interpreter for novice users (at least in
environments like KDE/GNOME/XFCE, which target the novice users).
If the Debian menu is too overloaded, it becomes less useful.
Sometimes, less is more imho.

Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: adding desktop files to misc packages

[Frank Küster]

Frank Küster <[EMAIL PROTECTED]> wrote:

> Mike Hommey <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster <[EMAIL PROTECTED]> 
>> wrote:
>>> Mike Hommey <[EMAIL PROTECTED]> wrote:
>>> 
>>> > On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL 
>>> > PROTECTED]> wrote:
>>> >> Absolutely *wrong*.
>>> >> 
>>> >> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
>>> >> as a desktop user, I install a graphical app on my machine, I *expect*
>>> >> to see that app in the main menu.  The place where I put important
>>> >> and/or frequently used apps is on a panel/toolbar.
>>> >
>>> > If you install the python interpreter on your machine, do you also expect 
>>> > it
>>> > to appear in the main menu ?
>>> 
>>> No, why do you ask?  The python interpreter isn't a graphical
>>> application.  It also doesn't have a menu entry, so there's nothing to
>>> hide. 
>>
>> You obviously never looked at the Debian menu.
>
> How do you come to that conclusion?  

Well, that's clear, since it actually has a menu entry.  I looked in
/usr/share/menu but overlooked it.  But that's still completely
irrelevant for the question at hand.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Mike Hommey <[EMAIL PROTECTED]> wrote:

> On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster <[EMAIL PROTECTED]> 
> wrote:
>> Mike Hommey <[EMAIL PROTECTED]> wrote:
>> 
>> > On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL 
>> > PROTECTED]> wrote:
>> >> Absolutely *wrong*.
>> >> 
>> >> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
>> >> as a desktop user, I install a graphical app on my machine, I *expect*
>> >> to see that app in the main menu.  The place where I put important
>> >> and/or frequently used apps is on a panel/toolbar.
>> >
>> > If you install the python interpreter on your machine, do you also expect 
>> > it
>> > to appear in the main menu ?
>> 
>> No, why do you ask?  The python interpreter isn't a graphical
>> application.  It also doesn't have a menu entry, so there's nothing to
>> hide. 
>
> You obviously never looked at the Debian menu.

How do you come to that conclusion?  On the contrary, I use it
frequently (there's other menu in my WM).  

But from Marvin's sentence (which I think is right) 

,
| If, as a desktop user, I install a graphical app on my machine, I
| *expect* to see that app in the main menu
`

you cannot conclude on his (or my) expectations regarding python, because
python is not a graphical application.



In case you are in fact interested in the unrelated question "Should
non-graphical applications have a menu entry?", here's my opinion:  In
most cases I think they shouldn't.  All those interpreters in
Applications/Programming are a good example for executables which IMHO
don't need a menu entry.  

There may be cases, though, were a menu entry makes sense.  In
particular for programs which usually need their own terminal, anyway,
and are likely to stay open for a while (e.g. mutt).  Selecting
appropriate settings for the terminal used is a different issue...

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Mike Hommey]

On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster <[EMAIL PROTECTED]> 
wrote:
> Mike Hommey <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL PROTECTED]> 
> > wrote:
> >> Absolutely *wrong*.
> >> 
> >> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
> >> as a desktop user, I install a graphical app on my machine, I *expect*
> >> to see that app in the main menu.  The place where I put important
> >> and/or frequently used apps is on a panel/toolbar.
> >
> > If you install the python interpreter on your machine, do you also expect it
> > to appear in the main menu ?
> 
> No, why do you ask?  The python interpreter isn't a graphical
> application.  It also doesn't have a menu entry, so there's nothing to
> hide. 

You obviously never looked at the Debian menu.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Frank Küster]

Mike Hommey <[EMAIL PROTECTED]> wrote:

> On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL PROTECTED]> 
> wrote:
>> Absolutely *wrong*.
>> 
>> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
>> as a desktop user, I install a graphical app on my machine, I *expect*
>> to see that app in the main menu.  The place where I put important
>> and/or frequently used apps is on a panel/toolbar.
>
> If you install the python interpreter on your machine, do you also expect it
> to appear in the main menu ?

No, why do you ask?  The python interpreter isn't a graphical
application.  It also doesn't have a menu entry, so there's nothing to
hide. 

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Mike Hommey]

On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL PROTECTED]> 
wrote:
> Absolutely *wrong*.
> 
> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
> as a desktop user, I install a graphical app on my machine, I *expect*
> to see that app in the main menu.  The place where I put important
> and/or frequently used apps is on a panel/toolbar.

If you install the python interpreter on your machine, do you also expect it
to appear in the main menu ?

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Marvin Renich]

* Josselin Mouette <[EMAIL PROTECTED]> [070725 06:10]:
> Le mercredi 25 juillet 2007 à 00:14 -0500, Manoj Srivastava a écrit :
> > The latter might be fine as a local policy; but surely is not
> >  correct as a Debian default.  We should make it _possible_ to implement
> >  a local policy of hiding information from users; but we must not let
> >  information hiding be the default; nor the only possible local policy.

Exactly.

> 
> No. We should hide part of the information by default, but make it both
> possible:
>   * for users to access the extra information without anything too
> complicated;
>   * for administrators to really lock information if that's really
> useful.
> 
> Relevant information easily gets lost when there is too much of it,
> which is why a *default* setup should never show all available
> information. And this isn't only relevant for menus.
> 

Absolutely *wrong*.

Gnome and KDE are targeted primarily at desktop users, not servers.  If,
as a desktop user, I install a graphical app on my machine, I *expect*
to see that app in the main menu.  The place where I put important
and/or frequently used apps is on a panel/toolbar.

If a novice user installs an app and then goes to the menu and doesn't
find it, how is this user supposed to know what to do?  This is
completely *un*usable.  The more novice the user, the more important it
is for the *default* to be for all graphical apps to be shown.  Then let
the individual user decide which ones are important to him/her.

Menus, by their nature, are inherently unusable for the most frequently
used apps, and we should not be trying to make them more usable at the
expense of making less frequently used apps harder to access.

Menus make less frequently used apps easy to get at, while toolbars make
frequently used apps even easier; use the right tool for the right job.

If Gnome were to have a "menu policy" configuration, with the Debian
default being "show all apps", but which made it easy for the "less is
more useable" camp to accept someone else's idea of "most important
apps" with a single setting rather than having to wade through the menu
editor, I would find that an excellent compromise.

As for multiuser systems and servers, the same logic applies.  The
Debian default should be to show all apps, then let the sysadmin tailor
that for the installation, then let the users fine tune it.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Andreas Tille]

On Wed, 25 Jul 2007, Josselin Mouette wrote:


I'm open to any propositions to make it better,


Well, I made the suggestion of user roles which was more or less ignored
in this thread.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mercredi 25 juillet 2007 à 12:12 +0200, Andreas Barth a écrit :
> Actually, it might also be useful to allow different window managers to
> have different default levels of what information is shown.

Definitely.

The freedesktop specification could allow to do that, provided that menu
files are correctly tagged with OnlyShowIn and Categories fields. It
also requires some tweaking from the menu systems maintainers.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Andreas Barth]

* Josselin Mouette ([EMAIL PROTECTED]) [070725 12:06]:
> Le mercredi 25 juillet 2007 à 00:14 -0500, Manoj Srivastava a écrit :
> > The latter might be fine as a local policy; but surely is not
> >  correct as a Debian default.  We should make it _possible_ to implement
> >  a local policy of hiding information from users; but we must not let
> >  information hiding be the default; nor the only possible local policy.
> 
> No. We should hide part of the information by default, but make it both
> possible:
>   * for users to access the extra information without anything too
> complicated;
>   * for administrators to really lock information if that's really
> useful.

Actually, it might also be useful to allow different window managers to
have different default levels of what information is shown.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mardi 24 juillet 2007 à 20:13 +0200, Eduard Bloch a écrit :
> > This is a very bad idea. It is going to clutter the freedesktop menu
> > with tons of useless entries with ugly icons and make it as useless as
> 
> Make it short, what is your point? Not allowing others to play in your
> GNOME sandbox?

My point is that currently the GNOME menu is usable, and it's one of the
key parts of this desktop's usability. I'm open to any propositions to
make it better, and closed to propositions that make it worse (e.g. by
making it look like the Debian menu).

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mercredi 25 juillet 2007 à 00:14 -0500, Manoj Srivastava a écrit :
> The latter might be fine as a local policy; but surely is not
>  correct as a Debian default.  We should make it _possible_ to implement
>  a local policy of hiding information from users; but we must not let
>  information hiding be the default; nor the only possible local policy.

No. We should hide part of the information by default, but make it both
possible:
  * for users to access the extra information without anything too
complicated;
  * for administrators to really lock information if that's really
useful.

Relevant information easily gets lost when there is too much of it,
which is why a *default* setup should never show all available
information. And this isn't only relevant for menus.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Josselin Mouette]

Le vendredi 20 juillet 2007 à 16:26 +0200, Michelle Konzack a écrit :
> But the bigger problem is, that some applications have "titles"
> for applications which go over 1/3 of a 1024x768 screen mostly
> Openoffice Apps like "Openoffice.org Printer Administration"
> where the menu has a width of 372 pixels which is realy annoying.

This sounds exactly like the kind of entries which have nothing to do in
the menu. Printers should be configured centrally and made available to
OOo - in fact, they are. If there are any OOo specific parameters for
printers, they should be made available from inside OOo only, not from
the menu.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/25/07 00:14, Manoj Srivastava wrote:
> On Tue, 24 Jul 2007 19:56:37 -0500, Ron Johnson <[EMAIL PROTECTED]> said: 
> 
>> On 07/24/07 17:31, Manoj Srivastava wrote:
>>> On Tue, 24 Jul 2007 21:25:47 +0100, Matthew Johnson
>>> <[EMAIL PROTECTED]> said:
[snip]
 Surely the correct approach is to say that people who don't want to
 see it won't have it installed and people who have it installed want
 to be able to use it from the menu. Programs which you have to have
 installed and yet don't want to see in the menu probably shouldn't
 have (visible by default) menu entries and should be dealt with by
 fixing that program, not by removing all the other entries.
>>> Haven't heard of multi-user systems, have we?  What if some of the
>>> users want to see it in the menu, and other do not?  Surely we do not
>>> want to make Debian unsuited for multi user installations?
>>>
>>> I have been using a central server with essentially Etch thin clients
>>> at one of our testbeds at work; and it does solve a number of
>>> sysadmin headaches for us.
> 
>> Sounds like he's either (a) got a Windows mentality, or (b) doesn't
>> want unprivileged users to see non-essential apps.
> 
> The latter might be fine as a local policy; but surely is not
>  correct as a Debian default.  We should make it _possible_ to implement
>  a local policy of hiding information from users; but we must not let
>  information hiding be the default; nor the only possible local policy.

100% ACK.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGpvMwS9HxQb37XmcRAoiDAJwJuw70f0DtiQ6faIRoBSixmbZ0/wCeJaop
M50vfajDvv0zOmcAidgDUeQ=
=VTej
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Manoj Srivastava]

On Tue, 24 Jul 2007 19:56:37 -0500, Ron Johnson <[EMAIL PROTECTED]> said: 

> On 07/24/07 17:31, Manoj Srivastava wrote:
>> On Tue, 24 Jul 2007 21:25:47 +0100, Matthew Johnson
>> <[EMAIL PROTECTED]> said:
>> 
>>> Eduard Bloch wrote:
 * Josselin Mouette [Wed, Jul 18 2007, 07:32:28PM]:
 
>> The Debian menu system will generate .desktop files from .menu
>> files if the .desktop file does not exist. This is intended
>> solely as a temporary compatibility measure.
> This is a very bad idea. It is going to clutter the freedesktop
> menu with tons of useless entries with ugly icons and make it as
> useless as
 Make it short, what is your point? Not allowing others to play in
 your GNOME sandbox?
>> 
>>> Surely the correct approach is to say that people who don't want to
>>> see it won't have it installed and people who have it installed want
>>> to be able to use it from the menu. Programs which you have to have
>>> installed and yet don't want to see in the menu probably shouldn't
>>> have (visible by default) menu entries and should be dealt with by
>>> fixing that program, not by removing all the other entries.
>> 
>> Haven't heard of multi-user systems, have we?  What if some of the
>> users want to see it in the menu, and other do not?  Surely we do not
>> want to make Debian unsuited for multi user installations?
>> 
>> I have been using a central server with essentially Etch thin clients
>> at one of our testbeds at work; and it does solve a number of
>> sysadmin headaches for us.

> Sounds like he's either (a) got a Windows mentality, or (b) doesn't
> want unprivileged users to see non-essential apps.

The latter might be fine as a local policy; but surely is not
 correct as a Debian default.  We should make it _possible_ to implement
 a local policy of hiding information from users; but we must not let
 information hiding be the default; nor the only possible local policy.

manoj

-- 
"A verbal contract isn't worth the paper it's printed on." Samuel
Goldwyn
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/24/07 17:31, Manoj Srivastava wrote:
> On Tue, 24 Jul 2007 21:25:47 +0100, Matthew Johnson <[EMAIL PROTECTED]> said: 
> 
>> Eduard Bloch wrote:
>>> * Josselin Mouette [Wed, Jul 18 2007, 07:32:28PM]:
>>>
> The Debian menu system will generate .desktop files from .menu
> files if the .desktop file does not exist. This is intended
> solely as a temporary compatibility measure.
 This is a very bad idea. It is going to clutter the freedesktop
 menu with tons of useless entries with ugly icons and make it as
 useless as
>>> Make it short, what is your point? Not allowing others to play in
>>> your GNOME sandbox?
> 
>> Surely the correct approach is to say that people who don't want to
>> see it won't have it installed and people who have it installed want
>> to be able to use it from the menu. Programs which you have to have
>> installed and yet don't want to see in the menu probably shouldn't
>> have (visible by default) menu entries and should be dealt with by
>> fixing that program, not by removing all the other entries.
> 
> Haven't heard of multi-user systems, have we?  What if some of
>  the users want to see it in the menu, and other do not?  Surely we do
>  not want to make Debian unsuited for multi user installations?
> 
> I have been using a central server with essentially Etch thin
>  clients at one of our testbeds at work; and it does solve a number of
>  sysadmin headaches for us.

Sounds like he's either (a) got a Windows mentality, or (b) doesn't
want unprivileged users to see non-essential apps.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGpp/FS9HxQb37XmcRAvKVAJ9QWgEg7G17XmIEI/F2uXlwjWmxdQCggwOz
hKI50dPqHRDyb6RI6T0S02I=
=MY1/
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Manoj Srivastava]

On Tue, 24 Jul 2007 21:25:47 +0100, Matthew Johnson <[EMAIL PROTECTED]> said: 

> Eduard Bloch wrote:
>> * Josselin Mouette [Wed, Jul 18 2007, 07:32:28PM]:
>> 
>> > > The Debian menu system will generate .desktop files from .menu
>> > > files if the .desktop file does not exist. This is intended
>> > > solely as a temporary compatibility measure.
>> > 
>> > This is a very bad idea. It is going to clutter the freedesktop
>> > menu with tons of useless entries with ugly icons and make it as
>> > useless as
>> 
>> Make it short, what is your point? Not allowing others to play in
>> your GNOME sandbox?

> Surely the correct approach is to say that people who don't want to
> see it won't have it installed and people who have it installed want
> to be able to use it from the menu. Programs which you have to have
> installed and yet don't want to see in the menu probably shouldn't
> have (visible by default) menu entries and should be dealt with by
> fixing that program, not by removing all the other entries.

Haven't heard of multi-user systems, have we?  What if some of
 the users want to see it in the menu, and other do not?  Surely we do
 not want to make Debian unsuited for multi user installations?

I have been using a central server with essentially Etch thin
 clients at one of our testbeds at work; and it does solve a number of
 sysadmin headaches for us.

manoj
-- 
He's just like Capistrano, always ready for a few swallows.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Matthew Johnson]

Eduard Bloch wrote:
> * Josselin Mouette [Wed, Jul 18 2007, 07:32:28PM]:
> 
> > > The Debian menu system will generate .desktop files from .menu files
> > > if the 
> > > .desktop file does not exist. This is intended solely
> > > as a temporary compatibility measure.
> > 
> > This is a very bad idea. It is going to clutter the freedesktop menu
> > with tons of useless entries with ugly icons and make it as useless as
> 
> Make it short, what is your point? Not allowing others to play in your
> GNOME sandbox?

Surely the correct approach is to say that people who don't want to see
it won't have it installed and people who have it installed want to be
able to use it from the menu. Programs which you have to have installed
and yet don't want to see in the menu probably shouldn't have (visible
by default) menu entries and should be dealt with by fixing that
program, not by removing all the other entries.

Having said that, I do agree with moving to .desktop by default, but
that does not address the issue of what should be in the menus, just
how.

Matt
--
Matthew Johnson


signature.asc
Description: Digital signature

Re: adding desktop files to misc packages

[Eduard Bloch]

#include 
* Josselin Mouette [Wed, Jul 18 2007, 07:32:28PM]:

> > The Debian menu system will generate .desktop files from .menu files if the 
> > .desktop file does not exist. This is intended solely
> > as a temporary compatibility measure.
> 
> This is a very bad idea. It is going to clutter the freedesktop menu
> with tons of useless entries with ugly icons and make it as useless as

Make it short, what is your point? Not allowing others to play in your
GNOME sandbox?

Eduard.
-- 
 Arghl.
 Ich wunderte mich gerade über *sehr* ekliges Perl... bis ich das fand:
 # Copyright (C) 2004 Marc Brockschmidt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Eduard Bloch]

#include 
* Bernhard R. Link [Sat, Jul 14 2007, 04:26:50PM]:
> * Eduard Bloch <[EMAIL PROTECTED]> [070714 14:44]:
> > #include 
> > I also suggest moving away from the Debian menu files to .desktop files
> > because of more flexible format. Therefore, if the menu using packages
> > support the new style, they would read the menu data from those .desktop
> > files.
> 
> What do you mean with "format" and what with "more flexible"?

file:///usr/share/doc/menu/html/ch3.html
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.0.html

> There can hardly be anything more flexible than free-style key-string

Oh yeah, any more extremes? I talk about better roads with more optimal
ways and you say there is no difference since it's as good as driving
through forests and deserts which also takes you to the destination
(figurative speaking).

Eduard.

-- 
 Halloechen, ihr Spinner, so frueh auf?
 nein, wir schlafen alle im kollektiv
 mein alkoven ist kaputt
 alkohol kaputt?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Daniel Leidert]

Am Freitag, den 20.07.2007, 18:03 +0200 schrieb Michelle Konzack:
> Am 2007-07-15 22:57:10, schrieb Daniel Leidert:
> > Am Samstag, den 14.07.2007, 12:44 -0400 schrieb Joey Hess:
> > > Until there is one, I don't see any reason why I should accept patches
> > > adding menu files to my packages.
> > 
> > The .desktop format is not only about the menu item itself. It also
> > contains the application <-> MIME/file type association information. The
> > update-desktop-database then parses all .desktop files and creates this
> > database (/usr/share/applications/mimeinfo.cache). AFAIK KDE 3 uses this
> > system, his own system and the old system via /usr/lib/mime (metamail,
> > right?). But GNOME AFAIK only uses the current shared MIME info
> > database.
> 
> Which mean, over the half of the .desktop files would be useless for peoples
> NOT USING KDE or Gnome.

This is wrong. There are many other systems that make use of these
_cross-desktop_ specifications, written to unify the ways, the different
environments handled these things in the past (e.g. current browser use
this information to know, which applications to use for a MIME type; but
there are many other systems and implementation to use these information
- not only written for GNOME/KDE/XFCE). Further my point was, that .menu
only contains a subset of information a .desktop file contains and that
the conversion into .desktop files will be very limited.

> However, I support ONE fileformat since maintaining
> a .menu AND A .desktop file costs some nerv specialy, if you can not use/test
> the .desktop files.

There are test applications for .desktop files. And PS: That something
is getting on your nerves is not a compelling argument.

> So if "menu" use the .desktop files as input, it would be good.

Yes, that would be possible. However I think, that this only makes more
work that simply switching the Debian .menu file format into
the .desktop format too.

> > > Generating both menu and .desktop files from a third format would be
> > > pointless. Either format can be generated from the other format.
> > 
> > No. The Debian menu entries do not contain the information about which
> > MIME/file types can be handled nor in which menus the entry should
> 
> This is right, but WM's which do not use .desktop files do they support
> those mime stuff?  --  AFAIK no.

A pretty silly argument. I was talking about the conversion of
Debian's .menu files into fd.o .desktop files. Can you please tell me,
which WMs support or use Debian's .menu files or it's features? Right:
We are talking about a Debian internal system.

> > occur. The Debian menu items also do not contain the information, how to
> 
> ???  --  What do you mean, with "in which entry they should occur"?

OnlyShowIn, NotShowIn, Categories - Debian .menu files do not follow the
"Desktop Entry Specification" and do not contain the Categories
information from the specification, beginning with the fact, that there
is no 'Application' category, because it's very useless - the Type key
tells, if the .desktop file is for an application.

> The "Menu System" have the "section=" which is, WHERE the item occur.

The Debian menu sections are differently organised and use different
categories. E.g. Application(s) is not registered category in the
"Desktop Menu Specification". 

> > handle the arguments when calling the program from e.g. nautilus to open
> 
> Does this work under "fvwm" too?  AFAIK no.

We speak about a cross-desktop specification, that was written to unify
the systems on the desktops. Also current KDE 3 doesn't fully support
all specs, but KDE 4 will. So I cannot tell you, if or when fvwm (parts)
will follow the specs, but I can tell you, that using fvwm as argument
here, is pretty useless. I was talking about the limitation of
converting the different formats. And applications using the extended
features of the .desktop format will more suffer from the limited
conversion than applications/systems _not_ using _any_ parts of the
specifications. But these systems also will not loose anything by
dropping the Debian .menu file format in favour of the .desktop file
format. I wasn't talking about removing the Debian menu in favour of the
GNOME/KDE/XFCE menus.

> > a special file. And I don't want to start to tell about the "action"
> > section possibilities ;) However, the formats only share some basic
> > information, but the .desktop format contains much more information,
> > than the Debian menu item files. You may be able to create a Debian menu
> > file from the .desktop file. But the other way would be very useless.
> 
> It depends, whether the apps SHOULD be run from GNOME/KDE or not.

This is wrong and I already explained why. And even a limited .desktop
file would only work on the systems, where the .desktop format is
supported (including Debian's internal menu). So what is your argument?

> For many (most of my) apps, I do not need any mime stuff and such.

And this is the compelling argument agai

Re: adding desktop files to misc packages

[Don Armstrong]

On Fri, 20 Jul 2007, Michelle Konzack wrote:
> The last sentence makes no sense, because WM's do not depend on the
> "Menu System". They only Recommends or Suggests "menu". So you can
> not drop anything.

I'm talking about droping the 'Debian menu' here, not droping
dependencices on 'the menu system'.


Don Armstrong

-- 
I leave the show floor, but not before a pack of caffeinated Jolt gum
is thrust at me by a hyperactive girl screaming, "Chew more! Do more!"
The American will to consume more and produce more personified in a
stick of gum. I grab it.
 -- Chad Dickerson

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Michelle Konzack]

Am 2007-07-15 22:57:10, schrieb Daniel Leidert:
> Am Samstag, den 14.07.2007, 12:44 -0400 schrieb Joey Hess:
> > Until there is one, I don't see any reason why I should accept patches
> > adding menu files to my packages.
> 
> The .desktop format is not only about the menu item itself. It also
> contains the application <-> MIME/file type association information. The
> update-desktop-database then parses all .desktop files and creates this
> database (/usr/share/applications/mimeinfo.cache). AFAIK KDE 3 uses this
> system, his own system and the old system via /usr/lib/mime (metamail,
> right?). But GNOME AFAIK only uses the current shared MIME info
> database.

Which mean, over the half of the .desktop files would be useless for peoples
NOT USING KDE or Gnome.  However, I support ONE fileformat since maintaining
a .menu AND A .desktop file costs some nerv specialy, if you can not use/test
the .desktop files.

So if "menu" use the .desktop files as input, it would be good.

> > Generating both menu and .desktop files from a third format would be
> > pointless. Either format can be generated from the other format.
> 
> No. The Debian menu entries do not contain the information about which
> MIME/file types can be handled nor in which menus the entry should

This is right, but WM's which do not use .desktop files do they support
those mime stuff?  --  AFAIK no.

> occur. The Debian menu items also do not contain the information, how to

???  --  What do you mean, with "in which entry they should occur"?

The "Menu System" have the "section=" which is, WHERE the item occur.

> handle the arguments when calling the program from e.g. nautilus to open

Does this work under "fvwm" too?  AFAIK no.

> a special file. And I don't want to start to tell about the "action"
> section possibilities ;) However, the formats only share some basic
> information, but the .desktop format contains much more information,
> than the Debian menu item files. You may be able to create a Debian menu
> file from the .desktop file. But the other way would be very useless.

It depends, whether the apps SHOULD be run from GNOME/KDE or not.
For many (most of my) apps, I do not need any mime stuff and such.

> > menu
> > already generates .desktop files from menu files, and I don't believe it
> > would be too hard to make menu _read_ .desktop files directly and use it
> > as a source for the other files it generates.
> 
> This may be possible. Maybe the Debian menu file format should follow
> the freedesktop.org specification too and contain something like:
> 
> NoDisplay=true
> X-Debian_only=true
> 
> to show, that the item should only appear in the Debian menu. Then put
> these files into e.g. /usr/share/applications/debian and drop the old
> menu format in /usr/share/menu. This is just one possible solutions to
> the situation (not an recommendation).

This could be a solution :-)

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Michelle Konzack]

Am 2007-07-14 10:55:00, schrieb Bernhard R. Link:
> * Josselin Mouette <[EMAIL PROTECTED]> [070713 23:44]:
> > IMO the Debian menu should be entirely deprecated unless something
> > serious is done about it. Currently:
> >   * It is utterly and absolutely ugly. 32x32 XPM icons are not
> > matching the graphic quality we have on the rest of the desktop.
> 
> Then just add larger or any other icons (in appropiate additional fields).
> One of my packages already has a 64x64 icon. Currently no window manager
> user it, but if I would use any window manager showing icons and not
> scaling them down to 16x16 it would be almost no efford to make them use
> them.

Mabe the "Debian Menu" or .desktop files should not only
support icon16 and icon32 but icon48 and icon64 too?

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Michelle Konzack]

Hi Don,

Am 2007-07-16 04:12:02, schrieb Don Armstrong:
> So it seems like we should do the following:
> 
> 1. Make changes to the menu system to use .desktop files in preference
> to .menu files when they exist
> 
> 2. Generate .desktop files from .menu files using the menu system when
> .desktop files don't exist.

This two would be realy good.

> 3. Continue using the menu system for window managers which don't
> natively understand .desktop files; drop the Debian menu for those
> that do.

The last sentence makes no sense, because WM's do not depend on the
"Menu System".  They only Recommends or Suggests "menu".  So you can
not drop anything.

If you have a WM which support .desktop files, this WM should not
Recommends/Suggests "menu".  All others which support menus should.

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Michelle Konzack]

Hello Neil,

Am 2007-07-15 14:11:55, schrieb Neil Williams:
> If all Gnome packages silently drop debian/menu in the next upload, is
> that actually going to be a problem for anyone?

Since WE (me, colegous and friends) do not use any GNOME/KDE Apps,
where will be no lost for us.

But maybe the KDE/GNOME menu files can be put into a seperated package
for those which do not RUN KDE/GNOME but some dedicated Apps?

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Michelle Konzack]

Am 2007-07-13 23:43:56, schrieb Josselin Mouette:
> Le vendredi 13 juillet 2007 à 16:54 -0400, Joey Hess a écrit : 
> > I've gotten some bug reports lately asking for desktop files to be added
> > to packages like xgalaga and kobodeluxe, and saw some others in the BTS.
> > All of these packages, of course, already include Debian menu files. But I 
> > don't understand what the rationalle is behind adding a desktop file to a
> > package that includes a Debian menu file and is not a Gnome/KDE component.
> 
> The Freedesktop.org menu is not meant to be limited to GNOME and KDE
> components.
> 
> IMO the Debian menu should be entirely deprecated unless something
> serious is done about it. Currently: 
>   * It is utterly and absolutely ugly. 32x32 XPM icons are not
> matching the graphic quality we have on the rest of the desktop.

Example?

>   * Its structure is impractical. Most important things are in
> Applications/, which adds a menu level with no use, and several
> submenus are useless.

Oh right, there are some Entries which can not be started form the "Menu
System" since they need at least a Parameter/Filename/XTerm and such...
For such Apps I have several times contacted the appropiated Maintainer
in the last 3 years, but nothing has changed...

This has something to do with busy or lazzy Maintainers and not the
"Menu System" itself.

>   * Most importantly, it is absolutely full of useless stuff.

Example?

> Why do we need a menu entry for each shell ? A user who wants another
> shell is most probably capable of running it himself.

How to start it form FVWM?

if I want a eTerm, and have only an entry vor XTerm schould I start
an XTerm and from the XTerm my eTerm?  --  Sounds a little bit Weird.

> A menu entry for each window manager? WTF? We can select them from the
> display manager now.

And if you do now want to logout and ONLY replace the actual WM?
(fvwm support it)

Oh yes, some of the fvwm Module entries are currently definitiv useless,
but they can be improved, since zou can load modules as you need it.
(You can create a config for it and then if you need it start it from
the "Menu System" which does not work for most Modules in the current
form)

> A menu entry for yelp? It is already accessible from all applications
> needing it and from the GNOME panel.

I have no GNOME and starting a terminal with "info" or the xman is in
the Section "Help" right placed.

> An entry for each python/TCL/guile interpreter on the system? Can't
> developers use terminals? 

I found it usefull to runn a Python 2.3 and 2.4 shell or the Tclsh 8.4.

> An entry for each of the bsdgames? For nano? For so many terminal
> applications that you want to run, well, in a terminal?

Yes, since for most are no GUI applications if you NOT use KDE/GNOME.
OK, BSD games schould not be realy there (never used and I do not know...)

> Apart from a few games (see the initial request you were faced with), I
> can't find anything in the Debian menu which is neither already in the
> GNOME menu at a better place, or simply completely unsuitable for a
> graphical menu.

But what about peoples which do not RUN GNOME/KDE?

Most of the peoples I know, do not use such DE's AND WE use High-End
Machines where we can run 10 Gnome/KDE Installations in parallel without
seeing a perforance problem...

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Michelle Konzack]

Hello Joey,

Am 2007-07-13 18:02:18, schrieb Joey Hess:
> Bastian Venthur wrote:
> You should be able to do this on your own system by editing
> /etc/menu-methods/translate_menus.
> 
> But.. The Appications menu can already have up to 23 submenus, and already
> grows beyond 10 on many typical systems. Rather and moving it up and so
> having an enormous root menu with 15-30 items, it would be good to
> reduce the number of items already in it closer to 10 via deeper tree
> structure or more reorganisation. Bearing in mind that menu can flatten
> unnecessarily deeper tree structures if the tree is lightly populated.

I have nearly the same problem with 16 submenus in Apps.

But the bigger problem is, that some applications have "titles"
for applications which go over 1/3 of a 1024x768 screen mostly
Openoffice Apps like "Openoffice.org Printer Administration"
where the menu has a width of 372 pixels which is realy annoying.

> > Besides that, from my naive-user's point of view I wonder why my menu
> > has so many redundant entries? Maybe we could get rid of the Debian menu

I have never seen a redunant menu entry since I use "fvwm"
and have over 1400 entries in the Debian Menu System.


Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Michelle Konzack]

Am 2007-07-13 23:49:29, schrieb Josselin Mouette:
> Le vendredi 13 juillet 2007 à 17:30 -0400, Joey Hess a écrit :
> > There are probably enhancements that would let it create _better_
> > .desktop files. For example, ones with translations..
> 
> Ah, right. I forgot translations. Another good reason to drop the Debian
> menu system.

And if someone does not use KDE/GNOME for ANY reason?

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le jeudi 19 juillet 2007 à 10:28 +0900, Charles Plessy a écrit :
> PS : what is wrong with XPM ? If it is inferior to PNG, I can convert
> the icons in the packages I maintain. But XPM is a text file, which is
> convenient since we (unfortunately) use this .diff.gz which requires to
> uuencode any binary addition to a package.

XPM has only a 1bit alpha channel. This makes a very important visual
difference, especially when it gets downsized to 22x22.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: adding desktop files to misc packages

[Charles Plessy]

Le Wed, Jul 18, 2007 at 07:32:28PM +0200, Josselin Mouette a écrit :
> 
> > The Debian menu system will generate .desktop files from .menu files if the 
> > .desktop file does not exist. This is intended solely
> > as a temporary compatibility measure.
> 
> This is a very bad idea. It is going to clutter the freedesktop menu
> with tons of useless entries with ugly icons and make it as useless as
> the Debian menu. Please don't do that, and take the opportunity to
> enforce stricter rules about what should be in the menu. If this is
> done, the policy changes you are suggesting will just be ignored.

In the end, there will not be a big difference if the generation of the
.desktop files will be made by human or computer, provided that there is
no information on what the GNOME, KDE, and XFCE teams want or do not
want in their menu. The tool for hiding entries exists. All we need is
information. In the absence of information, yes, ugly icons and menu
entries opening terminals to run interactive command-line programs will
appear.

PS : what is wrong with XPM ? If it is inferior to PNG, I can convert
the icons in the packages I maintain. But XPM is a text file, which is
convenient since we (unfortunately) use this .diff.gz which requires to
uuencode any binary addition to a package.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Russ Allbery]

Magnus Holmgren <[EMAIL PROTECTED]> writes:
> On Wednesday 18 July 2007 19:44, Russ Allbery wrote:

>> Surely any proposal for replacing the menu system with desktop files
>> has to involve generating menu files from desktop files for the benefit
>> of programs that use the menu system and don't understand desktop
>> files?

> Eh, correct me if I'm wrong, but surely the way it works is that
> install-menu and the various menu-method provided by window/desktop
> manager packages to convert the set of menu files into the native menu
> configuration formats of those window/desktop managers? install-menu
> would now be improved to read .desktop files directly; there is no need
> to convert them into .menu files first (and really no reason to convert
> .menu to .desktop either).

Yes, good point, although I'm worried that it's going to take a while to
rewrite that code to convert .desktop files instead, and converting
.desktop to .menu would give us interim backward compatibility.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Magnus Holmgren]

On Wednesday 18 July 2007 19:44, Russ Allbery wrote:
> Surely any proposal for replacing the menu system with desktop files has
> to involve generating menu files from desktop files for the benefit of
> programs that use the menu system and don't understand desktop files?

Eh, correct me if I'm wrong, but surely the way it works is that install-menu 
and the various menu-method provided by window/desktop manager packages to 
convert the set of menu files into the native menu configuration formats of 
those window/desktop managers? install-menu would now be improved to 
read .desktop files directly; there is no need to convert them into .menu 
files first (and really no reason to convert .menu to .desktop either).

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)

  "Exim is better at being younger, whereas sendmail is better for 
   Scrabble (50 point bonus for clearing your rack)" -- Dave Evans


pgpxyCJQ8X0T7.pgp
Description: PGP signature

Re: adding desktop files to misc packages

[Russ Allbery]

Josselin Mouette <[EMAIL PROTECTED]> writes:
> Le mercredi 18 juillet 2007 à 12:57 -0400, Joe Smith a écrit :

>> The Debian menu system will generate .desktop files from .menu files if
>> the .desktop file does not exist. This is intended solely as a
>> temporary compatibility measure.

> This is a very bad idea.

Uh, this is already done, no?  This is merely documentation, as I see it,
of the current state and a note that we shouldn't drop that support until
after we've finished the transition.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: adding desktop files to misc packages

[Russ Allbery]

"Joe Smith" <[EMAIL PROTECTED]> writes:

> To formalize this as a proposal:

[...]

Surely any proposal for replacing the menu system with desktop files has
to involve generating menu files from desktop files for the benefit of
programs that use the menu system and don't understand desktop files?

The way I expect a transition would go, assuming we decide it's a good
idea, would be:

 * We write a clear specification for what goes into a .desktop file from
   a Debian perspective, which can mostly be a reference to the
   freedesktop.org documentation of the format if that's adequate but
   probably involves at least some discussion of the menu hierarchy from a
   Debian integration perspective.  We also need a policy on what packages
   should create desktop files and if some packages should create desktop
   files that aren't shown by default or some other similar magic.  This
   is the *first* step.

 * The menu code is modified to generate menu files from desktop files if
   a desktop file exists and no menu file exists.

 * Only *then* are packages encouraged to start switching from menu files
   to desktop files, to avoid unnecessary duplication of information in
   the packages.

 * We then track progress on adding desktop files with the *long term*
   goal (+2 releases, realistically) of dropping the generation of desktop
   files from the old menu format.

The first step is vital and hasn't happened yet, and would be useful even
in the absence of a decision to do an overall transition.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mercredi 18 juillet 2007 à 12:57 -0400, Joe Smith a écrit :
> Given that .desktop is a standardized file format, and is roughly a superset 
> of the current .menu format,
> the Debian menu system will add support reading .desktop files as source in 
> addition to the .menu files.

This is feasible, but not as easy as you seem to imply. For example you
have to generate 32x32 XPM files (har har har) from the icons, which can
be different depending on the icon theme and located at different
places.

> When both a .desktop file and a .menu file exists the .desktop file takes 
> precedence.

Fine, but you'll have a hard time isolating duplicates.

> The Debian menu system will generate .desktop files from .menu files if the 
> .desktop file does not exist. This is intended solely
> as a temporary compatibility measure.

This is a very bad idea. It is going to clutter the freedesktop menu
with tons of useless entries with ugly icons and make it as useless as
the Debian menu. Please don't do that, and take the opportunity to
enforce stricter rules about what should be in the menu. If this is
done, the policy changes you are suggesting will just be ignored.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: adding desktop files to misc packages

[Joe Smith]

"Joe Smith" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]


"Don Armstrong" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

So it seems like we should do the following:

1. Make changes to the menu system to use .desktop files in preference
to .menu files when they exist

2. Generate .desktop files from .menu files using the menu system when
.desktop files don't exist.

3. Continue using the menu system for window managers which don't
natively understand .desktop files; drop the Debian menu for those
that do.

The other issue that was brought up was improving the hierarchical
organization of the menus, but how to do that hasn't been made clear
in this thread.



That is exactly the correct thing to do. It has the advantage of basically 
converting Debian to the stardard FDO .desktop format.
It also effectively adds limited support for the FDO format to the other 
window managers (the menu system would be converting the .desktop files of 
any installed package automatically).


Of course one of the keys to this transition would be to eventually 
depreciate the .menu files. If the menu system can read the .desktop files 
then there would be no reason to keep the .menu format around long term, 
but it would need to stay temporally as part of the transition.


To formalize this as a proposal:
-BEGIN PROPOSAL-
Given that .desktop is a standardized file format, and is roughly a superset 
of the current .menu format,
the Debian menu system will add support reading .desktop files as source in 
addition to the .menu files.


When both a .desktop file and a .menu file exists the .desktop file takes 
precedence.


The Debian menu system will generate .desktop files from .menu files if the 
.desktop file does not exist. This is intended solely

as a temporary compatibility measure.

The .menu format is depreciated. Lintian should add a check warning about 
packages that include a .menu file but no .desktop file. Maintainers are 
encouraged to replace the .menu file with a full .desktop file, conformant 
with the "Desktop Menu Specification" and the "Desktop Entry Specification". 
However, once a revised Debian menu policy has been adopted, the files 
should conform with policy in any case where policy contradicts those 
specifications.


Windows managers that support the "Desktop Menu Specification" should stop 
including the Debian menu, as all its entries would be available as .desktop 
files.


A revised menu policy should be drafted. It should indicate when a package 
requires a .desktop file, and when it would not require a desktop file. It 
should also specify which types of menu entries should default to 
NoDisplay=True. If extensions to the .desktop format are desired, such as to 
implement a roles based system for determining which entries appear in the 
menu, this would be to document which should specify the extension. Finally 
the document may amend the "Desktop Menu Specification" hierarchy, if it is 
determined that a change to that hierarchy would be benifical to the users.

-END PROPOSAL-


Comments? 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]