Wine 1.3.19 Improves Direct3D 9 Support

[bobwya]

I, like many other Linux-based O.S. users, would spend most of my time logged into Windows 7 without the efforts of the WINE developers. I subscribe to mailing lists - I can see the whole thing is a bit of a bloated mess - but at the end of the day a lot of applications work really well in WINE and without much effort (on the part of the user).

I am sure Valve would even be considering releasing a Steam client for Linux if it wasn't for the WINE project.

All the complaints about WINE file associations side-effects are frankly rather lame... As for the WINE main menu entries I just delete all the entries and put in what I want - boom - problem solved (unless you find it hard to edit your menus ).

Bob

[dacha]

No.
This one is by far better:

chmod o-w -R ~/.local/share/applications/

This will strip ability to modify any custom file associations for current user.
Do o+w for reverse.
The problem is that crappy WINE has no option to stop integrating windows bullsh!t into linux DE. It replaces many associations bound to sane linux programs instead to windows bullcr@p or wine running that bullcr@p. No one understands why. People need WINE to run 1-2 wincrap programs over linux, but instead WINE tries to pull wincr@p on linux.

Disabling the ability to modify custom associations fixes this WINE idiocy. Or you have to patch it to remove that crap in the binary.

But don't worry, WINE STILL makes all your user files available for write to wincrap stuff and there is no official way to run wincrap programs under different user, whilst remaining in original user (like sudo, but for wine), so wincr@p stuff has zero access to user files. Because it runs viruses as well. Well, I figured out how to do that but somebody should really make codewavers FIX this.

Codeweavers didn't write the file type association code, I did.

If you are not using menu shortcuts and file type associations, then you're probably a power user typing stuff in a terminal, and you can figure out how to rename/delete winemenubuilder or disable it in winecfg, delete .desktop files as shown above, or patch the Wine source code and compile it yourself. Also instructing your Windows application not the generate associations works too.

I for one love the fact that some Windows file types which Linux doesn't easily open itself (eg. HLP, CHM) open just fine when you have Wine installed.

If you have constructive suggestions about how the integration could be done better, or real problems that could be fixed, I am waiting to hear them.

[devius]

If you have constructive suggestions about how the integration could be done better, or real problems that could be fixed, I am waiting to hear them.

Cool. Here I go:

1. Don't associate text files with notepad.exe. Every single text editor that runs natively in linux can open these files just fine.

2. Don't associate image files (tested with png, jpg and gif), with "wine core exe" (whatever that is), because once again most distros will already include viewers for those file types.

3. Don't associate xml and html files with "winebrowser", "notepad" and "wine core exe". Isn't winebrowser using the gecko rendering engine? If so, what's the point of opening those files in it compared to regular firefox?

4. When wine is removed from the system delete all the associations (this is probably a distro issue, and if you confirm it is so I'll file a bug with the distro)

5. All wine context menu entries are using a generic icon and this is a bit ugly. Is this because I uninstalled wine and so the application's icons are no longer available or is this normal behaviour? If this is normal, then these entries could use more meaningful icons.

[stqn]

The automatic file association of Wine certainly is annoying. This is rendered worse by the fact that (at least on Arch Linux / Xfce) the favourite application for each filetype sometimes gets messed up when updating software.

[dacha]

Cool. Here I go:

1. Don't associate text files with notepad.exe. Every single text editor that runs natively in linux can open these files just fine.

2. Don't associate image files (tested with png, jpg and gif), with "wine core exe" (whatever that is), because once again most distros will already include viewers for those file types.

3. Don't associate xml and html files with "winebrowser", "notepad" and "wine core exe". Isn't winebrowser using the gecko rendering engine? If so, what's the point of opening those files in it compared to regular firefox?

4. When wine is removed from the system delete all the associations (this is probably a distro issue, and if you confirm it is so I'll file a bug with the distro)

5. All wine context menu entries are using a generic icon and this is a bit ugly. Is this because I uninstalled wine and so the application's icons are no longer available or is this normal behaviour? If this is normal, then these entries could use more
meaningful icons.

(Why didn't my post come through the first time around? Anyway...)

On 23 November 2010 my patch to rename "Wine Core Exe" to "Wine Internet Explorer" was committed (http://source.winehq.org/git/wine.gi...647110f4997992).

As for point 5, on 17 November 2010 my patch to add context menu icons was committed (http://source.winehq.org/git/wine.gi...aa87838f154f25).

Please always test the latest release when you report problems.

As for .txt, .jpg, and such, those shouldn't be used by default (if you double-click a .txt file it shouldn't open with Notepad). Does it really matter if they're there, but unused? They offer more choice.

Point 4 is interesting. Distro package managers usually only manage system directories such as /bin, /lib, /usr, /etc, /var and such. Wine's menu/icon/association files are in $HOME/.local/share/applications. Thus to remove those files on uninstall, the package uninstall script would have to scan all users' home directories and delete those files. But what if you're uninstalling Wine to install a different version of it, and want those files to stay behind? You see the problem. Also, each user might want something different to happen to their $HOME.

Maybe whether Wine installs menu and associates at all, could be some sort of opt-out setting when you create your WINEPREFIX for the first time, the way that whether to install the Gecko plugin is a setting now.

[devius]

Please always test the latest release when you report problems.

You're right. These results are from an older version o wine I installed some months ago. It was from the 1.3 series IIRC.

As for .txt, .jpg, and such, those shouldn't be used by default (if you double-click a .txt file it shouldn't open with Notepad). Does it really matter if they're there, but unused? They offer more choice.

Yes, they aren't used for default, except .txt which did got associated with notepad IIRC. That was my main issue. Of course it's an easy fix, but it still shouldn't have happened. When I get the time to try a newer version I'll see if this still happens and report back. The problem with the context menus being there but unused is that they "polute" my menus. I'm a bit obsessive, and having stuff around that doesn't do anything, or is related to something that doesn't exist anymore makes me go crazy!

Thus to remove those files on uninstall, the package uninstall script would have to scan all users' home directories and delete those files. But what if you're uninstalling Wine to install a different version of it, and want those files to stay behind? You see the problem. Also, each user might want something different to happen to their $HOME.

That makes sense and it's how most (if not all) software works.

Maybe whether Wine installs menu and associates at all, could be some sort of opt-out setting when you create your WINEPREFIX for the first time, the way that whether to install the Gecko plugin is a setting now.

That would be awesome because as it is I'm "scared" of installing wine since I know it's going to create a ton of associations and context menus I don't want. I'm sure there are others out there who also feel this way, Right now wine is too intrusive.