[Mono-osx] Menu Bar for Mac OS X?

[Elfen]

@Joanna: it sounds like you are evangelizing that Mono is bad for
cross-platform development with GUI's, because it requires a huge amount of
effort to make 3 different GUIs for Mac vs. Linux vs. Windows?  What about
Java Swing (with Eclipse IDE, or NetBeans IDE)?  What about C++ Qt?  I want
to use whatever will be best (and easiest) for cross-platform Windows,
Linux, Mac OS X.  It sounds like you are saying that Java Swing is wayyy
ahead of Mono GTK# in terms of cross-platform application development (with
a GUI) for Mac OS X?  Therefore, you think I should switch to Java Swing
(such as with Eclipse IDE)?

@Joanna: For example, you mention tabs and scrollbars as bad in Mono GTK#,
but it looks like they are good for Java Swing?  See this link (
http://developer.apple.com/mac/library/documentation/Java/Conceptual/Java14Development/04-JavaUIToolkits/JavaUIToolkits.html).
 This is just a look and feel style.  If Mono doesn't have an Aqua
look
and feel (the way that Java Swing does), then that doesn't mean it's
impossible - it just means that Mono GTK# is behind Java Swing (and also C++
Qt)?

@Joanna: I've actually used Qt with Visual Studio on Windows and gcc make
files for Linux, but...  This Stack Overflow post (
http://stackoverflow.com/questions/420065/best-crossplatform-c-qt4-development-environment)
suggests Eclipse with Qt and C++?  In any event, I bet Java Swing
(Eclipse) would be easier?

thank you for info

On Sun, Apr 4, 2010 at 6:35 PM, Joanna Carter <
cocoasharp at carterconsulting.org.uk> wrote:

> Hi Elfen
>
> > Expecting every single application developer to rewrite the entire GUI
> would be a huge waste of effort.  If we have 10,000 people write
> applications that use Mono GTK#, they should not all write two copies of
> their GUI's.  The GUI framework (such as Java Swing, or Mono GTK#, or Qt,
> etc) should do the 99% of it that is possible (such as the look and feel for
> Aqua)...  Then the application developers who use the GUI API would only
> have to do the last 1% that is application-specific (such as
>  application-specific menu bar / application bar, application-specific app
> bundle config).  Unless I am completely confused, I think Apple's "Java
> Development Guide for Mac OS X" clearly agrees?
> >
> > Java Swing does the Aqua interface look and feel for you.  This is the
> responsibility of Mono GTK#, so that every single application developer that
> wants to use Mono GTK# does not have to reinvent the wheel.  Right?
>
> The GTK# frameworks do not support the generation of either the correct
> Winforms or the correct Aqua L&F UIs. GTK# UIs look like what they are, GTK#
> UIs. There are some frameworks that allow the compilation of GTK+2 programs
> on OS X but none, that I am aware of, for Mono applications.
>
> The truth of the matter is, if you want to design a Winforms application,
> you have to either use the Winforms designer or design all your applications
> in code, using the Mono Winforms UI libraries, but the resultant UI will
> look "wrong" on Linux or OS X.
>
> If you want to design a GTK# UI for Linux, it will be based on the Carbon
> widget libraries, which is no longer considered the "norm" for OS X where
> Cocoa is the "standard"; and it will look "wrong" on both Windows and OS X.
>
> If you want to design a Cocoa UI, then it can only be deployed on OS X.
>
> Whichever way you try to design a "one size fits all" UI, you will end up
> with a UI that will not look "right" in some way on some platform. The Apple
> HIG specifies a different layout for OK/Cancel/Apply buttons than you would
> expect for Windows. There is no Windows equivalent to Cocoa's NSBrowser
> control. There is no Cocoa equivalent to Microsoft's Ribbon interface. Not
> only is the menu placement different in OS X, there are many other style
> differences that cannot be accommodated in a single design.
>
> Take a look at the screenshot in the link from Michael's post. You will see
> that the tabs and scrollbars are not true Cocoa and thus the application
> looks wrong, even though the menu is in the right place.
>
> Trying to design a single UI, in code, will result in an enormous amount of
> conditional, platform detecting, code that will, eventually become harder
> and harder to maintain and extend. Unlike traditional Winforms applications,
> where much code ends up being written in the main form class, Apple have
> opted for the clean separation of concerns by using the MVC design pattern.
> If you wrote your .NET/Mono applications using that same MVC pattern, then
> you would only need to rewrite the controller classes for each platform,
> using the relevant UI designers to make laying out the forms a lot easier
> than having to write them all in code.
>
> Certainly, there are frameworks like Qt, that can be used, but that
> requires that the application is written in C++ and that the Qt libraries
> are deployed to the target machine.
>
> The installation of Mono is also a requirement on all machines if you
> intend to write an application that uses the Mono framework.
>
> I recently ported a "native" Objective-C application to Delphi Prism, using
> the Monobjc framework to talk to a Cocoa UI, designed in Interface Builder.
> The native Mac app bundle came out at around 147KB. The Mono/Monobjc app
> bundle came out at over 2MB, and that didn't include the requirement to
> install Mono, which comes as a 58MB download.
>
> Now, Windows users may be used to having to install the .NET frameworks but
> Mac users expect a simple xcopy type of installation wher all they have to
> do is to drag the application bundle from the download .dmg image to the
> Applications folder.
>
> There are many, many differences between a Mac application and a Windows
> application, other than simply replacing the menu.
>
> Joanna
>
> --
> Joanna Carter
> Carter Consulting
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-osx/attachments/20100404/b71beb13/attachment-0001.html