http://bugs.winehq.org/show_bug.cgi?id=19182
Summary: Allow to completely disable MIME-type and application integration Product: Wine Version: 1.1.25 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: diafero@arcor.de
Note: I could not find a component "winemenubilder" which is why I selected "-unknown".
It would be great to have a way to tell wine not to create a whole bunch of files across the .config and .local directories. I don't want any mime-type which is registered by a windows application run through wine to reflect on my system - if I really want to use wine to open a certain filetype (which never happened so far) I will do that manually. Nor do I want all the unnecessary start menu entries to be added to my KDE menu - they end up in the wrong category anyway. I like to have the control of creating these entries myself. For the menu it worked fine to simply remove the "Wine" menu directory with the menu editor. The annoying files still got created, but they were ignored. However now wine started to spam my mime directory, too, and it constantly re-creates the files in there - a really annoying behaviour. This not only leads to the danger of me accidentally starting wine without wanting to do so, it also drives some applications crazy (for example the KDE screenshot application no longer recognizes ".jpg" to be a JPEG extension since wine added .jfif). I understand that many people want wine to just magically integrate into their Linux environment, but there are also people like me who switched to Linux because they like to have control, and Windows often prefers its own preferences over the user's. Wine should really not bring that to Linux, or it will get as annoying as Windows is. If I could not patch wine myself to no longer create these files, I had no way to stop all these mime types from being added, no configuration panel to remove them, nothing. I do not even know which of my many WINEPREFIXes created the files.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #1 from diafero@arcor.de 2009-07-04 09:17:26 --- I just found out that the reason why the KDE screenshot application goes crazy is that wine actually removes the system-wide jpg file extensions (*.jpg, *.jpeg and so on) and replaces them by *.jfif, which is obviously bad. Should I report this a separate bug?
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #2 from Alexandre Julliard julliard@winehq.org 2009-07-04 10:37:12 --- You can set winemenubuilder.exe to disabled in the Libraries winecfg tab.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #3 from diafero@arcor.de 2009-07-04 11:04:18 --- Thanks for the quick reply :)
What do I have to set there? winemenubuilder is not even in the automatically provided drop-down list.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #4 from Austin English austinenglish@gmail.com 2009-07-05 17:18:14 --- (In reply to comment #3)
Thanks for the quick reply :)
What do I have to set there? winemenubuilder is not even in the automatically provided drop-down list.
You'd have to type it.
Or add 'WINEDLLOVERRIDES=winmenubuilder.exe=d' your environment (~/.bashrc).
http://bugs.winehq.org/show_bug.cgi?id=19182
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dimesio@earthlink.net
--- Comment #5 from Rosanne DiMesio dimesio@earthlink.net 2009-07-05 22:07:54 --- I've added instructions for disabling winemenubuilder.exe to the FAQ.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #6 from diafero@arcor.de 2009-07-06 12:05:57 --- Ok, I revert my local path and tried the environment variable (to make it apply on all of my WINEPREFIXes). I will mark the bug as fixed in some days if I have no more problems.
Thank you for your tips :)
http://bugs.winehq.org/show_bug.cgi?id=19182
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |nerv@dawncrow.de Ever Confirmed|0 |1
--- Comment #7 from André H. nerv@dawncrow.de 2009-07-16 10:00:15 --- I still think we should have a checkbox in winecfg under "Desktop-Integration" for that. Even if it just overrides winemenubuilder.exe to disabled. Also the already made mime-types should be deletable
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #8 from diafero@arcor.de 2009-07-16 10:26:18 --- I agree with you: While I am satisfied with the current solution, many users will not know how to do that, and even more they will not know what to remove (and what not!) in order to get their system back to the old state they know.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #9 from diafero@arcor.de 2009-08-14 14:52:15 --- Since I updated to version 1.1.27, even though the environment variable is still set, wine now creates mime types again - so that, for example, when I click on an .inf file, it no longer opens in my favourite editor (Kate) but it asks which application to use for that file.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #10 from Austin English austinenglish@gmail.com 2009-08-14 16:08:48 --- (In reply to comment #9)
Since I updated to version 1.1.27, even though the environment variable is still set, wine now creates mime types again - so that, for example, when I click on an .inf file, it no longer opens in my favourite editor (Kate) but it asks which application to use for that file.
I've noticed something similar. I've disabled it, but nautilus is still trying to open some files in windows apps. If they're old associations I haven't reset, or new ones that slipped by, I haven't checked.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #11 from diafero@arcor.de 2009-08-15 04:23:55 --- (In reply to comment #10)
I've noticed something similar. I've disabled it, but nautilus is still trying to open some files in windows apps. If they're old associations I haven't reset, or new ones that slipped by, I haven't checked.
It is definitely new ones - when I first noticed the new mime types, I removed them (from ~/.local/share/mime/packages) and ran update-mime-database, and later on the files where again in there. However, it does not open them in any windows application for me, it just breaks opening them in Linux applications.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #12 from André H. nerv@dawncrow.de 2009-08-15 04:52:56 --- (In reply to comment #9)
Since I updated to version 1.1.27
Which Version u had before? If it was not 1.1.26 please install it and test it again. There were much changes on winemenubuilder, so i want to locate the timeframe where to search.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #13 from diafero@arcor.de 2009-08-15 04:58:31 --- (In reply to comment #12)
Which Version u had before? If it was not 1.1.26 please install it and test it again. There were much changes on winemenubuilder, so i want to locate the timeframe where to search.
I had version 1.1.26 before.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #14 from André H. nerv@dawncrow.de 2009-08-15 05:21:23 --- if something broke, then it was f428813ce283949e05b93afa04d79b6774c124e0 but i can see problems with that patch
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #15 from diafero@arcor.de 2009-11-03 14:29:00 --- Created an attachment (id=24533) --> (http://bugs.winehq.org/attachment.cgi?id=24533) showing both sound files in Audacity: Above the correct one, below what is created with wine
http://bugs.winehq.org/show_bug.cgi?id=19182
diafero@arcor.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #24533|0 |1 is obsolete| |
--- Comment #16 from diafero@arcor.de 2009-11-03 14:29:54 --- (From update of attachment 24533) Argh, I hate Bugzilla randomly jumping to other bugs... sorry, the attachment is wrong here.
http://bugs.winehq.org/show_bug.cgi?id=19182
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |integration CC| |damjan.jov@gmail.com Component|-unknown |programs Severity|normal |enhancement
--- Comment #17 from Damjan Jovanovic damjan.jov@gmail.com 2009-11-04 09:00:51 --- For winemenubuilder, the correct component is "programs", and the keyword is "integration".
This would be a feature not a bug, also one unique to Wine (Windows doesn't have it) so downgrading importance to "Enhancement".
http://bugs.winehq.org/show_bug.cgi?id=19182
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |minor
--- Comment #18 from Austin English austinenglish@gmail.com 2009-11-04 13:09:34 --- (In reply to comment #17)
For winemenubuilder, the correct component is "programs", and the keyword is "integration".
This would be a feature not a bug, also one unique to Wine (Windows doesn't have it) so downgrading importance to "Enhancement".
It is a bug. I have winemenubuilder.exe disabled but mime-types are still added. .desktop files are not made, so that behavior is fine. .lnk files are still made, but that's not winemenubuilder's doing.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #19 from Damjan Jovanovic damjan.jov@gmail.com 2009-11-07 09:46:31 --- (In reply to comment #0)
Nor do I want all the unnecessary start menu entries to be added to my KDE menu - they end up in the wrong category anyway.
Bug 13963 now has a patch for the wrong category problem you can try.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #20 from Damjan Jovanovic damjan.jov@gmail.com 2009-11-07 10:25:34 --- (In reply to comment #18)
(In reply to comment #17)
For winemenubuilder, the correct component is "programs", and the keyword is "integration".
This would be a feature not a bug, also one unique to Wine (Windows doesn't have it) so downgrading importance to "Enhancement".
It is a bug. I have winemenubuilder.exe disabled but mime-types are still added. .desktop files are not made, so that behavior is fine. .lnk files are still made, but that's not winemenubuilder's doing.
The *feature* to disable MIME types and menus is an enhancement, since it can't be done in Windows. One of the possible *methods* to get that *feature* (ie. by disabling winemenubuilder.exe in winecfg) not working, seems to me to be a separate bug, possibly even a regression as the comments here claim.
There are many other ways to get the feature if you're so willing, eg. delete winemenubuilder, rename winemenubuilder, disallow Wine to write to ~/.config and ~/.local/... with a AppArmor rule, etc.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #21 from Rosanne DiMesio dimesio@earthlink.net 2009-11-07 10:54:12 --- Windows apps know nothing about KDE, Gnome, or any other Linux desktop manager. Wine meddling with these settings is a "feature" that does not exist in Windows to begin with.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #22 from Austin English austinenglish@gmail.com 2009-11-08 02:36:23 --- (In reply to comment #20)
(In reply to comment #18)
(In reply to comment #17)
For winemenubuilder, the correct component is "programs", and the keyword is "integration".
This would be a feature not a bug, also one unique to Wine (Windows doesn't have it) so downgrading importance to "Enhancement".
It is a bug. I have winemenubuilder.exe disabled but mime-types are still added. .desktop files are not made, so that behavior is fine. .lnk files are still made, but that's not winemenubuilder's doing.
The *feature* to disable MIME types and menus is an enhancement, since it can't be done in Windows. One of the possible *methods* to get that *feature* (ie. by disabling winemenubuilder.exe in winecfg) not working, seems to me to be a separate bug, possibly even a regression as the comments here claim.
http://bugs.winehq.org/show_bug.cgi?id=20612
http://bugs.winehq.org/show_bug.cgi?id=19182
Felix spam@femail.mine.nu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spam@femail.mine.nu
--- Comment #23 from Felix spam@femail.mine.nu 2010-03-14 20:01:49 --- (In reply to comment #2)
You can set winemenubuilder.exe to disabled in the Libraries winecfg tab.
THANK YOU for this! I've been wondering why all of those mime types keep getting re-created and was tearing my hair out wondering if my distro's packaging system was to blame. I even started writing some wrapper scripts to chmod +x wine only when I meant to run it. (The pitfalls of having other apps that pay attention to the mime types -- some of the wine-created ones took precedence over some others and resulted in my web browser trying to open Flash files with wine. NOT fun.)
In my opinion this feature should be off by default. If there are users that want it, they can click through a "I understand the risks of letting Windows applications run automatically for file types" screen.
~Felix.
http://bugs.winehq.org/show_bug.cgi?id=19182
Dylan McCall dylanmccall@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dylanmccall@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=19182
cousteau cousteaulecommandant@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cousteaulecommandant@hotmai | |l.com
--- Comment #24 from cousteau cousteaulecommandant@hotmail.com 2010-04-10 14:05:03 --- Agree with Felix. At least for the MIME types; the menu entries aren't dangerous as long as they're kept on the Wine submenu.
Also, it would be nice that, instead of creating files directly on ~/.local and ~/.config, they were created in a folder inside the wineprefix, and soft-linked from ~/.local and ~/.config. This way, removing a wineprefix folder would break the links, which would then be easily recognized and deleted with a script.
http://bugs.winehq.org/show_bug.cgi?id=19182
giner ginermail@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ginermail@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=19182
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle@yahoo.fr
http://bugs.winehq.org/show_bug.cgi?id=19182
Artem S. Tashkinov t.artem@mailcity.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |t.artem@mailcity.com
--- Comment #25 from Artem S. Tashkinov t.artem@mailcity.com 2010-11-29 03:15:48 CST --- I think the best solution to this enhancement request is [via] setting a certain shell variable, e.g.
DESKTOPINTEGRATION=0 or DE_INTEGRATION=0 or NO_DE_INTEGRATION=1 or whatever else.
Using registry for setting this option isn't the best idea, because a user might not have ~/.wine at all when he'd like to install a new application.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #26 from André H. nerv@dawncrow.de 2010-11-29 10:13:30 CST --- (In reply to comment #25)
Using registry for setting this option isn't the best idea, because a user might not have ~/.wine at all when he'd like to install a new application.
Then the user can run regedit before...
A environment variable would most likely look like WINEDESKTOPINTEGRATION, but also i doubt it will happen
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #27 from Artem S. Tashkinov t.artem@mailcity.com 2010-11-29 13:59:08 CST --- Alexandre says that he won't fix this bug because
$ export WINEDLLOVERRIDES=winmenubuilder.exe=d
is an official resolution of this bug (and it's just enough to fix it).
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #28 from giner ginermail@gmail.com 2010-11-29 14:05:20 CST --- (In reply to comment #27)
Alexandre says that he won't fix this bug because
$ export WINEDLLOVERRIDES=winmenubuilder.exe=d
is an official resolution of this bug (and it's just enough to fix it).
It looks just like work around but not a solution.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #29 from diafero@arcor.de 2010-11-29 14:05:53 CST --- Actually, while that works, it is not a proper fix: It results in this error message being shown whenever any wine app is launched:
wine: cannot find L"C:\windows\system32\winemenubuilder.exe"
Removing the corresponding Run key from the registry only temporarily fixes that, until the next prefix upgrade is performed.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #30 from Artem S. Tashkinov t.artem@mailcity.com 2010-11-29 14:32:46 CST --- (In reply to comment #28)
(In reply to comment #27)
Alexandre says that he won't fix this bug because
$ export WINEDLLOVERRIDES=winmenubuilder.exe=d
is an official resolution of this bug (and it's just enough to fix it).
It looks just like work around but not a solution.
OK, here's exactly what he's said today:
Hello, Alexandre!
I know you are a busy person and you know what's most important for Wine, but I still think bug 19182 could be solved in a matter of minutes using the proposal I've made.
Can you please consider devoting some of your valuable time to this feature request?
Use WINEDLLOVERRIDES, no need for a new feature.
This question needs to bought up at wine-devel[at]winehq.org because Alexandre doesn't receive messages from bugzilla. And whenever someone comes with a solution or patch, it will go through Alexandre.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #31 from xnitropl xnitropl@gmail.com 2010-12-11 07:28:41 CST --- Created an attachment (id=32448) --> (http://bugs.winehq.org/attachment.cgi?id=32448) disable the default integration
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #32 from Artem S. Tashkinov t.artem@mailcity.com 2010-12-16 14:49:33 CST --- Even with the "official" (export WINEDLLOVERRIDES=winmenubuilder.exe=d) solution I still get
err:menubuilder:write_freedesktop_association_entry error writing association file "/home/birdie/.local/share/applications/wine-extension-chm.desktop" err:menubuilder:write_freedesktop_mime_type_entry error writing file /home/birdie/.local/share/mime/packages/x-wine-extension-cpl.xml err:menubuilder:write_freedesktop_mime_type_entry error writing file /home/birdie/.local/share/mime/packages/x-wine-extension-dib.xml err:menubuilder:write_freedesktop_mime_type_entry error writing file /home/birdie/.local/share/mime/packages/x-wine-extension-dll.xml err:menubuilder:write_freedesktop_association_entry error writing association file "/home/birdie/.local/share/applications/wine-extension-gif.desktop" err:menubuilder:write_freedesktop_mime_type_entry error writing file /home/birdie/.local/share/mime/packages/x-wine-extension-hlp.xml err:menubuilder:write_freedesktop_association_entry error writing association file "/home/birdie/.local/share/applications/wine-extension-hlp.desktop" err:menubuilder:write_freedesktop_mime_type_entry error writing file /home/birdie/.local/share/mime/packages/x-wine-extension-htc.xml err:menubuilder:write_freedesktop_association_entry error writing association file "/home/birdie/.local/share/applications/wine-extension-htm.desktop" err:menubuilder:write_freedesktop_mime_type_entry error writing file /home/birdie/.local/share/mime/packages/x-wine-extension-inf.xml err:menubuilder:write_freedesktop_mime_type_entry error writing file /home/birdie/.local/share/mime/packages/x-wine-extension-ini.xml err:menubuilder:write_freedesktop_association_entry error writing association file "/home/birdie/.local/share/applications/wine-extension-ini.desktop" err:menubuilder:write_freedesktop_mime_type_entry error writing file /home/birdie/.local/share/mime/packages/x-wine-extension-its.xml err:menubuilder:write_freedesktop_mime_type_entry error writing file /home/birdie/.local/share/mime/packages/x-wine-extension-jfif.xml err:menubuilder:write_freedesktop_association_entry error writing association file "/home/birdie/.local/share/applications/wine-extension-jfif.desktop" err:menubuilder:write_freedesktop_association_entry error writing association file "/home/birdie/.local/share/applications/wine-extension-jpe.desktop" err:menubuilder:write_freedesktop_mime_type_entry error writing file /home/birdie/.local/share/mime/packages/x-wine-extension-lnk.xml err:menubuilder:write_freedesktop_mime_type_entry error writing file /home/birdie/.local/share/mime/packages/x-wine-extension-mht.xml err:menubuilder:write_freedesktop_mime_type_entry error writing file /home/birdie/.local/share/mime/packages/x-wine-extension-mhtml.xml err:menubuilder:write_freedesktop_association_entry error writing association file "/home/birdie/.local/share/applications/wine-extension-png.desktop" err:menubuilder:write_freedesktop_association_entry error writing association file "/home/birdie/.local/share/applications/wine-extension-rtf.desktop" err:menubuilder:write_freedesktop_association_entry error writing association file "/home/birdie/.local/share/applications/wine-extension-txt.desktop" err:menubuilder:write_freedesktop_association_entry error writing association file "/home/birdie/.local/share/applications/wine-extension-wri.desktop" err:menubuilder:write_freedesktop_association_entry error writing association file "/home/birdie/.local/share/applications/wine-extension-xml.desktop"
every time when I try to run any application.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #33 from Andrew Nguyen arethusa26@gmail.com 2010-12-16 15:02:42 CST --- (In reply to comment #32)
Even with the "official" (export WINEDLLOVERRIDES=winmenubuilder.exe=d) solution I still get
That should be winemenubuilder.exe.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #34 from Artem S. Tashkinov t.artem@mailcity.com 2010-12-16 16:14:02 CST --- I misquoted sorry, just to be sure I'm pasting my evn:
$ env | grep DLL WINEDLLOVERRIDES=winmenubuilder.exe=d
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #35 from Juan Lang juan_lang@yahoo.com 2010-12-16 16:16:25 CST --- (In reply to comment #34)
$ env | grep DLL WINEDLLOVERRIDES=winmenubuilder.exe=d
As Andrew already said, there's a typo.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #36 from Artem S. Tashkinov t.artem@mailcity.com 2010-12-16 17:13:14 CST --- I'm so stupid today, thanks for pointing me out!
Then the only errors I have are:
wine: cannot find L"C:\windows\system32\winemenubuilder.exe" err:wineboot:ProcessRunKeys Error running cmd L"C:\windows\system32\winemenubuilder.exe -a -r" (2) wine: cannot find L"C:\windows\system32\winemenubuilder.exe" wine: cannot find L"C:\windows\system32\winemenubuilder.exe" wine: cannot find L"C:\windows\system32\winemenubuilder.exe" wine: cannot find L"C:\windows\system32\winemenubuilder.exe" wine: cannot find L"C:\windows\system32\winemenubuilder.exe" wine: cannot find L"C:\windows\system32\winemenubuilder.exe" wine: cannot find L"C:\windows\system32\winemenubuilder.exe"
and only when I install something new.
http://bugs.winehq.org/show_bug.cgi?id=19182
xnitropl xnitropl@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xnitropl@gmail.com
--- Comment #37 from xnitropl xnitropl@gmail.com 2010-12-17 12:40:03 CST --- (In reply to comment #36)
Then the only errors I have are:
wine: cannot find L"C:\windows\system32\winemenubuilder.exe" err:wineboot:ProcessRunKeys Error running cmd L"C:\windows\system32\winemenubuilder.exe -a -r" (2) wine: cannot find L"C:\windows\system32\winemenubuilder.exe" wine: cannot find L"C:\windows\system32\winemenubuilder.exe" wine: cannot find L"C:\windows\system32\winemenubuilder.exe" wine: cannot find L"C:\windows\system32\winemenubuilder.exe" wine: cannot find L"C:\windows\system32\winemenubuilder.exe" wine: cannot find L"C:\windows\system32\winemenubuilder.exe" wine: cannot find L"C:\windows\system32\winemenubuilder.exe"
and only when I install something new.
Why are you surprised if you just hide winemenubuilder from wine (so "wine: cannot find" it) rather than simply turn it off in the registry (prevent it from starting as a service) after running winecfg ~/.wine/system.reg or in (before running winecfg) /usr/share/wine/wine.inf
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #38 from diafero@arcor.de 2010-12-17 13:03:09 CST --- (In reply to comment #37)
Why are you surprised if you just hide winemenubuilder from wine (so "wine: cannot find" it) rather than simply turn it off in the registry (prevent it from starting as a service) after running winecfg ~/.wine/system.reg or in (before running winecfg) /usr/share/wine/wine.inf
Both of your suggestions do not work: The registry key will be re-added after the next wine update (which triggers a prefix upgrade), and the file will be overwritten on the next "make install".
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #39 from giner ginermail@gmail.com 2011-03-14 02:57:28 CDT --- I use different WINEPREFIX very often for testing software on clean instalation. So MIME and application integration make my profile contains a lot of 'garbage'.
http://bugs.winehq.org/show_bug.cgi?id=19182
chipiwaqua@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chipiwaqua@hotmail.com
http://bugs.winehq.org/show_bug.cgi?id=19182
Henrik Danielsson h.danielsson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |h.danielsson@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=19182
stomp.stompclap@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stomp.stompclap@gmail.com
--- Comment #40 from stomp.stompclap@gmail.com 2012-04-30 13:56:58 CDT --- I also agree. This "feature" is more of a nuisance than it is worth.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #41 from diafero@arcor.de 2012-04-30 15:41:38 CDT --- Unfortunately, the only "work-around" known is annoying in that it adds error messages to each program started using wine:
wine: cannot find L"C:\windows\system32\winemenubuilder.exe" err:wineboot:ProcessRunKeys Error running cmd L"C:\windows\system32\winemenubuilder.exe -a -r" (2)
which is especially annoying for Windows console applications used via wine (for example, to use MinGW to compile windows applications without a VM).
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #42 from Artem S. Tashkinov t.artem@mailcity.com 2012-04-30 16:03:46 CDT --- (In reply to comment #41)
And this "workaround" still allows applications to install LNK files on the desktop.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #43 from diafero@arcor.de 2012-05-01 03:09:59 CDT --- (In reply to comment #42)
And this "workaround" still allows applications to install LNK files on the desktop.
This is not something the winemenubuilder integration does though, that's a mere consequence of wine symlinking the Desktop, My Documents, ... folders to their linux equivalent. You can simply remove the symlinks and create empty folders instead (~/.wine/drive_c/users/<username>). Personally, I don't concider that so much of a problem and I like windows applications to show my linux documents when I want to open a file. If there was a reliable setting that told the winemenubuilder not to do anything (but without any error messages being shown), I'd be happy.
http://bugs.winehq.org/show_bug.cgi?id=19182
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |et.junk@ethome.sk
--- Comment #44 from Rosanne DiMesio dimesio@earthlink.net 2012-07-11 08:11:10 CDT --- *** Bug 31194 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #45 from Martin Misuth et.junk@ethome.sk 2012-08-01 08:20:50 CDT --- Excuse me I was not present to discuss this. I am coming from Bug 31194.
Well it's nice mine got closed, but issue really wasn't solved.
Seems like adding correct variable to profile and exceptions to libraries listbox fixes this issue, but it simply DOESN'T SOLVE the problem.
**User should have a clearly understandable choice to completely disable integration in the correct winecfg menu, if he/she wants!**
How many of not so advanced users (think ubuntu), who would still like to send wine integration to hell, are gonna mess with their shell profile or manually add exceptions to libraries listbox?
Really guys, don't come on me with windows crap a la: "on windows aps can't disable integration bla bla"
Let crappy wine explorer handle it's own verbs and associations, but don't push on normal users this mime db disturbance of the HOST shit.
More and more users are really unhappy with wine overtaking their native desktop, and just because they are not as vocal as me right now, doesn't make the problem go away.
Most of them were completely clueless that winemenubuilder is the culprit, and one of my acquintances even removed wine altogether to sort this shit out.
Please fix this by providing normal visible and sensible option and give users choice, not everybody wants wine to overake his computer Microsoft fashion.
What wine does with it's registry is it's problem but don't crap my mime acssociations please.
I tolerated this shit 2 years but now i am really fed up.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #46 from Artem S. Tashkinov t.artem@mailcity.com 2012-08-01 09:38:05 CDT --- (In reply to comment #45)
To say it bluntly Alexander Julliard doesn't give a flying f-word about this bug, so you have two options: either write a patch to implement this feature or hire someone who'll do that for you.
Of course, there's no guarantee whatsoever that Alexander will approve this patch, but you can at least keep it here and apply for your own installation.
There are many bug reports of this kind - the ones which have patches but those patches are vetoed from inclusion.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #47 from Martin Misuth et.junk@ethome.sk 2012-08-01 11:46:39 CDT --- Well I am not a coder, but maybe I should try. May I ask why are such patches vetoed ? They ruin wine for everybody?
Wine is pushing integration too hard - for example mountig home dir is quite a security risk. Why is that?
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #48 from diafero@arcor.de 2012-08-01 11:54:41 CDT --- (In reply to comment #47)
Wine is pushing integration too hard - for example mountig home dir is quite a security risk. Why is that?
Uh, wine has no security features at all. Every windows application running with your user privileges can do anything a linux application could do, no matter which folders are assigned drive letters and which are not. So, mounting the home directory is not a security risk at all. If you need security and separation, use a virtual machine, or a linux container or something similar.
On another note: How could/should a patch fixing this problem look like, if it aims at getting accepted? A checkbox in winecfg won't work, because when winecfg is started, wine already created these mimetypes and stuff. So, at the very least enabling that checkbox would have to remove the previously created mimetypes.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #49 from Artem S. Tashkinov t.artem@mailcity.com 2012-08-01 12:16:08 CDT --- Checkbox won't help for one very important reason - some users absolutely need integration, others absolutely abhor it.
I think there can be a much better solution, something similar to what's already implemented in Crossover Office.
Any changes in regard to associations/new installed shortcuts/etc should be made temporary in Wine and after the application or installer finished, Wine should show a window asking the user if he/she wants to commit those changes to his Unix desktop or not, e.g.
Pending Desktop Integration
Application MyCoolApp.exe has installed new shortcuts or/and made changes to files associations. Do you want to integrate these changes into your Linux desktop environment?
Yes | No
In this case there's no need for any checkbox'es in WineCFG, there's no need to use any hacks (like `export WINEDLLOVERRIDES=winemenubuilder.exe=d`), you just approve or disapprove the changes.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #50 from Artem S. Tashkinov t.artem@mailcity.com 2012-08-01 12:28:53 CDT --- (In reply to comment #47)
Well I am not a coder, but maybe I should try. May I ask why are such patches vetoed ? They ruin wine for everybody?
There's a certain policy (code style, code cleanness, adherence to Wine development principles, etc.), there's a certain vision and there's certain person (Alexander) who has his own understanding of where Wine's going. Some patches happen to be in opposition with the mentioned things.
Wine is pushing integration too hard - for example mountig home dir is quite a security risk. Why is that?
Like it's already been mentioned any Windows application can access anything your Unix user account can. To make things worse, Wine allows Windows applications to run Unix commands (so, if you have passwordless 'sudo su -' then a Windows application can potentially do pretty much anything with your computer).
Wine has never been meant to be a sandbox. If you care about security, you must check all your windows applications with the antivirus software, and ideally you should run them under a separate user account/sandbox/virtual machine.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #51 from André H. nerv@dawncrow.de 2012-08-01 12:52:54 CDT --- (In reply to comment #49)
Checkbox won't help for one very important reason - some users absolutely need integration, others absolutely abhor it.
I think there can be a much better solution, something similar to what's already implemented in Crossover Office.
Any changes in regard to associations/new installed shortcuts/etc should be made temporary in Wine and after the application or installer finished, Wine should show a window asking the user if he/she wants to commit those changes to his Unix desktop or not, e.g.
Pending Desktop Integration
Application MyCoolApp.exe has installed new shortcuts or/and made changes to files associations. Do you want to integrate these changes into your Linux desktop environment?
Yes | No
That really would be nice, but maybe with some "dont ask me again" (per wineprefix), otherwise i see a new bug report coming :)
(In reply to comment #45)
... Let crappy wine explorer handle it's own verbs and associations, but don't push on normal users this mime db disturbance of the HOST shit. ... Most of them were completely clueless that winemenubuilder is the culprit, and one of my acquintances even removed wine altogether to sort this shit out. ... What wine does with it's registry is it's problem but don't crap my mime acssociations please. ... I tolerated this shit 2 years but now i am really fed up.
It's hard to take you seriously with such immature writing and when you easily tolerated this for 2 years
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #52 from Martin Misuth et.junk@ethome.sk 2012-08-01 20:13:57 CDT ---
It's hard to take you seriously with such immature writing and when you easily tolerated this for 2 years.
I don't mind appearing as immature and I don't mind if I come accross as trolling or retarded. Think what you want about it, but this is expression of genuine frustration. I know I am not alone. I think after years of fixing my mime entries from backup, I have full right to complain vocally and to even swear a fair bit.
To me it appears much more immature to steal associations of the host system by default. WINE's iexplorer for handling image files? Come on. Thats like worst decision. I know it was like that on windows till XP's image viewer arrived (or something like that), and remember very well how it always made me angry. That was the reason I was happy with Linux, but coming full circle, WINE is now doing very same thing. That is just sad.
In any case, well behaved WINE would ask me before first run whether I even want integration or not. I don't care about prefixes, WINE should handle it. If winemenubuilder is not making those .lnk and .desktop files, then that something else what is creating them, should respect my wish to have no integration at all as well.
I don't know how freedesktop suggests to sort out mime type priorities, but I know for a fact that on many computers (not just mine) I must setup a script to restore mimetypes from backup, or now when I know better, add above mentioned hacks.
Windows apps know nothing about KDE, Gnome, or any other Linux desktop manager. Wine meddling with these settings is a "feature" that does not exist in Windows to begin with.
My words, exactly. Why can't we have sane default of being asked first, during very first initialisation, while we are still focused to the fact, we are initialising wine for first time?
Pending Desktop Integration
Application MyCoolApp.exe has installed new shortcuts or/and made changes to files associations. Do you want to integrate these changes into your Linux desktop environment?
Yes | No
Have you seen how "normal" users behave, when they are shown such dialog by firewall on windows? It's nice at first, but after a while it becomes annoying. And many just click whathever is closer to mouse cursor without even reading.
Uh, wine has no security features at all. Every windows application running with your user privileges can do anything a linux application could do, no matter which folders are assigned drive letters and which are not.
Point taken.
Integration is nice for those who care about it, but there is fair number of those, who are not that happy with it too. What can we expect next, automatic binfmt_misc registration without even being asked?
Maybe there should be separate program created as integration cleaner / enabler? I don't know, but just running amok stealing mimetypes and dropping desktop files everywhere cannot sound right.
http://bugs.winehq.org/show_bug.cgi?id=19182
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #53 from Bruno Jesus 00cpxxx@gmail.com 2012-08-01 21:05:53 CDT --- Usually I test several different applications and most of the times in different prefixes. To avoid app integration issues I do all testing using a different user for wine (named wine). After sometime I stopped using my main user with wine and I started running all applications with the other user. You could try this, I hope it helps.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #54 from Rosanne DiMesio dimesio@earthlink.net 2012-08-02 09:17:10 CDT --- Well, since people are quoting my earlier words, I suppose I better weigh in.
Philosophically, I stand by my earlier statement; IMO, adding mimetype associations to the host system instead of just to Wine's explorer goes beyond mimicking Windows. If I had my druthers, it would be off by default, with a simple checkbox in winecfg to turn it on for people who want it.
But as a practical matter, working around this is trivial. Adding the override to .bashrc quashes it once and for all for that user, and the instructions for how to do that have been in the FAQ for over three years. I do not think adding a single line to a plain text file that does not even require sudo to edit is beyond the mental capacity of normal users.
I also think some people are greatly overstating the dire effects of not turning it off. My experience (on KDE) before I disabled it entirely was that mimetypes were added to the bottom of the list of associations, so the default for the system was not changed: LibreOffice still opened doc files when I clicked them, even though Wine had added a more than a dozen associations for Word (none of which worked, btw) to the list. If someone is seeing Wine's associations supersede existing defaults, IMO, they should file a bug for that, because I don't think that's the intended behavior.
As to the suggestion for some sort of complicated dialog to pester users about this every time they create a wineprefix, personally, I would find that MORE intrusive, so if someone decides to add that, please make sure there is an easy way to disable that once and for all.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #55 from diafero@arcor.de 2012-08-02 09:47:16 CDT --- (In reply to comment #54)
But as a practical matter, working around this is trivial. Adding the override to .bashrc quashes it once and for all for that user, and the instructions for how to do that have been in the FAQ for over three years. I do not think adding a single line to a plain text file that does not even require sudo to edit is beyond the mental capacity of normal users.
Just that this does not work reliably, as was reported repeatedly in this thread: Even with the appropriate override being in place, sometimes mime-type associations are added.
I also think some people are greatly overstating the dire effects of not turning it off. My experience (on KDE) before I disabled it entirely was that mimetypes were added to the bottom of the list of associations, so the default for the system was not changed: LibreOffice still opened doc files when I clicked them, even though Wine had added a more than a dozen associations for Word (none of which worked, btw) to the list. If someone is seeing Wine's associations supersede existing defaults, IMO, they should file a bug for that, because I don't think that's the intended behavior.
Then you were lucky, for some reason. Before I managed to properly disable this behaviour (by patching my local wine installation to make winemenubuilder.exe exit immediately), wine would regularly change the default program associated with file associations like .txt or .inf. For local files, this was hardly noticeable as Dolphin noticed from the content that these were just text files. But if a content analysis was not possible (like, for example, when using the sftp:/ KIO slave to work on a foreign machine - which I do often), then only the filename is used to determine the file type, which means that every file ending .txt, .inf and some other endings would start notepad (which of course fails to get the file from the remote machine)... So yes, this kind of "integration" IS annoying.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #56 from Rosanne DiMesio dimesio@earthlink.net 2012-08-02 10:11:28 CDT --- (In reply to comment #55)
Just that this does not work reliably, as was reported repeatedly in this thread: Even with the appropriate override being in place, sometimes mime-type associations are added.
That's bug 20612. My own experience is that that problem was caused by winetricks (I used to see it with WMP), and that has been fixed in winetricks. If you are still seeing plain Wine do that you should add a comment to that bug.
But if a content analysis was not possible (like, for example, when using the sftp:/ KIO slave to work on a foreign machine - which I do often), then only the filename is used to determine the file type, which means that every file ending .txt, .inf and some other endings would start notepad (which of course fails to get the file from the remote machine)...
So, is Wine adding the .txt and .inf associations for notepad to the TOP of the list (making it the default), or is Dolphin ignoring the list order?
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #57 from diafero@arcor.de 2012-08-03 06:38:00 CDT --- (In reply to comment #56)
But if a content analysis was not possible (like, for example, when using the sftp:/ KIO slave to work on a foreign machine - which I do often), then only the filename is used to determine the file type, which means that every file ending .txt, .inf and some other endings would start notepad (which of course fails to get the file from the remote machine)...
So, is Wine adding the .txt and .inf associations for notepad to the TOP of the list (making it the default), or is Dolphin ignoring the list order?
I don't know. My impression was that wine added new mimetypes (called application/x-wine-something or similar) for these filename patterns.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #58 from Rosanne DiMesio dimesio@earthlink.net 2012-08-04 07:09:00 CDT --- I haven't seen anything added by Wine since I put the override in my .bashrc. Before that, I was doing it manually for each wineprefix, and in retrospect, I think at least some of the cases where mimetypes got added seemingly against my will were simply cases where I forgot to specify the override before running something. That's easy to do, so I really recommend putting it in .bashrc.
But if you are seeing cases where plain Wine really is adding mimetypes even though you have the override in .bashrc, please post exact steps to reproduce the problem in bug 20612. IMO, the current problem with that bug is that the only examples mentioned involve winetricks, and that was a winetricks problem.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #59 from Sylvain Petreolle spetreolle@yahoo.fr 2012-08-07 07:48:08 CDT --- (In reply to comment #58)
But if you are seeing cases where plain Wine really is adding mimetypes even though you have the override in .bashrc, please post exact steps to reproduce the problem in bug 20612. IMO, the current problem with that bug is that the only examples mentioned involve winetricks, and that was a winetricks problem.
The last comment in bug 20612 involves an user with the override and no winetricks.
http://bugs.winehq.org/show_bug.cgi?id=19182
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.winehq.org/show | |_bug.cgi?id=20612
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #60 from Rosanne DiMesio dimesio@earthlink.net 2012-08-07 08:10:39 CDT --- (In reply to comment #59)
The last comment in bug 20612 involves an user with the override and no winetricks.
That comment does not include explicit steps to reliably reproduce the problem.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #61 from Hristo Venev mustrumr97@gmail.com 2012-08-11 13:15:27 CDT --- Created attachment 41342 --> http://bugs.winehq.org/attachment.cgi?id=41342 winemenubuilder
I have a patch which conditionally disables it in winemenubuilder using a registry value at HKCU\Software\Wine\FileOpenAssociations\Enable. I'll be very glad if it gets included for a wine release because I hate having to change file associations.
http://bugs.winehq.org/show_bug.cgi?id=19182
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch CC| |adys.wh@gmail.com
--- Comment #62 from Jerome Leclanche adys.wh@gmail.com 2012-08-11 14:10:20 CDT --- (In reply to comment #61) Patches are not picked up from bugzilla, please send it to wine-patches.
http://bugs.winehq.org/show_bug.cgi?id=19182
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |punx69@gmx.net
--- Comment #63 from Rosanne DiMesio dimesio@earthlink.net 2013-01-03 12:31:53 CST --- *** Bug 32636 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=19182
Per Johansson per@morth.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |per@morth.org
--- Comment #64 from Per Johansson per@morth.org 2013-03-26 10:12:42 CDT --- I only just noticed this bug. FWIW my currently submitted appbundle patches to winemenubuilder adds an option to disable it (winemenubuilder) through the registry. They're yet to be approved though.
http://bugs.winehq.org/show_bug.cgi?id=19182
Gregori awebster@falsecolour.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |awebster@falsecolour.com
--- Comment #65 from Gregori awebster@falsecolour.com 2013-08-21 14:59:55 CDT --- *** Bug 34320 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=19182
liquider liquiderz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |liquiderz@gmail.com
--- Comment #66 from liquider liquiderz@gmail.com --- xnitropl's patch gives a clue.
The most casual Wine user may WANT their XDG menu populated with launchers to newly installed software, but NOT WANT their host system's file associations modified. In this case, the FAQ-solution about disabling winemenubuilder.exe does not apply.
Instead, how about Wine upstream distribution, for the benefit of all, sets winemenubuilder.exe Service to run without -a switch by default?
winemenubuilder.exe with -a switch, as documented in the source, updates file associations. Should one, e.g. a popular distribution maintainer, wish their winemenubuilder to build freedesktop menus but not snatch mimeapps, the Services group in the systemwide wine.inf file can be amended to only ever run "winemenubuilder.exe -r".
Is this correct? Is "winemenubuilder.exe -a" ever run regardless of this setting (provided a user doen't have a already-tainted $WINEPREFIX/system.reg file)? If not, the majority of wine users strongly agrees there should be an option to build menus without changing mime associations.
http://bugs.winehq.org/show_bug.cgi?id=19182
Lesmana lesmana@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lesmana@gmx.de
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #67 from Lesmana lesmana@gmx.de --- IMO the way to fix this is to follow the unix philosophy: do one thing and do it well. wine does one thing: provide the windows API. it should not do another thing: mess around with the file associations in the linux desktop.
instead of adding file associations directly wine should provide an interface, something like a socket. when a windows program want to change a file association wine will publish this on the socket. a client can then listen to the socket and react to the messages however it sees fit.
this way distributions like ubuntu can set up a listener which will add any and all file associations from windows programs to their desktop, while people who do not want windows programs from messing around in their linux desktop can just ignore the socket. it is even possible to write a listener which will ask the user first before adding the file association.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #68 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to comment #67)
IMO the way to fix this is to follow the unix philosophy: do one thing and do it well. wine does one thing: provide the windows API. it should not do another thing: mess around with the file associations in the linux desktop.
Nothing prevents it to work properly. The source is there and patches are gladly accepted.
http://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #69 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to comment #67)
IMO the way to fix this is to follow the unix philosophy: do one thing and do it well. wine does one thing: provide the windows API. it should not do another thing: mess around with the file associations in the linux desktop.
IMO Winelib provides the Windows API, Wine is much more than that.
instead of adding file associations directly wine should provide an interface, something like a socket. when a windows program want to change a file association wine will publish this on the socket. a client can then listen to the socket and react to the messages however it sees fit.
this way distributions like ubuntu can set up a listener which will add any and all file associations from windows programs to their desktop, while people who do not want windows programs from messing around in their linux desktop can just ignore the socket. it is even possible to write a listener which will ask the user first before adding the file association.
That "listener" would need to call the Windows API, read/write the registry, and do things like extract icons embedded in EXE/DLL files - 16, 32 and 64 bit versions of those. There's a reason winemenubuilder runs inside Wine.
https://bugs.winehq.org/show_bug.cgi?id=19182
yanestra vanish@arcor.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vanish@arcor.de
--- Comment #70 from yanestra vanish@arcor.de --- Under no circumstances shall an encapsulated application (via an emulator) damage or modify its host. This is what Wine does all the time. An excessively annoying behaviour.
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #71 from Artem S. Tashkinov t.artem@mailcity.com --- (In reply to yanestra from comment #70)
Under no circumstances shall an encapsulated application (via an emulator) damage or modify its host. This is what Wine does all the time. An excessively annoying behaviour.
Wine Is Not an Emulator. It's not a virtual machine either - it's a translation layer for Win32 API.
IMO this bug should be resolved this way: upon discovering new associations, Wine should show a configuration window where you can selectively propagate these associations to your Linux host. If I'm not mistaken CrossOver Office already behaves this way.
https://bugs.winehq.org/show_bug.cgi?id=19182
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |davidhoch.hh@gmail.com
--- Comment #72 from Rosanne DiMesio dimesio@earthlink.net --- *** Bug 37763 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=19182
Fincer fincer89@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fincer89@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=19182
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sb56637@gmail.com
--- Comment #73 from Rosanne DiMesio dimesio@earthlink.net --- *** Bug 40417 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=19182
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ddascalescu+wine@gmail.com
--- Comment #74 from Bruno Jesus 00cpxxx@gmail.com --- *** Bug 41275 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #75 from Artem S. Tashkinov t.artem@mailcity.com --- (In reply to Bruno Jesus from comment #74)
*** Bug 41275 has been marked as a duplicate of this bug. ***
This bugzilla desperately needs an extra text field which would contain a workaround or temporary solution for a bug.
Digging this bug report for a solution is a Herculean task.
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #76 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Artem S. Tashkinov from comment #75)
Digging this bug report for a solution is a Herculean task.
No one has to. The info has been in the FAQ for years. https://wiki.winehq.org/FAQ#How_can_I_prevent_Wine_from_changing_the_filetyp...
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #77 from Artem S. Tashkinov t.artem@mailcity.com --- (In reply to Rosanne DiMesio from comment #76)
(In reply to Artem S. Tashkinov from comment #75)
Digging this bug report for a solution is a Herculean task.
No one has to. The info has been in the FAQ for years.
Still it would be nice to have this information posted at the top of this page.
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #78 from Dan Dascalescu ddascalescu+wine@gmail.com --- Disabling winemenubuilding will also prevent associations the user actually wants made, most often Office file types (.XLSM, .PPTX etc.).
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #79 from liquider liquiderz@gmail.com --- I _strongly_ doubt the _MAJORITY_ of Wine users expect to open OOXML files with MS Office when the native alternatives work so well. Or INI files in IE6. Or GIF images in IE6 ...
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #80 from Henri Verbeet hverbeet@gmail.com --- (In reply to liquider from comment #79)
I _strongly_ doubt the _MAJORITY_ of Wine users expect to open OOXML files with MS Office when the native alternatives work so well.
Well, perhaps not Wine users in general, but it doesn't seem that unlikely that the people that went through the trouble of installing MS Office actually want to use it.
That's not to say some other associations aren't unfortunate, but it isn't necessarily easy to always do the right thing, or clear what that even is.
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #81 from liquider liquiderz@gmail.com --- Why override defaults when right-clicking to Open with ... is easy enough?
Simply installing Wine hijacks tens of associations, all of which are abysmal and not trivial to revert in batch.
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #82 from Artem S. Tashkinov t.artem@mailcity.com --- (In reply to liquider from comment #81)
Why override defaults when right-clicking to Open with ... is easy enough?
Simply installing Wine hijacks tens of associations, all of which are abysmal and not trivial to revert in batch.
Wine already has a solution for this issue in a form of Crossover Office. Alexander Julliard just doesn't feel like open sourcing it. If you write an actual patch which allows to choose what Windows associations need to propagate to your Linux profile it might be merged.
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #83 from Austin English austinenglish@gmail.com --- (In reply to Artem S. Tashkinov from comment #82)
(In reply to liquider from comment #81)
Why override defaults when right-clicking to Open with ... is easy enough?
Simply installing Wine hijacks tens of associations, all of which are abysmal and not trivial to revert in batch.
Wine already has a solution for this issue in a form of Crossover Office. Alexander Julliard just doesn't feel like open sourcing it.
Where are you getting that info from?
The source is available here: https://www.codeweavers.com/products/more-information/source
https://bugs.winehq.org/show_bug.cgi?id=19182
Detlef Riekenberg wine.dev@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine.dev@web.de
https://bugs.winehq.org/show_bug.cgi?id=19182
Jens Reyer jre.winesim@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jre.winesim@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=19182
winetaste@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetaste@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=19182
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |186ae9ed31317aa76b2f768b2b5 | |55451b2021057 Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #84 from Dmitry Timoshkov dmitry@baikal.ru --- Since wine-3.14 (commit 186ae9ed31317aa76b2f768b2b555451b2021057) Wine now has a winecfg switch (in the Desktop Integration tab) that disables file associations management performed by Wine.
Some distributions may even consider adding a registry key that disables file associations management by default.
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #85 from Rahim sb56637@gmail.com --- Excellent! That's great news.
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #86 from Pekka Helenius fincer89@hotmail.com --- Yeah, this is good news indeed. Thanks for implementing the feature!
Just to add some info for other users. The global registry key for this new setting is (Wine 3.14 or newer):
"HKCU\Software\Wine\FileOpenAssociations\Enable" (REG_SZ)
Value (without quotes) - File associations enabled:
"Y"
Value (without quotes) - File associations disabled:
"N"
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #87 from diafero@arcor.de --- That's great indeed, thanks. :)
Is there some way as a user to e.g. set an environment variable or put something into `~/.config` or so to do this globally for all prefixes? I wouldn't want to accidentally have this enabled when I created a new prefix.
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #88 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to diafero from comment #87)
Is there some way as a user to e.g. set an environment variable or put something into `~/.config` or so to do this globally for all prefixes? I wouldn't want to accidentally have this enabled when I created a new prefix.
Disabling winemenubuilder in ~/.bashrc still works, though that will also disable the creation of menu entries when you install apps.
https://bugs.winehq.org/show_bug.cgi?id=19182
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #89 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.15.
https://bugs.winehq.org/show_bug.cgi?id=19182
jpegxguy@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jpegxguy@outlook.com
--- Comment #90 from jpegxguy@outlook.com --- Comment #66 reflects my view.
What I have done in my Arch install for now is to remove the -a switch specified in /usr/share/wine/wine.inf and (IMPORTANT!) add that file to the NoUpgrade array in /etc/pacman.conf so that it doesn't get overwritten when wine is upgraded. On upgrade the file will be saved with the .pacnew extension and then I can merge any changes that *aren't* about messing up my associations.
I originally found this here: https://askubuntu.com/a/400430
It works beautifully. The change propagates to any new prefixes and I still get the nice XDG desktop entries for my start menu in Cinnamon.
I think it should be the default.
https://bugs.winehq.org/show_bug.cgi?id=19182
--- Comment #91 from Leo jpegxguy@outlook.com --- For anyone searching for workarounds, ArchWiki's got your back with dynamically updated info:
https://wiki.archlinux.org/index.php/Wine#Prevent_new_Wine_file_associations
-
wine-bugs＠winehq.org