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

[Brian J. Tarricone]

pre-email warning: i'm probably going to go rambling on quite a bit in 
this one, so either hone your skimming skills or make sure you have some 
free time on your hands ^_~.

On Thu, 26 Feb 2004, Tuukka Mäkinen wrote:

> Brian J. Tarricone wrote:
> > i'm not terribly thrilled with it either. but these guys seem to be 
> > generally useless in xfce.  the items that show up without the blacklist 
> > are things like kde's menu editor (oddly, there are 3 of them), and some 
> > very desktop-centric config panels.  the only one that i can see an 
> > argument for leaving alone is gnome-control-center, and even then, i 
> > don't see how it's terribly useful.  the point here is that these are 
> > all _desktop_ configuration apps, and really don't have much (if 
> > anything) to do with applications.  afaict, anyway.
> 
> We'll just have to get freedesktop menu implemented so that we can do
> <Exclude>
>     <Filename>gnome-control-center</Filename>
>     <Filename>kmenuedit</Filename>
> </Exclude>
> 
> This nicely solves this problem.

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'm becoming a bit ambivalent on this whole desktop menu spec thing.  i 
think specs are good, but i'm not so happy with just throwing out the 
current parser/generator.  i also think a requirement of any new system 
is that it supports the old ~/.xfce4/menu.xml format as well, which 
could get ugly.

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.

having said that, i'm not totally happy with what we have.  at present, 
the only way to make a customised menu with a subset of all apps in it 
is to use an as-yet-unwritten (yet relatively trivial) tool that 
generates a menu from desktop entries and outputs a menu.xml file, which 
you can then edit in xfce4-menueditor.  this isn't terrible (though not 
ideal), except when you consider the installation of new applications.  
this either requires a total menu regeneration, followed by the user 
pruning the entries they don't want, or you place the burden on the user 
to manually add the entry to their menu.  either option is, imho, 
unacceptable.

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.

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.

finally there's the matter of the existing codebase.  the two menu 
management ideas seem somewhat mutually exclusive.  i can't think of a 
great way of including both, at least not without basically having a big 
on/off switch for each method - either you use the old menu.xml file, or 
the new menu spec system.  not both.

danny, jean-francois, and i have already invested quite a bit of time 
and effort into the existing menu system.  while i'm personally willing 
to throw it out if something better comes along, i'd like that something 
to be a significant improvement.  i suppose we'll only know after we see 
the menu spec parser generate a prototype menu.

aside from some tweaking, i'm relatively happy with the menu system 
as-is.  well, except for two things.  one is a generator for the legacy 
menu hierarchies, which is pretty easy to write, but i've been holding 
off pending the menu spec stuff.  the other is the issue of making it 
easy for the user to edit the automatically generated menu while still 
making it possible for the system to add new apps as they are installed.  
i don't have a good answer to that problem at present.

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.

any comments/suggestions/etc.?

	-brian