To the list....
-----Forwarded Message----- >From: James Mckenzie <[email protected]> >Sent: May 20, 2010 12:49 PM >To: Damjan Jovanovic <[email protected]> >Subject: Re: Release plans > >> >>On Fri, May 14, 2010 at 12:31 PM, <[email protected]> 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 :-). >> >No. BTW, I've used: > >TRSDOS (Model III) >MS-DOS 1.0/2.0/3.0/4.0/5.0/6.0 (6.22) and updates >DR-DOS 4.0/5.0 >Windows 3.1, 3.11WFW, 95, 98, NT 3.51, NT 4.0, XP and Vista >OS/2 >Linux, Linux and more Linux (it is still user unfriendly) >Mac Classic >MacOSX 10.3/.4/.5 > >I consider MacOSX the most polished as a User Experience of all of them. > >>> 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. > >Thank you. It is not a good thing that MacOSX cannot use .xpm files "out of >the box". >> >>> 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...) > >That's because Mike no longer makes any changes directly to the Wine code. He >states that on the site (or did.) >>Wineskin is a complete installation >>wrapper that I would guess does the desktop integration itself, > >That's what doh123 states. It is a wrapper program that builds an exportable >.app product that will start Wine and then any program that you wrap with it. >He also gets the files for specific programs using winetricks. > >>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. >> >CrossOver Mac is and will remain a commercial product. They do all sorts of >magic to fix the brokenness of Apple/XQuartz(s) X11's inability to display >full screen and other enhancements specific to making Wine work better on the >MacOSX platform. > >>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. >> >No. Mac users expect Mac software to just damn work. We don't want to >'tweek' and 'twist' and apply patch after patch after patch. If it don't >work, out of the box, it goes. We don't have time to 'play'. So, many of us >use Crossover. We pay for others to fix that which is broken. That being >said, there are those of us that really like the challange of making Windows >software work on the Mac as well as making Linux software work on the Mac. >And we EXPECT to get paid for it. > >Please be aware that 'free' software NEVER IS. The phrase "You get what you >pay for" really applies here. Again, Mac users have been conditioned to 'it >works'. Wine is not, at the present time, ready for this level of acceptance >and may never be. And no, Mac users are not going to switch to Linux. Some >may run Ubuntu, but a vast majority unpack the system, plug it in and go to >work. > >>> 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? >> >Correct. When a new user is created on the Mac, the user name, less spaces >and special characters, is used for the folder name. The Desktop folder IS >the Mac Aqua desktop and I highly suggest NOT placing .desktop and .lnk files >there. Unlike Windows users, most Mac users like to keep their desktops >'clean'. Doing what you desire will take more work and a good poll of the Mac >community before implementation. This is part of the reason that Apple has >used the Dock and created Documents/Download folders on it. Maybe that would >be a good place to put Wine application icons. > >Please keep in mind that this is not to bash Linux or Windows users. Each >category of user has their own method of OS and system use. > >James McKenzie
