That is not to say that a rational cost/bene analysis will not ultimately favor a pure-linux implementation, depending on where your code is going.... but my bias would be towards a wine/winelib implementation. Do you forsee this code going into wine or into kde/gnome, or remaining as a separate thing? What relationship would you like between your code and wine's "explorer.exe," once it has one?
Since I want the menu to really integrate into your Linux environment, this would be a Linux executable. I guess than that if I'd want to query Wine for the needed links, that would have to be in a Wine executable. The problem is that this seems a bit of an overkill:
- I'd have to write a communcation protocoll between the Wine app and Linux app - A wine process would always be running, just for serving the menu. Killing your wineserver (what I personally like to do often :-)) would kill the start menu server too... It would take some fancy programming to get it back up again without the user noticing it (i.e. without some horrible crashing of the Linux client ;-))
Therefore, I would prefer to write just a number of Linux apps, one for each desktop environment. Maybe some could be merged together.
In the current setup, an abstract menu is kept as a datastructure in which the menu items are stored. So, for the different Linux desktop environments, only the very frontend of the application would have to be rewritten.
Thus, I am currently thinking whether it is worth it to make a Wine client / linux server setup. Is there a way to access the Wine dll's from a Linux program? This would ease things up severely.
Codeweavers has done a lot of work with shortcuts & menuitems, to make them work with different distros... so they might know what some of the nitty-gritty details are (Unfortunately, I do not).
Do you know if it is possible to recycle code from them? Since there product seems to be commercial...?
Greetings, Robert van Herk