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
On Fri, May 14, 2010 at 12:31 PM, <Joerg-Cyril.Hoehle(a)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
On Thu, May 20, 2010 at 3:08 PM, Damjan Jovanovic <damjan.jov(a)gmail.com> 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
On Thu, May 20, 2010 at 3:44 PM, Steven Edwards <winehacker(a)gmail.com>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 -- 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
On Thu, May 20, 2010 at 9:51 PM, Steven Edwards <winehacker(a)gmail.com> wrote:
On Thu, May 20, 2010 at 3:44 PM, Steven Edwards <winehacker(a)gmail.com> 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
On Thu, May 20, 2010 at 4:13 PM, Damjan Jovanovic <damjan.jov(a)gmail.com> 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 "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On Thu, May 20, 2010 at 4:17 PM, Steven Edwards <winehacker(a)gmail.com> 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
On Thu, May 20, 2010 at 10:25 PM, Steven Edwards <winehacker(a)gmail.com> wrote:
On Thu, May 20, 2010 at 4:17 PM, Steven Edwards <winehacker(a)gmail.com> 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
On Sat, May 22, 2010 at 12:27 PM, Damjan Jovanovic <damjan.jov(a)gmail.com> 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
On Mon, May 24, 2010 at 4:26 PM, Steven Edwards <winehacker(a)gmail.com> wrote:
On Sat, May 22, 2010 at 12:27 PM, Damjan Jovanovic <damjan.jov(a)gmail.com> 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
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
On Fri, May 21, 2010 at 3:47 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> 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. -- -Austin
participants (5)
-
Austin English -
Damjan Jovanovic -
Joerg-Cyril.Hoehle＠t-systems.com -
Ken Thomases -
Steven Edwards