Launchpad has imported 53 comments from the remote bug at https://bugs.winehq.org/show_bug.cgi?id=3548.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2005-10-11T14:59:24+00:00 M-goemmel wrote: It's great that Wine is noticing that a .lnk file were written by IID_IPersistFile->Save and is creating a Linux compatibe program icon on the desktop. But why the .lnk file is also appearing on the desktop, which has (in my opinion) no use. Only a cosmetic thing Thanks Markus Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/0 ------------------------------------------------------------------------ On 2006-01-03T10:47:41+00:00 M-goemmel wrote: this affects http://www.emtec.com/zoc during setup phase Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/1 ------------------------------------------------------------------------ On 2006-07-09T04:10:28+00:00 Dan Kegel wrote: see also bug 5631. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/2 ------------------------------------------------------------------------ On 2006-09-14T12:55:43+00:00 Fatih Aşıcı wrote: I think, wine should use a separate directory for the desktop or there should be a way to disable such integrations before building wine. For example, I want to use a kicker menu extension for KDE which shows the start menu and some other dirs and do not want wine to try integrating itself to window manager. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/3 ------------------------------------------------------------------------ On 2006-12-29T18:19:15+00:00 KEYofR wrote: I have seen this too. AnzioWin / AnzioLite : http://www.anzio.com (terminal emulator) WinRAR : http://www.rarlab.com (compression & archiving util) SuSE 10.1 & 10.2 at least slosh:~ # wine --version Wine 0.9.24 Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/4 ------------------------------------------------------------------------ On 2007-03-23T04:12:11+00:00 Vitaliy-bugzilla wrote: *** Bug 7823 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/5 ------------------------------------------------------------------------ On 2007-03-23T14:05:00+00:00 Speeddymon wrote: Confirming. As far as I can tell, if you run winecfg and go to Desktop Integration tab, and click on Desktop under shell folders, and uncheck the Link To box, then only the Linux compatible icon is put on the Desktop, while the .lnk file is put into the Desktop folder in wine's drive_c/windows/profiles Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/6 ------------------------------------------------------------------------ On 2007-03-26T11:32:48+00:00 M-goemmel wrote: Hm, sounds like Wine is doing what it should. But is it useful to place the .lnk file also the the Linux desktop, when there is definitely no use for it? So maybe a exception for .lnk files would be useful... Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/7 ------------------------------------------------------------------------ On 2007-03-26T13:52:31+00:00 Speeddymon wrote: I suggested that, but unfortunately the developers can't reproduce this issue as far as I can tell. Actually if you have binfmt_misc setup properly on your system, you can use the .lnk files. So IMHO, wine should just drop .desktop icon creation and change the icon for the .lnk files. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/8 ------------------------------------------------------------------------ On 2007-06-22T06:43:29+00:00 Speeddymon wrote: Looking back into this, I'd like to correct what I said in my last message.. Don't drop .desktop file creation. The reason wine puts both the Freedesktop icon and the Window icon is due to winecfg having the windows desktop set to the same location as the Linux desktop (~/Desktop).. Either we need to change the default location to somewhere else, or (better yet) we should intercept .lnk file creation and put .lnk files to ~/.wine/drive_c/windows/Desktop while everything else goes to the linux desktop... Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/9 ------------------------------------------------------------------------ On 2008-06-12T14:42:48+00:00 Austin English wrote: Still present. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/10 ------------------------------------------------------------------------ On 2008-07-14T04:11:24+00:00 Vitaliy-bugzilla wrote: *** Bug 14459 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/11 ------------------------------------------------------------------------ On 2009-03-30T17:36:13+00:00 Austin English wrote: Still present. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/12 ------------------------------------------------------------------------ On 2009-05-17T10:30:28+00:00 Jacques Dong wrote: still presents Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/13 ------------------------------------------------------------------------ On 2009-07-04T15:42:31+00:00 AL3X wrote: Isn't that fixed in WINE 1.1.25 ? Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/14 ------------------------------------------------------------------------ On 2009-07-06T02:49:06+00:00 Austin English wrote: Looks like it. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/15 ------------------------------------------------------------------------ On 2009-07-07T17:35:09+00:00 Q-tommy wrote: It's NOT fixed. Just installed Trine demo using today's GIT and the bug is still present. How to reopen this bug? Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/16 ------------------------------------------------------------------------ On 2009-07-07T18:18:21+00:00 Austin English wrote: (In reply to comment #16) > It's NOT fixed. Just installed Trine demo using today's GIT and the bug is > still present. How to reopen this bug? Yeah, it appears to depend on the program. Firefox doesn't have the problem anymore, but, e.g., CCleaner does. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/17 ------------------------------------------------------------------------ On 2009-07-07T18:57:21+00:00 Q-tommy wrote: If the program is creating .lnk files in some temp directory, then it's copying the file to the desktop I think this might be a WONTFIX. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/18 ------------------------------------------------------------------------ On 2009-08-08T15:01:50+00:00 Imwellcushtymelike wrote: Created attachment 22902 Wine 1.1.27 +file +menubuilder (2.2MB) trace:file:CreateFileW L"C:\\users\\test\\Desktop\\Magic Workstation.lnk" GENERIC_READ GENERIC_WRITE creation 2 attributes 0x0 Magic Workstation (affected) doesn't appear to use a temp directory, and creates the .lnk directly on the desktop. +file,+menubuilder attached for perusal. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/19 ------------------------------------------------------------------------ On 2009-09-13T16:08:41+00:00 Erich-e-hoover wrote: Rather than going through this process of creating a ".desktop" file, couldn't Wine register a MIME type for the ".lnk" file and setup Wine to launch through the ".lnk" file directly? Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/20 ------------------------------------------------------------------------ On 2009-09-13T16:41:50+00:00 Vincent Povirk wrote: Yes, but the .lnk files would not work correctly for prefixes other than the default. Also, the desktop environment would probably have to create a winelib process to thumbnail the .lnk files, which could be expensive. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/21 ------------------------------------------------------------------------ On 2009-09-13T17:02:57+00:00 Erich-e-hoover wrote: (In reply to comment #21) > Yes, but the .lnk files would not work correctly for prefixes other than the > default. Also, the desktop environment would probably have to create a winelib > process to thumbnail the .lnk files, which could be expensive. Good points. While you could work around these issues pretty readily it's probably not really worth it. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/22 ------------------------------------------------------------------------ On 2009-09-18T01:35:37+00:00 Kristoffer Grundström wrote: It whould be good if links to programs was supported in the coming version of wine. It's lame that the icon looks & works like a textdocument. When you install stuff in Windows the icon has a picture so why not implement it? Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/23 ------------------------------------------------------------------------ On 2009-09-18T03:09:14+00:00 Dmitry-baikal wrote: Patches are more than welcome. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/24 ------------------------------------------------------------------------ On 2009-10-24T23:00:56+00:00 9-john-w wrote: Bug duplicated before I read these reports. Wine 1.1.31. The app icon and .lnk on the desktop, and an item appeared in the Wine menu structure. App allowed me to log into my B&N account, then crashed. Thereafter, would crash without allowing me to log into my B&N account. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/25 ------------------------------------------------------------------------ On 2010-03-28T14:03:47+00:00 Christoph Jüngling wrote: This behaviour happens with IMatch 3.6.0.90, too. See http://appdb.winehq.org/objectManager.php?sClass=version&iId=15969 for details. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/26 ------------------------------------------------------------------------ On 2010-05-05T19:36:57+00:00 Damjan Jovanovic wrote: Wine has 2 desktops: the user desktop under C:\users\user\Desktop, and the public desktop under C:\users\Public\Desktop. Applications that install .lnk files to the public desktop end up putting those files under ~/.wine/drive_c/users/Public/Desktop, from which winemenubuilder generates a .desktop file in ~/Desktop. All is well. But some applications (eg. WinRAR) want to install .lnk files to the user's desktop, which is ~/.wine/drive_c/users/user/Desktop, but that isn't a directory, it's just a symlink to ~/Desktop. So the .lnk file goes onto the real desktop instead of the hidden one. The selection of where to save the .lnk happen in shell32's IShellLink's IPersistFile COM interface, before winemenubuilder is launched. By the time winemenubuilder runs, the .lnk file already exists in the wrong place. It would be possible for winemenubuilder to move or delete the .lnk file after it generates the .desktop file, but then we'd lose track of the .lnk <-> .desktop mapping which winemenubuilder can do in order to delete .desktop files when the corresponding .lnk files are gone (because eg. the application was uninstalled). Some more intelligent Wine desktops <-> ~/Desktop synchronization might be necessary. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/27 ------------------------------------------------------------------------ On 2010-05-06T16:50:01+00:00 Austin English wrote: Perhaps we could move the .lnk's from the 'user' desktop to the 'public' desktop, which would keep it off the 'real' desktop, but also allow keeping track of it to remove the .desktop for later removal? Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/28 ------------------------------------------------------------------------ On 2010-05-07T08:36:18+00:00 Damjan Jovanovic wrote: (In reply to comment #28) > Perhaps we could move the .lnk's from the 'user' desktop to the 'public' > desktop, which would keep it off the 'real' desktop, but also allow keeping > track of it to remove the .desktop for later removal? The application tells shell32 to write the .lnk file to a specific C:\path\to\file.lnk location and remembers that location. Any attempt to move or rename the .lnk after that - even to the other desktop - loses that file and stops the application from deleting it on uninstall. The only thing I can think of that would fix this is to virtualize the filesystem - eg. use a FUSE module that merges ~/.wine/drive_c/users/user/Desktop with ~/Desktop when reading, but write .lnk files to ~/.wine/drive_c/users/user/Desktop and everything else to ~/Desktop. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/29 ------------------------------------------------------------------------ On 2010-05-17T19:28:41+00:00 Zilforever wrote: > The application tells shell32 to write the .lnk file to a specific > C:\path\to\file.lnk location and remembers that location. Any attempt to move > or rename the .lnk after that - even to the other desktop - loses that file > and > stops the application from deleting it on uninstall. so when some application want to write .lnk file to: ~/.wine/drive_c/users/user/Desktop handle it and redirect to: ~/.wine/drive_c/users/Public/Desktop and when uninstaller will want to delete it from: ~/.wine/drive_c/users/user/Desktop handle again and redirect to: ~/.wine/drive_c/users/Public/Desktop Can it work just like that? Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/30 ------------------------------------------------------------------------ On 2010-05-18T07:15:05+00:00 Damjan Jovanovic wrote: (In reply to comment #30) > > The application tells shell32 to write the .lnk file to a specific > > C:\path\to\file.lnk location and remembers that location. Any attempt to > > move > > or rename the .lnk after that - even to the other desktop - loses that file > > and > > stops the application from deleting it on uninstall. > > so when some application want to write .lnk file to: > ~/.wine/drive_c/users/user/Desktop > handle it and redirect to: > ~/.wine/drive_c/users/Public/Desktop > and when uninstaller will want to delete it from: > ~/.wine/drive_c/users/user/Desktop > handle again and redirect to: > ~/.wine/drive_c/users/Public/Desktop > > Can it work just like that? If the application wants to write .lnk file to: ~/.wine/drive_c/users/user/Desktop and Wine instead writes to: ~/.wine/drive_c/users/Public/Desktop the application still thinks it wrote to: ~/.wine/drive_c/users/user/Desktop and on uninstall tries to delete the .lnk from: ~/.wine/drive_c/users/user/Desktop where it isn't. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/31 ------------------------------------------------------------------------ On 2010-05-18T07:56:58+00:00 Hans-meelstraat wrote: Perhaps we can store the Wine prefix in the .lnk file somewhere. Then we'd write a Unix tool that extracts the prefix and runs 'wine start <shortcut>.lnk' in it. We'd register the tool with the native desktop as the handler for application/x-win-lnk and stop writing separate .desktop files when writing to the desktop folder. That leaves the thumbnail issue. Presumably thumbnails are cached to mitigate the performance issue? Alternatively we could have our own thumbnailer cache the generated icons. Another issue with this approach is that Gnome hides the .desktop extension but not the .lnk extension, like Windows does. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/32 ------------------------------------------------------------------------ On 2010-05-18T13:41:44+00:00 Vitaliy-bugzilla wrote: (In reply to comment #32) > Perhaps we can store the Wine prefix in the .lnk file somewhere. You can't do that. Some dumb installers have "pre-packaged" .lnk files that are just copied into place. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/33 ------------------------------------------------------------------------ On 2010-05-18T14:02:05+00:00 Hans-meelstraat wrote: Those are broken on Windows too, although differently. I recall that Windows has a dialog to search or browse a missing shortcut target. We could do something along those lines if we don't find the prefix. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/34 ------------------------------------------------------------------------ On 2010-05-18T14:18:52+00:00 Damjan Jovanovic wrote: (In reply to comment #33) > (In reply to comment #32) > > Perhaps we can store the Wine prefix in the .lnk file somewhere. > You can't do that. Some dumb installers have "pre-packaged" .lnk files that > are > just copied into place. Pre-packaged .lnk files that get just copied into place would bypass shell32's IShellLink's IPersistFile_Save, and winemenubuilder won't get invoked to build .desktop files. Such files also imply that you can't choose where to install the application, since that affects the .lnk contents? We shouldn't store the Wine prefix in the .lnk file, it could go into some other settings database (maybe not the registry, since that's local to each Wine prefix), from where the tool that starts .lnk can look up which Wine to use. At least we can patch Gnome and write a thumbnailer - it must be real fun and games to fix this on MacOS :-). Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/35 ------------------------------------------------------------------------ On 2010-05-18T14:55:59+00:00 Hans-meelstraat wrote: > We shouldn't store the Wine prefix in the .lnk file Why not? It appears to an extensible format, see IShellLinkDataList. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/36 ------------------------------------------------------------------------ On 2010-12-11T15:38:16+00:00 Albert Pool wrote: What should be possible, is that Wine converts a .lnk to .desktop when a program copies it into any Desktop folder. When a program tries to move the 'lnk' away, the .desktop is converted back to .lnk. If a program tries to rename/delete a .lnk on the desktop, it is done with the .desktop file. When a program queries a list of files in the desktop folder, the .desktop files seem (to the Windows program) to be named .lnk. Just an idea how to solve this problem. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/37 ------------------------------------------------------------------------ On 2011-04-02T12:54:00+00:00 Duncan Lithgow wrote: Still happening with Wine 1.3.16 and SketchUp 8.0.4811 Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/38 ------------------------------------------------------------------------ On 2011-11-02T04:29:17+00:00 Gatlinsullivan wrote: I tested this with Fedora 16 Beta+ with Wine 1.3.31 (Fedora's version) and Notepad++ 5.9.6. Both files appear. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/39 ------------------------------------------------------------------------ On 2012-04-24T08:42:54+00:00 Gatlinsullivan wrote: Still present in Notepad++ 6.1.1 using Fedora 16 x86_64 with wine 1.5.1. I'm not sure if any ideas on this have changed from Gnome3/Unity/OtherDE? with new method of not showing the files. Is this a large issue any more (for certain D.E.)? Has this move changed ideology for .lnk files being a viewable issue? Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/40 ------------------------------------------------------------------------ On 2012-04-24T09:36:08+00:00 Damjan Jovanovic wrote: (In reply to comment #40) > Still present in Notepad++ 6.1.1 using Fedora 16 x86_64 with wine 1.5.1. > I'm not sure if any ideas on this have changed from Gnome3/Unity/OtherDE? with > new method of not showing the files. Is this a large issue any more (for > certain D.E.)? Has this move changed ideology for .lnk files being a viewable > issue? 1. When the .lnk file is on the invisible desktop, we add a .desktop file on the visible desktop. 2. When the .lnk file is on the visible desktop, we add a custom thumbnail to that .lnk file. Point 1 already works. Point 2 is difficult, since each desktop environment has its own way of adding custom thumbnails to files. I wonder if the Portland project could add a desktop-independent tool for adding custom thumbnails to arbitrary files? Oh and Gnome 3 / KDE 4 have dropped support for so many XDG standards that I have even less hope for this working properly everywhere nowdays. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/41 ------------------------------------------------------------------------ On 2012-04-24T09:46:43+00:00 Speeddymon wrote: (In reply to comment #29) > (In reply to comment #28) > > Perhaps we could move the .lnk's from the 'user' desktop to the 'public' > > desktop, which would keep it off the 'real' desktop, but also allow keeping > > track of it to remove the .desktop for later removal? > > The application tells shell32 to write the .lnk file to a specific > C:\path\to\file.lnk location and remembers that location. Any attempt to move > or rename the .lnk after that - even to the other desktop - loses that file > and > stops the application from deleting it on uninstall. > > The only thing I can think of that would fix this is to virtualize the > filesystem - eg. use a FUSE module that merges > ~/.wine/drive_c/users/user/Desktop with ~/Desktop when reading, but write .lnk > files to ~/.wine/drive_c/users/user/Desktop and everything else to ~/Desktop. I like the virtualized filesystem idea, but its probably not practical for wine itself to implement, moreso something for a separate project (winetricks?) As for the link tracking, the same thing happens in Windows when one moves the .lnk file from their personal start menu folder or desktop to the public one. IMHO, it should just be considered expected behaviour for the links to be manually removed from the user's desktop when an app is uninstalled. That or do a forced check of the user's desktop for a .desktop file in the wine uninstaller tool, though I think the manual removal idea is better, personally. As far as your comment on GNOME and KDE dropping support for XDG standards, that's just sad. They used to be the pinnacle of openness, and the decreasing support for those standards just shows the winds of change are not always good. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/42 ------------------------------------------------------------------------ On 2012-04-24T09:55:25+00:00 Speeddymon wrote: (In reply to comment #42) > I like the virtualized filesystem idea, but its probably not practical for > wine > itself to implement, moreso something for a separate project (winetricks?) Thinking further about the virtualized filesystem idea, it should, in theory, be possible to virtualize the filesystem without needing a fuse driver, if the user were to setup a single file that were to hold the filesystem, sort of like a VHD or an ISO. I like the ISO idea better, but perhaps something that's not associated with a read-only media would be more appropriate. That way it could be mounted with the loopback driver already in the kernel and reads/writes would just take place to the mount point. It would make managing things easier because the user could create an fstab-like file for wine to read (or just do it in winecfg) to specify the mount point and path to the file containing wine's filesystem -- That's the one thing I've always disliked about wine was having the filesystem default to being under my home directory. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/43 ------------------------------------------------------------------------ On 2012-04-24T10:10:03+00:00 Speeddymon wrote: Rather, I dislike that it defaults to being in .wine under my home directory. I'd be OK with it being inside a hidden file, because it's a single file, rather than a whole folder that some tools (grep -R, find, etc) would then search through. Also, if the filesystem is virtualized from inside of a single file, then the user's desktop can be an actual folder and wine can track links to that between it and the real ~/Desktop. In addition it solves a lot of issues with multiple users in the linux system wanting to share a single prefix (could move the prefix out of ~/.wine and into /home/.wine or /home/wine as well as allowing one to have and manage multiple prefixes from within winecfg could become easier)... Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/44 ------------------------------------------------------------------------ On 2012-06-04T03:25:50+00:00 Glenn Stuart Morrissey wrote: Upon installation, Notepad ++ put desktop .lnk and program icon on desktop. No big problem, just delete desktop.lnk and get on with it. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/45 ------------------------------------------------------------------------ On 2012-12-20T10:11:43+00:00 Yurishish wrote: Its not a bug but feature. It allows to run Steam games in Crossover. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/46 ------------------------------------------------------------------------ On 2013-07-14T16:51:47+00:00 Pepes wrote: Still exist in wine1.6-rc4 Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/47 ------------------------------------------------------------------------ On 2014-02-07T01:41:06+00:00 Imwellcushtymelike wrote: Still present in wine-1.7.11-306-g8f289c8 Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/48 ------------------------------------------------------------------------ On 2014-07-16T16:03:51+00:00 Maik Wagner wrote: Still present in Wine 1.7.20 (CentOS 6.5 32-bit - Command and Conquer 3 - Tiberium Wars demo) Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/49 ------------------------------------------------------------------------ On 2014-07-26T14:37:49+00:00 Hanska2 wrote: Still the same as comment 1. wine 1.7.22 Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/50 ------------------------------------------------------------------------ On 2014-08-24T12:50:32+00:00 Hanska2 wrote: Has something changed? I have installed some programs via 1.7.24 and I only see 1 desktop icon, no lnk file anymore. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/54 ------------------------------------------------------------------------ On 2015-01-08T16:59:47+00:00 Corben wrote: Just installed Command and Conquer 3 Kane Edition with wine 1.7.18 (latest for Ubuntu 12.04 LTS?). Here also a .lnk and a desktop shortcut have been created. Reply at: https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1353024/comments/56 ** Changed in: wine Status: Unknown => Confirmed ** Changed in: wine Importance: Unknown => Low -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1353024 Title: Wine is creating .lnk files in addition to desktop shortcuts To manage notifications about this bug go to: https://bugs.launchpad.net/wine/+bug/1353024/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
