Re: "Start menu" (continued ...)
On Tue, Sep 30, 2003 at 10:02:40PM +0200, Robert van Herk wrote: > Would such a system be appreciated by the you people? Or do you think I > should wait untill a better standarization is available? Or do you think > creating a Windows deamon and a Linux client is too much overkill for > such a feature? _Waiting_ for standards could mean waiting forever. Creating something on the other may very well be creating a _de_facto_ standard. -- regards, Jakob It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News
Re: "Start menu" (continued ...)
Robert van Herk <[EMAIL PROTECTED]> >As I understand, right now there are various "standards" on how to write >menus for Linux, that are incompatible. That would mean that writing a >"grand unified ;-)" start menu client as I discussed before is currently >impossible. > >What could be made already though, is a Wine deamon that talks to >shell32.dll internally and input/outputs with pipes to some linux >client, in order to serve the start menu items. This would link the >Windows start menu to Linux, in a tidy way. So the idea is that the >Windows program's output could be piped to some Linux client that >actually creates the menu dynamically, so it stays in continuous >synchronization with your Start menu directory. > > >Would such a system be appreciated by the you people? Or do you think I >should wait untill a better standarization is available? Or do you think >creating a Windows deamon and a Linux client is too much overkill for >such a feature? > >Also, if this feature would be handy, does anyone have expirience with >the KPanelAppMenu? I can't get the thingy to work yet... Just a thought which may or may not be completely out of proportion: In which sense can Wine and native Desktop be easily synchronized? I see a number of problems such as who should synchronize to whom. Why make an arbitrary Unix desktop synchronize to a Wine start menu? Why not the other way around? Wine builds in all other areas on top of the existing Unix platform. Is it really useful to start to base the native Unix desktop on Wine? Or is this the first step in getting Wine as yet another Unix desktop into the picture? Also the Wine start menu will usually contain mostly Windows or Winelib apps, I suppose. The Unix desktop would have to treat those entries accordingly, makeing proper distinction between them and native unix apps/scripts or whatever which of course shouldn't be a real problem. Maybe this has been discussed already in depth and I missed it? Rolf Kalbermatter
Re: "Start menu" (continued ...)
Just a thought which may or may not be completely out of proportion: In which sense can Wine and native Desktop be easily synchronized? I see a number of problems such as who should synchronize to whom. Why make an arbitrary Unix desktop synchronize to a Wine start menu? Why not the other way around? Wine builds in all other areas on top of the existing Unix platform. Is it really useful to start to base the native Unix desktop on Wine? Or is this the first step in getting Wine as yet another Unix desktop into the picture? I am not talking about a complete desktop, just about a little submenu in your K-menu, or Gnome menu, or whatever menu one could be using. Such a thing already exists, but is implemented with scripts instead of with a Wine deamon/linux client. The current system does not seem to be to flexible. Therefore, I suppose that a setup with wine deamon as a server and a linux client would be better. For example: one could easily add support for more desktop environments, without the changing the deamon. Robert
