Hi At the moment, wine builds fd.o menus by calling winemenubuilder and wineshelllink when shell32's IPersistFile_fnSave is invoked. This both misses menus copied directly into the menu directory without calling IPersistFile_fnSave, and provides no way to remove the menus when the app is uninstalled. Wine also keeps .lnk files in ~/.wine/drive_c/windows/profiles/<user>/Start Menu/ just like Windows does, and those .lnk files seem like a much better representation of the menus that should appear on the system, because they are also deleted when an app is uninstalled. Is it possible to add a new utility, or patch an existing utility like wineboot, to synchronize between wine's .lnk files in the windows directory and the fd.o menus, instead of using winemenubuilder/wineshelllink? Would a patch that does that be okay? Thank you Damjan
I actually did some testing behind .lnk functionality (unscientific testing, that is) with wine a few months ago. Xorg actually fully supports Windows' .lnk files with 2 minor annoyances.. The .lnk files could theoretically be used as the links in the menus if these 2 annoyances could be fixed (probably by Xorg, not wine).. 1) The .lnk extension shows up even in the menu 2) The icon is just a picture of a window with a white background and a MS flag. If that icon could be changed to, say the icon specified inside the .lnk file, it would be perfect. Other than that, you can double click on a .lnk file and the program will be executed with wine (assuming BINFMT_MISC is setup properly on your system), including whatever command line options are specified to the program, in the lnk file. Now with all that being said, this still deviates from Freedesktop, so I kinda need to backtrack and say that I am not recommending that we USE those files as the menu entries. Quite the contrary! I think if we can find out what license the xorg code to parse the .lnk files is under, then we could potentially use that code to help us with a parser, or if it is not LGPL'ed then we might be able to get the code author's permission.. One other amendment to what I said above, because I haven't fully checked this.. It may just be KDE that supports the lnk files, and not Xorg.. As KDE is what I use, I don't have time to install/test with GNOME, or others. Someone please feel free to give it a shot with something other than KDE and post results back.. Hope that helps Tom P.S. While we are at it, can someone look into bug 3548 please? On 6/22/07, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote:
Hi
At the moment, wine builds fd.o menus by calling winemenubuilder and wineshelllink when shell32's IPersistFile_fnSave is invoked. This both misses menus copied directly into the menu directory without calling IPersistFile_fnSave, and provides no way to remove the menus when the app is uninstalled.
Wine also keeps .lnk files in ~/.wine/drive_c/windows/profiles/<user>/Start Menu/ just like Windows does, and those .lnk files seem like a much better representation of the menus that should appear on the system, because they are also deleted when an app is uninstalled.
Is it possible to add a new utility, or patch an existing utility like wineboot, to synchronize between wine's .lnk files in the windows directory and the fd.o menus, instead of using winemenubuilder/wineshelllink? Would a patch that does that be okay?
Thank you Damjan
-- Thanks Tom
Fredag 22 juni 2007 08:43, skrev Tom Spear:
I actually did some testing behind .lnk functionality (unscientific testing, that is) with wine a few months ago. Xorg actually fully supports Windows' .lnk files with 2 minor annoyances..
The .lnk files could theoretically be used as the links in the menus if these 2 annoyances could be fixed (probably by Xorg, not wine)..
1) The .lnk extension shows up even in the menu
2) The icon is just a picture of a window with a white background and a MS flag. If that icon could be changed to, say the icon specified inside the .lnk file, it would be perfect.
Other than that, you can double click on a .lnk file and the program will be executed with wine (assuming BINFMT_MISC is setup properly on your system), including whatever command line options are specified to the program, in the lnk file.
Now with all that being said, this still deviates from Freedesktop, so I kinda need to backtrack and say that I am not recommending that we USE those files as the menu entries. Quite the contrary! I think if we can find out what license the xorg code to parse the .lnk files is under, then we could potentially use that code to help us with a parser, or if it is not LGPL'ed then we might be able to get the code author's permission..
One other amendment to what I said above, because I haven't fully checked this.. It may just be KDE that supports the lnk files, and not Xorg.. As KDE is what I use, I don't have time to install/test with GNOME, or others. Someone please feel free to give it a shot with something other than KDE and post results back..
Hope that helps
Tom
Yes, that is part of KDE. I'm not sure why you would think it was a part of X.Org :/ Alexander N. Sørnes
P.S. While we are at it, can someone look into bug 3548 please?
On 6/22/07, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote:
Hi
At the moment, wine builds fd.o menus by calling winemenubuilder and wineshelllink when shell32's IPersistFile_fnSave is invoked. This both misses menus copied directly into the menu directory without calling IPersistFile_fnSave, and provides no way to remove the menus when the app is uninstalled.
Wine also keeps .lnk files in ~/.wine/drive_c/windows/profiles/<user>/Start Menu/ just like Windows does, and those .lnk files seem like a much better representation of the menus that should appear on the system, because they are also deleted when an app is uninstalled.
Is it possible to add a new utility, or patch an existing utility like wineboot, to synchronize between wine's .lnk files in the windows directory and the fd.o menus, instead of using winemenubuilder/wineshelllink? Would a patch that does that be okay?
Thank you Damjan
On 6/22/07, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote:
Is it possible to add a new utility, or patch an existing utility like wineboot, to synchronize between wine's .lnk files in the windows directory and the fd.o menus, instead of using winemenubuilder/wineshelllink? Would a patch that does that be okay?
Maybe we could duplicate the lnk dumper in tools/winedump/lnk.c and import parts of it in to explorer. As part of explorer startup the lnk parser could run and check to see the xdg menus for Wine and the~/.wine/drive_c/windows/profiles/<user>/Start Menu is in sync. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On 22.06.2007 08:21, Damjan Jovanovic wrote:
Is it possible to add a new utility, or patch an existing utility like wineboot, to synchronize between wine's .lnk files in the windows directory and the fd.o menus, instead of using winemenubuilder/wineshelllink? Would a patch that does that be okay?
Another idea: let wine's explorer monitor the start menu directory and let it update the fd.o menu as soon as it detects a change. This way changes to the start menu folder are instant, at least while explorer runs. -f.r.
On 6/22/07, Frank Richter <frank.richter(a)gmail.com> wrote:
Another idea: let wine's explorer monitor the start menu directory and let it update the fd.o menu as soon as it detects a change. This way changes to the start menu folder are instant, at least while explorer runs.
Alexandre: do you have any recommendations about this? Should explorer poll periodically and be in charge of keeping the lnk's in sync with the fd.o? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On 6/22/07, Steven Edwards <winehacker(a)gmail.com> wrote:
On 6/22/07, Frank Richter <frank.richter(a)gmail.com> wrote:
Another idea: let wine's explorer monitor the start menu directory and let it update the fd.o menu as soon as it detects a change. This way changes to the start menu folder are instant, at least while explorer runs.
Thank you for that idea Frank, I was wondering how to detect changes.
Alexandre: do you have any recommendations about this? Should explorer poll periodically and be in charge of keeping the lnk's in sync with the fd.o?
With FindFirstChangeNotification() and FindNextChangeNotification() you don't even have to poll, and those are implemented on wineserver using inotify, so it's very efficient.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
I'm already working on it :-) Damjan
"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes:
With FindFirstChangeNotification() and FindNextChangeNotification() you don't even have to poll, and those are implemented on wineserver using inotify, so it's very efficient.
Except it doesn't work on many platforms, so it can't be the standard mechanism. -- Alexandre Julliard julliard(a)winehq.org
On 6/23/07, Alexandre Julliard <julliard(a)winehq.org> wrote:
"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes:
With FindFirstChangeNotification() and FindNextChangeNotification() you don't even have to poll, and those are implemented on wineserver using inotify, so it's very efficient.
Except it doesn't work on many platforms, so it can't be the standard mechanism.
Could we detect if it fails and then have a fallback case where it sync's the lnk's to xdg-menus on explorer shutdown? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Damjan Jovanovic wrote:
Hi
At the moment, wine builds fd.o menus by calling winemenubuilder and wineshelllink when shell32's IPersistFile_fnSave is invoked. This both misses menus copied directly into the menu directory without calling IPersistFile_fnSave, and provides no way to remove the menus when the app is uninstalled. Installers that doing this sort of stuff are broken by design. They usually don't work well/at all on different language systems. Or the pre-made .lnk files won't work if app is installed into different location.
Is it possible to add a new utility, or patch an existing utility like wineboot, to synchronize between wine's .lnk files in the windows directory and the fd.o menus, instead of using winemenubuilder/wineshelllink? Would a patch that does that be okay?
All you really need to synchronize is something like this: find ~/.wine/drive_c/ -name "*.lnk" -exec wine winemenubuilder '{}' \; However this is "one-way" and it won't remove uninstalled links (which is pretty easy to add). But this still does not account for number of things: 1. Desktop entries (they are tricky - winemenubuilder uses some "magic" to decide if the link should be placed on the desktop or menu). 2. Multiple WINEPREFIXes 3. User modified .desktop entries (added extra parameters, env variables, etc.) 4. User (re)moved Wine menu entries using KDE/Gnome/etc menu editor(s). I can see this can be a huge annoyance when user deletes something and it's coming back. I think what you can do, is to move location where Wine creates it's XDG links and menu structure somewhere under WINEPREFIX itself. Not sure if this would help or not. Most installers won't remove directories if they are not empty, even if created during the install. Vitaliy.
participants (7)
-
Alexander Nicolaysen Sørnes -
Alexandre Julliard -
Damjan Jovanovic -
Frank Richter -
Steven Edwards -
Tom Spear -
Vitaliy Margolen