[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: COMDLG32: native color picker on mac os x
From:       Ken Thomases <ken () codeweavers ! com>
Date:       2013-12-23 20:33:27
Message-ID: A5509FB3-C6EA-4F25-86C2-2AD8B5D51753 () codeweavers ! com
[Download RAW message or body]

Hi =8Eiga,

On Dec 23, 2013, at 11:00 AM, =8Eiga =8Eeljko wrote:

> I have made a patch for comdlg32 on Mac OS X that replaces Wine's own col=
or
> 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 f=
ar from any possible inclusion in Wine.

Replacement source file are not a "patch".  A patch should be in unified di=
ff format (including those generated by git) showing the differences betwee=
n the existing sources and your proposed versions.  Any proposed changes ha=
ve to maintain functionality on all platforms that Wine supports, so they c=
an'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 w=
hen 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 dri=
ver provides the entry point, it should be possible for it to decline to pr=
esent a driver-specific dialog (by returning FALSE, for example), so the co=
de 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 e=
xercise control over the behavior of the dialog.  If you don't support that=
, then the caller will get unexpected behavior.  Since it's basically impos=
sible to support such a hook procedure when using the Mac-native dialog, yo=
u 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 prepar=
ed to handle certain colors being returned.  You would have to implement th=
at 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 o=
thers would get the built-in dialog.  In fact, both might be used by the sa=
me 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 id=
ea at all.  At the very least, there should be a registry setting to turn o=
ff 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 impleme=
ntation of the Mac-native dialog would have to do the same thing in order t=
o 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.  Th=
e PickColor() function was preferred when Carbon was still in active develo=
pment.  The Cocoa equivalent (NSColorPanel) should be preferred.

Regards,
Ken



[prev in list] [next in list] [prev in thread] [next in thread]