[Mono-winforms-list] MWF Mac.

[Geoff Norton]

Miguel,

  I think that Keyboard is a realistic goals for 1.2.6.  I'm still 
completing some research on Async but I should have an update on the 
feasability of that for 1.2.6 tomorrow (it currently looks good).  
Clipping unfortunately will be one of our biggest outstanding things 
going forward (I'll explain below) but it will be improved in that time 
frame as well.

  In terms of community contributions if anyone. is interested please 
let me know.  I can help walk through some of the simpler lower priority 
tasks (audio/dnd/clipboard/cursors come to mind as simpler in terms of 
complexity).

  The clipping issue is one I've explained before, but its probably 
important to reiterate for the sake of the community.  We're currently 
implementing HWNDs as HIViews on the mac.  However the HIToolkit has no 
support to do "Hey, HIView give me the clipping path to paint on you."  
Apple expects you to only draw when they tell you too, and they give you 
a CGContext (think XDrawable) with the clipping already applied.  
Unfortunately in the Win32 model people can do Graphics.FromHwnd 
(handle) at any time out of the apple provided drawing event.  We've 
worked around this but it makes us responsible to clip things 
ourselves.  There is a few cases where this becomes important.  The 
simple case (and most common) is HWNDs that have chilren mapped into 
them.  We now track the existence of these in the HWND object and 
reflect that information across to System.Drawing and build our own 
clipping path to the CGContext before we blit to it.  That case is 
handled.  The intermediary case is sibling HWNDs that cover a portion of 
each other.  We currently dont handle this gracefully.  The most complex 
case (also uncovered right now) is siblings up the parent tree that clip 
a child (this can happen in MDI for example).

  On the topic of an OSX theme.  I'm fairly certain that OSX doesn't 
provide a way to draw a control without instantiating it; meaning that 
an OSX them (while entirely possible) would probably require people to 
actually do all the drawing themselves (like we do for Win32).  The plus 
side to this is we could provide a OSX and a OSX_BRUSHED_METAL theme or 
something if some graphic designer was so inclined.

-geoff

Miguel de Icaza wrote:
> Hello Geoff,
>
>     I like the prioritization;   Do you think that the stuff in "HIGH"
> can be achieved by the 1.2.6 release?
>
>     Hopefully if we get that out of the way, we can get some folks from
> the OSX community to help out with the MEDIUM/LOW tasks.
>
>     Another thing that might be a useful contribution is to have someone
> develop an OSX "theme", something that tries to mimic some of the OSX
> UI.   Am not sure how far this can go though.
>
>   
>> Talking with Miguel on IRC today we decided it would be a good idea to update everyone on the state of the MWF Mac driver in hopes to 
>> prioritize a set of realistic goals for 1.2.6.  As of yesterday I have committed the bulk of my work to get the driver working again.  The list included in this email does not include bugs or performance issues but is a rough map of the features that are currently 
>> missing / not fully implemented in the driver.
>>
>> My first pass at the priority list is this:
>>
>> HIGH
>>     1. Keyboard Driver
>>     2. Clipping (I have about 80% coverage of the clipping cases; but there are a lot of edge cases that cause controls to disappear)
>>     3. Async methods
>>
>> MEDIUM
>>     1. Clipboard
>>     2. DND
>>     3. ReversibleDrawing
>>
>> LOW
>>     1. Audio
>>     2. Systray
>>     3. Cursors
>>
>> I plan on focusing on the keyboard driver in the immediate future.  If anyone is curious as to what is involved you can look at the X11Keyboard.cs for a sample implementation for X11.
>>
>> -geoff
>>
>> _______________________________________________
>> Mono-winforms-list maillist  -  Mono-winforms-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-winforms-list
>>