http://bugs.winehq.org/show_bug.cgi?id=10277
Summary: Uninstalling software does not remove them from Programs menu Product: Wine Version: 0.9.48. Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-binary AssignedTo: wine-bugs@winehq.org ReportedBy: jfarroyo82@hotmail.com
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
http://bugs.winehq.org/show_bug.cgi?id=10277
javier fernandez jfarroyo82@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal
http://bugs.winehq.org/show_bug.cgi?id=10277
Jonathan echidnaman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |echidnaman@gmail.com
--- Comment #1 from Jonathan echidnaman@gmail.com 2007-11-02 07:08:34 --- Confirming here in Kubuntu 7.10. Hooray for KMenu edit, though. :P
http://bugs.winehq.org/show_bug.cgi?id=10277
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |trivial Status|UNCONFIRMED |NEW Component|wine-binary |wine-misc Ever Confirmed|0 |1
--- Comment #2 from Vitaliy Margolen vitaliy@kievinfo.com 2007-11-02 07:40:28 --- Confirming.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #3 from Juan Lang juan_lang@yahoo.com 2007-11-02 11:10:42 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #4 from Austin English austinenglish@gmail.com 2007-11-02 11:29:58 --- Shouldn't this be up to the distribution to handle?
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #5 from javier fernandez jfarroyo82@hotmail.com 2007-11-02 17:02:46 --- (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...
http://bugs.winehq.org/show_bug.cgi?id=10277
Brandon Sachtleben brandontheninja@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brandontheninja@gmail.com
--- Comment #6 from Brandon Sachtleben brandontheninja@gmail.com 2007-11-06 03:22:43 --- Okay, I just figured out if you go to ~/.local/share/applications and delete 'wine', it will remove those entries from the Applications menu.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #7 from javier fernandez jfarroyo82@hotmail.com 2007-11-06 14:16:53 --- (In reply to comment #6)
Okay, I just figured out if you go to ~/.local/share/applications and delete '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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #8 from Vitaliy Margolen vitaliy@kievinfo.com 2007-11-06 20:58:21 --- (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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org
--- Comment #9 from Scott Ritchie scott@open-vote.org 2007-11-16 18:58:10 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov@gmail.com
--- Comment #10 from Damjan Jovanovic damjan.jov@gmail.com 2007-11-17 11:52:09 --- 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/drive_c/windows/start menu and such, but the mapping between .lnk files and freedesktop menus is currently one-way.
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.
http://bugs.winehq.org/show_bug.cgi?id=10277
unggnu unggnu@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |unggnu@googlemail.com
http://bugs.winehq.org/show_bug.cgi?id=10277
Adam Dempsey dempsey@weirdfish.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dempsey@weirdfish.net
http://bugs.winehq.org/show_bug.cgi?id=10277
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com Target Milestone|--- |1.2.0
--- Comment #11 from Dan Kegel dank@kegel.com 2008-03-24 11:01:26 --- This affects lots of apps. Let's fix it for wine-1.2.
http://bugs.winehq.org/show_bug.cgi?id=10277
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thesource@mail.ru
--- Comment #12 from Austin English austinenglish@gmail.com 2008-04-11 13:13:47 --- *** Bug 8717 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10277
Ambro ambro@b4ever.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ambro@b4ever.net
--- Comment #13 from Ambro ambro@b4ever.net 2008-05-06 05:40:22 --- 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?
http://bugs.winehq.org/show_bug.cgi?id=10277
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
--- Comment #14 from Vincent Povirk madewokherd@gmail.com 2008-05-19 21:42:50 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #15 from Vincent Povirk madewokherd@gmail.com 2008-05-19 23:08:10 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #16 from Vincent Povirk madewokherd@gmail.com 2008-05-24 20:53:01 --- Created an attachment (id=13315) --> (http://bugs.winehq.org/attachment.cgi?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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=10277
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |soldich@gmail.com
--- Comment #17 from Austin English austinenglish@gmail.com 2008-06-12 16:08:32 --- *** Bug 13874 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10277
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |integration
http://bugs.winehq.org/show_bug.cgi?id=10277
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |integration
--- Comment #18 from Vincent Povirk madewokherd@gmail.com 2008-07-05 09:26:38 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #19 from Ambro ambro@b4ever.net 2008-07-05 11:27:23 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #20 from Vincent Povirk madewokherd@gmail.com 2008-07-05 11:33:48 --- There's no hook. Windows has API for creating links (IShellLink), and Wine creates .desktop files when they are saved.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #21 from Ambro ambro@b4ever.net 2008-07-05 11:42:18 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #22 from The Source thesource@mail.ru 2008-07-05 12:51:12 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #23 from Ambro ambro@b4ever.net 2008-07-05 13:05:44 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #24 from Ambro ambro@b4ever.net 2008-07-05 16:32:50 --- Created an attachment (id=14602) --> (http://bugs.winehq.org/attachment.cgi?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/shortcuts. Every file there represents a shortcut created and contains the list of paths in xdg trees. Every file is prefixed with "p:" (private) or "s:" (shared) - if it is shared, it can only be deleted once no other shortcut lists it as shared.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #25 from Ambro ambro@b4ever.net 2008-07-05 18:00:16 --- Created an attachment (id=14603) --> (http://bugs.winehq.org/attachment.cgi?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/MyApp/LaynchMyApp' --icon '/some/icon.xpm' --path '/home/user/.wine/dosdevices/c:/MyApp/MyApp.exe'
you can remove it by calling wineshellunlink --menu --link 'Programs/MyApp/LaynchMyApp'
http://bugs.winehq.org/show_bug.cgi?id=10277
Ambro ambro@b4ever.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14602|0 |1 is obsolete| |
--- Comment #26 from Ambro ambro@b4ever.net 2008-07-06 10:18:58 --- Created an attachment (id=14623) --> (http://bugs.winehq.org/attachment.cgi?id=14623) wineshellink seperate wineprefixes, independent files, record created files
http://bugs.winehq.org/show_bug.cgi?id=10277
Ambro ambro@b4ever.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14603|0 |1 is obsolete| |
--- Comment #27 from Ambro ambro@b4ever.net 2008-07-06 10:19:20 --- Created an attachment (id=14624) --> (http://bugs.winehq.org/attachment.cgi?id=14624) wineshellunlink - removes created shortcuts
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #28 from Ambro ambro@b4ever.net 2008-07-06 10:20:11 --- Created an attachment (id=14625) --> (http://bugs.winehq.org/attachment.cgi?id=14625) winemenubuilder - work with previous patches, add scalling for removed .lnk files
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #29 from Ambro ambro@b4ever.net 2008-07-06 10:27:07 --- 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/shortcuts - winemenubuilder records the .lnk locations of new shortcuts to HKCU/Wine/Software/WineMenuBuilder/Shortcuts. - "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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maskaro@gmail.com
--- Comment #30 from Vitaliy Margolen vitaliy@kievinfo.com 2008-07-09 08:57:55 --- *** Bug 14385 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #31 from Ambro ambro@b4ever.net 2008-07-16 18:04:43 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Ambro ambro@b4ever.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14623|0 |1 is obsolete| | Attachment #14624|0 |1 is obsolete| | Attachment #14625|0 |1 is obsolete| |
--- Comment #32 from Ambro ambro@b4ever.net 2008-07-18 05:59:51 --- Created an attachment (id=14895) --> (http://bugs.winehq.org/attachment.cgi?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\profiles\all users\start menu", its menu entry will be removed. Again refresh the desktop to see the change.
The code could probably be added to explorer to avoid creating a new process. Anyway, what do you think about my approach?
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #33 from Ambro ambro@b4ever.net 2008-07-18 06:01:13 --- Created an attachment (id=14896) --> (http://bugs.winehq.org/attachment.cgi?id=14896) mailslot async fix
this patch is also required, it fixes some Wine bug I have stumbled on
http://bugs.winehq.org/show_bug.cgi?id=10277
Ambro ambro@b4ever.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14895|0 |1 is obsolete| |
--- Comment #34 from Ambro ambro@b4ever.net 2008-07-18 06:06:54 --- Created an attachment (id=14897) --> (http://bugs.winehq.org/attachment.cgi?id=14897) lnk file watcher plus my previous modifications
previous patch didn't compile ...
http://bugs.winehq.org/show_bug.cgi?id=10277
nathan.n saturn_systems@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |saturn_systems@yahoo.com
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #35 from Damjan Jovanovic damjan.jov@gmail.com 2008-11-27 09:05:03 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #36 from Vincent Povirk madewokherd@gmail.com 2008-11-27 10:23:30 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #37 from Ambro ambro@b4ever.net 2008-11-28 05:03:30 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #38 from Damjan Jovanovic damjan.jov@gmail.com 2008-11-28 05:20:29 --- 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*ChangeNotification*() functions, and says they aren't available on all systems and should only be used as a hint, you need to poll for file changes as well.
Comments starting with // aren't allowed, use /* */.
Anyway, thank you, good luck - and hurry up :-).
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #39 from The Source thesource@mail.ru 2008-11-28 05:40:12 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #40 from The Source thesource@mail.ru 2008-11-28 06:50:19 --- Hm. Looks like only menu entries are created, but not desktop launchers.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #41 from Ambro ambro@b4ever.net 2008-11-30 04:26:57 --- 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/windows/profiles/<user>/Desktop, which points to ~/Desktop), the .lnk file is of course visible on the desktop, along with the real shortcut (this can be seen without my patch). 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/windows/profiles/<user>/Desktop) to the real desktop folder (~/Desktop). This way, removal will work, and the user will not be annoyed, but I'm afraid some apps use the Desktop folder for things other than shortcuts (e.g. Firefox saves downloads to desktop by default).
Does anyone see a better solution?
BTW, URLs are not implemented yet.
http://bugs.winehq.org/show_bug.cgi?id=10277
Ambro ambro@b4ever.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14896|0 |1 is obsolete| | Attachment #14897|0 |1 is obsolete| |
--- Comment #42 from Ambro ambro@b4ever.net 2008-11-30 04:28:42 --- Created an attachment (id=17561) --> (http://bugs.winehq.org/attachment.cgi?id=17561) shortcut watcher service
Here is the current state if anyone wants to test it; make sure to run "tools/make_makefiles && autoconf" and reconfigure.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #43 from Ambro ambro@b4ever.net 2008-11-30 07:59:39 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #44 from Vincent Povirk madewokherd@gmail.com 2008-11-30 10:44:03 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #45 from Damjan Jovanovic damjan.jov@gmail.com 2008-12-01 01:42:04 --- Ambro, in dlls/shdocvw/intshcut.c, I've documented a program that installs .url files, one on the desktop, one in the menus.
http://bugs.winehq.org/show_bug.cgi?id=10277
Ove Kaaven ovek@arcticnet.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ovek@arcticnet.no
--- Comment #46 from Ove Kaaven ovek@arcticnet.no 2008-12-31 23:48:56 --- Forwarded Debian bug #507863 here.
http://bugs.winehq.org/show_bug.cgi?id=10277
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |from_wine_bugzilla@ssokolow. | |com
--- Comment #47 from Dmitry Timoshkov dmitry@codeweavers.com 2009-02-09 03:35:04 --- *** Bug 17315 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #48 from Dmitry Timoshkov dmitry@codeweavers.com 2009-02-09 22:17:10 --- *** Bug 17315 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #49 from Scott Ritchie scott@open-vote.org 2009-06-03 15:54:43 --- By the way, the XDG-Dirs spec: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
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?
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #50 from Dan Kegel dank@kegel.com 2009-06-03 16:17:42 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Dylan Taylor aliendude5300@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aliendude5300@gmail.com
--- Comment #51 from Dylan Taylor aliendude5300@gmail.com 2009-06-11 17:24:39 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #52 from javier fernandez jfarroyo82@hotmail.com 2009-06-12 16:58:17 --- i guess you really HATE me :-)
http://bugs.winehq.org/show_bug.cgi?id=10277
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|wine-bugs@winehq.org |damjan.jov@gmail.com Difficulty|--- |Days
--- Comment #53 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-13 11:54:16 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #13315|0 |1 is obsolete| | Attachment #17561|0 |1 is obsolete| |
--- Comment #54 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-13 11:59:44 --- Created an attachment (id=21774) --> (http://bugs.winehq.org/attachment.cgi?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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #55 from Jerome Leclanche adys.wh@gmail.com 2009-06-18 09:37:32 --- (In reply to comment #54)
Created an attachment (id=21774)
--> (http://bugs.winehq.org/attachment.cgi?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://source.winehq.org/git/wine.git//wine.git?a=commitdiff;h=267858b4c2484...
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #56 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-26 11:41:08 --- With my 2 patches just committed to the lastest git:
http://source.winehq.org/git/wine.git/?a=commit;h=420d64291876130c49255d4298...
http://source.winehq.org/git/wine.git/?a=commit;h=fe1cc3272149503323d7bcb99c...
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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
--- Comment #56 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-26 11:41:08 --- With my 2 patches just committed to the lastest git:
http://source.winehq.org/git/wine.git/?a=commit;h=420d64291876130c49255d4298...
http://source.winehq.org/git/wine.git/?a=commit;h=fe1cc3272149503323d7bcb99c...
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.
--- Comment #57 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 12:00:37 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
--- Comment #56 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-26 11:41:08 --- With my 2 patches just committed to the lastest git:
http://source.winehq.org/git/wine.git/?a=commit;h=420d64291876130c49255d4298...
http://source.winehq.org/git/wine.git/?a=commit;h=fe1cc3272149503323d7bcb99c...
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.
--- Comment #57 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 12:00:37 --- 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.
--- Comment #58 from Scott Ritchie scott@open-vote.org 2009-06-30 14:00:00 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
--- Comment #56 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-26 11:41:08 --- With my 2 patches just committed to the lastest git:
http://source.winehq.org/git/wine.git/?a=commit;h=420d64291876130c49255d4298...
http://source.winehq.org/git/wine.git/?a=commit;h=fe1cc3272149503323d7bcb99c...
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.
--- Comment #57 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 12:00:37 --- 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.
--- Comment #58 from Scott Ritchie scott@open-vote.org 2009-06-30 14:00:00 --- 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.
--- Comment #59 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 14:37:18 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #56 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-26 11:41:08 --- With my 2 patches just committed to the lastest git:
http://source.winehq.org/git/wine.git/?a=commit;h=420d64291876130c49255d4298...
http://source.winehq.org/git/wine.git/?a=commit;h=fe1cc3272149503323d7bcb99c...
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.
--- Comment #57 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 12:00:37 --- 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.
--- Comment #58 from Scott Ritchie scott@open-vote.org 2009-06-30 14:00:00 --- 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.
--- Comment #59 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 14:37:18 --- 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.
--- Comment #60 from Alexandre Julliard julliard@winehq.org 2009-07-03 11:41:57 --- Closing bugs fixed in 1.1.25.
http://bugs.winehq.org/show_bug.cgi?id=10277
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #56 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-26 11:41:08 --- With my 2 patches just committed to the lastest git:
http://source.winehq.org/git/wine.git/?a=commit;h=420d64291876130c49255d4298...
http://source.winehq.org/git/wine.git/?a=commit;h=fe1cc3272149503323d7bcb99c...
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.
--- Comment #57 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 12:00:37 --- 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.
--- Comment #58 from Scott Ritchie scott@open-vote.org 2009-06-30 14:00:00 --- 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.
--- Comment #59 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 14:37:18 --- 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.
--- Comment #60 from Alexandre Julliard julliard@winehq.org 2009-07-03 11:41:57 --- Closing bugs fixed in 1.1.25.
--- Comment #61 from Ken Sharp kennybobs@o2.co.uk 2009-07-09 07:45:33 --- The shortcuts are removed, the folders are not. Under Windows, the folders are removed also. Reopen or is that bit a wontfix?
http://bugs.winehq.org/show_bug.cgi?id=10277
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #56 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-26 11:41:08 --- With my 2 patches just committed to the lastest git:
http://source.winehq.org/git/wine.git/?a=commit;h=420d64291876130c49255d4298...
http://source.winehq.org/git/wine.git/?a=commit;h=fe1cc3272149503323d7bcb99c...
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.
--- Comment #57 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 12:00:37 --- 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.
--- Comment #58 from Scott Ritchie scott@open-vote.org 2009-06-30 14:00:00 --- 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.
--- Comment #59 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 14:37:18 --- 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.
--- Comment #60 from Alexandre Julliard julliard@winehq.org 2009-07-03 11:41:57 --- Closing bugs fixed in 1.1.25.
--- Comment #61 from Ken Sharp kennybobs@o2.co.uk 2009-07-09 07:45:33 --- The shortcuts are removed, the folders are not. Under Windows, the folders are removed also. Reopen or is that bit a wontfix?
--- Comment #62 from Vincent Povirk madewokherd@gmail.com 2009-07-09 08:04:51 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #56 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-26 11:41:08 --- With my 2 patches just committed to the lastest git:
http://source.winehq.org/git/wine.git/?a=commit;h=420d64291876130c49255d4298...
http://source.winehq.org/git/wine.git/?a=commit;h=fe1cc3272149503323d7bcb99c...
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.
--- Comment #57 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 12:00:37 --- 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.
--- Comment #58 from Scott Ritchie scott@open-vote.org 2009-06-30 14:00:00 --- 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.
--- Comment #59 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 14:37:18 --- 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.
--- Comment #60 from Alexandre Julliard julliard@winehq.org 2009-07-03 11:41:57 --- Closing bugs fixed in 1.1.25.
--- Comment #61 from Ken Sharp kennybobs@o2.co.uk 2009-07-09 07:45:33 --- The shortcuts are removed, the folders are not. Under Windows, the folders are removed also. Reopen or is that bit a wontfix?
--- Comment #62 from Vincent Povirk madewokherd@gmail.com 2009-07-09 08:04:51 --- 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.
--- Comment #63 from Ken Sharp kennybobs@o2.co.uk 2009-07-09 08:17:05 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zebul666@hotmail.com
--- Comment #56 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-26 11:41:08 --- With my 2 patches just committed to the lastest git:
http://source.winehq.org/git/wine.git/?a=commit;h=420d64291876130c49255d4298...
http://source.winehq.org/git/wine.git/?a=commit;h=fe1cc3272149503323d7bcb99c...
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.
--- Comment #57 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 12:00:37 --- 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.
--- Comment #58 from Scott Ritchie scott@open-vote.org 2009-06-30 14:00:00 --- 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.
--- Comment #59 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 14:37:18 --- 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.
--- Comment #60 from Alexandre Julliard julliard@winehq.org 2009-07-03 11:41:57 --- Closing bugs fixed in 1.1.25.
--- Comment #61 from Ken Sharp kennybobs@o2.co.uk 2009-07-09 07:45:33 --- The shortcuts are removed, the folders are not. Under Windows, the folders are removed also. Reopen or is that bit a wontfix?
--- Comment #62 from Vincent Povirk madewokherd@gmail.com 2009-07-09 08:04:51 --- 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.
--- Comment #63 from Ken Sharp kennybobs@o2.co.uk 2009-07-09 08:17:05 --- 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.
--- Comment #64 from Ken Sharp kennybobs@o2.co.uk 2009-07-11 11:16:50 --- *** Bug 19213 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10277
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zebul666@hotmail.com
--- Comment #56 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-26 11:41:08 --- With my 2 patches just committed to the lastest git:
http://source.winehq.org/git/wine.git/?a=commit;h=420d64291876130c49255d4298...
http://source.winehq.org/git/wine.git/?a=commit;h=fe1cc3272149503323d7bcb99c...
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.
--- Comment #57 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 12:00:37 --- 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.
--- Comment #58 from Scott Ritchie scott@open-vote.org 2009-06-30 14:00:00 --- 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.
--- Comment #59 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 14:37:18 --- 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.
--- Comment #60 from Alexandre Julliard julliard@winehq.org 2009-07-03 11:41:57 --- Closing bugs fixed in 1.1.25.
--- Comment #61 from Ken Sharp kennybobs@o2.co.uk 2009-07-09 07:45:33 --- The shortcuts are removed, the folders are not. Under Windows, the folders are removed also. Reopen or is that bit a wontfix?
--- Comment #62 from Vincent Povirk madewokherd@gmail.com 2009-07-09 08:04:51 --- 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.
--- Comment #63 from Ken Sharp kennybobs@o2.co.uk 2009-07-09 08:17:05 --- 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.
--- Comment #64 from Ken Sharp kennybobs@o2.co.uk 2009-07-11 11:16:50 --- *** Bug 19213 has been marked as a duplicate of this bug. ***
--- Comment #65 from Vitaliy Margolen vitaliy@kievinfo.com 2009-08-05 01:36:07 --- *** Bug 19213 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=10277
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zebul666@hotmail.com
Ilya Chernykh neptunia@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |neptunia@mail.ru
--- Comment #56 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-26 11:41:08 --- With my 2 patches just committed to the lastest git:
http://source.winehq.org/git/wine.git/?a=commit;h=420d64291876130c49255d4298...
http://source.winehq.org/git/wine.git/?a=commit;h=fe1cc3272149503323d7bcb99c...
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.
--- Comment #57 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 12:00:37 --- 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.
--- Comment #58 from Scott Ritchie scott@open-vote.org 2009-06-30 14:00:00 --- 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.
--- Comment #59 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-30 14:37:18 --- 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.
--- Comment #60 from Alexandre Julliard julliard@winehq.org 2009-07-03 11:41:57 --- Closing bugs fixed in 1.1.25.
--- Comment #61 from Ken Sharp kennybobs@o2.co.uk 2009-07-09 07:45:33 --- The shortcuts are removed, the folders are not. Under Windows, the folders are removed also. Reopen or is that bit a wontfix?
--- Comment #62 from Vincent Povirk madewokherd@gmail.com 2009-07-09 08:04:51 --- 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.
--- Comment #63 from Ken Sharp kennybobs@o2.co.uk 2009-07-09 08:17:05 --- 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.
--- Comment #64 from Ken Sharp kennybobs@o2.co.uk 2009-07-11 11:16:50 --- *** Bug 19213 has been marked as a duplicate of this bug. ***
--- Comment #65 from Vitaliy Margolen vitaliy@kievinfo.com 2009-08-05 01:36:07 --- *** Bug 19213 has been marked as a duplicate of this bug. ***
--- Comment #66 from Ilya Chernykh neptunia@mail.ru 2010-03-04 15:13:37 --- I experience the same problem with Tropico 3 and Wine 1.1.39.
http://bugs.winehq.org/show_bug.cgi?id=10277
--- Comment #67 from Vincent Povirk madewokherd@gmail.com 2010-03-04 15:20:15 --- 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.
http://bugs.winehq.org/show_bug.cgi?id=10277
ax 34noff otaku@rambler.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |otaku@rambler.ru
--- Comment #68 from ax 34noff otaku@rambler.ru 2012-02-01 11:12:58 CST --- the same bug in wine 1.4-rc1, ubuntu 11.10 wine winemenubuilder -a -r doesn't help
-
wine-bugs＠winehq.org