If you're interested in my personal opinion on what the names in menus
should look like, read the bits under the first quoted section.
If you're interested in real development suggestions in how to make
GNOME conform to the spec, skip to the second block.
Matthias Clasen wrote:
On Thu, 2007-05-31 at 19:57 +0000, Kevin Kofler wrote:
X-Chat has a meaning, it's the particular IRC client called X-Chat. There's
several IRC clients in Fedora, including one called xchat-gnome which several
people think should be the default (in fact, I'd LOVE for it to become the
default, not because I actually use it, in fact I hate it, but because that
could lead you to leave the regular X-Chat alone!), so "IRC" is very vague as a
menu entry.
Yes, IRC is not a very good menu item either, "IRC client" would be a
bit better, except you really don't want "clients" in the menus. But I
stand by my claim that X-Chat is totally meaningless to regular users.
And KDE actually displays "X-Chat (IRC client)" if the user preferences are set
that way.
FWIW: My 2p worth is that this is a very sensible default - people who
know what X-Chat is can just click it. People who don't can read the bit
in parenthesis and mentally make the association so when they see just
"X-Chat" somewhere else (say, the window's titlebar in the launched
application) they know what it is, and they know what to call it when
they ask others for help.
*Personally* I know what everything does, so just "X-Chat" is fine. The
only time I'd want to see a totally generic name as a menu item is when
it's actually a launcher that picks my current default "IRC client" (or
"web broser" etc).
I can appreciate arguments for just the generic name - chiefly total
newbies who will only ever have one application per "task" installed...
... though I can think of several reasons why that might be bad.
However, I'm not interested in arguing them. Choice is good. If the FDO
spec [1] is followed when creating the .desktop files and GNOME follows
KDE's example in being able to create the menu items in a configurable
combination that covers all of the above, then everybody wins right?
[1] http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
Why does GNOME _still_ not support GenericName years after this
specification has been supposedly agreed on? IMHO, the real technical problem
lies there, mangling .desktop files like this is just papering over the
problem.
Because nobody implemented it ? Yes, that is not a great answer, but
just ignoring the fact in the name of blind guideline compliance is not
moving us forward.
OK, I'll put up. I'm prepared to do the coding and try and get it
submitted to GNOME. Assuming that was successful, Fedora could then pick
that up the next release and choose a default that suited their policy
(or just use whatever default GNOME goes with). Desktop files can be
updated to be in-line with the spec. I can change my display default and
live in silly-obscure-names-only-developers-could-come-up-with bliss.
If anyone has already tried this I'd be interested to know how they got
on. From a very quick search I couldn't see any recent discussion on
this topic within GNOME.
My curiosity got the better of me and I started digging. Traced the
GNOME panel code through to gnome-menus gmenu_tree_entry_get_name()
function. This just calls desktop_entry_get_name() which as you'd expect
returns the appropriate value of Name.
So, we extend desktop-entries.c to read and store GenericName, and
present a getter method. After that, the question is should gmenu-tree.c
(ie: gnome-menus) be making the decision on how to form the resulting
string... or whatever is using it (gnome-panel in our case). In order to
avoid duplicate code (or worse: code doing similar things with differing
behaviour), I would say the former. Only issue is that would seem [2] to
indicate that if we wish to make this configurable, gnome-menus needs to
gain a dependency on gconf or whatever. Currently:
$ ldd /usr/lib/libgnome-menu.so.2.1.3
linux-gate.so.1 => (0x0066b000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00c60000)
libfam.so.0 => /usr/lib/libfam.so.0 (0x00ba0000)
libc.so.6 => /lib/libc.so.6 (0x0074d000)
/lib/ld-linux.so.2 (0x80000000)
However:
$ rpm -q --whatrequires gnome-menus
gnome-panel-2.16.3-2.fc6
control-center-2.16.3-11.fc6
$ rpm -q --whatrequires /usr/lib/libgnome-menu.so.*
no package requires /usr/lib/libgnome-menu.so.2
no package requires /usr/lib/libgnome-menu.so.2.1.3
(Is that second query necessary?) Based on that survey of one machine,
it would seem adding a gconf dependency to libgnome-menu shouldn't be a
big issue.
Enough boring developer stuff. It's bedtime here, but I'll fire an email
off to the gnome-menus maintainer tomorrow and get their opinion. If
feedback is positive I'll get hacking on implementing that, along with
exposing an interface for the configuration.
[2] IANA GNOME configuration hacker.
--
Stuart
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
