On Fri, May 14, 2010 at 12:31 PM, Joerg-Cyril.Hoehle@t-systems.com wrote:
Hi,
Hi
The 64-bit support is now more or less complete
I hope I can finish my MCI parser patches in time. Without them, every 64bit app using MCI string commands is likely to crash (OTOH MCI commands work (those using the MCI_*_PARAMS structures)).
What can Mac users expect from this release?
Hopefully, conversion to Linux :-).
Yesterday I installed an app with wine-1.1.44 on Mac OS (instead of moving it from a Linux install). It was disappointing from a user POV:
- Wine created .desktop files that work on Linux but don't make sense
on Mac OS. Here I've been thinking about a simple patch that would instead generate a .command file like I've described in the FAQ. OTOH, Steven Edwards IIRC once had a much more elaborate patch about better Mac OS integration, rejected last year.
- In the hidden directory ~/.local/share/icons/ it created .xpm files
that the Finder does not display. .png would be displayed.
winemenubuilder generates .png only for 24 and 32 bits-per-pixel icons, all other resolutions get converted to .xpm. I am planning to change it to make .png's for everything, since thumbnailing .lnk files requires .png as output, and then keep .xpm only as a fallback when libpng is not installed and we're not thumbnailing. This should help you on MacOS too.
I have no idea how the other packages built atop Wine behave on MacOS behave: - Kronenberg's WineBottler - doh's WineSkin - Macports build - CodeWeaver's CrossOver4Mac I assume they create nice icons that the user can click after an install.
Regarding the former 2 packages, I've always been wondering why there's some sort of split in the Wine+Mac user community. Obviously the stock Wine fails to meet the Mac user's expectations, such that several people start and write something better integrated with the GUI -- but not integrated into the Wine source.
From visiting the websites, I see Kronenberg's Winebottler doesn't
provide source (the source link takes you to an empty repository; interestingly the LGPL requires you to provide the changed source if you distribute the software...), Wineskin is a complete installation wrapper that I would guess does the desktop integration itself, macports.org is down but http://wine.darwinports.com/ doesn't have any relevant patches, and I don't have CrossOver4Mac or a Mac to test it and see what it does.
Maybe it's that Linux users generally expect the free software to be good, while Mac users generally expect good software to cost money, so when someone develops the extra bits for Wine on Mac, they either keep them to themselves or sell them? Also, I think more Wine developers use Linux than Mac, so there's less interest in fixing Wine on Mac.
And I didn't write trivial Mac patches either, e.g. to have wineprefixcreate symlink c:\users\xyz\ Desktop + Videos + Documents + Music to /Users/xyz/Desktop/ etc. This happens on Linux, not on MacOS. That's another (example of a) missing element. (Why didn't I write it? Because I was unsure where to put the #ifdef)
Isn't that linking done relative to $HOME, which should resolve to /Users/xyz on Mac?
Regards, Jörg Höhle
Regards Damjan Jovanovic