[Xfce4-commits] CVS: xfce4/xfdesktop/src menu-dentry.c,1.7,1.8

[Tuukka Mäkinen]

Brian J. Tarricone wrote:
> i think we're getting a little ahead of ourselves, but this sounds like 
> it would work (tho i believe the <Filename> element here would actually 
> be the .desktop file name, right?).  anyway, tuukka, you mentioned to me 
> earlier that you were trying to put together a sample app that can 
> generate a menu.  how is this going?  i've looked through your menu 
> parser, but i'm not really sure how to best start integrating it.  at 
> any rate, i'm sure you've made a bunch of changes since then.

I haven't had much time this week to do it but the plan is to continue 
today and this weekend. Conversion from xmllib to glib xml is still 
unfinished so I haven't started doing any graphical test app.

Creating the application *shouldn't* be too hard when it basicly just 
needs to contain a menu but I haven't worked with gtk either...

> in addition, i think the philosophies behind how these two systems are 
> being written are a bit different.  tuukka's been writing his parser 
> from the viewpoint of the spec, with the goal of implementing the entire 
> spec.  that makes perfect sense of course - that's what a spec is for.  
> danny and i, in a somewhat opposite manner, have basically just looked 
> at the current menu system, decided what we wanted it to be able to do, 
> and just did it, consulting the spec along the way to make sure we 
> weren't doing anything broken.  i think in general our latter method 
> results in a faster, more efficient system, as you only get what you 
> need/want.

True, there's no way to be both standard compliant and fast. Or lets say 
it can be fast but not faster than than our own system. The question is, 
is it fast enough. After the menu is parsed for the first time there's 
no need to do it again so it's a one time penalty anyway.

> the freedesktop menu spec has some... interesting... features in it to 
> support menu editing.  the main options there are the {In,Ex}clude 
> elements, and the Move element.  this has a couple inherent problems.  
> the first is speed.  basically, you first generate a menu with 
> everything in it, then process the {In,Ex}clude and Move elements, and 
> add to, remove from, and rearrange the menu.  this strikes me as being 
> somewhat slow, though i can't think of a better way to do it.  the next 
> problem is that, if you aren't careful, you can end up with a rather 
> bloated and redundant menu file.  not only does this make the file 
> difficult to read, but it further slows down processing.  this means 
> writing yet another tool to clean it up periodically.

That is something that should be asked from fellows working with 
Freedesktop menu specification. Only reasonable way I can think of is to 
  have several system level menu.xml files. One for KDE, one for Gnome, 
...(KDE and Gnome might actually have several files) That way there 
wouldn't be so much possible unnecessary work.

Generating a clean menu.xml after parsing would of course be possible...

> 
> then there are the tweaks.  i've put a lot of stuff into the current 
> menu system to force it to behave more sanely than the spec would have 
> it behave.  one thing is combining a bunch of similar categories into an 
> "accessories" category.  the other is giving friendly/localised display 
> names for the categories.  both of these are possible with the menu spec 
> system, but it involves reimplementing the tweaks for that system.

I'm not sure what you mean by tweaks with menu system. The properties 
you mention are possible like you say. So only tweaking is to get some 
speed into it.


> so, i think for the time being i'm going to let the menu go as-is and 
> work on other things (icon themes, .desktop files, desktop 
> launchers/minimised icons, etc.).  if tuukka can get me a sample app 
> that generates a menu, i'll revisit it and we can try to come up with a 
> plan of what to do.

Working on it.

-Tuukka