Fw: Re: Release plans

[James Mckenzie]

To the list....


-----Forwarded Message-----
>From: James Mckenzie <jjmckenzie51 at earthlink.net>
>Sent: May 20, 2010 12:49 PM
>To: Damjan Jovanovic <damjan.jov at gmail.com>
>Subject: Re: Release plans
>
>>
>>On Fri, May 14, 2010 at 12:31 PM,  <Joerg-Cyril.Hoehle at 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 :-).
>>
>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