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

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



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


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