Hi all, As some of you might know I am working on a Wine Start menu, for Linux. I have heard different things on this list about the way Windows treats the start menu. Some told me that it would be better to make a Windows (wine) client that reads the actual start menu by querying a Wine dll, while others told me that this is not neccesairy as all the links are contained in the Start Menu directory. From looking at my Windows installation, I must agree that it seems that all items in Programs are indeed in the Start Menu directory. So, my question is: would it be enough to create just a Linux program that synchronizes with this directory? Can anyone give me an example of a lnk file that IS actually missing in a Start Menu directory, but is there in his Program folder in the Windows start menu? Does anyone know how far people came at parsing the lnk files for Linux? I read something about the .lnk format, but I don't really feel like writing my own link file parser ;-). Does anybody know of parts of other software that could be recycled here? Grtz, Robert
On Monday 13 October 2003 01:46 pm, Robert van Herk wrote:
So, my question is: would it be enough to create just a Linux program that synchronizes with this directory? Can anyone give me an example of a lnk file that IS actually missing in a Start Menu directory, but is there in his Program folder in the Windows start menu?
Not offhand, but my guess is that, eventually, some fancy feature will be lacking unless wine/winelib is brought into the picture, for example, control-panel, "My Computer" or context-sensitive right-click menu-actions, the fancy docking capability of Windows Media Player 9, etc. One thing I do know for sure -- those don't /have/ to be .lnk files in there... they could be .exe's or .mp3's or whatever, and in Windows, "the right thing" would happen.... 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? 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). You may also want to look at LiteStep, ReactOS's explorer, and other windows shell-replacement software for clues. Good luck! -- gmt "The vice I am talking about is Pride or Self-Conceit: and the virtue opposite to it, in Christian morals, is called Humility. ... According to Christian teachers, the essential vice, the utmost evil, is Pride. Unchastity, greed, drunkenness, and all that, are mere flea-bites in comparison: it was through Pride that the devil became the devil: Pride leads to every other vice: it is the complete anti-God state of mind." --C. S. Lewis
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
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...?
I'd rather you didn't recycle our code; we do have some nice bits that we've put an awful lot of blood, sweat and tears into, and they tend to be the bits that encourage folks to send money our way... With that said, we're cheerful to share knowledge and tips; we've learned an awful lot the hard way. That's why Mike is so eager to see this done, btw... Cheers, Jer
Hi Robert, It's probably easier to just go with the link file reader first, but it will have some limitations: 1) you won't be able to get stuff in the shell namespace (eg. desktop icons, Control panel stuff) 2) you'll have to hardcode the location of the start menu (you can change the location of the start menu by playing with registry keys... see SHGetSpecialFolderLocation). 3) you'll have to duplicate the code to read .lnk files (see dlls/shell32/shelllink.c), and the code to read the icons from .exe files 4) if you want to support adding other stuff (eg. a .txt file) to the menus, you'll have to read the registry to get the right association, to pull the right icon from an exe. I guess that's not too much of a problem, and it's probably not worth the effort to make it perfect. The code that wine Crossover uses to generate KDE/Gnome menus is already merged into Wine. We just have a more extensive wineshelllink script that deals with more corner cases. Mike Robert van Herk wrote:
Hi all,
As some of you might know I am working on a Wine Start menu, for Linux.
I have heard different things on this list about the way Windows treats the start menu.
Some told me that it would be better to make a Windows (wine) client that reads the actual start menu by querying a Wine dll, while others told me that this is not neccesairy as all the links are contained in the Start Menu directory.
From looking at my Windows installation, I must agree that it seems that all items in Programs are indeed in the Start Menu directory.
So, my question is: would it be enough to create just a Linux program that synchronizes with this directory? Can anyone give me an example of a lnk file that IS actually missing in a Start Menu directory, but is there in his Program folder in the Windows start menu?
Does anyone know how far people came at parsing the lnk files for Linux? I read something about the .lnk format, but I don't really feel like writing my own link file parser ;-). Does anybody know of parts of other software that could be recycled here?
Grtz,
Robert
participants (4)
-
Gregory M. Turner -
Jeremy White -
Mike McCormack -
Robert van Herk