Meaningless name (was: Re: rpms/xchat/devel ...)

[Stuart Children]

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