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 - [email protected] >> http://lists.ximian.com/mailman/listinfo/mono-winforms-list >> _______________________________________________ Mono-winforms-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-winforms-list
