Incomplete uninstall of wine applications
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Wine |
Fix Released
|
Low
|
|||
wine (Ubuntu) |
Fix Released
|
Low
|
Unassigned |
Bug Description
When I uninstall an application with the Uninstall Wine Application, it erases all the folders of this application but the application uninstalled stills in Applicationx->Wine. Why?
Changed in wine: | |
assignee: | nobody → ubuntu-wine |
Sam Peterson (peabodyenator) wrote : | #1 |
Changed in wine: | |
status: | New → Confirmed |
Loye Young (loyeyoung) wrote : Re: [Bug 116080] Re: Incomplete uninstall of wine applications | #2 |
On Sunday, October 14, 2007 6:09:54 am Sam Peterson wrote:
>While it's not that
> important. It would be nice to have this fixed.
It's only not important if you know what's going on. Regular users, especially
those who are installing Windows apps, don't know (nor should have to care)
what's going on behind the scenes. Users are just going to think it's still
installed, but merely turned off.
I vote for a higher importance level.
John Pye (jdpipe) wrote : | #3 |
Yes, I vote for a higher importance too. If the applications menu can't be reverted to its original state, then wine shouldn't change it in its first place, as it breaks the whole "uninstall" concept.
In Wine Bugzilla #10277, elhoir (jfarroyo82) wrote : | #4 |
I am using Ubuntu 7.10 which places a Wine submenu under Application menu, where there also are Sound & Video, Office, Programming and so...
In that Wine menu there are every software that i install from Wine
But when i uninstall software, or remove .wine directory, those softwares are not removed from that Wine submenus
In Wine Bugzilla #10277, Jonathan Thomas (echidnaman) wrote : | #5 |
Confirming here in Kubuntu 7.10.
Hooray for KMenu edit, though. :P
In Wine Bugzilla #10277, Vitaliy-bugzilla (vitaliy-bugzilla) wrote : | #6 |
Confirming.
In Wine Bugzilla #10277, Juan-lang (juan-lang) wrote : | #7 |
I agree with you that uninstalling a program, or wine, should remove the menu entries. Just removing the .wine directory really can't remove these entries, however.
In Wine Bugzilla #10277, Austin English (austinenglish) wrote : | #8 |
Shouldn't this be up to the distribution to handle?
In Wine Bugzilla #10277, elhoir (jfarroyo82) wrote : | #9 |
(In reply to comment #3)
> I agree with you that uninstalling a program, or wine, should remove the menu
> entries. Just removing the .wine directory really can't remove these entries,
> however.
>
i think it can, since wine loads its content from the local directory of each user
it would be just a redirection of pointers, i think so...
In Wine Bugzilla #10277, Brandontheninja (brandontheninja) wrote : | #10 |
Okay, I just figured out if you go to ~/.local/
In Wine Bugzilla #10277, elhoir (jfarroyo82) wrote : | #11 |
(In reply to comment #6)
> Okay, I just figured out if you go to ~/.local/
> 'wine', it will remove those entries from the Applications menu.
>
i dont think that solution is fine, since that file is shared with all users, and we only want to delete our wine programs file menu, not others one.
In Wine Bugzilla #10277, Vitaliy-bugzilla (vitaliy-bugzilla) wrote : | #12 |
(In reply to comment #7)
"~" means your home directory. So no you removing only your [user] links, not some one else's. You can more that directory and see what will happen. But it's more then just that directory. See FAQ on Wine's wiki for more details.
In Wine Bugzilla #10277, Scott Ritchie (scottritchie) wrote : | #13 |
Is the issue that Wine simply doesn't implement the "uninstall this shortcut" method in Windows uninstallers? Or do Windows uninstallers rely on Windows keeping track of what shortcuts it installed and doing it for them?
In the latter case, we should be keeping a cache somewhere of the shortcuts Wine has created so we can uninstall applications cleanly.
eldhaber_unit (eldhaber-unit) wrote : Re: [Bug 116080] Re: Incomplete uninstall of wine applications | #14 |
Ayus 'to ah! Thank you!
----- Original Message ----
From: Scott Ritchie <email address hidden>
To: <email address hidden>
Sent: Saturday, November 17, 2007 8:26:32 AM
Subject: [Bug 116080] Re: Incomplete uninstall of wine applications
** Bug watch added: Wine Bugzilla #10277
http://
** Also affects: wine via
http://
Importance: Unknown
Status: Unknown
--
Incomplete uninstall of wine applications
https:/
You received this bug notification because you are a direct subscriber
of a duplicate bug.
_
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how. http://
Changed in wine: | |
status: | Unknown → Confirmed |
In Wine Bugzilla #10277, Damjan Jovanovic (damjan-jov) wrote : | #15 |
The freedesktop.org menus are the most complex out of all operating systems out there, and wine goes through a laborious process to make them.
Removing them is not simple. I believe wine does remove the .lnk files in ~/.wine/
A while back I thought up a scheme where explorer monitors the .lnk menus and the freedesktop menus and syncs them in real-time. But there are more problems, like if you delete a freedesktop menu it will be recreated as long as the .lnk file is there, unless you keep another list of created menus and don't create a freedesktop menu twice, but you have to keep track of .lnk deletions and remove from that list...
Yes, it's an incredible amount of work.
In Wine Bugzilla #10277, Dan Kegel (dank) wrote : | #16 |
This affects lots of apps. Let's fix it for wine-1.2.
Andreas Braml (a-strich-b) wrote : | #17 |
From the Wine FAQ at http://
<quote>The uninstaller does not remove menu entries. To remove all Wine created menu entries run the following commands
rm -f $HOME/.
rm -rf $HOME/.
rm -f $HOME/.
rm -f $HOME/.
</quote>
In Wine Bugzilla #10277, Austin English (austinenglish) wrote : | #18 |
*** Bug 8717 has been marked as a duplicate of this bug. ***
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #19 |
Would it be possible for Wine to keep it's own database somewhere inside ~/.wine and just link to is some way? The database could be linked to if the user adds it to XDG_DATA_DIRS, but that would be hard to do in a uniform way and changes would not be instant. Or is there some better way?
In Wine Bugzilla #10277, Vincent Povirk (madewokherd) wrote : | #20 |
Shouldn't using the TryExec setting to link the menu shortcuts to their .lnk files solve this problem? From reading the spec, it seems like that should prevent the shortcuts from being displayed (even though files are still present) when .lnk files go away.
In Wine Bugzilla #10277, Vincent Povirk (madewokherd) wrote : | #21 |
It's no good. The latest version of the spec says that the entry can be ignored if the file TryExec points to is not executable, which .lnk files are not.
TryExec ALMOST does what we need without requiring something crazy in Wine, and GNOME happens to implement it in a way that makes it work.. on GNOME at least, for now. It's so close I'm tempted to ask them to add a new field for non-executables.
In Wine Bugzilla #10277, Vincent Povirk (madewokherd) wrote : | #22 |
Created an attachment (id=13315)
proof of concept patch
This is a rough attempt using the TryExec approach. Some issues:
* We have to chmod +x the .lnk file, which is sort of hacky.
* GNOME apparently expects the TryExec field to be strictly escaped (spaces replaced with \s and all).
* GNOME does not notice immediately when .lnk files are removed. I had to restart gnome-panel before it would see the changes.
I've not tested with any other desktop environments.
The advantage over some monitoring and/or syncing approach is that this is much simpler to implement and will hide the links if ~/.wine is removed.
In Wine Bugzilla #10277, Austin English (austinenglish) wrote : | #23 |
*** Bug 13874 has been marked as a duplicate of this bug. ***
In Wine Bugzilla #10277, Vincent Povirk (madewokherd) wrote : | #24 |
We could also create some new field in the .desktop files, e.g. X-Wine-Lnkfile, so that a process could periodically delete .desktop files whose .lnk files no longer exist. This is like the syncing approach except that it does not require the creation of some new "database" so would be easier to implement.
There is still the problem of deciding when to run this process.
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #25 |
But how does wine create a shortcut in the first place?
I guess there is a hook somewhere so that when an app writes a .lnk, some code is called that reads it and creates the appropriate freedesktop shortcut.
If so, I don't see why it couldn't be done the other way as well. When creating a freedesktop shortcut, wine should map the source .lnk to the files that were created for the freedesktop shortcut, most probably in the registry. Then add another hook to the delete function, and if the file being deleted is a .lnk, look it up in the registry and delete all parts of the freedesktop shortcut.
In Wine Bugzilla #10277, Vincent Povirk (madewokherd) wrote : | #26 |
There's no hook. Windows has API for creating links (IShellLink), and Wine creates .desktop files when they are saved.
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #27 |
But who cares?
As I said, make wineshelllink map the shortcut to the files created in the registry. Then create another progam, such as "wineshelldelete", that is passed the location of the .lnk (existent or not), that would delete all the shortcut files associated with it. Finally, add a hook in the delete function to run wineshelldelete if the file ends in .lnk. Such a hook would really be no problem and would cause no performance problems.
In Wine Bugzilla #10277, Thesource-mail (thesource-mail) wrote : | #28 |
Connecting .lnk files to .desktop ones is a bad idea. Why wine creates .lnk files in the first place? They are useless in linux and I don't want to see this garbage on my desktop. We need some other way of handling launchers. Using registry perhaps.
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #29 |
It's a fact that Windows deletes shortcuts by deleting .lnk files.
Yes, there would be a problem with desktop shortcuts specifically, becouse Wine tends to delete them, so the uninstallers might check if they still exist before calling "delete" on them. But this is no problem for the start menu, as the .lnk files reside in private folders which are invisible to the user. Actually, wine could keep desktop shortcuts in a private folder as well and avoid the hassle with deleting them.
For my plan to work, each shortcut should have independent .menu files.
Currently, when wineshelllink is adding a shortcut to an existing menu, it overwrites the corresponding .menu file and automatically adds all prevous menu entries to the new one. This is problematic, becouse when deleting a shortcut, wine would have to actually parse the menu file and remove only the shortcut's entry from it (<FileName>).
So the idea is that when a shortcut is being created, only new files would be added to the xdg database. This way deleting them would cause no harm to other menu entries.
I've tried splitting a .menu file with multiple entries in parts so that each one has just one <Filename> entry, and KDE merges the entries properly. I'm modifying wineshellink right now to do this.
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #30 |
Created an attachment (id=14602)
wineshellink seperate wineprefixes, independent files, record created files
This patch does the following:
- It changes the way files in the database are created so that they can be safely deleted when deleting a shortcut.
- It completly seperates wine prefixes when adding shortcuts to the start menu (different root Wine folders). This is required becouse all management would be local to a single wine instance.
- Maked wineshellink record all files created to $WINEPREFIX/
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #31 |
Created an attachment (id=14603)
wineshellunlink - removes created shortcuts
This is a shell script that removes a specific shortcut created with my version of wineshelllink. It should be used the same way as wineshelllink is, but only the --menu, --desktop and --link options.
Example, if a shortcut was created this way:
wineshelllink --menu --link 'Programs/
you can remove it by calling
wineshellunlink --menu --link 'Programs/
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #32 |
Created an attachment (id=14623)
wineshellink seperate wineprefixes, independent files, record created files
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #33 |
Created an attachment (id=14624)
wineshellunlink - removes created shortcuts
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #34 |
Created an attachment (id=14625)
winemenubuilder - work with previous patches, add scalling for removed .lnk files
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #35 |
The three patches I have just attached together provide you the ability to update the xdg database and remove shortcuts whose .lnk files have been removed using the command "winemenubuilder -s".
It will only work for shortcuts created using the above patches.
NOTE: wine tends to use "wineshelllink" from $PATH. Make sure wine is using my version of wineshelllink.
How it works:
- wineshellink records created files to $WINEPREFIX/
- winemenubuilder records the .lnk locations of new shortcuts to HKCU/Wine/
- "winemenubuilder -s" scans the registry for .lnk files, calls wineshellunlink on nonexistent .lnk files, and removes their registry entries
Right now, "winemenubuilder -s" it will only work good for menu shortcuts, and will automatically delete all recorded desktop shortcuts, as wine deletes their source .lnk files.
Ravichandra R (ravichandrra) wrote : | #36 |
Thanks it worked for me.
In Wine Bugzilla #10277, Vitaliy-bugzilla (vitaliy-bugzilla) wrote : | #37 |
*** Bug 14385 has been marked as a duplicate of this bug. ***
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #38 |
Once the .lnk files are linked to the menu entries (example my previous patches), Wine could just sync the menu on startup (remove entries whose .lnk files no longer exist, in case the user removed them), and then use filesystem modification notification to monitor their removal while Wine is running (inotify, whatever it is). This would be a much saner method than adding a hook to detect delections.
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #39 |
Created an attachment (id=14895)
lnk file watcher plus my previous modifications
I've written some code to monitor .lnk files that are recorded to the registry. Right now I've added it do winemenubuilder because it has all the functions I need. This patch also includes all my previous modifications.
To try it out, first make sure my versions of wineshelllink and wineshellunlink are the first in PATH, and make sure wineshelllink is executable. After creating some start menu shortcuts, refresh your desktop so you see them (kde: kbuildsycoca). Then run "winemenubuilder -d" and leave it running. Now every time you delete a .lnk file from "c:\windows\
The code could probably be added to explorer to avoid creating a new process. Anyway, what do you think about my approach?
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #40 |
Created an attachment (id=14896)
mailslot async fix
this patch is also required, it fixes some Wine bug I have stumbled on
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #41 |
Created an attachment (id=14897)
lnk file watcher plus my previous modifications
previous patch didn't compile ...
cr0ybot (mastercory13) wrote : | #42 |
I didn't want to take out ALL of the menu items from Wine, so I went into the above mentioned directories and manually deleted the files/folders. I wish that for every app Wine installs, it would keep track of these items so that they could be uninstalled automatically.
John Pye (jdpipe) wrote : | #43 |
Presumably this thing is working by creating .desktop files in response to files that are created in the equivalent Windows/wine path eg ~/.wine/
http://
It should be possible to delete all these *.desktop files as directed above and then to recreate them. Wine needs to provide a script that does this periodically, perhaps.
John Pye (jdpipe) wrote : | #44 |
Actually, looks like a patch has been proposed now over in wine..
Scott Ritchie (scottritchie) wrote : | #45 |
This is an upstream bug so I'm marking it the same priority as the other upstream Wine bugs on launchpad.
Changed in wine: | |
assignee: | ubuntu-wine → nobody |
importance: | Undecided → Low |
status: | Confirmed → Triaged |
In Wine Bugzilla #10277, Damjan Jovanovic (damjan-jov) wrote : | #46 |
Hello Ambro, Vincent
Are you ever going to submit your patches to the wine-patches mailing list? And are you actually working on this bug?
If not, I'd like to take it over soon.
In Wine Bugzilla #10277, Vincent Povirk (madewokherd) wrote : | #47 |
I'm not actively working on this bug right now. The patch I attached is not a good solution to this problem. It's an abuse of the TryExec field, and it doesn't work very well at all.
Now that wineshelllink is dead (good job killing it btw :), I am thinking about trying to add an X-Wine-LnkFile field to Wine-generated .desktop files and some sort of command to remove dead links. I don't have a clean path to a real fix, and there's no telling when I'll get to doing even that much.
I won't mind if you take this over, especially if you have a plan that might work.
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #48 |
I'm willing to work on this, but it seemed to me that nobody is really interested. So yes, I'll try to clean them up and submit them soon.
In Wine Bugzilla #10277, Damjan Jovanovic (damjan-jov) wrote : | #49 |
Actually 10 votes + 38 comments is more than lack of interest. It's just that nobody looks at patches in Bugzilla.
Also, some hints from my personal experience of weeks of wrestling winemenubuilder patches into the tree:
Do not use a shell script. Alexandre was unwilling to commit a patch to winemenubuilder for .url files, until I sent a patch to delete wineshelllink. Your patch has no chance if you use a wineshellunlink script.
winemenubuilder has changed since last you looked at it, some of the functions you used no longer exist.
You should handle .url files as well as .lnk - currently you don't.
Alexandre doesn't like the Find*ChangeNoti
Comments starting with // aren't allowed, use /* */.
Anyway, thank you, good luck - and hurry up :-).
In Wine Bugzilla #10277, Thesource-mail (thesource-mail) wrote : | #50 |
Removing links on uninstall is good, but adding them on install is broken in 1.1.9 in Fedora 10. .lnk file are created, but not .desktop ones.
In Wine Bugzilla #10277, Thesource-mail (thesource-mail) wrote : | #51 |
Hm. Looks like only menu entries are created, but not desktop launchers.
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #52 |
I've already written something relatively functional. I've patched winemenubuilder to record created shortcuts (.lnk) to registry, along with some info. Then I've written a service which watches these files, and when it finds a nonexistent .lnk file, it removes the associated shortcuts on the user's desktop.
But there is a small problem. If the application installs a user-local desktop shortcut (~/.wine/
Because the .lnk files annoy users, they will delete them, which will make my service remove the real shortcut as well.
I see two possible things to do:
- Don't attempt to record user-local desktop shortcuts to the registry. This way, they will never be removed.
- Don't point the Desktop folder (~/.wine/
Does anyone see a better solution?
BTW, URLs are not implemented yet.
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #53 |
Created an attachment (id=17561)
shortcut watcher service
Here is the current state if anyone wants to test it; make sure to run "tools/
In Wine Bugzilla #10277, Ambro (ambro) wrote : | #54 |
About supporting URL files, can someone point me to a program that actually installs them? I've tried like 10 programs and those that do install URLs really create a .lnk that points to the .url somewhere.
In Wine Bugzilla #10277, Vincent Povirk (madewokherd) wrote : | #55 |
You will probably need to break this into smaller patches before you send it in (not that there's any need to do it now), and I don't think you need to include the menu removal if it still doesn't work by that time. Just removing the shortcuts would be a large improvement, and usually empty menus will be invisible.
The separate .lnk and .desktop files on desktop shortcuts is a separate problem that you don't have to solve. It's been suggested that we should teach desktop environments to use the .lnk files so that .desktop files aren't needed, but we would need a way to store the wine prefix.
In Wine Bugzilla #10277, Damjan Jovanovic (damjan-jov) wrote : | #56 |
Ambro, in dlls/shdocvw/
In Wine Bugzilla #10277, WanderingVillager (ovek) wrote : | #57 |
Forwarded Debian bug #507863 here.
In Wine Bugzilla #10277, Dmitry-codeweavers (dmitry-codeweavers) wrote : | #58 |
*** Bug 17315 has been marked as a duplicate of this bug. ***
Steve Dodier-Lazaro (sidi) wrote : | #60 |
By the way, gold_Single, you can get your divx movies to run in Totem if you install ubuntu-
See : https:/
Hope it helps.
In Wine Bugzilla #10277, Scott Ritchie (scottritchie) wrote : | #61 |
By the way, the XDG-Dirs spec: http://
Would it be unreasonable to simply store the menu in the .wine folder and just add an extra base dir for XDG to look in?
In Wine Bugzilla #10277, Dan Kegel (dank) wrote : | #62 |
It would require a change in the spec, and then
Gnome, KDE, and everybody else would have to implement
the change. That's reasonable in principle, but very slow
unless you happen to have a hotline to guys
in Gnome and KDE that can speed up consensus. Then
it would only take six months or so.
In Wine Bugzilla #10277, Dylan Taylor (dylanmtaylor) wrote : | #63 |
This is probably one of THE most annoying bugs in Wine. The only solution I can think of is to have the entire program menu deleted every time something is added or removed, and then have it dynamically generated from a database of some sort that would be stored within the .wine folder. Although that would prove to be difficult to implement.
In Wine Bugzilla #10277, elhoir (jfarroyo82) wrote : | #64 |
i guess you really HATE me :-)
In Wine Bugzilla #10277, Damjan Jovanovic (damjan-jov) wrote : | #65 |
Vincent, Ambro: you've had your chance. Now I'm taking over.
javier: sorry to take so long, I'll try to fix it quickly.
In Wine Bugzilla #10277, Damjan Jovanovic (damjan-jov) wrote : | #66 |
Created an attachment (id=21774)
log where freedesktop files go and provide an option to delete them
With this patch applied, freedesktop menus that winemenubuilder creates are logged to the registry, and when you delete the .lnk files and run "wine winemenubuilder -r" the corresponding freedesktop menus disappear.
Your menus generated before this patch was in effect can't be removed.
Also you have to run "wine winemenubuilder -r" manually, that will be done automatically in the future.
Patch has already been posted to wine-patches for review.
Changed in wine: | |
status: | Confirmed → In Progress |
In Wine Bugzilla #10277, Removed by request (removed1836289) wrote : | #67 |
(In reply to comment #54)
> Created an attachment (id=21774) [details]
> log where freedesktop files go and provide an option to delete them
>
> With this patch applied, freedesktop menus that winemenubuilder creates are
> logged to the registry, and when you delete the .lnk files and run "wine
> winemenubuilder -r" the corresponding freedesktop menus disappear.
>
> Your menus generated before this patch was in effect can't be removed.
>
> Also you have to run "wine winemenubuilder -r" manually, that will be done
> automatically in the future.
>
> Patch has already been posted to wine-patches for review.
Patch was committed.
http://
In Wine Bugzilla #10277, Damjan Jovanovic (damjan-jov) wrote : | #68 |
With my 2 patches just committed to the lastest git:
http://
http://
I am tempted to close this bug, because menu deletion now works - but it's only preformed on Wine startup, and only on menus created with Wine >= 1.1.24 (maybe the version is a little earlier).
The latter problem is hard to fix and probably won't be (you'll have to delete menus made with older Wine versions manually), but the fix for the former is another patch I sent in and wasn't accepted.
So a few more days for that last patch to go in and then I'll close this bug.
You can expect this to fully work with Wine 1.1.25.
In Wine Bugzilla #10277, Damjan Jovanovic (damjan-jov) wrote : | #69 |
Alexandre Julliard tells me that the menu deletion while Wine is running "would have to be some sort of [Windows NT] service, but yes i expect startup only is good enough for now".
Hence, no patch to delete menus while Wine is running at this time.
Resolving fixed.
In Wine Bugzilla #10277, Scott Ritchie (scottritchie) wrote : | #70 |
Why would a service be needed? All I really want is some way to manually tell Wine "check the menu again" - then we could put that code into Wine Uninstaller and Gnome-App-Install (a frontend to wine uninstaller that I'm working on). That way if Wine is still running while they uninstall an app everything would be handled fine.
That would cover a very large use case right there.
In Wine Bugzilla #10277, Damjan Jovanovic (damjan-jov) wrote : | #71 |
Scott, you can manually run "wine winemenubuilder -r" to uninstall menus whenever you want to (eg. after an app is uninstalled). "wine winemenubuilder -a -r" is even better since it will clean up file type associations too.
And while you're here: even though I use Ubuntu, I hope all these changes you are making to better integrate Wine into the desktop are cross-distro, and done in Wine itself when possible.
Changed in wine: | |
status: | In Progress → Fix Released |
In Wine Bugzilla #10277, Alexandre Julliard (julliard) wrote : | #72 |
Closing bugs fixed in 1.1.25.
In Wine Bugzilla #10277, Ken Sharp (kennybobs) wrote : | #73 |
The shortcuts are removed, the folders are not.
Under Windows, the folders are removed also.
Reopen or is that bit a wontfix?
In Wine Bugzilla #10277, Vincent Povirk (madewokherd) wrote : | #74 |
It doesn't make sense to remove the folders. They're likely to be used in a different wine prefix, and menu implementations tend to not show empty folders anyway.
In Wine Bugzilla #10277, Ken Sharp (kennybobs) wrote : | #75 |
Why would I have the same program in two different wineprefixes?
With that in mind, if I do, the shortcut would only point to one wineprefix anyway, which, when removed, would make the folder again redundant.
Removing the shortcut is only half the problem. Users still have to go in, find the directory, and delete it, which is what was happening anyway.
In Wine Bugzilla #10277, Ken Sharp (kennybobs) wrote : | #76 |
*** Bug 19213 has been marked as a duplicate of this bug. ***
In Wine Bugzilla #10277, Vitaliy-bugzilla (vitaliy-bugzilla) wrote : | #77 |
*** Bug 19213 has been marked as a duplicate of this bug. ***
In Wine Bugzilla #10277, Ansus (neptunia) wrote : | #78 |
I experience the same problem with Tropico 3 and Wine 1.1.39.
In Wine Bugzilla #10277, Vincent Povirk (madewokherd) wrote : | #79 |
You should probably open a new bug for that. Since this is a general issue and it should be fixed, it's likely you're seeing a more narrow problem.
Changed in wine: | |
importance: | Unknown → Low |
In Wine Bugzilla #10277, Russian redneck (otaku-8) wrote : | #80 |
the same bug in wine 1.4-rc1, ubuntu 11.10
wine winemenubuilder -a -r doesn't help
Rolf Leggewie (r0lf) wrote : | #81 |
this was apparently fixed upstream
Changed in wine (Ubuntu): | |
status: | Triaged → Fix Released |
As far as I can tell, there's poor coupling between wine and the applications menu. It's sort of a one way deal. While it's not that important. It would be nice to have this fixed.