[Mono-osx] Why not implement WPF using OpenGL on Mac OS X?

[Mac Programmer]

 >>Creating XplatUICocoa & CocoaInternal, and converting 2,500 lines  
of Carbon code to Cocoa
 >>would seem to be less work than competing suggestions found in  
this mailing list.

That's probably a good place to start, but I'm not sure that would  
solve all of WinForms' problems on Mac.

Let's take a seemingly simple example. Assume we have a hypothetical  
cross-platform widgetset that has a class named "Form" (as does  
WinForms) and the Form class coincidentally has a property named  
Position (as does WinForms and Delphi VCL), of an enumerated type  
that includes Manual (as does WinForms; Delphi VCL calls it poDesigned).

Here's WinForms definition of Manual: "The position of the form is  
determined by Location" or, as we used to call it, Left and Top.

So what does Top mean? WinForms again: "distance, in pixels, between  
the top edge of the control and the top edge of its container client  
area."

So what is the "container client area" of a form? One might think  
that this would be Screen.WorkingArea, which excludes taskbar, etc.  
But it's not. It's the entire screen.

So in its literal-minded way, this is what Mono's Mac WinForms  
implementation does too. Setting a System.Windows.Forms.Form object's  
Top to 0 positions the form at the very top of the screen, its title  
bar underneath the menu bar, making its "window menu" inaccessible.  
If this is the app's main form, Force Quit is about your only option  
at this point.

You can see the same problem if you put the Dock on the left side of  
the screen and set a Form's Left to 0.

On Mac, it would appear that NSWindow.Screen.VisibleFrame is  
analogous to WorkingArea. Apple: "The rectangle defining the portion  
of the screen in which it is currently safe to draw your application  
content." VisibleFrame starts just below the menu bar and ends just  
above the Dock (if the Dock is at the bottom). So you could just  
compute Top so it doesn't do that, right, the way you would on  
Windows by looking at WorkingArea?

I have my Mac set to 1056 x 792 screen resolution.  
NSWindow.Screen.VisibleFrame tells me that with the Dock along the  
bottom, the usable vertical area starts at 37 and is 733 pixels high.  
(Never mind that 37 is relative to the lower-left corner with Cocoa  
and Carbon, not the upper-left corner, of the screen.)

But what does WorkingArea tell me? That the working area is 1056 x  
792, or the entire screen, meaning the menu bar and Dock areas are  
all fair game. And that working area's Left is 0 and Top is 0. That  
doesn't seem correct. So how do you calculate the topmost Top and the  
leftmost Left for a form with WinForms on Mac? I don't know.


These are the kinds of things that would need to be solved if  
WinForms is to be "fixed". But would "fixing" it break existing code.  
Well, yeah.


It would seem that _every_ aspect of Mono's WinForms on Mac would  
need to be carefully and tediously re-examined with the Mac in mind.  
For example, you could move on to  
FormStartPosition.WindowsDefaultLocation. WinForms again: "The form  
is positioned at the Windows default location."

Well, what if the form's app is not running on Windows?

I like Delphi's definition of its equivalent poDefaultPosOnly better:  
"the operating system chooses its position on the screen." Now we're  
getting somewhere.

And what is that default position on Mac? Well, you could argue that  
it's the way most apps come up initially, positioned in the upper- 
left corner of the  VisibleFrame area. In any case, it shouldn't be  
some weird cascading position that changes each time you display the  
window, as it does on Windows. To its credit, Mono's WinForms does  
position the form up against the menu bar, but horizontally it's  
moved in a bit from the left. Also note that you can't move the  
window's title bar under the menu bar or under the Dock, so it's  
aware of the usable area. So why allow Top and Left to be set to  
invalid values?

Thanks.

-Phil