Release plans

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?

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.

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.

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)

Regards,
 Jörg Höhle

[Damjan Jovanovic]

On Fri, May 14, 2010 at 12:31 PM,   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

[Steven Edwards]

On Thu, May 20, 2010 at 3:08 PM, Damjan Jovanovic  wrote:
> 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.

I have a hacked version in the Bordeaux tree that uses sips to create
icns icons and working Application bundles. If they have time, Austin
or Tom can send it along for your review if your interested. The
'right' solution would be to figure out how to make them happy with
png's or write a WIC encoder/filter/whatever for icns, I just don't
have the time these days. Without getting off on to a long rant, I
'hacked' our version call sips on OS X to convert the images to icns.I
was never able to get App bundles to want to play nice with the png
images winemenubuilder spits out but it works most of the time. Since
it's derived LGPL code we are happy to share, though it really is a
hack and I am sure Alexandre would not want it in the tree, even for
the new release.

Thanks
--
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Steven Edwards]

On Thu, May 20, 2010 at 3:44 PM, Steven Edwards wrote:
> I have a hacked version in the Bordeaux tree that uses sips to create
> icns icons and working Application bundles. If they have time, Austin
> or Tom can send it along for your review if your interested. The
> 'right' solution would be to figure out how to make them happy with
> png's or write a WIC encoder/filter/whatever for icns, I just don't
> have the time these days. Without getting off on to a long rant, I
> 'hacked' our version call sips on OS X to convert the images to icns.I
> was never able to get App bundles to want to play nice with the png
> images winemenubuilder spits out but it works most of the time. Since
> it's derived LGPL code we are happy to share, though it really is a
> hack and I am sure Alexandre would not want it in the tree, even for
> the new release.

Sorry for the double spam, I thought I did not have a copy of the code
handy. Here is the hacked patch, it's quite nasty as it forks for every
image is processes so it takes a while to generate the icons. There was a
bit of a race condition so I further hacked it by sleeping but it got the
job done. As I said, figuring out why Appbundles did not want to play nice
with the png images would be great. I suspect png image AppBundle support
really only works on iDevices and not full OS X and if so, we just need a
better way to spitout/convert to icns images.

Thanks

[Damjan Jovanovic]

On Thu, May 20, 2010 at 9:51 PM, Steven Edwards  wrote:
> On Thu, May 20, 2010 at 3:44 PM, Steven Edwards 
> wrote:
> > I have a hacked version in the Bordeaux tree that uses sips to create
> > icns icons and working Application bundles. If they have time, Austin
> > or Tom can send it along for your review if your interested. The
> > 'right' solution would be to figure out how to make them happy with
> > png's or write a WIC encoder/filter/whatever for icns, I just don't
> > have the time these days. Without getting off on to a long rant, I
> > 'hacked' our version call sips on OS X to convert the images to icns.I
> > was never able to get App bundles to want to play nice with the png
> > images winemenubuilder spits out but it works most of the time. Since
> > it's derived LGPL code we are happy to share, though it really is a
> > hack and I am sure Alexandre would not want it in the tree, even for
> > the new release.
>
> Sorry for the double spam, I thought I did not have a copy of the code
> handy. Here is the hacked patch, it's quite nasty as it forks for every
> image is processes so it takes a while to generate the icons. There was a
> bit of a race condition so I further hacked it by sleeping but it got the
> job done. As I said, figuring out why Appbundles did not want to play nice
> with the png images would be great. I suspect png image AppBundle support
> really only works on iDevices and not full OS X and if so, we just need a
> better way to spitout/convert to icns images.
> Thanks

Everything in the .png generation looks bog standard, but maybe MacOS
doesn't like our PNG comment. Try remove that ppng_set_text call in
winemenubuilder's SaveIconResAsPNG and see if it helps?
> --
> Steven Edwards
>
> "There is one thing stronger than all the armies in the world, and that is
> an idea whose time has come." - Victor Hugo

Damjan

[Steven Edwards]

On Thu, May 20, 2010 at 4:13 PM, Damjan Jovanovic  wrote:
> Everything in the .png generation looks bog standard, but maybe MacOS
> doesn't like our PNG comment. Try remove that ppng_set_text call in
> winemenubuilder's SaveIconResAsPNG and see if it helps?

I've tried with other PNGs before that we've not generated. Take a
third party png, edit the Info.plist and change the icon entry to
instead of pointing at the icns file point at the new Png image. Of
course I've tried this on Leopard, perhaps the behaviour is different
on snow leopard, I don't have a copy of it here.

[Steven Edwards]

On Thu, May 20, 2010 at 4:17 PM, Steven Edwards  wrote:
> I've tried with other PNGs before that we've not generated. Take a
> third party png, edit the Info.plist and change the icon entry to
> instead of pointing at the icns file point at the new Png image. Of
> course I've tried this on Leopard, perhaps the behaviour is different
> on snow leopard, I don't have a copy of it here.

I am pretty sure the png support is iPod/Pad/Phone only. There may be
some magic flag to allow OS X to use png rather than icns but I can't
find it from google.

[Damjan Jovanovic]

On Thu, May 20, 2010 at 10:25 PM, Steven Edwards  wrote:
> On Thu, May 20, 2010 at 4:17 PM, Steven Edwards  wrote:
> > I've tried with other PNGs before that we've not generated. Take a
> > third party png, edit the Info.plist and change the icon entry to
> > instead of pointing at the icns file point at the new Png image. Of
> > course I've tried this on Leopard, perhaps the behaviour is different
> > on snow leopard, I don't have a copy of it here.
>
> I am pretty sure the png support is iPod/Pad/Phone only. There may be
> some magic flag to allow OS X to use png rather than icns but I can't
> find it from google.
>
> --
> Steven Edwards
>
> "There is one thing stronger than all the armies in the world, and
> that is an idea whose time has come." - Victor Hugo

My latest patch set (http://source.winehq.org/patches/data/61966,
http://source.winehq.org/patches/data/61967,
http://source.winehq.org/patches/data/61968,
http://source.winehq.org/patches/data/61969,
http://source.winehq.org/patches/data/61970) moves all icon generation
in winemenubuilder to use windowscodecs and only outputs PNG icons.
This should make it pretty easy to add ICNS icon support.

If you're going to test this before it gets committed, be sure to also
grab http://source.winehq.org/patches/data/61940 which fixes a nasty
bug in windowscodecs that corrupts many paletted ICO files. I think
this was the cause of the image corruption and RGB/BGR issue Steven
reported in his experiments with windowscodecs in early February.

Jörg can you test whether you still get icons with black backgrounds
with these patches?

Damjan

[Steven Edwards]

On Sat, May 22, 2010 at 12:27 PM, Damjan Jovanovic  wrote:
> My latest patch set (http://source.winehq.org/patches/data/61966,
> http://source.winehq.org/patches/data/61967,
> http://source.winehq.org/patches/data/61968,
> http://source.winehq.org/patches/data/61969,
> http://source.winehq.org/patches/data/61970) moves all icon generation
> in winemenubuilder to use windowscodecs and only outputs PNG icons.
> This should make it pretty easy to add ICNS icon support.
>
> If you're going to test this before it gets committed, be sure to also
> grab http://source.winehq.org/patches/data/61940 which fixes a nasty
> bug in windowscodecs that corrupts many paletted ICO files. I think
> this was the cause of the image corruption and RGB/BGR issue Steven
> reported in his experiments with windowscodecs in early February.
>
> Jörg can you test whether you still get icons with black backgrounds
> with these patches?

YAY! This makes me feel like I was actually close to understanding how
it all worked ;) Thanks for all of your work on this. Since I have no
clue as to how we should actually implement icns support and how well
it is documented I will try to merge in my Appbundler hack once this
is all merged in to head.

Thanks

[Damjan Jovanovic]

On Mon, May 24, 2010 at 4:26 PM, Steven Edwards  wrote:
> On Sat, May 22, 2010 at 12:27 PM, Damjan Jovanovic  wrote:
> > My latest patch set (http://source.winehq.org/patches/data/61966,
> > http://source.winehq.org/patches/data/61967,
> > http://source.winehq.org/patches/data/61968,
> > http://source.winehq.org/patches/data/61969,
> > http://source.winehq.org/patches/data/61970) moves all icon generation
> > in winemenubuilder to use windowscodecs and only outputs PNG icons.
> > This should make it pretty easy to add ICNS icon support.
> >
> > If you're going to test this before it gets committed, be sure to also
> > grab http://source.winehq.org/patches/data/61940 which fixes a nasty
> > bug in windowscodecs that corrupts many paletted ICO files. I think
> > this was the cause of the image corruption and RGB/BGR issue Steven
> > reported in his experiments with windowscodecs in early February.
> >
> > Jörg can you test whether you still get icons with black backgrounds
> > with these patches?
>
> YAY! This makes me feel like I was actually close to understanding how
> it all worked ;) Thanks for all of your work on this. Since I have no
> clue as to how we should actually implement icns support and how well
> it is documented I will try to merge in my Appbundler hack once this
> is all merged in to head.
> Thanks
>
> Steven Edwards
>
> "There is one thing stronger than all the armies in the world, and
> that is an idea whose time has come." - Victor Hugo

ICNS seems like by far the easiest image file format in existence:
http://en.wikipedia.org/wiki/Apple_Icon_Image

Damjan

[Ken Thomases]

On May 24, 2010, at 9:56 AM, Damjan Jovanovic wrote:
> ICNS seems like by far the easiest image file format in existence:
> http://en.wikipedia.org/wiki/Apple_Icon_Image

It's apparently slightly more complicated than that page suggests, given a simple run-length compression scheme for image data:
http://ezix.org/project/wiki/MacOSXIcons

-Ken

Hi,

Damjan Jovanovic wrote:
> 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

Good to know. This answers my question in bug #21644
http://bugs.winehq.org/show_bug.cgi?id=21644#c0
It would be a great patch.
> > 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?

That's not the problem. What I also don't know is whether I could hardcode
the directories ~/Documents etc. (these already exist in my /Users/xyz,
(but what about Tiger?)), or whether I ought to call some OSX API that
yields the name of the dir (and possibly creates it if it does not yet exist).
I'm not familiar at all with Mac APIs, but it sounds like an easy patch
for somebody with a little MacOS programming knowledge.
> > What can Mac users expect from this release?
>
> Hopefully, conversion to Linux :-).

Actually, one day I was fed up with the Gnome and KDE4 GUIs,
so I started looking for something else. The Mac Mini with
NVidia came out right at that time: extremely silent (except
for the CD-ROM), excellent graphics (by far better than
any onboard Intel I knew previously) and it's a UNIX.

Regards,
 Jörg Höhle

[Austin English]

On Fri, May 21, 2010 at 3:47 AM,   wrote:
> > > 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?
>
> That's not the problem. What I also don't know is whether I could hardcode
> the directories ~/Documents etc. (these already exist in my /Users/xyz,
> (but what about Tiger?)), or whether I ought to call some OSX API that
> yields the name of the dir (and possibly creates it if it does not yet exist).
> I'm not familiar at all with Mac APIs, but it sounds like an easy patch
> for somebody with a little MacOS programming knowledge.

I haven't used Tiger in ages, but at least for me on Snow Leopard, I
can't delete those directories, since OSX considers them 'essential to
OS function'. The likelihood of them missing is small, IMHO.