http://bugs.winehq.org/show_bug.cgi?id=25481
Summary: Desktop launchers generated by Steam use unregistered URL handler Product: Wine Version: 1.3.8 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: shell32 AssignedTo: wine-bugs@winehq.org ReportedBy: jkohen@users.sourceforge.net CC: Andrew@CodeWeavers.com, sirbubbles01@yahoo.com.au
After upgrading Steam to the new UI, the application icons Steam generates have a launch command doesn't work with Wine, because the steam URL handler isn't registered (at least in GNOME):
[Desktop Entry] Name=Uplink Exec=env WINEPREFIX="/home/user/.wine" wine winebrowser steam://rungameid/6910 Type=Application StartupNotify=true
$ wine winebrowser steam://rungameid/1510 fixme:ntoskrnl:KeInitializeTimerEx stub: 0x110f60 0 gvfs-open: steam://rungameid/1510: error opening location: La ubicación especificada no está soportada (That translates to "unsupported location.")
A desktop file generated with the older UI looks like this and launches the game fine:
#!/usr/bin/env xdg-open [Desktop Entry] Name=Deus Ex Game of the Year Edition Exec=env WINEPREFIX="/home/user/.wine" wine "C:\Archivos de programa\Steam\steam.exe" -applaunch 6910 Type=Application StartupNotify=true Path=/home/user/.wine/dosdevices/c:/Archivos de programa/Steam Icon=/home/user/.local/share/icons/b45c_hdtp.png
There's a workaround for this problem. Add an URL handler for the steam protocol to your desktop environment and have it run the following: wine "c:\Archivos de Programa\steam\steam.exe" %s
http://bugs.winehq.org/show_bug.cgi?id=25481
nE0sIghT update.microsoft@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |update.microsoft@mail.ru
--- Comment #1 from nE0sIghT update.microsoft@mail.ru 2011-05-15 14:13:46 CDT --- This is still issue in 1.3.20
http://bugs.winehq.org/show_bug.cgi?id=25481
byteframe byteframe@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |byteframe@gmail.com
--- Comment #2 from byteframe byteframe@gmail.com 2011-07-07 19:31:21 CDT --- I think can confirm this is still present in 1.3.23.
The desktop launcher created has: Exec=env WINEPREFIX="/home/byteframe/.wine" wine winebrowser steam://rungameid/6980
Clicking on it does nothing, running the command (minus the 'env') returns:
gvfs-open: steam://rungameid/6980: error opening location: The specified location is not supported.
http://bugs.winehq.org/show_bug.cgi?id=25481
Per Johansson per@morth.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |per@morth.org
--- Comment #3 from Per Johansson per@morth.org 2011-08-08 17:23:22 CDT --- winebrowser has no support for URLs registered by applications inside the wine prefix. It should have, however. The workaround mentioned only works if you only have a single wine prefix, and not at all on OS X (which has native Steam).
http://bugs.winehq.org/show_bug.cgi?id=25481
Per Johansson per@morth.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #4 from Per Johansson per@morth.org 2011-08-08 17:24:25 CDT --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=25481
--- Comment #5 from Per Johansson per@morth.org 2011-08-10 14:35:03 CDT --- Created an attachment (id=35913) --> (http://bugs.winehq.org/attachment.cgi?id=35913) Patch winemenubuilder to use start.exe instead of winebrowser for urls
Actually start.exe does the right thing, so the problem seems to be that winemenubuilder is hard coded to winebrowser. Try the attached patch (it works for me). It will only work for newly created desktop items (i.e. go into steam and select "Create desktop shortcut" again)
http://bugs.winehq.org/show_bug.cgi?id=25481
--- Comment #6 from Austin English austinenglish@gmail.com 2013-11-13 16:51:44 CST --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.6 or newer) wine? If so, please attach the terminal output in 1.7.6 (see http://wiki.winehq.org/FAQ#get_log).
http://bugs.winehq.org/show_bug.cgi?id=25481
--- Comment #7 from Per Johansson per@morth.org 2013-11-14 07:36:14 CST --- I submitted that patch. I believe it went into early 1.5. Only works on new shortcuts though.
https://bugs.winehq.org/show_bug.cgi?id=25481
--- Comment #8 from Bruno Jesus 00cpxxx@gmail.com --- This is the commit: http://source.winehq.org/git/wine.git/commitdiff/1a3b85a5bda240ef96a678781ef...
So, can we mark this as fixed?
https://bugs.winehq.org/show_bug.cgi?id=25481
--- Comment #9 from Per Johansson per@morth.org --- IMO yes. The pre-existing shortcuts issue has probably mostly solved itself by the passing of time.
https://bugs.winehq.org/show_bug.cgi?id=25481
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #10 from Austin English austinenglish@gmail.com --- (In reply to comment #9)
IMO yes. The pre-existing shortcuts issue has probably mostly solved itself by the passing of time.
Agreed.
https://bugs.winehq.org/show_bug.cgi?id=25481
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |1a3b85a5bda240ef96a678781ef | |1a98e595932dd
https://bugs.winehq.org/show_bug.cgi?id=25481
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.13.
-
wine-bugs＠winehq.org