Re: adding desktop files to misc packages
Russ Allbery
> Assuming that's accurate, I don't understand why we would want to add
> desktop files to lots of non-Gnome, non-KDE applications such as xgalaga
> and kobodeluxe[1]. It seems that if we added desktop files for
> _everything_, the abovementioned benefits would basically be lost. And
> we'd have to maintain both desktop files and Debian menu files for
> _everything_, which turns the abovementioned technical infelicity from
> not very nice but manageable on a small scale, to a gobal PITA.
A related question that I've been wanting to ask for a while: is it
possible to automatically generate desktop files from the menu files?
If not, should we be enhancing the menu format so that we can?
That feels like it might give us the best of both worlds, although desktop
environments are not an area of expertise for me and I may be missing
something fairly obvious.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Joey Hess
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.
My understanding is that in both Gnome and KDE, the main menu is created
based on the desktop files, and in both environments, we have a "Debian"
menu with the regular Debian menu system in it, based on the Debian menu
files.
This division, while not IMHO technically very nice, helps the
consistency and usability of the desktop environments, since the most
accessible menu items are those from the desktop files for that
particular desktop environment. To find some strange program that is not
a Gnome (or KDE) program, the user has to go spelunking in the depths of
the Debian menu structure.
Assuming that's accurate, I don't understand why we would want to add
desktop files to lots of non-Gnome, non-KDE applications such as xgalaga
and kobodeluxe[1]. It seems that if we added desktop files for
_everything_, the abovementioned benefits would basically be lost. And
we'd have to maintain both desktop files and Debian menu files for
_everything_, which turns the abovementioned technical infelicity from
not very nice but manageable on a small scale, to a gobal PITA.
--
see shy jo
[1] Bear in mind that they're not just non-Gnome/KDE, but relatively
ancient and nonintuitive, though fun, programs.
Bastian Venthur
> Assuming that's accurate, I don't understand why we would want to add
> desktop files to lots of non-Gnome, non-KDE applications such as xgalaga
> and kobodeluxe[1]. It seems that if we added desktop files for
> _everything_, the abovementioned benefits would basically be lost. And
> we'd have to maintain both desktop files and Debian menu files for
> _everything_, which turns the abovementioned technical infelicity from
> not very nice but manageable on a small scale, to a gobal PITA.
Personally, I don't use the Debian menu at all. All the important apps I
use have a proper menu entries outside of the Debian menu or are
terminal applications which don't need a menu entry.
The most annoying part of our Debian menu is, that it is too
complicated. The first level with the entries: Apps, Screen, Help, Games
and X-Shells is pretty useless, and adds unnecessary depth to the menu
tree. It would be a major improvement if we would move the Apps section
to the root of the tree and sort the remaining sections (Screen, Help,
Games and X-Sheels) *into* this section. That would reduce the depth of
the menu tree by one, and would be a huge improvement of usability.
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
completely and just use the underlying system to create proper desktop
files for packages not providing their own?
Cheers,
Bastian
--
Bastian Venthur http://venthur.de
Debian Developer venthur at debian org
Joey Hess
> A related question that I've been wanting to ask for a while: is it
> possible to automatically generate desktop files from the menu files?
Yes, that's how Gnome and KDE get the Debian menu items in their menus.
:-) See /etc/menu-methods/xdg-desktop-entry-spec-apps and
/var/lib/menu-xdg/applications/menu-xdg
(On my system, FWIW, I have 239 .desktop files in
/usr/share/applications and 715 in /var. So most Debian packages arn't
including redundant .desktop files yet -- although I see a lot of
desktop-agnostic ones like xterm and xmms that already do.
> If not, should we be enhancing the menu format so that we can?
There are probably enhancements that would let it create _better_
.desktop files. For example, ones with translations..
--
see shy jo
Russ Allbery
> Russ Allbery wrote:
>> A related question that I've been wanting to ask for a while: is it
>> possible to automatically generate desktop files from the menu files?
> Yes, that's how Gnome and KDE get the Debian menu items in their menus.
> :-) See /etc/menu-methods/xdg-desktop-entry-spec-apps and
> /var/lib/menu-xdg/applications/menu-xdg
> (On my system, FWIW, I have 239 .desktop files in
> /usr/share/applications and 715 in /var. So most Debian packages arn't
> including redundant .desktop files yet -- although I see a lot of
> desktop-agnostic ones like xterm and xmms that already do.
Okay, so it is redundant information that people are asking you to
include? Basically another copy of the desktop file already generated by
the menu system but installed in a different location in the menu
hierarchy?
I suppose the reason why we're stuck with both is that upstream ships
their own .desktop files when the application is actually part of Gnome.
Josselin Mouette
> 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.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
Darren Salt
[snip]
> The most annoying part of our Debian menu is, that it is too complicated.
> The first level with the entries: Apps, Screen, Help, Games and X-Shells is
> pretty useless, and adds unnecessary depth to the menu tree. It would be a
> major improvement if we would move the Apps section to the root of the tree
> and sort the remaining sections (Screen, Help, Games and X-Sheels) *into*
> this section. That would reduce the depth of the menu tree by one, and
> would be a huge improvement of usability.
All five already are at the top level in my customised Xfce menu; for me,
your proposal would increase the depth by one level for all but Apps.
[snip]
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Generate power using sun, wind, water, nuclear. FORGET COAL AND OIL.
"First get your facts; then you can distort them at leisure." - Mark Twain
Josselin Mouette
> 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.
* Its structure is impractical. Most important things are in
Applications/, which adds a menu level with no use, and several
submenus are useless.
* Most importantly, it is absolutely full of useless stuff.
Why do we need a menu entry for each shell ? A user who wants another
shell is most probably capable of running it himself.
A menu entry for each window manager? WTF? We can select them from the
display manager now.
A menu entry for yelp? It is already accessible from all applications
needing it and from the GNOME panel.
An entry for each python/TCL/guile interpreter on the system? Can't
developers use terminals?
An entry for each of the bsdgames? For nano? For so many terminal
applications that you want to run, well, in a terminal?
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.
Cheers,
Joey Hess
> Personally, I don't use the Debian menu at all. All the important apps I
> use have a proper menu entries outside of the Debian menu or are
> terminal applications which don't need a menu entry.
I forgot to ask if the people filing bugs with .desktop files intend to
eventually just do away with the Debian menu system. If so it would be
good to make that explicit. I'm looking for _any_ kind of explicit
rationalle or coordinated change.
> The most annoying part of our Debian menu is, that it is too
> complicated.
This is probably true of any menu system when it's scaled up to anywhere
near the number of menu entries and breadth/depth of applications as
Debian's[1].
In the long run, big menus of all the possible programs all obsolete
anyway. A better interface is a tool that helps you search for programs,
and then remembers programs that you've used so you can quickly
re-access them. The command line has been doing this for decades;
desktops are only just starting to catch on to the idea. (And of course
Enrico is several leaps beyond it with some debtags stuff.)
> The first level with the entries: Apps, Screen, Help, Games
> and X-Shells is pretty useless, and adds unnecessary depth to the menu
> tree. It would be a major improvement if we would move the Apps section
> to the root of the tree and sort the remaining sections (Screen, Help,
> Games and X-Sheels) *into* this section.
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.
> 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
> completely and just use the underlying system to create proper desktop
> files for packages not providing their own?
Only problem with that idea, besides .desktop layout likely not scaling
any better than the Debian one, is the large set of window managers and
other programs that are supported by the Debian menu system and don't
understand .desktop files. Of course .desktop files could theoretically
be used as _input_ for the menu system.
--
see shy jo
[1] Disclaimer; I was heavily involved in the initial design of Debian's
menu system.
Joey Hess
> Okay, so it is redundant information that people are asking you to
> include? Basically another copy of the desktop file already generated by
> the menu system but installed in a different location in the menu
> hierarchy?
Well, essentially. xgalaga's menu item generates this desktop file:
[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=Galaga
GenericName=
Comment=
Icon=/usr/share/pixmaps/xgalaga-icon.xpm
Exec=/usr/games/xgalaga
Terminal=false
Categories=X-Debian-Games-Action
Bug #432398 asks me to include this desktop file in the package:
[Desktop Entry]
Name=XGalaga
Comment=Play Galaga Game
Exec=xgalaga
Icon=xgalaga-icon.xpm
Terminal=false
Type=Application
Categories=Game;
Besides using gratuitiously different menu labels for the same game,
it really doesn't seem to add much information, does it? Only real
difference is it won't be hidden in the Debian menu ghetto.
> I suppose the reason why we're stuck with both is that upstream ships
> their own .desktop files when the application is actually part of Gnome.
Yes, I'm also unsure what I should do in such cases. For example, my
just-uploaded fbreader package has a desktop file from upstream, and is
part of neither Gnome nor KDE (though it can use a gtk or qt interface).
I don't know if I should include its desktop file in it or not.
--
see shy jo
Roger Leigh
> Joey Hess <jo...@debian.org> writes:
>
>> Assuming that's accurate, I don't understand why we would want to add
>> desktop files to lots of non-Gnome, non-KDE applications such as xgalaga
>> and kobodeluxe[1]. It seems that if we added desktop files for
>> _everything_, the abovementioned benefits would basically be lost. And
>> we'd have to maintain both desktop files and Debian menu files for
>> _everything_, which turns the abovementioned technical infelicity from
>> not very nice but manageable on a small scale, to a gobal PITA.
>
> A related question that I've been wanting to ask for a while: is it
> possible to automatically generate desktop files from the menu files?
>
> If not, should we be enhancing the menu format so that we can?
Or, perhaps an even better approach would be to swap that idea around
and create the menu files from the desktop files, so that we get the
benefits of the desktop file format, and also allow older systems
supported by the Debian menu system to gain access to them. Perhaps
systems patched to use the Debian menu system could be updated to
support the menu files directly?
I have also wondered for a year or more now if the continuation of
Debian menu is largely NIH now that there is a cross-distribution,
cross-desktop standardised menu system which we could (presumably)
compatibly upgrade the menu system to use if we so chose, and then
eventually retire it completely if possible.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Joey Hess
> The Freedesktop.org menu is not meant to be limited to GNOME and KDE
> components.
But how well does it scale, if you put a random sampling of about 700 menu
items (about the quantity in my laptop's Debian menu) in it? Does it
become a total disaster and mess in which I can't find
$IMPORTANT_GOME_APP when I'm using Gnome, or is this somehow dealt with?
> IMO the Debian menu should be entirely deprecated unless something
> serious is done about it.
Well, I'm not particularly arguing against that. I am, however, asking
that if we decide to do it, we _decide_ and then _do_it_. Currently,
without rationalle, lots of maintainers are being asked to add redundant
info to their packages in the form of .desktop files. As such a
maintainer, I have a hard time telling if doing so is the right thing
for me to be doing right now, or if it will just add work and clutter up
Gnome's menu with my insignificant games and esoteric GUI apps.
Just filing a bunch of bugs with patches will tend to have scattershot
results, and will not get any scaling/organisation/design issues with
using the FDo menus anticipated and dealt with ahead of time.
> * Most importantly, it is absolutely full of useless stuff.
This seems to argue that if we throw out menu and add .desktop files, we
will only want to add them for some things. Which things, and how do we
decide what? Without some clear direction as to what's appropriate to
add, the way I see it heading is that we'll get .desktop files for maybe
50% of the same useless stuff.
> Why do we need a menu entry for each shell ? A user who wants another
> shell is most probably capable of running it himself.
Granted.
> A menu entry for each window manager? WTF? We can select them from the
> display manager now.
Some of us like to change WMs without closing our 50 xterms. This is a
very nice feature of the current system, actually.
> A menu entry for yelp? It is already accessible from all applications
> needing it and from the GNOME panel.
Granted. So, why does yelp have a desktop file too, then?
> An entry for each python/TCL/guile interpreter on the system? Can't
> developers use terminals?
Granted.
> An entry for each of the bsdgames?
> For nano? For so many terminal applications that you want to run, well,
> in a terminal?
Some of us like to set up dumb terminals from which users can select the
bsdgames and other terminal apps from a menu such as pdmenu. As a
typically overdesigned Debian sytem, the menu system caters to that. :-)
Note that it also allows _excluding_ all such text-based menu items from
a menu, so if we don't want them in Gnome, we could remove them from its
menus.
> Apart from a few games (see the initial request you were faced with),
Which few exactly?
> 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.
If that's actually true, we could drop menu from the gnome-desktop and
kde-destkop tasks. (What about XFCE?)
--
see shy jo
Russ Allbery
> 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.
This seems like a reasonable complaint to me.
> * Its structure is impractical. Most important things are in
> Applications/, which adds a menu level with no use, and several
> submenus are useless.
Switching to .desktop files doesn't inherently fix this. We still have to
figure out a coherent structure. I assume you're aware of the work
currently going on to restructure the menu hierarchy.
> * Most importantly, it is absolutely full of useless stuff.
Well, neither Policy nor Menu Policy offers any guidance on what should
have a menu entry and what shouldn't, so this isn't surprising. Switching
to .desktop files won't fix this either if people create .desktop files
for all the things you don't think should have them.
It seems to me like a productive way forward on this point would be to
develop a policy on what should have menu entries and what shouldn't and
add that policy to the existing Menu Policy document.
Otherwise, packagers of new shells, for example, will look at existing
shell packages, see a menu entry, and assume they should add one in the
absence of guidance otherwise.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Josselin Mouette
> But how well does it scale, if you put a random sampling of about 700 menu
> items (about the quantity in my laptop's Debian menu) in it? Does it
> become a total disaster and mess in which I can't find
> $IMPORTANT_GOME_APP when I'm using Gnome, or is this somehow dealt with?
We can use additional keywords in the desktop entries to get them sorted
in sub-menus when appropriate, but many desktop files are not tagged
correctly. As you can see in the specification [0], all categories we
need should be here, so if we tag desktop files appropriately, the
generated menu should be usable.
> Well, I'm not particularly arguing against that. I am, however, asking
> that if we decide to do it, we _decide_ and then _do_it_. Currently,
> without rationalle, lots of maintainers are being asked to add redundant
> info to their packages in the form of .desktop files. As such a
> maintainer, I have a hard time telling if doing so is the right thing
> for me to be doing right now, or if it will just add work and clutter up
> Gnome's menu with my insignificant games and esoteric GUI apps.
Unless an application is included in a task, you can expect that people
installing it want it in their menu.
> This seems to argue that if we throw out menu and add .desktop files, we
> will only want to add them for some things. Which things, and how do we
> decide what? Without some clear direction as to what's appropriate to
> add, the way I see it heading is that we'll get .desktop files for maybe
> 50% of the same useless stuff.
Yes, this is a problem. Just like the debconf situation some time ago,
it probably requires people hunting the abusing packages with a cluebat.
> > A menu entry for each window manager? WTF? We can select them from the
> > display manager now.
>
> Some of us like to change WMs without closing our 50 xterms. This is a
> very nice feature of the current system, actually.
Oh my. Do you mean that in the 90 window managers shipped in Debian,
none of them is suitable for all your needs and that you have to use
*several* ones depending on the moment?
> > A menu entry for yelp? It is already accessible from all applications
> > needing it and from the GNOME panel.
>
> Granted. So, why does yelp have a desktop file too, then?
It brings the icon in the panel's system menu.
> > Apart from a few games (see the initial request you were faced with),
>
> Which few exactly?
Depends on what I'm playing at the moment. Currently that would be
neverball and noiz2sa.
> > 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.
>
> If that's actually true, we could drop menu from the gnome-desktop and
> kde-destkop tasks. (What about XFCE?)
I think we should do that as soon as most relevant packages ship
their .desktop file, yes.
[0] http://standards.freedesktop.org/menu-spec/latest/apa.html
Steve Langasek
> > > A menu entry for each window manager? WTF? We can select them from the
> > > display manager now.
> > Some of us like to change WMs without closing our 50 xterms. This is a
> > very nice feature of the current system, actually.
> Oh my. Do you mean that in the 90 window managers shipped in Debian,
> none of them is suitable for all your needs and that you have to use
> *several* ones depending on the moment?
Unix systems have supported selecting window managers on-the-fly for years
before Debian did it. Why does one extra entry for a submenu offend you so?
If a user submits a bug that requires a different wm to reproduce than the
one you normally use, isn't it nice to be able to switch wms for testing
without having to log out or start a second X session?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vor...@debian.org http://www.debian.org/
Josselin Mouette
> > Oh my. Do you mean that in the 90 window managers shipped in Debian,
> > none of them is suitable for all your needs and that you have to use
> > *several* ones depending on the moment?
>
> Unix systems have supported selecting window managers on-the-fly for years
> before Debian did it. Why does one extra entry for a submenu offend you so?
I'm wondering what is the use case for that entry.
> If a user submits a bug that requires a different wm to reproduce than the
> one you normally use, isn't it nice to be able to switch wms for testing
> without having to log out or start a second X session?
I can imagine someone dealing with such a case (although I'd personally
start a new session to better match the user's environment) but I don't
think this justifies adding these entries to all users' menus.
Joey Hess
> We can use additional keywords in the desktop entries to get them sorted
> in sub-menus when appropriate, but many desktop files are not tagged
> correctly. As you can see in the specification [0], all categories we
> need should be here, so if we tag desktop files appropriately, the
> generated menu should be usable.
Oddly, the specification nearly exactly mirrors the despised
Debian menu system, as far as the categorisation of games goes:
FDo menu Debian menu
ActionGame Games/Action
AdventureGame Games/Adventure
ArcadeGame Games/Arcade [1]
BoardGame Games/Board
BlocksGame Games/Blocks (was Games/Tetris-like until recently)
CardGame Games/Card
KidsGame
LogicGame Games/Puzzles
RolePlaying
Simulation Games/Simulation
SportsGame
StrategyGame Games/Strategy
So if we're missing a lot of .desktop files for games, why not have menu
generate .desktop files for all games that put them in the Gnome/KDE
menus, outside of the Debian menu? How is adding desktop files to all
the games that have menu files a good use of our time, when we can get
to the same result with a simple code change?
I also notice that it offers a ConsoleOnly category (tag), that kinda
invalidates your earlier point about the Debian menus having too many
console apps in them. menu could simply put needs=text apps in the
ConsoleOnly category when generating .desktop files and they should be
hidden away in submenus.
> > > 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.
> > Which few exactly?
>
> Depends on what I'm playing at the moment. Currently that would be
> neverball and noiz2sa.
The best way to get menu dropped from the desktop tasks would be to show
that there's enough coverage in .desktop files that users won't be
installing many things and failing to find them in the menu.
That's a difficult analysis to make, IMHO. It could start by looking at
the lintian lab on gluck, and the Contents file, to come up with some
numbers for coverage in the whole of Debian:
FDo menu [2] Debian menu
total items 1525 3755
games 212 659
text mode 0 [3] 461
So, .desktop coverage of games is indeed not good. But neither is
general coverage. There are 1322 Debian menu items that are not for
text-mode programs, and not for games, and that don't seem to have a
corresponding .desktop file.
You've pointed out a few specific cases, like yelp, and some small
categories, like shells, window managers, and programming languages,
that shouldn't need desktop files. But these can't amount to more than
a few hundred menu items, surely.
It seems that you're still a ways off from your goal. IMHO the best way
to reach it would be to convince people that it's worth doing (I'm still
not convinced that it wouldn't be less work to improve the .desktop
files that menu generates), and then handle it as a transition, or
release goal, or something, rather than just filing bugs on individual
games as you fail to find them in the gnome menu.
--
see shy jo
[1] Recently retired in favour of Games/Action. Having both "action" and
"arcade" will probably lead to semi-random splits of games between the
two very similar categories, or games being put in both categories.
[2] Limited to ones in /usr/share/applications since all the other seem
to be for internal use by packages like app-install-data, or for
things generally not directly comprable to stuff the Debian menu is
used for.
[3] I didn't grep all the .desktop files to check, but I assume nearly
none are for text mode stuff, right?
Christian Perrier
Quoting Josselin Mouette (jo...@debian.org):
> 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.
Speaking about desktop files l10n, the current way to
translate them does not seem to scale very well to me.
From what I see in the dozens of .desktop files I have on my own
system, I see "Field[code]" fields for translations of "Field".
This is similar to what we had, in the past, for debconf templates and
we all known this doesn't scale and doesn't handle changes to English
strings very well.
I suppose that big projects like KDE and GNOME have setup their own
l10n infrastructure to localize these, but allowing the same to happen
with other .desktop files would be an interesting enhancement.
The same goes for menu entries.
So whatever choice is Good or Bad, there's an interesting problem to
work on: develop a gettext-based system to translate .desktop or .menu
files.
Indeed, it would be good to have something allowing such strings to go
in a debian/po directory, much similarly to what's currently done with
debconf templates. Then the translated .desktop or menu files would be
built at package build time from the original file and the set of
gettext translations in debian/po
Anyone feeling like digging into this problem?
Manoj Srivastava
>On Fri, 13 Jul 2007 23:43:56 +0200, Josselin Mouette <jo...@debian.org> said:
>> The Freedesktop.org menu is not meant to be limited to GNOME and KDE
>> components.
True enough. But my window manager, for one, does not
understand Freedesktop.org menu items, so what it is meant to be, and
what exists for users like me, is not the same.
>> IMO the Debian menu should be entirely deprecated unless something
>> serious is done about it. Currently:
> Well, I'm not particularly arguing against that. I am, however, asking
> that if we decide to do it, we _decide_ and then _do_it_.
Every window manager in Debian understands the Debian menu; and
this uniform acceptance is the primary reason, in my opinion, to not
deprecate the Debian menu system until we can replicate the
functionality.
>> * It is utterly and absolutely ugly. 32x32 XPM icons are not
>> matching the graphic quality we have on the rest of the
>> desktop.
While aesthetics are important, a regression in functionality
cannot make up for pretty interfaces.
>> * Most importantly, it is absolutely full of useless stuff.
If every package that currently provides a menu entry provided a
Freedesktop.org menu entry, this shall not change.
>> Why do we need a menu entry for each shell ? A user who wants another
>> shell is most probably capable of running it himself.
> Granted.
Hmm. I would think just about any application that can be
launched from a menu can be launched from the command line; so I am
missing something in this line of argument.
> 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.
Which is wonderful, if Debian were to only support Gnome in a
windowing environment.
manoj
--
There is no sin but ignorance. Christopher Marlowe
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Neil Williams
Christian Perrier <bub...@debian.org> wrote:
> (crossposted to -i18n)
> Speaking about desktop files l10n, the current way to
> translate them does not seem to scale very well to me.
>
> From what I see in the dozens of .desktop files I have on my own
> system, I see "Field[code]" fields for translations of "Field".
>
> This is similar to what we had, in the past, for debconf templates and
> we all known this doesn't scale and doesn't handle changes to English
> strings very well.
The strings used to generate translated .desktop entries can (should)
come from the upstream po/ directory via gettext - it can be handled
directly using gettext and make. All my upstream projects include all
translatable strings for the .desktop file in the .gmo (and therefore
the installed .mo) yet these also exist in the .desktop file that is
eventually installed. If an upstream package uses autofoo and does not
create a translated .desktop file for the .orig.tar.gz, that is (IMHO)
an upstream bug.
The thing is, that happens with debian/templates as well. Using
deb-gview, I can view any package that uses debconf with translations
in debian/po and the templates file in the .deb itself (part of
the control.tar.gz of the .deb) increases in size every time a new
translation is added to debian/po and contains long, long lists of
repeated translated strings. From an embedded perspective, I'd love to
lose this duplication:
debconf template (from emdebian-tools 0.3.0 .deb)
Description: Use apt-get to install toolchains?
emsetup can install toolchain packages for you using apt-get.
Alternatively, unset this option to use aptitude.
Description-cs.UTF-8: Použít pro instalaci nástrojů apt-get?
emsetup může automaticky nainstalovat balíky s nástroji pomocí
apt-get. Chcete-li použít aptitude, tuto možnost odmítněte.
Description-de.UTF-8: Soll apt-get zur Installation der Werkzeugkette
verwendet werden? Emsetup kann die Pakete der Werkzeugketten für Sie
mittels apt-get installieren. Alternativ lehnen Sie diese Option ab, um
Aptitude zu verwenden.
desktop file (from gpe-expenses .deb)
Comment=Simple Expenses records for GPE
Comment[cs]=Jednoduché záznamy o výdajích pro GPE
Comment[de]=Einfache Spesenaufzeichnung für GPE
Comment[pt]=Registos simples de Despesas para GPE
I'd agree that BOTH of these should be able to read the .mo just like
the application itself. I don't know if that is achievable. gettext
does support non-compiled implementations like Perl or PHP so there
should be some method of retrieving the strings directly from the .mo
so that both the debconf templates AND the .desktop file contain ONLY
the original "marked up" translatable strings and not the actual
translations. i.e. deal with .desktop and debconf in the same way as
the executable. gettext can do it - it works for PHP and Perl.
debconf template (from emdebian-tools 0.3.0 .deb)
_Description: Use apt-get to install toolchains?
emsetup can install toolchain packages for you using apt-get.
Alternatively, unset this option to use aptitude.
desktop file (from gpe-expenses .deb)
_Comment=Simple Expenses records for GPE
Or similar syntax to "markup" the strings:
debconf template (from emdebian-tools 0.3.0 .deb)
Description: _("Use apt-get to install toolchains?")
_("emsetup can install toolchain packages for you using apt-get.
Alternatively, unset this option to use aptitude.")
desktop file (from gpe-expenses .deb)
Comment=_("Simple Expenses records for GPE")
So I don't follow the logic above - AFAICT we still have the
debconf system that you describe as "in the past" - we just changed the
syntax. It is an improvement over Field[code] but it seems to me to be
an incomplete transition.
> So whatever choice is Good or Bad, there's an interesting problem to
> work on: develop a gettext-based system to translate .desktop or .menu
> files.
AFAICT what we need is the ability to retrieve the translated strings
from /usr/share/locale/$lang/LC_MESSAGES/$app.mo rather than copying
them en masse into /usr/share/applications/foo as well (and then doing
the same again in /usr/share/menu if we translate menu files too).
> Indeed, it would be good to have something allowing such strings to go
> in a debian/po directory, much similarly to what's currently done with
> debconf templates. Then the translated .desktop or menu files would be
> built at package build time from the original file and the set of
> gettext translations in debian/po
This is what I don't follow, Christian - I already do this upstream.
desktop/app.desktop.in.in can be preprocessed in packages using
autotools to handle gettext. The translated .desktop file is built at
package build time from the original file and the set of gettext
translations in the upstream po/ directory.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Ming Hua
>
> Quoting Josselin Mouette (jo...@debian.org):
> > 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.
>
> Speaking about desktop files l10n, the current way to
> translate them does not seem to scale very well to me.
>
> From what I see in the dozens of .desktop files I have on my own
> system, I see "Field[code]" fields for translations of "Field".
IIUC, these fields are (can be) automatically filled by intltool, using
the translations in PO files. So for translators the whole process is
transparent, they only need to deal with PO files.
> I suppose that big projects like KDE and GNOME have setup their own
> l10n infrastructure to localize these, but allowing the same to happen
> with other .desktop files would be an interesting enhancement.
The tool is there, it's just up to the individual software writer if
he/she wants to set up the infrastructure for translating desktop file.
[I am not subscribed to debian-devel, please cc: me if debian-i18n is
not crossposted.]
Ming
2007.07.14
--
To UNSUBSCRIBE, email to debian-i1...@lists.debian.org
Christian Perrier
> This is what I don't follow, Christian - I already do this upstream.
> desktop/app.desktop.in.in can be preprocessed in packages using
> autotools to handle gettext. The translated .desktop file is built at
> package build time from the original file and the set of gettext
> translations in the upstream po/ directory.
Hmm, this is indeed something I just wasn't aware of..:-)
Bernhard R. Link
> 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.
> * Its structure is impractical. Most important things are in
> Applications/, which adds a menu level with no use, and several
> submenus are useless.
That's a question of policy, not of the system. And actually arguing
about policy is in my eyes a point for menu files, as people are
supposed to read Debian policy to create it, and not blindly copying
other people's work, that are following (or even not following) some
other set of policy or another interpretation of policy.
> * Most importantly, it is absolutely full of useless stuff.
> A menu entry for each window manager? WTF? We can select them from the
> display manager now.
But if the display manager is only worth 2 cents, it's Debian default
configuration should get it from the place where all window managers
give proper notice of their existance, which is the Debian menu.
Also just because many of the new shiny desktop environment systems want
to reinvent everything, there are still many window managers which
are able to properly change window managers on the fly, to any other
window manager. Please do not drop this feature just because your pet
toy does not support it (or supports it but you never used it).
> An entry for each python/TCL/guile interpreter on the system? Can't
> developers use terminals?
> An entry for each of the bsdgames? For nano? For so many terminal
> applications that you want to run, well, in a terminal?
This is the primary reason why I hope the Debian menu will stay, because
it is centered as user-friendlyness and not about some obscure ideology.
Users need programs to do their tasks, no matter if they are terminal or
what guikit they use. If you have a different feeling or think you have
users fitting better into the ideology, the Debian menu system provides
all means to do a simple global change (like not showing terminal apps,
or moving everything you do not like to a other place) for a single or
all users on your systems, while the default can still be what it most
helpfull for people: Have everything that is available and usefull to
start without parameters as an easy to find menu item.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Mike Hommey
> But if the display manager is only worth 2 cents, it's Debian default
> configuration should get it from the place where all window managers
> give proper notice of their existance, which is the Debian menu.
> Also just because many of the new shiny desktop environment systems want
> to reinvent everything, there are still many window managers which
> are able to properly change window managers on the fly, to any other
> window manager. Please do not drop this feature just because your pet
> toy does not support it (or supports it but you never used it).
The fact is very very very very few users actually use these items. So
why bother the more than vast majority that doesn't need them ?
> > An entry for each python/TCL/guile interpreter on the system? Can't
> > developers use terminals?
> > An entry for each of the bsdgames? For nano? For so many terminal
> > applications that you want to run, well, in a terminal?
>
> This is the primary reason why I hope the Debian menu will stay, because
> it is centered as user-friendlyness and not about some obscure ideology.
> Users need programs to do their tasks, no matter if they are terminal or
> what guikit they use. If you have a different feeling or think you have
> users fitting better into the ideology, the Debian menu system provides
> all means to do a simple global change (like not showing terminal apps,
> or moving everything you do not like to a other place) for a single or
> all users on your systems, while the default can still be what it most
> helpfull for people: Have everything that is available and usefull to
> start without parameters as an easy to find menu item.
Do you really think having the python interpreter in a menu item is at
all useful ? Take the debian user base, the number of people using
python as a development tool is already quite low. Now, in these people
developping python scripts or applications, how many do run the python
interpreter without it running the script or application ? I bet very
few. Of these few, how many run the python interpreter outside the IDE
they must be using ? Even fewer, I'd say. Of these very very few, how
many would run it frequent enough that they'd need a menu item for it ?
Now do you think it's fair to clutter everyone's menu with something
that hardly anybody uses ?
If a filtering of the items is at all possible, these should be
filtered-out *by default*, like some programs pretty much useless to
have in a menu are by default in gnome, such as evince or file roller
or, guess what, the python interpreter. Yep, python2.4 provides a
.desktop that is hidden by default.
Mike
Charles Plessy
> 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.
Dear Joey,
Having a .desktop file is a requrement in Ubuntu, so it is not
surprising that people submit patches in wishlist bugs : they are
encouraged to do so. Looking from the email adress of the bug senders
from xgalaga and kobodeluxe, they obiously come from there.
The FreeDesktop menu system has a mechanism to make entries invisible
with given desktop managers. What we miss in Debian is a policy, or just
statemenst from relevant teams, which guides maintainers when they have
to deal with .desktop files.
In the absence of any policy from the GNOME, KDE or XFCE teams, my
personal standpoint is that entries are welcome, so I do add .desktop
files. Acutally, I even create them when I prepare a new package which
lacks them. I also support the idea to chose a format from which .menu
and .desktop files would be generated. It is definitely not fun to
maintian two similar files in parallel.
Have a nice day,
--
Charles Plessy
Debian-Med packaging team
Wako, Saitama, Japan
Josselin Mouette
> > From what I see in the dozens of .desktop files I have on my own
> > system, I see "Field[code]" fields for translations of "Field".
> >
> > This is similar to what we had, in the past, for debconf templates and
> > we all known this doesn't scale and doesn't handle changes to English
> > strings very well.
>
> The strings used to generate translated .desktop entries can (should)
> come from the upstream po/ directory via gettext - it can be handled
> directly using gettext and make.
Actually they are using intltool, just like we do for debconf templates.
> All my upstream projects include all
> translatable strings for the .desktop file in the .gmo (and therefore
> the installed .mo) yet these also exist in the .desktop file that is
> eventually installed.
Side note: you don't need to install such .mo files, unless they also
contain translations accessed from the code.
Bernhard R. Link
> On Sat, Jul 14, 2007 at 10:55:00AM +0200, Bernhard R. Link <brl...@debian.org> wrote:
> > But if the display manager is only worth 2 cents, it's Debian default
> > configuration should get it from the place where all window managers
> > give proper notice of their existance, which is the Debian menu.
> > Also just because many of the new shiny desktop environment systems want
> > to reinvent everything, there are still many window managers which
> > are able to properly change window managers on the fly, to any other
> > window manager. Please do not drop this feature just because your pet
> > toy does not support it (or supports it but you never used it).
>
> The fact is very very very very few users actually use these items. So
> why bother the more than vast majority that doesn't need them ?
Because our priority are our users, and not only those users that some
people think are the important ones?
And how is it bothering other people if there are options? Should we
remove all features just because you and some majority you claim to have
does not use them?
> > This is the primary reason why I hope the Debian menu will stay, because
> > it is centered as user-friendlyness and not about some obscure ideology.
> > Users need programs to do their tasks, no matter if they are terminal or
> > what guikit they use. If you have a different feeling or think you have
> > users fitting better into the ideology, the Debian menu system provides
> > all means to do a simple global change (like not showing terminal apps,
> > or moving everything you do not like to a other place) for a single or
> > all users on your systems, while the default can still be what it most
> > helpfull for people: Have everything that is available and usefull to
> > start without parameters as an easy to find menu item.
>
> Do you really think having the python interpreter in a menu item is at
> all useful ? Take the debian user base, the number of people using
> python as a development tool is already quite low. Now, in these people
> developping python scripts or applications, how many do run the python
> interpreter without it running the script or application ? I bet very
> few. Of these few, how many run the python interpreter outside the IDE
> they must be using ? Even fewer, I'd say. Of these very very few, how
> many would run it frequent enough that they'd need a menu item for it ?
I'd guess that the majority of people needing a menu item are those not
using the application often. Even if not using them for normal work,
it is an easy way to see what is installed and to try some little things.
Why do you insist on everyone not doing things like you is not important
and should not be worth being supported.
> Now do you think it's fair to clutter everyone's menu with something
> that hardly anybody uses ?
Sorry, I do not understand you. All definitions of clutter I could find
include "confusion" or "disorder". Having everything available that is
installed and useable in hierachy is a clear and easy to understand
concept. Hiding stuff by random and/or unpredictable criteria (and
both "person xyz thinks it is not important" or "not enough people use
it" belong to the most random I can think of).
> If a filtering of the items is at all possible, these should be
> filtered-out *by default*, like some programs pretty much useless to
> have in a menu are by default in gnome, such as evince or file roller
> or, guess what, the python interpreter.
I'm extremly against filtering out anything by default. Though I really
do not care what Gnome's default menu-method does. As far as I remember it
never had even the option to show the proper menu...
Bernhard R. Link
Wouter Verhelst
> I heard from quite many users, that they where confused about the
> doubled menu structure, and always asked why some applications are there
> and some others aren't.
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.
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Alexander Schmehl
* Joey Hess <jo...@debian.org> [070713 22:54]:
> This division, while not IMHO technically very nice, helps the
> consistency and usability of the desktop environments, since the most
> accessible menu items are those from the desktop files for that
> particular desktop environment. To find some strange program that is not
> a Gnome (or KDE) program, the user has to go spelunking in the depths of
> the Debian menu structure.
I heard from quite many users, that they where confused about the
doubled menu structure, and always asked why some applications are there
and some others aren't.
Yours sincerely,
Alexander
--
http://learn.to/quote/
http://www.catb.org/~esr/faqs/smart-questions.html
Loïc Minier
> In the long run, big menus of all the possible programs all obsolete
> anyway. A better interface is a tool that helps you search for programs,
> and then remembers programs that you've used so you can quickly
> re-access them. The command line has been doing this for decades;
> desktops are only just starting to catch on to the idea. (And of course
> Enrico is several leaps beyond it with some debtags stuff.)
Actually desktops support this since some years too via deskbar-applet
and beagle. These programs are now very usable, but as file contents
are also indexed for some of them, I am not sure we should install such
a program by default.
I just tried deskbar-applet, and it searches through the information of
.desktop files just fine.
Another benefit of FreeDesktop menu systems is in the availability of
menu editors, such as alacarte, which permit reorganizing your menu,
adding / removing / changing entries etc.
Translations were also pointed out as a major advantage.
You can also benefit from launchers in panels or on your desktop which
will keep all the attributes of the original .desktop files.
I already complained of flaws of the Debian menu system in the past,
and I agree with all the complaints I've seen here (icon formats,
useless entries, Debian specificity).
Debian specificity is the worst thing here as it prevents us from
sending improvements upstream and doesn't permit application authors to
contribute new applications or features: it's less likely that someone
spends time creating a Debian menu editor than a Freedesktop one. It
puts the burden on Debian folks to reinvent everything (translations,
categories, user overrides) and doesn't permit contributing the efforst
on the menu entries upstream.
Maintainers also lose time writing Debian menu entries, or
downscaling icons in size and colors.
--
Loďc Minier
Eduard Bloch
* Josselin Mouette [Sat, Jul 14 2007, 02:26:55AM]:
> Le vendredi 13 juillet 2007 à 17:16 -0700, Steve Langasek a écrit :
> > > Oh my. Do you mean that in the 90 window managers shipped in Debian,
> > > none of them is suitable for all your needs and that you have to use
> > > *several* ones depending on the moment?
> >
> > Unix systems have supported selecting window managers on-the-fly for years
> > before Debian did it. Why does one extra entry for a submenu offend you so?
>
> I'm wondering what is the use case for that entry.
Changing another WM on-the-fly when letting somebody use your PC,
without restarting the whole X session? Testing other WMs? The fact you
are not imagining any use cases does not mean that such ones do not exist.
> I can imagine someone dealing with such a case (although I'd personally
> start a new session to better match the user's environment) but I don't
> think this justifies adding these entries to all users' menus.
If you don't like seeing them, move them to the Settings submenu.
Eduard.
--
<Joey_> Weasel: schreib mal da hinein, daß ich im IRC immer
so schroff bin und nur auf die Türen zeige, öffnen
und durchgehen müssen die Leute schon selbst. Und
wenn sie nicht tun, was ich ihnen sage, endet mein
Support an der Stelle.
Eduard Bloch
* Bernhard R. Link [Sat, Jul 14 2007, 01:10:50PM]:
> * Mike Hommey <m...@glandium.org> [070714 11:30]:
> > On Sat, Jul 14, 2007 at 10:55:00AM +0200, Bernhard R. Link <brl...@debian.org> wrote:
> > The fact is very very very very few users actually use these items. So
> > why bother the more than vast majority that doesn't need them ?
>
> Because our priority are our users, and not only those users that some
> people think are the important ones?
You confuse importance and interests of vast majority.
> And how is it bothering other people if there are options? Should we
> remove all features just because you and some majority you claim to have
> does not use them?
Not remove. Restructure, make the more important submenues appear
earlier and move the unimportant stuff (shells, emulators, hamradio,
...) out of sight.
In fact, I would suggest changing our menu structure a little bit, or
just convert it to the fd.o specs compliant structure (see [1]).
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.
Since we cannot change every package delivering a menu file, this could
be done by a helper package in the transition phase... this helper
package would put auto-generated .desktop file into a replacement
directory so the new-style-menu-generators can use those files unless
real versions are provided by the correspondig package.
[1] http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#category-registry
Regards,
Eduard.
--
Wie man sein Kind nicht nennen sollte:
Gerold Steiner
Mike Hommey
> #include <hallo.h>
> * Josselin Mouette [Sat, Jul 14 2007, 02:26:55AM]:
> > Le vendredi 13 juillet 2007 à 17:16 -0700, Steve Langasek a écrit :
> > > > Oh my. Do you mean that in the 90 window managers shipped in Debian,
> > > > none of them is suitable for all your needs and that you have to use
> > > > *several* ones depending on the moment?
> > >
> > > Unix systems have supported selecting window managers on-the-fly for years
> > > before Debian did it. Why does one extra entry for a submenu offend you so?
> >
> > I'm wondering what is the use case for that entry.
>
> Changing another WM on-the-fly when letting somebody use your PC,
> without restarting the whole X session? Testing other WMs? The fact you
> are not imagining any use cases does not mean that such ones do not exist.
The fact there are use cases does not mean it *must* have a menu entry.
You can pretty much find use cases for very rare and useful for a
only a couple people things, and yet not have to include a menu entry for
that for everyone.
Mike
Magnus Holmgren
> I demand that Bastian Venthur may or may not have written...
>
> [snip]
>
> > The most annoying part of our Debian menu is, that it is too complicated.
> > is pretty useless, and adds unnecessary depth to the menu tree. It would
> > be a major improvement if we would move the Apps section to the root of
> > the tree and sort the remaining sections (Screen, Help, Games and
> > tree by one, and would be a huge improvement of usability.
>
> All five already are at the top level in my customised Xfce menu; for me,
> your proposal would increase the depth by one level for all but Apps.
If so, the contents of Apps could presumably be moved to the top level,
decreasing the depth by one for Apps even there, and leave the level of the
relatively few other entries the same, or maybe in some cases increased by
one.
--
Magnus Holmgren holm...@lysator.liu.se
(No Cc of list mail needed, thanks)
Bernhard R. Link
> #include <hallo.h>
> 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"?
There can hardly be anything more flexible than free-style key-string
pairs. I'm still waiting from the last discussion about the most basic
documentation about the free desktop mess:
How do I as user override a menu item? How as admin?
(At least to this question there is said to be an answer, something
involving creating an undocumented directory and putting things in
there).
Not to speak about all the more complicated stuff. And inventing all
kind of new .desktop things for those things not part of it
(window manager specific modules, window managers, ...) does not sound
that much easier...
Bernhard R. Link
Bernhard R. Link
> The fact there are use cases does not mean it *must* have a menu entry.
> You can pretty much find use cases for very rare and useful for a
> only a couple people things, and yet not have to include a menu entry for
> that for everyone.
Switching the window manager on the fly is in my eyes one of the most
important features of all. Most window managers hardly support it per
command line, and mistyping while entering it can terminate your
session, which is not nice at all.
So the feature is almost only useable when it is in the default menu.
It's useful (and regulary used) for:
- debugging and testing programs (how does this resize work
with this wm, how with this, are the style hints understood
by all,...)
- using a computer by a group. (multiple people thinking about
an article, one after the other having the task of writing,
then it is very nice to have the wm changed with a few clicks
or key presses).
- explaining stuff. If people come to ask for help, having the
same window manager active like them makes it much easier to
understand you (most peoples are not that good at abstracting
the wm away, especially tilded vs overlapping) when you can
just fastly change the wm to explain/show and change back once
they are gone.
- buggy programs failing with some WMs.
<sarkasm>
How about next suggesting to remove all modules for hardware less than
10% of users have? That would help much to not clobber the kernel image
packages.
</sarkasm>
Bernhard R. Link
Darren Salt
> On Friday 13 July 2007 23:30, Darren Salt wrote:
>> I demand that Bastian Venthur may or may not have written...
[snip]
>>> It would be a major improvement if we would move the Apps section to the
>>> root of the tree and sort the remaining sections (Screen, Help, Games and
>>> X-Sheels) *into* this section. That would reduce the depth of the menu
>>> tree by one, and would be a huge improvement of usability.
>> All five already are at the top level in my customised Xfce menu; for me,
>> your proposal would increase the depth by one level for all but Apps.
> If so, the contents of Apps could presumably be moved to the top level,
> decreasing the depth by one for Apps even there,
Maybe, but that would double the height of the top level... no, I prefer it
as it is.
[snip]
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT.
"Bother", said Pooh, as the read/write heads flew across the room.
Neil Williams
Josselin Mouette <jo...@debian.org> wrote:
> Le samedi 14 juillet 2007 à 08:28 +0100, Neil Williams a écrit :
> > > From what I see in the dozens of .desktop files I have on my own
> > > system, I see "Field[code]" fields for translations of "Field".
> > >
> > > This is similar to what we had, in the past, for debconf
> > > templates and we all known this doesn't scale and doesn't handle
> > > changes to English strings very well.
> >
> > The strings used to generate translated .desktop entries can
> > (should) come from the upstream po/ directory via gettext - it can
> > be handled directly using gettext and make.
>
> Actually they are using intltool, just like we do for debconf
> templates.
Yes, just ignore my initial post - I broke my own rule about sending in
haste.
> > All my upstream projects include all
> > translatable strings for the .desktop file in the .gmo (and
> > therefore the installed .mo) yet these also exist in the .desktop
> > file that is eventually installed.
>
> Side note: you don't need to install such .mo files, unless they also
> contain translations accessed from the code.
Yes, they do. The .desktop strings are included to that there is only
one POT file to send to translators.
Joey Hess
> I'd agree that BOTH of these should be able to read the .mo just like
> the application itself.
.mo files do not exist when debconf preconfigures packages. Unless you
want to stick them in control.tar.gz and deal with them in
/var/lib/dpkg/info/. When debconf l10n was being developed, this was
thought to be a bad idea.
A better way to save space would be to remove debconf's templates
database, and have it use the .templates files directly as its database.
This would save in the neighborhood of 8-10 mb, or more generally,
2x the total size of all the .templates files.
(To save just 1x, you can just turn off retention of the backup copy of
the database, This needs no code changes at all, just set Backup: false
in debconf.conf.)
Compressing the templates files would also save several mb,
more space than would be saved converting them to .mo files.
--
see shy jo
Joey Hess
> Having a .desktop file is a requrement in Ubuntu, so it is not
> surprising that people submit patches in wishlist bugs : they are
> encouraged to do so. Looking from the email adress of the bug senders
> from xgalaga and kobodeluxe, they obiously come from there.
Yes, but I'm talking about Debian, and what Debian should do.
> The FreeDesktop menu system has a mechanism to make entries invisible
> with given desktop managers. What we miss in Debian is a policy, or just
> statemenst from relevant teams, which guides maintainers when they have
> to deal with .desktop files.
Yes, that's why I started this thread.
Until there is one, I don't see any reason why I should accept patches
adding menu files to my packages.
> In the absence of any policy from the GNOME, KDE or XFCE teams, my
> personal standpoint is that entries are welcome, so I do add .desktop
> files. Acutally, I even create them when I prepare a new package which
> lacks them. I also support the idea to chose a format from which .menu
> and .desktop files would be generated. It is definitely not fun to
> maintian two similar files in parallel.
Generating both menu and .desktop files from a third format would be
pointless. Either format can be generated from the other format. 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.
--
see shy jo
Neil Williams
Joey Hess <jo...@debian.org> wrote:
> Neil Williams wrote:
> > I'd agree that BOTH of these should be able to read the .mo just
> > like the application itself.
>
> .mo files do not exist when debconf preconfigures packages. Unless you
> want to stick them in control.tar.gz and deal with them in
> /var/lib/dpkg/info/. When debconf l10n was being developed, this was
> thought to be a bad idea.
Yes, I agree - the original was sent in haste, I realised later why this
wasn't such a good idea.
> A better way to save space would be to remove debconf's templates
> database, and have it use the .templates files directly as its
> database. This would save in the neighborhood of 8-10 mb, or more
> generally, 2x the total size of all the .templates files.
That's a very good idea, thanks!
In most cases, Emdebian will use cdebconf instead of debconf because
we're removing Perl from essential and doing without perl in the rootfs
(and probably most installations). (Also dropping python etc. and
using busybox/dash instead of bash, we aren't just picking on perl.)
> (To save just 1x, you can just turn off retention of the backup copy
> of the database, This needs no code changes at all, just set Backup:
> false in debconf.conf.)
I'll make a note to test that with cdebconf.
> Compressing the templates files would also save several mb,
> more space than would be saved converting them to .mo files.
Thanks.
Holger Levsen
On Saturday 14 July 2007 13:10, Bernhard R. Link wrote:
> Because our priority are our users, and not only those users that some
> people think are the important ones?
>
> And how is it bothering other people if there are options? Should we
> remove all features just because you and some majority you claim to have
> does not use them?
[...]
> Sorry, I do not understand you. All definitions of clutter I could find
> include "confusion" or "disorder". Having everything available that is
> installed and useable in hierachy is a clear and easy to understand
> concept.
(In general: too much) choice is bad. Please read
http://www.joelonsoftware.com/items/2006/11/21.html
Exceptions confirm this rule ;-)
I have also been (more) confused by the debian menu than it helped me and I
know of several others who experienced the same. Maybe renaming "Debian"
to "all applications" would be helpful enough, that way users could start all
applications they have installed easily and also copy the launchers to the
panels, which is what I use(d) the debian menu most often for
I also think a policy and/or release goal is a appropriate way of solving this
for all packages.
regards,
Holger
Charles Plessy
It seems that unfortunately we managed to reach a misunderstanding rate
close to 100 % :(
Le Sat, Jul 14, 2007 at 12:44:16PM -0400, Joey Hess a écrit :
> Charles Plessy wrote:
> > Having a .desktop file is a requrement in Ubuntu, so it is not
> > surprising that people submit patches in wishlist bugs : they are
> > encouraged to do so. Looking from the email adress of the bug senders
> > from xgalaga and kobodeluxe, they obiously come from there.
>
> Yes, but I'm talking about Debian, and what Debian should do.
I read from your mail that you were asking for the rationale of those
bug reports. Also it seems that you feel like it is users who want you
to do something. I thing it is not. It is just that enough persons have
said that it is nice to send a patch to the Debian package when there is
a modification in Ubuntu which is perceived as an improvement. You are
of course free to decide that it is unsuitable to your package.
I have been encouraging subscribers of the ubuntu-science mailing list
to send their .desktop files and icons to the Debian developpers (this
obviously does not include xgalaga and kobodeluxe). If this was a bad
idea, I welcome maintainers of scientific packages to contact me in
private and let me correct that mistake.
> > In the absence of any policy from the GNOME, KDE or XFCE teams, my
> > personal standpoint is that entries are welcome, so I do add .desktop
> > files. Acutally, I even create them when I prepare a new package which
> > lacks them. I also support the idea to chose a format from which .menu
> > and .desktop files would be generated. It is definitely not fun to
> > maintian two similar files in parallel.
>
> Generating both menu and .desktop files from a third format would be
> pointless. Either format can be generated from the other format. 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.
I have never said that the original format should not be Debian Menu or
FreeDesktop. Indeed, I have already proposed this last year, and got
flamed for this.
I also have volunteered last year to give some time to a transition if
it would happen.
--
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan
Josselin Mouette
> Switching the window manager on the fly is in my eyes one of the most
> important features of all. Most window managers hardly support it per
> command line, and mistyping while entering it can terminate your
> session, which is not nice at all.
> So the feature is almost only useable when it is in the default menu.
The fact this is the best way to implement this feature doesn't make it
less frivolous.
> <sarkasm>
> How about next suggesting to remove all modules for hardware less than
> 10% of users have? That would help much to not clobber the kernel
> image
> packages.
> </sarkasm>
Kernel modules don't clutter the user interface.
Josselin Mouette
> > 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.
>
> If that's actually true, we could drop menu from the gnome-desktop and
> kde-destkop tasks. (What about XFCE?)
I wouldn't speak for KDE, but after this discussion, I'd recommend
dropping it from the gnome-desktop task.
There seem to be a strong opposition to any proposal willing to fix the
Debian menu. People will all want to keep their pet useless entry in the
menu, and forcing them to migrate to another system will just lead to
the same clutter in the new menu. It will be too difficult to make the
project move as a whole in the same direction. We GNOME people focus on
usability, and this goal seems incompatible with some other developers'
will. I have seen how hard it is to make people fix their crappy debconf
questions, and at least in this case the debconf and d-i developers
could act as a central authority.
There are more constructive things to do than fighting for years to
improve the Debian menu situation; I think we should just let it die,
and let people who want to work on a dead system continue if they want
to.
As a consequence, this will duplicate the work, but I think we should
add .desktop entries to packages, especially games, that don't have one
and deserve it.
Josselin Mouette
> Why not drop the Debian Menu Policy completely? The only sane argument
> against .desktop is hierarchy support but then the most pertinent
> complaint against menu is that the hierarchy is wasteful.
The Freedesktop menu has hierarchy support, but it's much more clever
than the Debian menu's.
The most important argument against it is more about window manager
coverage. There are a good number of packages with Debian menu support
and no Freedesktop menu support.
> What we'd need would be strong guidelines on which packages provide
> a .desktop file and leave it at that.
That, we need in all cases.
> If all Gnome packages silently drop debian/menu in the next upload, is
> that actually going to be a problem for anyone?
That could be for people using GNOME applications in an environment
without fd.o menu support.
Neil Williams
Josselin Mouette <jo...@debian.org> wrote:
> Le vendredi 13 juillet 2007 à 18:34 -0400, Joey Hess a écrit :
> > > 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.
> >
> > If that's actually true, we could drop menu from the gnome-desktop and
> > kde-destkop tasks. (What about XFCE?)
>
> I wouldn't speak for KDE, but after this discussion, I'd recommend
> dropping it from the gnome-desktop task.
It makes me wonder if there is any point keeping debian/menu at all.
Why not drop the Debian Menu Policy completely? The only sane argument
against .desktop is hierarchy support but then the most pertinent
complaint against menu is that the hierarchy is wasteful.
What we'd need would be strong guidelines on which packages provide
a .desktop file and leave it at that.
I'm wondering about removing the menu package from my own machines -
they all run Gnome and the only problem I can see right now is that
dwww depends on menu. If that can be downgraded to a Recommend (I feel
a wishlist bug coming on) then I'll gladly remove the 'menu' package.
True, that means I cannot check debian/menu entries in packages that I
build but I'm willing to trust lintian for that or maybe keep one
machine using 'menu' for now.
Is that such a problem?
> There seem to be a strong opposition to any proposal willing to fix the
> Debian menu. People will all want to keep their pet useless entry in the
> menu, and forcing them to migrate to another system will just lead to
> the same clutter in the new menu. It will be too difficult to make the
> project move as a whole in the same direction. We GNOME people focus on
> usability, and this goal seems incompatible with some other developers'
> will. I have seen how hard it is to make people fix their crappy debconf
> questions, and at least in this case the debconf and d-i developers
> could act as a central authority.
If all Gnome packages silently drop debian/menu in the next upload, is
that actually going to be a problem for anyone?
--
Andreas Barth
> On Sat, Jul 14, 2007 at 02:26:05PM +0200, Eduard Bloch <e...@gmx.de> wrote:
> > #include <hallo.h>
> > * Josselin Mouette [Sat, Jul 14 2007, 02:26:55AM]:
> > > Le vendredi 13 juillet 2007 à 17:16 -0700, Steve Langasek a écrit :
> > > > > Oh my. Do you mean that in the 90 window managers shipped in Debian,
> > > > > none of them is suitable for all your needs and that you have to use
> > > > > *several* ones depending on the moment?
> > > >
> > > > Unix systems have supported selecting window managers on-the-fly for years
> > > > before Debian did it. Why does one extra entry for a submenu offend you so?
> > >
> > > I'm wondering what is the use case for that entry.
> >
> > Changing another WM on-the-fly when letting somebody use your PC,
> > without restarting the whole X session? Testing other WMs? The fact you
> > are not imagining any use cases does not mean that such ones do not exist.
>
> The fact there are use cases does not mean it *must* have a menu entry.
> You can pretty much find use cases for very rare and useful for a
> only a couple people things, and yet not have to include a menu entry for
> that for everyone.
One solution might be to generate a "view all"-view, and allow
applications to specify to be seen in default view or only in "view
all"-view.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Manoj Srivastava
> There seem to be a strong opposition to any proposal willing to fix
> the Debian menu. People will all want to keep their pet useless entry
> in the menu, and forcing them to migrate to another system will just
> lead to the same clutter in the new menu. It will be too difficult to
> make the project move as a whole in the same direction. We GNOME
> people focus on usability, and this goal seems incompatible with some
> other developers' will. I have seen how hard it is to make people fix
> their crappy debconf questions, and at least in this case the debconf
> and d-i developers could act as a central authority.
This sounds fairly combative; and it also begins to sound
divisive (the GNOME people, keepers of usability, vs all the useless
users who do not use desktop systems). I hope I am misreading the
attitude.
> There are more constructive things to do than fighting for years to
> improve the Debian menu situation; I think we should just let it die,
> and let people who want to work on a dead system continue if they want
> to.
> As a consequence, this will duplicate the work, but I think we should
> add .desktop entries to packages, especially games, that don't have
> one and deserve it.
You will, of course, have to convince maintainers of the fames
(I have a couple of my own) to do so; and I, for one, would like to
support as many users as I can, not just my pet enlightened ones that
use GNOME.
Given that, I would like to see more of the proposals about
perhaps translating menu/desktop.org entries into the other format, so
that we do not drop users of window managers that do not follow the
desktop.org menu entries out in the cold.
manoj
--
Nothing succeeds like the appearance of success. Christopher Lascl
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Josselin Mouette
> This sounds fairly combative; and it also begins to sound
> divisive (the GNOME people, keepers of usability, vs all the useless
> users who do not use desktop systems). I hope I am misreading the
> attitude.
This is your own interpretation. I understand from the discussion that
some people are strongly opposed to the changes that are required to
make the Debian menu more usable. I don't want to count people but it
sounds pointless to start a fight against a number of developers when we
can just ignore them and let them use an obsolete menu system if they
want to.
> > As a consequence, this will duplicate the work, but I think we should
> > add .desktop entries to packages, especially games, that don't have
> > one and deserve it.
>
> You will, of course, have to convince maintainers of the fames
> (I have a couple of my own) to do so; and I, for one, would like to
> support as many users as I can, not just my pet enlightened ones that
> use GNOME.
Simple: to support GNOME/KDE/XFCE users, you can include a .desktop
file. To support other users, you can include a .menu file. Both can
coexist safely.
> Given that, I would like to see more of the proposals about
> perhaps translating menu/desktop.org entries into the other format, so
> that we do not drop users of window managers that do not follow the
> desktop.org menu entries out in the cold.
I will be happy to see such a thing if it allows to remove all the .menu
files from the GNOME packages. I will not if it starts being used as an
excuse to add thousands of useless entries in the menu.
Steve Langasek
> Le dimanche 15 juillet 2007 ą 11:24 -0500, Manoj Srivastava a écrit :
> > This sounds fairly combative; and it also begins to sound
> > divisive (the GNOME people, keepers of usability, vs all the useless
> > users who do not use desktop systems). I hope I am misreading the
> > attitude.
> This is your own interpretation. I understand from the discussion that
> some people are strongly opposed to the changes that are required to
> make the Debian menu more usable.
I'm opposed to people who drink the GNOME koolaid and call it "usability".
> I don't want to count people but it sounds pointless to start a fight
> against a number of developers when we can just ignore them and let them
> use an obsolete menu system if they want to.
I hope that whatever design is adopted for revamping the menu system will
have the force of policy, and prevent koolaiders from making menu entries
that the Debian Project as a whole deems useful completely inaccessible from
their menu structure.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vor...@debian.org http://www.debian.org/
Josselin Mouette
> > This is your own interpretation. I understand from the discussion that
> > some people are strongly opposed to the changes that are required to
> > make the Debian menu more usable.
>
> I'm opposed to people who drink the GNOME koolaid and call it "usability".
Call it like you want. We call it usability, and it looks incompatible
with what a number of developers expect from the menu system.
> I hope that whatever design is adopted for revamping the menu system will
> have the force of policy, and prevent koolaiders from making menu entries
> that the Debian Project as a whole deems useful completely inaccessible from
> their menu structure.
I hope that nostalgics from Windows 95 won't ruin upstream projects to
make the GNOME menu usable in their efforts to keep the WindowMaker menu
as it is now.
The way Debian works is that developers have the final word on what
happens in their packages. The GNOME team decides of what's in the GNOME
menu, and the WindowMaker maintainers decide what's in the WindowMaker
menu. If we can agree to put the same things in both menus, that's fine.
If we can't, we'll all go working on something more productive.
Steve Langasek
> The way Debian works is that developers have the final word on what
> happens in their packages.
No, the way Debian works is that we have this little thing called Policy
that's intended to ensure consistency between packages in the distribution
so that the system works as a cohesive whole instead of being fragmented
as a result of pigheadedness on the part of individual developers who think
they know better than everybody else, and this other little thing called the
Technical Committee to enforce Policy.
Josselin Mouette
> No, the way Debian works is that we have this little thing called Policy
> that's intended to ensure consistency between packages in the distribution
> so that the system works as a cohesive whole instead of being fragmented
> as a result of pigheadedness on the part of individual developers who think
> they know better than everybody else, and this other little thing called the
> Technical Committee to enforce Policy.
I can't wait to see someone seize the technical committee to ask the
GNOME menu to be replaced by the Debian menu.
Daniel Leidert
> Charles Plessy wrote:
[..]
> > The FreeDesktop menu system has a mechanism to make entries invisible
> > with given desktop managers. What we miss in Debian is a policy, or just
> > statemenst from relevant teams, which guides maintainers when they have
> > to deal with .desktop files.
>
> Yes, that's why I started this thread.
>
> 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.
> > In the absence of any policy from the GNOME, KDE or XFCE teams, my
> > personal standpoint is that entries are welcome, so I do add .desktop
> > files. Acutally, I even create them when I prepare a new package which
> > lacks them. I also support the idea to chose a format from which .menu
> > and .desktop files would be generated. It is definitely not fun to
> > maintian two similar files in parallel.
>
> 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
occur. The Debian menu items also do not contain the information, how to
handle the arguments when calling the program from e.g. nautilus to open
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.
> 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).
Regards, Daniel
Ross Burton
> 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).
OnlyShowIn=Debian would be more in spirit with the specification I
believe.
Ross
--
Ross Burton mail: ro...@burtonini.com
jabber: ro...@burtonini.com
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Joey Hess
> I wouldn't speak for KDE, but after this discussion, I'd recommend
> dropping it from the gnome-desktop task.
Ok, well, I outlined in my other mail what I feel needs to happen before
that could be done.
> There seem to be a strong opposition to any proposal willing to fix the
> Debian menu. People will all want to keep their pet useless entry in the
> menu, and forcing them to migrate to another system will just lead to
> the same clutter in the new menu. It will be too difficult to make the
> project move as a whole in the same direction. We GNOME people focus on
> usability, and this goal seems incompatible with some other developers'
> will. I have seen how hard it is to make people fix their crappy debconf
> questions, and at least in this case the debconf and d-i developers
> could act as a central authority.
I've never had any difficulty getting people to fix debconf questions.
Neither have others such as Christian Perrier, AFAIK. (This may have
something to do with us not writing inflammatory paragraphs like the one
above when we do it.)
--
see shy jo
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.
Not for any of my packages, AFAIK.
> 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
> occur.
The Debian menu format is flexible, it can have any necessary extra info
added to it. See for example dwww that uses the debian menu format for
manauging documentation and not starting programs at all.
> You may be able to create a Debian menu
> file from the .desktop file. But the other way would be very useless.
We ALREADY create .desktop files from menu files.
--
see shy jo
Bruce Sass
> Le dimanche 15 juillet 2007 à 14:11 +0100, Neil Williams a écrit :
> > Why not drop the Debian Menu Policy completely? The only sane
> > argument against .desktop is hierarchy support but then the most
> > pertinent complaint against menu is that the hierarchy is wasteful.
>
> The Freedesktop menu has hierarchy support, but it's much more clever
> than the Debian menu's.
>
> The most important argument against it is more about window manager
> coverage. There are a good number of packages with Debian menu
> support and no Freedesktop menu support.
Neil,
If by "drop the Debian Menu Policy completely" you mean adopting
Freedesktop's .desktop file format, menu hierarchy rules, and whatever
tools they have for working with menus---sure. From an enduser's
perspective it doesn't matter what lies beneath the menus we see[1], if
you DD's decide the Freedesktop way is the better one for packaging
menu entries then so be it.
If you are suggesting dropping the Debian menu infrastructure as well,
therebye forcing the other window managers to learn how to
read .desktop files or convert them into their native format on their
own time---that sounds like a bad idea. I would hate it if my
lightweight and fast wm suddenly started using more RAM, took longer to
startup, or if the menus became as sluggish as KDE's[2]. Since the
conversion route is likely to be a popular solution and lengthening
startup time is the least objectionable (both could be done without
touching the wm's code), there would be a significant amount of code
duplication happening and therefore pressure to devise infrastructure
which does a good chunk of what the existing menu system does now.
AFAICT, all potential benefits from this last kind of change favour the
few window managers which natively "speak" .desktop, and everyone else
gets the undoubtedly shitty end of the stick. Furthermore, it seems
really odd to potentially shift onto, or create work for, all the
lighter weight window managers, likely to be running on less capable
than average boxes, for the benefit of window managers which pretty
much require a box of average or better capabilities. IOW, if there are
hoops to be jumped through to get a better menu subsystem then it is
best to put those hoops into the arenas most likely to have enough
spare resources to do the jumping.
I would think that would be enough to place the idea of dropping the
menu infrastructure in the non-starter category, but obviously it isn't
because "window manager coverage" is an issue. I mean, if simply
changing the menu infrastructure to use .desktop files as input is what
is on the table, then presumably all window managers will need to
change the way they do things and any "coverage" problems will be
temporary ones which could affect any wm while the Maintainers rewrite
their menu generating code.
Josselin,
If I am understanding you correctly then I must say that "window manager
coverage" is more than just "the most important argument against", it's
a TKO for the idea (see above for why I believe that).
I believe I am understanding you correctly because, "Debian menu support
and no Freedesktop menu support", is only an issue if the common menu
generating infrastructure disappears and all we are left with is a
collection of .desktop files.
I hope you reconsider your position.
- Bruce
[1] It would be nice to have a friendly Debian->Freedesktop menu entry
conversion utility so those of us with custom menu entries and
no .desktop experience can get a little hand holding while we make the
switch.
[2] it has been awhile since I used Gnome but their menus used to be
slower than KDE's, KDE's have gotten slower (and take up more HDD
space, perhaps a consequence of the Freedesktop related stuff added to
the menu subsystem and maybe why there has been a push to swith
to .desktop files)... but the menus I get with UWM are always very fast
Daniel Leidert
> On Sun, 2007-07-15 at 22:57 +0200, Daniel Leidert wrote:
> > 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).
>
> OnlyShowIn=Debian would be more in spirit with the specification I
> believe.
True, but the key has some registered values and "Debian" currently
isn't one of them :) However I agree, this would be the more appropriate
key/place (and adding Debian as registered value shouldn't be a big
problem IMHO).
Daniel Leidert
> Daniel Leidert wrote:
> > > 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.
>
> Not for any of my packages, AFAIK.
Just grep through /usr/share/applications for the MimeType field. This
is the way to assign your program with the MIME/file types it can
handle. Maybe your packages use the metamail-system in /usr/lib/mime or
maybe you don't need to assign any of your programs with MIME types for
desktop users :)
> > 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
> > occur.
>
> The Debian menu format is flexible, it can have any necessary extra info
> added to it. See for example dwww that uses the debian menu format for
> manauging documentation and not starting programs at all.
However, if you want to make the Debian menu files represent the whole
desktop entry spec, it would IMHO be easier to change their format to
follow the spec instead of re-inventing/completing another format. Just
for the case, you want to know more about the format, see [1]. The only
thing (of a Debian menu file) the .desktop file format currently doesn't
support is (to my knowledge) the needs-key. However, the spec [1]
doesn't forbid X- prefixed self-defined keys (section "Extending the
format").
> > You may be able to create a Debian menu
> > file from the .desktop file. But the other way would be very useless.
>
> We ALREADY create .desktop files from menu files.
Yes. But I think you understand, what I wanted to say. You can currently
just create a simple menu entry, but not a full featured .desktop file,
because the Debian menu file does not contain all the necessary
information. This IMHO begins with the fact, that the created Exec key
value does not contain any of the information you can find in section
"The Exec key" of the specification [1], because the Debian menu files
do not contain this kind of information. But it would be a necessary
info to let other programs like file or web-browsers know, how to open a
document with an application.
I think, this should be clear now, so I will not longer dwell upon this-
[1] http://standards.freedesktop.org/desktop-entry-spec/latest/
Joey Hess
> Yes. But I think you understand, what I wanted to say. You can currently
> just create a simple menu entry, but not a full featured .desktop file
The majority of desktop files do not need to contain mime information.
Consider all games.
--
see shy jo
Sam Hocevar
> On Sun, Jul 15, 2007 at 09:56:42PM +0200, Josselin Mouette wrote:
> > The way Debian works is that developers have the final word on what
> > happens in their packages.
>
> No, the way Debian works is that we have this little thing called Policy
> that's intended to ensure consistency between packages in the distribution
> so that the system works as a cohesive whole instead of being fragmented
> as a result of pigheadedness on the part of individual developers who think
> they know better than everybody else, and this other little thing called the
> Technical Committee to enforce Policy.
Sorry to interrupt, but the way Debian works is that we have this
other thing called the Social Contract that says we do what our users
want. Not directed at you, Steve, but it looks like most of this thread
is slowly losing track of it.
Cheers,
--
Sam.
Raphael Hertzog
> On Sun, Jul 15, 2007, Steve Langasek wrote:
> > On Sun, Jul 15, 2007 at 09:56:42PM +0200, Josselin Mouette wrote:
> > > The way Debian works is that developers have the final word on what
> > > happens in their packages.
> >
> > No, the way Debian works is that we have this little thing called Policy
> > that's intended to ensure consistency between packages in the distribution
> > so that the system works as a cohesive whole instead of being fragmented
> > as a result of pigheadedness on the part of individual developers who think
> > they know better than everybody else, and this other little thing called the
> > Technical Committee to enforce Policy.
>
> Sorry to interrupt, but the way Debian works is that we have this
> other thing called the Social Contract that says we do what our users
> want. Not directed at you, Steve, but it looks like most of this thread
> is slowly losing track of it.
Granted.
And at least to me it's pretty clear that the proper course of action is
replace "menu" files by "dekstop" files. Modify the menu package to use
desktop file as input and continue to use the menu package for software
which are not able to handle "desktop" file natively.
It looks like the fd.o desktop files have all the features needed to
express the various things that we need:
- indicate if it's a console or graphical application
- etc.
Then the gnome menu can filter out console applications and the menu of window
managers used by advanced users can have the full list.
Yes, it's probably some non-trivial work. And the behaviour of Josselin is
not really constructive in that regard. Because he cares only about
Gnome/KDE/Xfce, he doesn't want to fix the menu package himself. It's his
right, but then he should also acknowledge what is the proper course of
action for the project and encourage people to go in that direction
instead of throwing accusations and telling everybody how horrible the
Debian menu is.
Yes, the Debian menu is problematic in the Gnome environment:
- it confuses people
- it's sometimes regenerated in english when you install new
packages after the initial installation
- i even saw him with only two sub menus (the apps one having
disappeared among others)
(No I haven't bothered to check if those bugs are already reported or
not)
I completely understand the will to have that menu disappear in the Gnome
environment.
Bill, you haven't participated in this discussion, what's your opinion?
Would you like to do that work?
Would it be helpful to have the technical committee decide on this
topic?
Cheers,
--
Raphaës Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Don Armstrong
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.
Don Armstrong
--
"I'm a rational being--of a sort--rational enough, at least, to see the
symptoms of insanity around me. And I'm human, the same as the people
I think of as victims when my guard drops. It's at least possible I'm
even crazier than my fellows, whom I'm tempted to pity.
"There seems only one thing to do, and that's get drunk"
-- Chad C. Mulligan (John Brunner _Stand On Zanzibar p390)
http://www.donarmstrong.com http://rzlab.ucr.edu
Wouter Verhelst
> On Sun, 15 Jul 2007 14:36:47 +0200
> Josselin Mouette <jo...@debian.org> wrote:
> > Le vendredi 13 juillet 2007 à 18:34 -0400, Joey Hess a écrit :
> > > > 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.
> > >
> > > If that's actually true, we could drop menu from the gnome-desktop and
> > > kde-destkop tasks. (What about XFCE?)
> >
> > I wouldn't speak for KDE, but after this discussion, I'd recommend
> > dropping it from the gnome-desktop task.
>
> It makes me wonder if there is any point keeping debian/menu at all.
>
> Why not drop the Debian Menu Policy completely? The only sane argument
> against .desktop is hierarchy support but then the most pertinent
> complaint against menu is that the hierarchy is wasteful.
The debian menu hierarchy has just been revised, and a new menu policy
has been active since a few weeks. Why not wait that out, and see
whether that improves things? Personally, I think it will improve
matters by much.
In any case, I don't think just dropping debian/menu is the best thing
to do. Perhaps make it an option, but IMO one of the main strengths
about Debian as a whole is precisely this unified menu system. If
there's an opinion floating around that the fdo menu hierarchy is much
better, then that may be a good argument to improve the Debian menu
system, but not necessarily one to drop it entirely.
[...]
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Andreas Tille
>> I'm opposed to people who drink the GNOME koolaid and call it "usability".
>
> Call it like you want. We call it usability, and it looks incompatible
> with what a number of developers expect from the menu system.
I don't think that there is something like "general usability". There might
be something that is "very usable for a certain group of users". So claiming
to design a system for maximum usability requires to define the group of
users first. You obviousely are speeking for thoses users that prefer
Gnome - which is perfectly valid, but a generalisation of this seems not
to be possible.
> The way Debian works is that developers have the final word on what
> happens in their packages. The GNOME team decides of what's in the GNOME
> menu, and the WindowMaker maintainers decide what's in the WindowMaker
> menu. If we can agree to put the same things in both menus, that's fine.
> If we can't, we'll all go working on something more productive.
Well, I've also tried something productive: In the cdd-dev framework for
custom Debian distributions it is possible to define user roles that will
be presented with an extra menu entry that matches the tasks that are
defined for the CDD. The rationale behind this is that I here *know*
the users and there preferences and are able to guess what they are interested
in. Unfortunately this works only for the Debian menu system - which
should be by no means a pro-Debian-menu argument. In contrary I plan
to implement a fd.o solution as soon as possible.
The idea I want to bring in into this discussion is that even if we really
would .desktop files in all packages it does not make the situation much
better because the menu will be very long again. What we need is kind of
a task specific menu according to different user roles - this is exactly
what CDD intent to do: Define groups od specific users, support easy installation
of packages related to their tasks and prepare their dasktop accordingly.
I personally prefer a menu item for every installed package in this CDD
scope, because for a user who did not installed the machine themselves
anything that is not in the menu is "not available" or at least "hidden".
In another mail
On Sun, 15 Jul 2007, Josselin Mouette wrote:
> As a consequence, this will duplicate the work, but I think we should
> add .desktop entries to packages, especially games, that don't have one
> and deserve it.
What do you mean with "deserve it"? Could you please give some criteria
to deside which packages deserve a menu entry? For which group of users
makes a menu entry sense and for which not?
Kind regards
Andreas.
--
http://fam-tille.de
Bernhard R. Link
> On Sun, Jul 15, 2007, Steve Langasek wrote:
> > On Sun, Jul 15, 2007 at 09:56:42PM +0200, Josselin Mouette wrote:
> > > The way Debian works is that developers have the final word on what
> > > happens in their packages.
> >
> > No, the way Debian works is that we have this little thing called Policy
> > that's intended to ensure consistency between packages in the distribution
> > so that the system works as a cohesive whole instead of being fragmented
> > as a result of pigheadedness on the part of individual developers who think
> > they know better than everybody else, and this other little thing called the
> > Technical Committee to enforce Policy.
>
> Sorry to interrupt, but the way Debian works is that we have this
> other thing called the Social Contract that says we do what our users
> want. Not directed at you, Steve, but it looks like most of this thread
> is slowly losing track of it.
But there is no single user. (If there was, we could go and ask him/her
what the users want, and would not need the whole discussion). I don't
think anyone here is not claiming to supporting what the users want.
The problem is that users have different needs and and wishes, even to
the extend of mutually exclusive ones, and different priorities.
Which especially mean that people do not want to think about everything,
so if there are decisions, there should be easier to memorize patterns
than "maintainer X does not like Y" or "gnome people don't think X
is intresting for users they can imagine". That's why having a policy
is one of the biggest advantages of Debian in being useful for users.
Hochachtungsvoll,
Bernhard R. Link
Russ Allbery
> On Sun, 15 Jul 2007, Josselin Mouette wrote:
>> As a consequence, this will duplicate the work, but I think we should
>> add .desktop entries to packages, especially games, that don't have one
>> and deserve it.
> What do you mean with "deserve it"? Could you please give some criteria
> to deside which packages deserve a menu entry? For which group of users
> makes a menu entry sense and for which not?
Yes, please. This seems to be one of the fundamental objections to the
current menu system, and we *have* a Menu Policy already where this sort
of thing could be addressed. And if we're going to replace menu with
.desktop files, we're *still* going to need a policy that addresses this.
It's all very fine and good to say that there's stuff with menu entries
that shouldn't have them, but nothing will change until someone writes a
clear policy on what should be included and what shouldn't that we can all
agree to.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Steve Greenland
> Le vendredi 13 juillet 2007 ? 17:16 -0700, Steve Langasek a ?crit :
> > > Oh my. Do you mean that in the 90 window managers shipped in Debian,
> > > none of them is suitable for all your needs and that you have to use
> > > *several* ones depending on the moment?
> >
> > Unix systems have supported selecting window managers on-the-fly for years
> > before Debian did it. Why does one extra entry for a submenu offend you so?
>
> I'm wondering what is the use case for that entry.
So I can try a new window manager without restarting my xsession.
So J. Random User can easily see what window managers are available.
Not everybody thinks GNOME and KDE are the epitome of desktop management.
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
Steve Greenland
> The fact this is the best way to implement this feature doesn't make it
> less frivolous.
>
> > <sarkasm>
> > How about next suggesting to remove all modules for hardware less than
> > 10% of users have? That would help much to not clobber the kernel
> > image
> > packages.
> > </sarkasm>
>
> Kernel modules don't clutter the user interface.
But all those KDE packages clutter my usage of aptitude. So do the
windowmaker packages. And all those damn perl packages.
Just because *you* don't use something doesn't make it unimportant. One
of the big values of Debian is a long time tolerance and support of a
variety of users and use patterns, even those that are non-mainstream.
If you find the Debian menu to be clutter, fine. Ignore it, or change
the configuration to skip it.
Josselin Mouette
> So I can try a new window manager without restarting my xsession.
Does your job include daily window manager testing?
> So J. Random User can easily see what window managers are available.
Some of the users we target don't even know what a window manager is,
and they don't want to know it.
Steve Greenland
> Le dimanche 15 juillet 2007 ? 13:07 -0700, Steve Langasek a ?crit :
> > No, the way Debian works is that we have this little thing called Policy
> > that's intended to ensure consistency between packages in the distribution
> > so that the system works as a cohesive whole instead of being fragmented
> > as a result of pigheadedness on the part of individual developers who think
> > they know better than everybody else, and this other little thing called the
> > Technical Committee to enforce Policy.
>
> I can't wait to see someone seize the technical committee to ask the
> GNOME menu to be replaced by the Debian menu.
Why do you think that would happen? None of the people here have
suggested that. You, on the other hand, have suggested that the Debian
menu system be trashed in favor the GNOME menu system.
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
Josselin Mouette
> > Kernel modules don't clutter the user interface.
>
> But all those KDE packages clutter my usage of aptitude. So do the
> windowmaker packages. And all those damn perl packages.
Nothing to do with the user interface (which in this case should be
improved to filter out packages you don't want to see), but I would be
glad if we could clean the archive of its unmaintained and/or useless
packages.
> Just because *you* don't use something doesn't make it unimportant.
Just because you use something doesn't make it necessary.
> One
> of the big values of Debian is a long time tolerance and support of a
> variety of users and use patterns, even those that are non-mainstream.
> If you find the Debian menu to be clutter, fine. Ignore it, or change
> the configuration to skip it.
This is exactly what I am asking for.
Neil Williams
Don Armstrong <d...@debian.org> wrote:
> 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.
Sounds good to me.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Steve Greenland
> Le dimanche 15 juillet 2007 ? 11:24 -0500, Manoj Srivastava a ?crit :
> > This sounds fairly combative; and it also begins to sound
> > divisive (the GNOME people, keepers of usability, vs all the useless
> > users who do not use desktop systems). I hope I am misreading the
> > attitude.
>
> make the Debian menu more usable.
The problem is your idea of "more usable" is, to me, "remove valuable
functionality".
Yes, the menu hierarchy could use some work. Yes, it might be better if
not every shell and console text editor had a menu entry, or if they
were buried under the "Obscure Console Apps" sub-head.
But that's got nothing to do with format of the menu entries. You're
going to have to decide policy for that kind of stuff no matter what
format you choose. And *right now*, there is a lot more support for the
Debian menu format that the freedesktop.org format.
And for the record, I'm someone who is generally in favor of the
direction GNOME chose. But I think that rather than trashing the Debian
menu system, it might be the better choice for GNOME (in Debian), to
ignore/disable the Debian menu by default.
Javier Fernández-Sanguino Peña
> Josselin Mouette wrote:
> > in sub-menus when appropriate, but many desktop files are not tagged
> > correctly. As you can see in the specification [0], all categories we
> > need should be here, so if we tag desktop files appropriately, the
> > generated menu should be usable.
>
> Oddly, the specification nearly exactly mirrors the despised
> Debian menu system, as far as the categorisation of games goes:
(...)
Just a few thoughts based on my personal experience. I present you my home
system: sid, GNOME 2.18, but not with the full gnome-desktop-environment
metapackage installed, as it's rather huge, but with gnome-core and an
assorted collection of gnome-specific packages as well as many games.
In my case the Debian menu properly introduces these games in their proper
submenu but the GNOME menu does *not* create submenu for any of the
categories, all games are presented in a flat menu which overflows the
screen. Is this a feature only available when installing a particular
package?
Check this:
$ find . -name "*desktop" -exec egrep "Categories.*Game.*" \{\} \; | wc -l
54
I get all these 54 items in GNOME's Game menu with no category division.
And, both GNOME *and* KDE *and* Desktop-agnostic games are shown there.
Not that I'm completely in favour of submenus (a submenu with a single entry
does not seem useful to me). However, having a list of items that cannot be
seen on screen without browsing through it does not seem very user-friendly
to me. Specially as I don't play all games often (just a few of them)
What I would like to see implement (in the UI side?=
update-menus could also):
a- if # items in a menu are < THRESHOLD then present them in a flat list
b- if # items in a menu are > THRESHOLD then use submenus to categorise
but, if there is a submenu that has < THRESHOLD_B items (say 1) then
do not create a submenu for it.
c- "learn" which items the user uses most and present those hiding others
(there's people which despise this feature from other OSes, I actually
find it useful)
This could be implemented in the UI side, but maybe update-menus could
also implement this (specially a and b) to prevent having submenus with just
1 item.
I don't see any of this being mentioned in GNOME's Menu Usability wiki
(http://live.gnome.org/UsabilityTeam/Menu) which seems to imply that a flat
hierarchy is prefered by GNOME (but it is quite useless in Debian, as we do
carry much more applications if you install both GNOME and KDE). But maybe it
is because it works (better) in other (heavier) GNOME environments.
BTW. If I use GNOME's built-in menu editor (the one you get when you
right-clink on the footprint with just gnome-panel installed, not alacarte,
as it is not installed) I'm not able to create submenus and, even, to see the
categories the different desktop files assign to each Game. That isn't too
user-friendly to me.
I know I can install alacarte (pulled in by gnome-desktop-environment) but
IMHO a *proper menu editor should be an essential part of the GNOME desktop.
However, even if I install alacarte I don't get the option to create
submenus automatically based on the Game categories (which, again, are not
shown). Which means I have to automatically sort games byhand into menus when
there is already information in the desktop files to do this!
Just my 2c,
Javier
Josselin Mouette
> Why do you think that would happen? None of the people here have
> suggested that. You, on the other hand, have suggested that the Debian
> menu system be trashed in favor the GNOME menu system.
No. I have suggested that both systems continue to coexist as long as
their goals are incompatible.
Josselin Mouette
> The problem is your idea of "more usable" is, to me, "remove valuable
> functionality".
Yes. Improving usability requires removing or reworking functionality
exposure. This is a trade-off between not being able to do something
because there are no features and not being able to do something because
features are hidden into tons of other features.
> And for the record, I'm someone who is generally in favor of the
> direction GNOME chose. But I think that rather than trashing the Debian
> menu system, it might be the better choice for GNOME (in Debian), to
> ignore/disable the Debian menu by default.
I think we can also agree on this.
Josselin Mouette
écrit :
> Check this:
> $ find . -name "*desktop" -exec egrep "Categories.*Game.*" \{\} \; | wc -l
> 54
>
> I get all these 54 items in GNOME's Game menu with no category division.
> And, both GNOME *and* KDE *and* Desktop-agnostic games are shown there.
You should probably file bugs against game packages that provide
uncategorized desktop entries. The GNOME menu should sort them out in
submenus if this is done correctly.
Javier Fernández-Sanguino Peña
> 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.
> 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.
Maybe some of the people that claim that the hierarchical organization is
broken should open up a wiki page and do a side-to-side comparison of
Debian's menu vs. Freedesktop's menu structure.
Just my 2c,
Javier
Josselin Mouette
> The debian menu hierarchy has just been revised, and a new menu policy
> has been active since a few weeks.
The new hierarchy doesn't fix any of the issues that were raised.
Neil Williams
Bruce Sass <bms...@shaw.ca> wrote:
> > > Why not drop the Debian Menu Policy completely? The only sane
> > > argument against .desktop is hierarchy support but then the most
> > > pertinent complaint against menu is that the hierarchy is wasteful.
> >
> > The Freedesktop menu has hierarchy support, but it's much more clever
> > than the Debian menu's.
> >
> > The most important argument against it is more about window manager
> > coverage. There are a good number of packages with Debian menu
> > support and no Freedesktop menu support.
>
> Neil,
>
> If by "drop the Debian Menu Policy completely" you mean adopting
> Freedesktop's .desktop file format, menu hierarchy rules, and whatever
> tools they have for working with menus---sure. From an enduser's
> perspective it doesn't matter what lies beneath the menus we see[1], if
> you DD's decide the Freedesktop way is the better one for packaging
> menu entries then so be it.
I like Don's idea - remove the Debian menu from those window managers
etc. that understand .desktop files and make the Debian menu aware
of .desktop files for those other systems.
> 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.
> If you are suggesting dropping the Debian menu infrastructure as well,
> therebye forcing the other window managers to learn how to
> read .desktop files or convert them into their native format on their
> own time---that sounds like a bad idea.
True - that is avoidable so there's no need to go that far.
> I would think that would be enough to place the idea of dropping the
> menu infrastructure in the non-starter category, but obviously it isn't
> because "window manager coverage" is an issue.
If the current Debian Menu Policy is rewritten along the lines set out
in Don Armstrong's email, that is fine with me.
> [2] it has been awhile since I used Gnome but their menus used to be
> slower than KDE's, KDE's have gotten slower (and take up more HDD
> space, perhaps a consequence of the Freedesktop related stuff added to
> the menu subsystem and maybe why there has been a push to swith
> to .desktop files)... but the menus I get with UWM are always very fast
Depends what else has been happening on the machine - the .desktop
based menus load very quickly if there is sufficient cache. The first
time I view either menu, I get the same delay on this amd64 box, it
appears to be the icons that are the cause of the delay, not the source
of the textual data.
Javier Fernández-Sanguino Peña
> Le lundi 16 juillet 2007 à 20:01 +0200, Javier Fernández-Sanguino Peña a
> écrit :
> > Check this:
> > $ find . -name "*desktop" -exec egrep "Categories.*Game.*" \{\} \; | wc -l
> > 54
> >
> > I get all these 54 items in GNOME's Game menu with no category division.
> > And, both GNOME *and* KDE *and* Desktop-agnostic games are shown there.
>
> You should probably file bugs against game packages that provide
> uncategorized desktop entries. The GNOME menu should sort them out in
> submenus if this is done correctly.
It looks to me like they are properly categorised and its the GNOME menu
which is misbehaving:
$ find . -name "*desktop" -exec egrep "Categories.*Game.*" \{\} \; | \
perl -ne 'while ($_ ne "") {if (/([\-\w]+);(.*)/) {print "$1\n"; $_=$2;} \
else { $_= ""; }}' | sort | uniq -c |sort -nr
55 Game
31 Qt
31 KDE
18 GNOME
15 GTK
13 ArcadeGame
11 StrategyGame
11 BoardGame
7 LogicGame
6 Application
5 CardGame
1 X-KDE-KidsGame
1 GamesAction
1 GameAction
1 BlocksGame
1 ActionGames
1 ActionGame
There are some typos there too ('GameAction', 'ActionGame') which I'm going
to file bugs now.
Javier
Andreas Tille
> Le lundi 16 juillet 2007 à 12:25 -0500, Steve Greenland a écrit :
>> So I can try a new window manager without restarting my xsession.
>
> Does your job include daily window manager testing?
Interesting criterion: Daily use of an entry.
Hmmmm ....
>> So J. Random User can easily see what window managers are available.
>
> Some of the users we target don't even know what a window manager is,
> and they don't want to know it.
I'm sorry, but I consider myself as a quite important target user.
If I would not be a target user I probably wouldn't be a Debian
developer.
martin f krafft
> > So I can try a new window manager without restarting my xsession.
>
> Does your job include daily window manager testing?
Mine is, full-time. Stop being destructive.
> > So J. Random User can easily see what window managers are available.
>
> Some of the users we target don't even know what a window manager is,
> and they don't want to know it.
I don't think we know our target group to the point to be able to
make such statements.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <mad...@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"it is the mark of an educated mind
to be able to entertain a thought
without accepting it."
-- aristoteles
Frank Küster
> I like Don's idea - remove the Debian menu from those window managers
> etc. that understand .desktop files and make the Debian menu aware
> of .desktop files for those other systems.
Oh, please not. Everytime I try a "desktop environment", I end up using
its menus nearly only for configuring it, and the Debian menu for doing
real work. It's the menu I am used to, and it would really reduce my
productivity to miss it. Not that a desktop environment increases my
productivity, anyway; but should I actually want to get used to one for
longer, it would indeed make my personal transition smoother if I can
start with the familiar Debian menu and switch to the respective desktop
environment menus gradually.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Michael Biebl
> Neil Williams <li...@codehelp.co.uk> wrote:
>
>> I like Don's idea - remove the Debian menu from those window managers
>> etc. that understand .desktop files and make the Debian menu aware
>> of .desktop files for those other systems.
>
> Oh, please not. Everytime I try a "desktop environment", I end up using
> its menus nearly only for configuring it, and the Debian menu for doing
> real work. It's the menu I am used to, and it would really reduce my
> productivity to miss it. Not that a desktop environment increases my
> productivity, anyway; but should I actually want to get used to one for
> longer, it would indeed make my personal transition smoother if I can
> start with the familiar Debian menu and switch to the respective desktop
> environment menus gradually.
>
I actually do like Don's idea.
The first thing I usually do, after installing KDE or Gnome is to
disable the Debian menu in /etc/xdg/menus/(gnome,kde)-applications.menu,
for all the reason already given:
- It duplicates entries (so it's potentially confusing for novice users)
- Has no i18n
- ugly (although I agree that's subjective). No png icons for
applications, no icons for subdirectories, which imho makes it harder to
recognize the categories quickly.
So, yeah, I vote for disabling the Debian menu in KDE/Gnome/XFCE.
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Bruce Sass
> On Sun, 15 Jul 2007 18:16:49 -0600
> Bruce Sass <bms...@shaw.ca> wrote:
> I like Don's idea - remove the Debian menu from those window managers
> etc. that understand .desktop files and make the Debian menu aware
> of .desktop files for those other systems.
Ya, I think Don has come up with a pretty good summary of the most
reasonable/significant ideas. The only thing missing is an explicit
acknowledgement of the need for a way to grossly customize the menus
independently of any tools provided by a specific environment. E.g., I
would like the KDE K-menu to default to having a Debian submenu
containing all executables, with all other submenus containing only KDE
programs; if I fire up Gnome I would like its main menu to do the same;
etc.---without having to independently configure each environment.
> > [2] it has been awhile since I used Gnome but their menus used to
> > be slower than KDE's, KDE's have gotten slower (and take up more
> > HDD space, perhaps a consequence of the Freedesktop related stuff
> > added to the menu subsystem and maybe why there has been a push to
> > swith to .desktop files)... but the menus I get with UWM are always
> > very fast
>
> Depends what else has been happening on the machine - the .desktop
> based menus load very quickly if there is sufficient cache. The first
> time I view either menu, I get the same delay on this amd64 box, it
> appears to be the icons that are the cause of the delay, not the
> source of the textual data.
I'm not sure what is happening, only that shortly after it became
annoying I noticed "xdg" related menu-methods and a ~/.local dir which
hadn't existed before.
It does only happen first time accessing a menu, and seems to be related
more to the number of entries than whether they have icons or not.
<shrug> Anything I use frequently has a desktop shortcut, panel icon, or
is in the quick launcher, so it's not a big deal. A combination of KDE
style menu infrastructure and a less featureful environment would be
very annoying though.
Steve Greenland
> Le lundi 16 juillet 2007 ? 12:25 -0500, Steve Greenland a ?crit :
> > So I can try a new window manager without restarting my xsession.
>
> Does your job include daily window manager testing?
No. But anything I use daily gets its own icon on the application bar.
Right now the entries are rxvt, emacs, iceweasel, jpilot, trn, and
sonata. Oh, and a new mail detector hooked up to mutt.
By your argument, I'd say we don't need any menu entries at all.
> > So J. Random User can easily see what window managers are available.
>
> Some of the users we target don't even know what a window manager is,
> and they don't want to know it.
Some of the users we target don't use any desktop environment, running
headless servers. So let's remove KDE and GNOME.
Javier Fernández-Sanguino Peña
True. It looks like there is only one culprit (in my system, at least):
armagetronad. Bug filed (#433372).
I've just coded in a test for Lintian to implement validation of desktop
files. After implementing it (and sending it to the BTS, see #433411), I've
noticed that there was an outstanding bug report (#277441) which has been
open for over 3 years asking for just this feature.
My lintian tests do less than 'desktop-file-validate' (a tool I didn't know
about, until I read #277441) but can be easily extended based on the code of
that tool to avoid adding too many dependencies to lintian if needed.
Might be interesting to add the test I submitted into lintian and see which
packages fail it.... specially if we want to promote the use of desktop vs.
menu entries.
Regards
Javier
Frank Küster
> Frank Küster wrote:
>> Neil Williams <li...@codehelp.co.uk> wrote:
>>
>>> I like Don's idea - remove the Debian menu from those window managers
>>> etc. that understand .desktop files and make the Debian menu aware
>>> of .desktop files for those other systems.
>>
>> Oh, please not.
[...]
> I actually do like Don's idea.
> The first thing I usually do, after installing KDE or Gnome is to
> disable the Debian menu in /etc/xdg/menus/(gnome,kde)-applications.menu,
Okay, as long as it can easily be configured, I see no problem in
disabling it by default. But there should be either a prominent menu
entry which is easy to find, or a README.Debian in an obvious package.
> for all the reason already given:
> - It duplicates entries (so it's potentially confusing for novice users)
That's a point.
> - Has no i18n
That isn't an argument to remove it, but for adding i18n support to it.
> - ugly (although I agree that's subjective). No png icons for
> applications, no icons for subdirectories, which imho makes it harder to
> recognize the categories quickly.
Having no icons is probably a feature - someone else said in this thread
that the icons are the reason for slow menus.
Josselin Mouette
> > Some of the users we target don't even know what a window manager is,
> > and they don't want to know it.
>
> Some of the users we target don't use any desktop environment, running
> headless servers. So let's remove KDE and GNOME.
If you have nothing to say apart proving that you don't want to
understand what people write, what's the point of contributing to a
mailing list?
Thijs Kinkhorst
> Some of the users we target don't use any desktop environment, running
> headless servers. So let's remove KDE and GNOME.
This problem is about defaults, not about removing things entirely.
Appearently every user gets menu items for all installed window managers.
Fine with me if it's easy to add an installed window manager to the menu, but
I do agree with the general point here that it's quite useless to build a
menu with those options for every user by default.
Thijs
Andreas Tille
> Fine with me if it's easy to add an installed window manager to the menu, but
> I do agree with the general point here that it's quite useless to build a
> menu with those options for every user by default.
... which speaks for a role based user concept.
Kind regards
Andreas.
Bastian Venthur
> Michael Biebl <bi...@debian.org> wrote:
>> for all the reason already given:
>> - It duplicates entries (so it's potentially confusing for novice users)
>
> That's a point.
That's *the* point in my opinion. Duplicated entries are confusing and
therefore not user-friendly.
>> - Has no i18n
>
> That isn't an argument to remove it, but for adding i18n support to it.
But why re-invent the wheel when .desktop files already provide this and
other features?
>> - ugly (although I agree that's subjective). No png icons for
>> applications, no icons for subdirectories, which imho makes it harder to
>> recognize the categories quickly.
>
> Having no icons is probably a feature - someone else said in this thread
> that the icons are the reason for slow menus.
It is not a feature of the menu, it is a bug of the DE beeing unable to
hide icons if the user wants it.
This isn't usually a problem for users of the mainstream DEs. And
honestly, I think the vast majority of users (including those with
exotic DEs) actually likes icons in the menu since that's what menus
usually have. I don't want to waste my time and energy to please *every*
user out there (that's virtually impossible), so I'd draw the line right
here: If you don't want icons, fine but please don't elevate this bug to
a feature.
Cheers,
Bastian
--
Bastian Venthur http://venthur.de
Debian Developer venthur at debian org
Josselin Mouette
écrit :
> It looks to me like they are properly categorised and its the GNOME menu
> which is misbehaving
I have indeed to back out my previous claim. I'm going to work on fixing
this issue in gnome-menus.
Josselin Mouette
> > I actually do like Don's idea.
> > The first thing I usually do, after installing KDE or Gnome is to
> > disable the Debian menu in /etc/xdg/menus/(gnome,kde)-applications.menu,
>
> Okay, as long as it can easily be configured, I see no problem in
> disabling it by default. But there should be either a prominent menu
> entry which is easy to find, or a README.Debian in an obvious package.
If disabled with NoDisplay=true, you can easily re-enable the Debian
menu in alacarte (accessible with a right click and "edit menus"). Would
that suit you?
> Having no icons is probably a feature - someone else said in this thread
> that the icons are the reason for slow menus.
Ideally, slow features should be optimised, not disabled. See my
proposal on -release for generalising icon caches, and upstream
proposals to optimise icon caches further by sorting icons the same way
they are accessed.
Cheers,
Frank Küster
> Le mardi 17 juillet 2007 à 08:52 +0200, Frank Küster a écrit :
>> > I actually do like Don's idea.
>> > The first thing I usually do, after installing KDE or Gnome is to
>> > disable the Debian menu in /etc/xdg/menus/(gnome,kde)-applications.menu,
>>
>> Okay, as long as it can easily be configured, I see no problem in
>> disabling it by default. But there should be either a prominent menu
>> entry which is easy to find, or a README.Debian in an obvious package.
>
> If disabled with NoDisplay=true, you can easily re-enable the Debian
> menu in alacarte (accessible with a right click and "edit menus"). Would
> that suit you?
You mean, right click anywhere in the menu and choose edit? That would
be very accessible, yes. And user-friendly ;-)