[Mono-osx] Why not implement WPF using OpenGL on Mac OS X?
MacPgmr at fastermac.net
Thu May 21 20:19:15 EDT 2009
>>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
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.
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
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
More information about the Mono-osx