Dynamic menu plugins

Mike Hearn mike at theoretic.com
Fri Sep 12 16:52:22 EEST 2003

Hi all,

So I was chatting to Mike McCormack on IRC about various wine things,
and the topic of menu integration came up. While the current spec is
much better for Wine than previous ones were, he felt that there were
still some issues remaining - in particular, Windows also generates its
"start menu" on the fly, from various sources around the system. Having
to manually synchronize the state of Wine with the menu spec is hard,
going to be a big source of bugs and so on.

An easier way is to dynamically construct that part of the menu on the
fly as well, like Windows does, except that instead of using .desktop
files, the implementation has to be able to read the fake windows drive,
parse the  .lnk files etc - eurgh, ugly (especially when you consider
that .lnk shortcut files are based on OLE Structured Storage).

So - one solution is maybe to have a new element in the .menu file spec,
so you can write

	<plugin library="libwinemenus.so.0"/>

and have a simple, controversy-free C interface that libraries can
expose to return a tree of menu nodes. Issues might be:

* the format of the nodes, linking with libxml and using its structures
would be easy, but I'd guess some (kde?) desktops might not want to use

* dynamic updates: how does the plugin notify the implementation of
changes? Does it need to, or can it be polled whenever the menu is

* menu editing. what happens when a user wishes to drag the launchers
around, copy them etc...

Advantages to Wine, at any rate, would be that the plugin could parse
the windows menu files into the format needed by the free desktop
implementations on the fly, which also lets you do things like control
panel applets (the control panel listing is generated on demand by
scanning certain directories for .cpl files in windows), and it can hook
up with Wine when its running so that installers which create the links
immediately update the menus.

It's not a totally critical need, it *is* possible to simply hook up the
IShellLink API to generating .desktop files, but it's a bit harder to do
things with it once you have gone past that point - for instance
uninstallers typically just delete the file, the OS is never notified
explicitly that the menu link has been removed, so there's no
opportunity to synchronize with the linux menus.

What do implementors think? Would this be too hard to do reliably?

thanks -mike

More information about the xdg mailing list