trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: March 2011

Re: [trinity-devel] Do we want to update Kmenu spec now? (was Re: [trinity-devel] (4) basic kmenu fixes - (getting rid of 'More Applications'))

From: "David C. Rankin" <drankinatty@...>
Date: Tue, 08 Mar 2011 13:52:57 -0600
On 03/08/2011 12:52 PM, Robert Xu wrote:
> Well, they're DE-specific. None of these will integrate with each other.
> Each DE parses the desktop file differently.
> 
>> >
>> > (2) If Trinity can find its menus in /opt/trinity/etc/xdg/menus, then is there
>> > any harm leaving it there to keep changes in gnome from mucking up the trinity menu?
>> >
> No. But GNOME won't muck up the trinity menu...
> David, each category in each *.desktop file defines where it will be placed.
> The Trinity applications.menu doesn't care about GNOME has, and vice versa.

In theory, yes,

  But my concern (Well I don't know the technical reason), anyway, I can't tell
you the number of times on both Arch Linux and openSuSE I have edited my menus
in Gnome only to go back into kde3 and find new entries in my kde3 menu that I
just made in Gnome. That's frustrating.

  I know all desktops share the standard menu definition and the gnome entries
are 'usually' "hidden" in kde and vice-versa. I don't want that to happen in
Trinity. That's why I asked about leaving them in /opt/trinity. But, I don't
think that has any bearing on the issue since $XDG_CONFIG_DIRS has both /etc/xgd
and /opt/trinity/etc/xdg in the path :)

  Who will update kdelibs in the svn tree to set the location to /etc/xdg?

  And back to my original question -

"Do we want to update the applications.menu specification to add
Graphics/Utilities to put kruler, kcolorchooser, etc.. in the Graphics/Utilities
submenu instead of letting them clutter up Graphics?"

  Might as well "kill 2 birds with one stone" while were are working in the area :)

-- 
David C. Rankin, J.D.,P.E.