-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
I'm not 100% sure this is the good mailing-list, but I think so.
I was trying to use the 'winemenubuilder' with CVS-20040605, but I got an error: ===== luca@gismo:~/cvs/wine$ ./wine winemenubuilder \ /home/luca/.wine/fake_windows/TreeView.lnk fixme:shell:SHELL32_DllCanUnloadNow (void): stub err:menubuilder:WinMain failed to build menu item for \ /home/luca/.wine/fake_windows/TreeView.lnk luca@gismo:~/cvs/wine$ =====
Now, to let you know my 'wine' environment, my 'fake_windows' came from the 'WineTools' [1] and then I installed: 1) DCOM98 (via WineTools) 2) Windows Installer (via WineTools) 3) Adobe Illustrator 10 4) Adobe Photoshop 7.0 5) BioEdit && TreeView && pDRAW32 (biological programs)
In ~/.wine/config, I've: ===== luca@gismo:~/cvs/wine$ grep shell /home/luca/.wine/config "ShellLinker" = "wineshelllink" "shell32" = "builtin, native" luca@gismo:~/cvs/wine$ =====
Is this a 'wine' bug or a problem with my configuration?
Thx, bye, Gismo / Luca
[1] http://franksworld.net/winetools.html
On Sat, 05 Jun 2004 16:45:23 +0200, Luca Capello wrote:
Is this a 'wine' bug or a problem with my configuration?
I think it's a Wine bug. wineshelllink is just out of date ... keeping the menu code working in the face of the change to the new menu system is a *lot* of work.
thanks -mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
on 06/06/2004 12:03 PM, Mike Hearn wrote:
On Sat, 05 Jun 2004 16:45:23 +0200, Luca Capello wrote:
Is this a 'wine' bug or a problem with my configuration?
I think it's a Wine bug. wineshelllink is just out of date ... keeping the menu code working in the face of the change to the new menu system is a *lot* of work.
it's definitively a WINE bug: if I'm right (but I'm not a programmer), the problem is near thess lines (at winemenubuilder.c:877 and following, but I'm not sure as I modified it and I don't know how to get again the CVS version): ===== r = IPersistFile_Load( pf, fullname, STGM_READ ); if( SUCCEEDED( r ) ) { /* If we something fails (eg. Couldn't extract icon) * defer this menu entry to reboot via runonce */ if( ! InvokeShellLinker( sl, fullname ) && bAgain ) DeferToRunOnce( fullname ); else WINE_TRACE("Success.\n"); } =====
In fact, r isn't SUCCEDED.
'wineshelllink' is never called by 'winemenubuilder', as putting a printf("[function name]\n"); in every function of 'winemenubuilder' gives this output: ===== luca@gismo:~/cvs/wine$ ./wine winemenubuilder \ /home/luca/.wine/fake_windows/TreeView.lnk WinMain next_token Process_Link fixme:shell:SHELL32_DllCanUnloadNow (void): stub err:menubuilder:WinMain failed to build menu item for \ /home/luca/.wine/fake_windows/TreeView.lnk luca@gismo:~/cvs/wine$ =====
So, if the above considerations are correct, this is a WINE bug. How to fix it, at least to have 'wineshelllink' invoked by 'winemenubuilder'? The successive related problems (keeping update the menu system and so on) are secondaries (and I've already an idea about them).
Thx, bye, Gismo / Luca
Luca Capello wrote:
luca@gismo:~/cvs/wine$ ./wine winemenubuilder \ /home/luca/.wine/fake_windows/TreeView.lnk WinMain next_token Process_Link fixme:shell:SHELL32_DllCanUnloadNow (void): stub err:menubuilder:WinMain failed to build menu item for \ /home/luca/.wine/fake_windows/TreeView.lnk luca@gismo:~/cvs/wine$
Have you tried giving winemenubuilder a Windows path instead of a Unix path? And, yes, it isn't very informative when things go wrong.
Rob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Robert,
on 06/06/2004 03:39 PM, Robert Shearman wrote:
Have you tried giving winemenubuilder a Windows path instead of a Unix path? And, yes, it isn't very informative when things go wrong.
I had already tried, but I forgot to mention it... I tried again :-( ===== luca@gismo:~$ cd .wine/ luca@gismo:~/.wine$ cd fake_windows/ luca@gismo:~/.wine/fake_windows$ ls Local Settings My Documents Program Files Temp TreeView.lnk windows luca@gismo:~/.wine/fake_windows$ cd /home/luca/cvs/wine/
luca@gismo:~/cvs/wine$ ./wine winemenubuilder C:\TreeView.lnk WinMain next_token Process_Link fixme:shell:SHELL32_DllCanUnloadNow (void): stub err:menubuilder:WinMain failed to build menu item for C:\TreeView.lnk
luca@gismo:~/cvs/wine$ ./wine winemenubuilder "C:\TreeView.lnk" WinMain next_token Process_Link fixme:shell:SHELL32_DllCanUnloadNow (void): stub err:menubuilder:WinMain failed to build menu item for C:\TreeView.lnk
luca@gismo:~/cvs/wine$ ./wine winemenubuilder "C:\TreeView.lnk" WinMain next_token Process_Link fixme:shell:SHELL32_DllCanUnloadNow (void): stub err:menubuilder:WinMain failed to build menu item for C:\TreeView.lnk =====
Well, it seems that the problem is somewhere but not due to the .lnk path... I'm still here for other testings, as I'd like to solve it. Next step will be solving the 'wineshelllink' script (but I can do the latter, while for the former I've not enough programming skills).
Thx, bye, Gismo / Luca
Luca Capello wrote:
Hi Robert,
Well, it seems that the problem is somewhere but not due to the .lnk path... I'm still here for other testings, as I'd like to solve it. Next step will be solving the 'wineshelllink' script (but I can do the latter, while for the former I've not enough programming skills).
Ok, we can do a deal. I'll look at the winemenubuilder code if you look at the wineshelllink script (as I've not got enough programming skills for the latter!). I'll try to increase the amount of error detection.
Rob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Robert,
on 06/08/2004 03:58 AM, Robert Shearman wrote:
Ok, we can do a deal. I'll look at the winemenubuilder code if you look at the wineshelllink script (as I've not got enough programming skills
for the
latter!). I'll try to increase the amount of error detection.
ok, no problem :-). Here my plan about the menu system:
- - get it working again on my machine (GNOME2 on Debian) - - extend it to other desktop environments (KDE2/3, GNOME1) on Debian - - extend it to other distros
IMHO, 'wineshelllink' should first create the .desktop file and then check where it should be copied and so on, based on desktop environment/distro. This means a complete change in the 'wineshelllink'. And I'll add a new option, something like '--path-to-be-installed' (where the .desktop entry should be copied): in this case, 'wineshelllink' can be invocated to created general menu entry (not desktop environment/distro specific).
What I'd like to do is an improvement in the WineTools [1], adding some features like installer choice for a general application and creation of GNOME menu entries using Freedesktop.org's .desktop files (in this way it could be extendend to all Freedesktop.org compliant desktops).
The first feature is very simple and already done. The second one is not difficult if the menu you want to create is done manually, I mean, the .desktop files are plain text and creating/managing them is quite simple. If you want to do it by the installation process, is a little harder and here IMHO the necessary steps: - - launch WineTools - - choose to install an application - - WineTools saves the 'windows/Start Menu/' tree - - the application is installed - - WineTools compares the new 'windows/Start Menu/' with the saved one and returns which menu entries (folder and launchers) should be created in this form (example with BioEdit [3]): folder > Programs/BioEdit launcher > Programs/BioEdit/BioEdit Help.lnk launcher > Programs/BioEdit/BioEdit.lnk - - WineTools creates the new folder and launchers
The last step is achieved by 'winemenubuilder/wineshelllink' and I was thinking about a new menu folder created by the WineTools install process (something like the included image): - - Start [to look like Windows, maybe 'Win32' is as good as 'Start'] - --- Tools (like 'winefile', 'wcmd' and so on...) - --- Programs (and this will reflect the 'Start Menu/Programs tree') - --- WineTools launcher
Obviously, once the launchers are created, the user can simply move them as he/she wants ;-)
If someone as other ideas, please let me know!
Thx, bye, Gismo / Luca
[1] http://franksworld.net/winetools.html
On Tue, 08 Jun 2004 18:03:38 +0200, Luca Capello wrote:
- get it working again on my machine (GNOME2 on Debian) - - extend it
to other desktop environments (KDE2/3, GNOME1) on Debian - - extend it to other distros
I don't think it makes any sense to support anything other than the XDG menu spec (which unfortunately not much supports yet, I think Fedora Core 2 has most of it in place). There is a standard, we should follow it and wait for the desktops to catch up. Then standards compliant desktop/distro setups work, and others don't.
Believe me, if you saw the pain we go through in CrossOver to make this work everywhere you would understand this attitude.
Menu support has been broken in Wine for so long that a few months longer while waiting for the One True Standard (XDG menus) to filter down to the people is not a big deal.
IMHO, 'wineshelllink' should first create the .desktop file and then check where it should be copied and so on, based on desktop environment/distro. This means a complete change in the 'wineshelllink'. And I'll add a new option, something like '--path-to-be-installed' (where the .desktop entry should be copied): in this case, 'wineshelllink' can be invocated to created general menu entry (not desktop environment/distro specific).
Unfortunately it's not that simple. It's not enough to create a .desktop file and put it in the right place. Modern desktops require you to edit XML files (best way is to use XSLT I'd say) and other funky things as well as creating .desktop files.
The first feature is very simple and already done. The second one is not difficult if the menu you want to create is done manually, I mean, the .desktop files are plain text and creating/managing them is quite simple. If you want to do it by the installation process, is a little harder and here IMHO the necessary steps: - - launch WineTools - - choose to install an application
- WineTools saves the 'windows/Start Menu/' tree - - the application
is installed
and returns which menu entries (folder and launchers) should be created in this form (example with BioEdit [3]): folder > Programs/BioEdit launcher > Programs/BioEdit/BioEdit Help.lnk launcher > Programs/BioEdit/BioEdit.lnk
- WineTools compares the new 'windows/Start Menu/' with the saved one
- WineTools creates the new folder and launchers
Why not simply use the current system which hooks IShellLink?
thanks -mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Mike,
on 06/08/2004 07:45 PM, Mike Hearn wrote:
I don't think it makes any sense to support anything other than the XDG menu spec (which unfortunately not much supports yet, I think Fedora Core 2 has most of it in place). There is a standard, we should follow it and wait for the desktops to catch up. Then standards compliant desktop/distro setups work, and others don't.
I agree. I didn't know this standard before and I think you're referring to the specifications at [1]. AFAIK (and I didn't read more docs), GNOME2 uses something similar to XDG to create its menu via the 'gnome-vfs-2.0'. Now, I should check how the XDG is integrated into desktop environments and distro (Debian can use it [2]).
Believe me, if you saw the pain we go through in CrossOver to make this work everywhere you would understand this attitude.
Well, I understood ;-) OTOH, the latest CrossOffice 3.0 Demo doesn't create menus on GNOME2.6/Debian unstable :-(
Menu support has been broken in Wine for so long that a few months longer while waiting for the One True Standard (XDG menus) to filter down to the people is not a big deal.
I agree, anyway it seems that not so much users know the existence of 'winemenubuilder', as searching on Google didn't give me results in 'wine-[devel|user]' or other user-support mailing-lists.
Unfortunately it's not that simple. It's not enough to create a .desktop file and put it in the right place. Modern desktops require you to edit XML files (best way is to use XSLT I'd say) and other funky things as well as creating .desktop files.
Yeah, I know that at least GNOME2 uses XML entries [3].
Why not simply use the current system which hooks IShellLink?
Well, it seems that I should read some more docs or maybe I didn't understand your question: does wine automatically start 'winemenubuilder' when you install an application? I mean: - - wine ./setup.exe - - the installation creates Windows Start menus as .lnk - - wine invokes 'winemenubuilder' to create XDG menu entries
Am I correct? If this is the case, I'm sure I'm going to use the current system!
Thx, bye, Gismo / Luca
[1] http://freedesktop.org/Standards/menu-spec [2] http://packages.debian.org/testing/admin/menu-xdg [3] http://www.gnome.org/learn/admin-guide/latest/menustructure-13.html
On Wed, 09 Jun 2004 10:53:59 +0200, Luca Capello wrote:
I agree. I didn't know this standard before and I think you're referring to the specifications at [1].
Yep.
AFAIK (and I didn't read more docs), GNOME2 uses something similar to XDG to create its menu via the 'gnome-vfs-2.0'. Now, I should check how the XDG is integrated into desktop environments and distro (Debian can use it [2]).
Current Gnome implements an older version of the spec. They are moving to the latest version. The older version really did not work too well for Wines needs - in fact, this is one of the reasons the new version was developed. You'll see fgouget@codeweavers.com on the credits for the spec.
Well, I understood ;-) OTOH, the latest CrossOffice 3.0 Demo doesn't create menus on GNOME2.6/Debian unstable :-(
... which nicely demonstrates my point.
Well, it seems that I should read some more docs or maybe I didn't understand your question: does wine automatically start 'winemenubuilder' when you install an application? I mean:
- wine ./setup.exe
- the installation creates Windows Start menus as .lnk
- wine invokes 'winemenubuilder' to create XDG menu entries
Am I correct? If this is the case, I'm sure I'm going to use the current system!
Well, Wine will run wineshelllink, AFAIK, which you can put anything you like in.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi again, Mike!
on 06/09/2004 01:02 PM, Mike Hearn wrote:
Current Gnome implements an older version of the spec. They are moving to the latest version. The older version really did not work too well for Wines needs - in fact, this is one of the reasons the new version was developed. You'll see fgouget@codeweavers.com on the credits for the spec.
Yep, I saw ;-)
Ok, now the first step: Wine application can't be divided into single categories, as you can't know from the application what does. I mean, when you launch 'wine ./setup.exe' you can't know if this 'setup.exe' is for an image editor or a wordprocessor and so on. So, we need to choose for a general category which will be applied to all 'Wine' applications. - From the given categories [1], IMHO the only suitable could be: --- Emulator --- Emulator of another platform, such as a DOS emulator
But, setting 'Adobe Photoshop 7.0' menu entry as an 'Emulator', it seems so strange at my eyes. So, IMHO, the best solution will be a totally new categories (called 'win32' or whatever we choose) in order to identify 'Wine' applications.
Before writing to the XDG mailing-list in order to have their opinion, I'd like to know the WINE developers one, please.
Well, Wine will run wineshelllink, AFAIK, which you can put anything you like in.
Wait, I didn't understand: ATM (so in the latest CVS) 'wine' doesn't call 'winemenubuilder'. right? But it could be implemented if 'winemenubuilder' (which includes 'wineshelllink') works...
Thx, bye, Gismo / Luca
[1] http://freedesktop.org/Standards/menu-spec/menu-spec-0.8.html#category-regis...
On Wed, 09 Jun 2004 14:58:20 +0200, Luca Capello wrote:
Before writing to the XDG mailing-list in order to have their opinion, I'd like to know the WINE developers one, please.
No, categories aren't used for Windows programs. They just don't have a Categories= key at all. Instead you want to directly include them via the menu definition files. See the XDG spec and the <Include> element (hence the fact that I think we'll need an XSLT engine to do this properly).
Wait, I didn't understand: ATM (so in the latest CVS) 'wine' doesn't call 'winemenubuilder'. right? But it could be implemented if 'winemenubuilder' (which includes 'wineshelllink') works...
OK, I'm not sure how things work in current CVS, I have not looked at it.
-
Luca Capello -
Mike Hearn -
Robert Shearman