winemenubuilder - MIME type handling GSoC - bad idea

Sebastian Lackner sebastian at
Sun Mar 15 22:32:54 CDT 2015


I would also like to join this discussion.

First of all, we already know that no matter how "good" the idea is, there is always a risk that it will not be accepted upstream. As long as least a part of the Wine community thinks it is useful, we should give students the possibility to pick this task, imho.

On 16.03.2015 03:06, Damjan Jovanovic wrote:
> Hi
> I welcome this discussion.
> Of course manually deleting files in ~/.local is not user friendly,
> and it was never intended to be done that way.
> I did not write the part of the Wiki entry suggesting that applet :-).
> If you install a Windows app on Windows, and it creates menus and file
> associations, you don't get to opt out, and have to use a 3rd party
> tool to edit or delete those afterwards. If you install a Linux app on
> Linux, and it creates menus and file associations, you also don't get
> to opt out, and have to use a 3rd party tool (a Freedesktop
> menu/association editing tool) to edit or delete those afterwards. Why
> is Wine so special?

The big difference between Wine and other linux software packages is that those packages only add assocications for "useful" things, and they are removed again when uninstalling the package. Wine on the other hand adds associations for a lot of unnecessary stuff. In addition to that the associations remain and are broken when deleting the prefix.

> What are people actually looking for? For Wine not to create
> menu/associations when running on a non-"~/.wine" WINEPREFIX? For a
> way to stop the annoying use of Wine's "Internet Explorer" to open
> jpeg files? Anything else?

People are looking for a well-working Wine, without having to use third-party unsupported prefix management tools or doing things manually. Thats the whole idea of having configuration tools like winecfg in addition to regedit. I personally know how to solve / workaround these issues, in fact I try to avoid winemenubuilder completely because otherwise my whole system gets messed up with unwanted associations. That is exactly what the GSOC idea is trying to solve, find a way to solve this problem. The idea of moving parts to winecfg was just a suggestion, if there are other useful ideas, they can also be considered and discussed of course.

A lot of people are using third party Wine versions and builds already, but that doesn't mean that upstream should completely ignore the aspect of providing user-friendly software.

> BTW you don't need distro binfmt handlers to double-click .exe (and
> .msi and .lnk) files: Wine's tools/wine.desktop handles those. You
> only need binfmt handlers to run .exe directly from the command line -
> when you aren't in a desktop where you can use "xdg-open
> /path/to/file.exe". I suspect the Ubuntu package installs a binfmt
> handler because it doesn't know that.
> Regards
> Damjan

Best regards,

> On Sun, Mar 15, 2015 at 5:03 PM, Michael Müller <michael at> wrote:
>> Hi Damjan,
>> the idea of the GSOC project is to make the mime type association more
>> user friendly for ordinary users. Manually deleting files in
>> ~/.local/share/mime/ (which some users don't even find because it is a
>> hidden folder) or requiring a 3rd party program is not user friendly. If
>> Wine creates these associations it should also provide you with a way to
>> get rid of them. Even the wiki entry mentions that an applet would be
>> useful to manage these associations.
>> There is also no obvious way to disable the integration, there is no
>> checkbox or something like this in winecfg, you will need to lookup that
>> winemenubuilder is the component responsible for this and disable it
>> manually with library overrides. We are talking about users who use wine
>> by double clicking on an executable (using the binfmt handler installed
>> by their distro) or by using a menu entry and who wonder why all their
>> txt files now open with notepad and how to get rid of this.
>> There is also no easy and obvious way to create mime types only for a
>> specific program, i.e. disable the integration but later decide to
>> enable it only for Word and .doc* files. There might be different
>> solutions for this problem, but I think you can't deny that there is
>> something going wrong if you get a bug report with 72 comments and 4
>> duplicates. Arguing that providing a way to disable the integration
>> again would be a new feature and not a bug fix doesn't help us in this
>> case. If you have better ideas how to make the integration more user
>> friendly, feel free to share them with us, but your comments didn't
>> convince me so far that this GSOC idea is bad.
>> Maybe Rosanne can share her opinion on this topic, since she has more
>> contact with users complaining about this "feature".
>> Regards,
>> Michael
>> Am 15.03.2015 um 11:02 schrieb Damjan Jovanovic:
>>> Hi
>>> As the author of most of winemenubuilder, I am disappointed at how
>>> poorly understood it remains.
>>> The "Winecfg / winemenubuilder - enhance MIME type handling" GSoC idea
>>> suggests "The idea of this task is to provide a GUI (most probably as
>>> part of winecfg) to control the creation of such MIME type assignments
>>> and therefore making Wine more user friendly."
>>> If you read about the design of winemenubuilder's file associations on
>>> you'll see that
>>> winemenubuilder logs each file association mapping to the registry on
>>> creation, and doesn't recreate it if it's already in the registry and
>>> the .desktop file is gone. This allows you not just to customize and
>>> delete file associations by editing the registry, but also by editing
>>> the Freedesktop associations (and menus btw) with Freedesktop tools -
>>> .desktop files you've deleted in those tools won't be recreated by
>>> Wine (unless you uninstall and reinstall the Windows app).
>>> I believe people have been spoiled by installing everything through
>>> their distro package manager, and thus don't know about/use
>>> Freedesktop menu/association editing tools, so they now expect Wine to
>>> do something that even Windows doesn't.
>>> If Freedesktop tools don't let you edit file associations, surely
>>> that's a missing feature in those tools, not a GSoC project in Wine?
>>> Additionally Windows apps for editing menus and file associations
>>> (example list at
>>> should work under Wine.
>>> Thank you
>>> Damjan

More information about the wine-devel mailing list