(SOLVED) MintMenu won't load wine programs

[allypink]

I have installed Word 2007 via wine and although it starts when I use the gnome menu or click on the icon, it won't start using the MintMenu. All I get is "error file not found". Looking at some old posts this seems to have been a problem with MintMenu for some time. Is there a work around? I don't mind clicking on a shortcut to get Word running but the "cheese and kisses" is getting annoyed. I had to load Word 2007 just for her. Openoffice does the job for me. By the way Word 2007 runs fine in wine. No probs at all.

[Elisa]

BTW why u need Word in Linux?
Did u try to check the path:
/home/your_account/.wine/drive_c/Program Files/... ?

[allypink]

BTW why u need Word in Linux?
Did u try to check the path:
/home/your_account/.wine/drive_c/Program Files/... ?

I solved the problem by getting rid of the installed wine start command;

env WINEPREFIX="/home/al/.wine" wine C:\\windows\\command\\start.exe /Unix /home/al/.wine/dosdevices/c:/users/al/Start\ Menu/Programs/Microsoft\ Office/winword.lnk

to my own;

wine "/home/al/.wine/drive_c/Program Files/Microsoft Office/Office12/WINWORD.EXE"

As I said my wife is happy to use Linux provided she can have her chosen word processor........ Word. I although I am happy to use oo, Word is still one of the best and I have always been happy to pay for good software and Word 2007 works faultlessly and fast under wine.
Thanks for your interest. I hope my experience will help someone else.
Al.

[Statham]

Thanks for this. I am new to Mint and have found this WINE problem incredibly frustrating. This has solved my problem.

[jamesklyne]

I have this problem and this did NOT solve it.

[Elisa]

I have this problem and this did NOT solve it.

And what's your problem, put down more details...

[MestreLion]

For those that still have this issue, here's a simples workaround: just put double quotes around the last parameter (the path to the .lnk), and remove any scape backslash from that.

So, using the example from OP, this:

Code: Select all

env WINEPREFIX="/home/sb/.wine" wine C:\\windows\\command\\start.exe /Unix /home/sb/.wine/dosdevices/c:/users/sb/Start\ Menu/Programs/Microsoft\ Office/Microsoft\ Office\ Word\ 2007.lnk

would turn into this:

Code: Select all

env WINEPREFIX="/home/sb/.wine" wine C:\\windows\\command\\start.exe /Unix "/home/sb/.wine/dosdevices/c:/users/sb/Start Menu/Programs/Microsoft Office/Microsoft Office Word 2007.lnk"

It keeps the original command almost intact.

And dont forget to refresh the menu after the change: right-click menu icon in panel -> Reload Plugins

[wyrdoak]

Thanks allypink, I thought I was going to have to learn the Linux secret handshake before I found out what syntax to use for the "menu" command line for Wine programs. Works Like a charm. I only have one Window$ program that I haven't found anything close that written for Linux. I use it to re colorize old photos after I fix them in Gimp.

[MestreLion]

Thanks allypink, I thought I was going to have to learn the Linux secret handshake before I found out what syntax to use for the "menu" command line for Wine programs. Works Like a charm.

True, it works like a charm... for some apps. The syntax provided by allypink has the great advantage of being simple and ready-to-use, but it lacks some flexibility and features that may be needed for some apps/wine setups.

The most basic syntax (as he provided) can be generalized as:

Code: Select all

wine "/path/to/your/app.exe"

But... what is your app's executable file? And where is it? The above command requires you to browse through your windows tree, locate the installed directory, and find the right executable. Sometimes it is easy to find, sometimes it is not. What if your game has "loader.exe", "start.exe" and "game.exe" ? Which to choose? What if they need additional switches (arguments) to work? Is it "game /s /u" or "loader --start"? What about starting directory? Or compatibility settings?

That's why wine, by default, creates a command that points not to the executable itself, but to the menu entry created by the very install of program, the .lnk file. That is the correct way: let the application itself define which is the executable, the path, the parameters. In windows, you don't have to know which is the executable file of Word, or Internet Explorer. You use their generated menu entry. And that's what wine does. So the basic command is improved to:

Code: Select all

wine start /Unix "/unix/path/to/app's/menuentry.lnk"

Where "start" is a windows program, provided by wine, that can read a lnk file and launch it accordingly. The /Unix parameter tells start that the following will be a unix absolute path (/home/user/.wine/dosdevices/etc...), instead of a windows wine path (C:\Program Files\etc). And since start itself is located in System32 folder, wine's menu entry provides a full path to it, hence "C:\windows\system32\start.exe"

Although in 90% of cases the executable can be easily located, and can be launched without any additional parameters, wine chose a safer, fail-proof approach. (actually, it as no other choice: you may know that Office 2007 install.exe ends up installing Word in C:\xxxxx\Office12\winword.exe and excel in excel.exe. But wine has no way to know that!)

Last but not least, even that "enhanced command" is not enough for all scenarios: that will run the specified executable in the default wine prefix. A wine prefix can be thought of a "virtual machine". And wine allows you to have more than one prefix, each one being a completely independent, isolated environment. So you can tweak the settings for a given prefix (to make your app works better) without affecting apps installed in another, separate prefix. That's where the env WINEPREFIX="/path/to/prefix" from the original command comes from, and "/home/user/.wine" is the default prefix location.

Which leads us to the final, flexible, powerful yet fail-proof general syntax of wine's default menu entry:

Code: Select all

env WINEPREFIX="/path/to/prefix" [b]wine[/b] "C:\windows\path\to\start.exe" /Unix "/unix/path/to/menu/entry.lnk"

Looks like overkill when a simple 2 word "wine notepad" will work, but once you understand why and its advantages, you'll stick with the default command, no matter how scary it may seem at first glance.

[AlbertP]

It is failproof for the Gnome menu, but the Mintmenu doesn't like this command.

[wyrdoak]

When I was needing "Wine" more, the only "Mint Menu" entry that worked that "Wine" install was "Notepad". I have yet to find a program that "Wine" writes a command line that works in "Mint Menu" when installed. Sometimes it will create a good desktop launcher, but I have yet to see it make a good "Mint Menu" Launcher. And the command lines of the two are not interchangeable. And It has never written a command like the two posts in this thread.

[Garvan]

I have tried all the solutions in this post, and I am more than ever convinced that there is a bug or bugs in the handling of wine entries in the mintMenu. I can run scripts to start wine programs but only if I put them in locations other than the wine menu (such as the menu item office). It may be spaces in the path, or it may be deeply nested menu items do not work. I need some inspiration for further tests.

Does anybody know where the source code for mintmenu is? If its in C I might have a chance of understanding it.

Garvan

[AlbertP]

MintMenu is written in Python.

[Garvan]

MintMenu is written in Python.

Do you know where the source code is? Garvan

UPDATE: I found it a script named mintMenu.py, thanks. I also found the problem with my setup. Kindle was installed with this menu structure as seen in the menu editor (Main Menu):

mintMenu->Wine->Programs->Amazon->Amazon Kindle->Kindle

When I changed it to

mintMenu->Wine->Programs->Kindle

It worked correctly.

I am still sure it is a bug that it did not work as installed by Kindle's installer.

[josefg]

The MintMenu is also unable to run script files unless they start with #!/bin/bash or something corresponding (depending on the language).
I had some personal deb files that installed well under the Gnome menu, but refused to launch from the MintMenu because of this.
Could be that this issue is related to the wine-issue.