wine menus

[Damjan Jovanovic]

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

[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

P.S. While we are at it, can someone look into bug 3548 please?

On 6/22/07, 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.
>
> 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

[Alexander Nicolaysen Sørnes]

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)..
> -
>
> The .lnk extension shows up even in the menu
> -
>
> 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  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

[Steven Edwards]

On 6/22/07, 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?

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.

[Frank Richter]

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.

[Steven Edwards]

On 6/22/07, Frank Richter  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?

[Damjan Jovanovic]

On 6/22/07, Steven Edwards  wrote:
> On 6/22/07, Frank Richter  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

[Alexandre Julliard]

"Damjan Jovanovic"  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.

[Steven Edwards]

On 6/23/07, Alexandre Julliard  wrote:
> "Damjan Jovanovic"  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?

[Vitaliy Margolen]

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.