Hi Žiga,
On Dec 23, 2013, at 11:00 AM, Žiga Željko wrote:
I have made a patch for comdlg32 on Mac OS X that replaces Wine's own color picker dialog with the native one. Bellow are the sources for colordlg.c, cocoa_colordlg.m and Makefile.in (without comments).
Thanks for your interest in improving Wine, but I'm afraid this is pretty far from any possible inclusion in Wine.
Replacement source file are not a "patch". A patch should be in unified diff format (including those generated by git) showing the differences between the existing sources and your proposed versions. Any proposed changes have to maintain functionality on all platforms that Wine supports, so they can't remove the existing implementation. Any Mac-specific code would have to be conditionally compiled.
If Wine is going to use the Mac-native color picker, it should only do so when the Mac driver is being used. If the X11 driver is used, then the Mac-native dialog would belong to the wrong process and may even show up on the wrong display (if X11 is displaying remotely). So, really, this should be in the user driver as an optional entry point. Also, even if the user driver provides the entry point, it should be possible for it to decline to present a driver-specific dialog (by returning FALSE, for example), so the code should fall back to the normal built-in dialog.
The code would have to consider _all_ of the options that the calling code can specify via the ChooseColor() function and the CHOOSECOLOR structure. For example, if the caller specified a hook procedure, then it expects to exercise control over the behavior of the dialog. If you don't support that, then the caller will get unexpected behavior. Since it's basically impossible to support such a hook procedure when using the Mac-native dialog, you would have to decline to use the Mac-native dialog when a hook procedure is specified. Same with a dialog template.
Similarly, if the caller specifies CC_PREVENTFULLOPEN then it's only prepared to handle certain colors being returned. You would have to implement that or, if you can't, fall back to the built-in dialog. Etc.
This means that some Windows programs would get the Mac-native dialog and others would get the built-in dialog. In fact, both might be used by the same Windows program at different times, depending on context. Since this is undesirable, it's an open question as to whether this feature is a good idea at all. At the very least, there should be a registry setting to turn off the Mac-native dialog in case the user doesn't want it or it interferes with compatibility of some Windows program.
Built-in dialogs disable the owning window if one is specified. An implementation of the Mac-native dialog would have to do the same thing in order to prevent weird interaction bugs. Obviously, it would have to reenable the owner after it completes.
The GetColor() function is Carbon, which should be avoided if possible. In fact, even for Carbon, the GetColor() function was marked as obsolete. The PickColor() function was preferred when Carbon was still in active development. The Cocoa equivalent (NSColorPanel) should be preferred.
Regards, Ken