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

Sun Apr 4 23:49:16 EDT 2010

Overall, I'm looking at what's the best set of languages / tools / API's /
IDE's for cross-platform development that includes some GUI.  However, keep
in mind that my version of "best" leans towards "easier" (and towards - the
API does more of the work for you).  By this I mean that I was hoping to
find the best cross-platform GUI toolkit, rather than implement a completely
separate application GUI for Mac OS X.

When I first tried out (C#, Visual Studio for Windows, then Mac OS X via
Mono / MonoDevelop), I thought it would be comparable to Java, and I had
just assumed that MonoDevelop would make it easy to port (my small app that
I wrote on Windows in Visual Studio) to (Mac OS X platform).  Overall,
MonoDevelop succeeded in this...  Except for the part about the GUI style.
The GUI worked (without any effort), but it's clearly not using an Aqua LAF
(look and feel) or the application Menu Bar etc.

So now I'm starting to feel like (Java Swing Eclipse) is ahead of Mono, in
terms of Mac OS X support - especially in terms of the GUI support?
Especially based on that Apple doc (
http://developer.apple.com/mac/library/documentation/Java/Conceptual/Java14Development/00-Intro/JavaDevelopment.html#//apple_ref/doc/uid/TP40001911).
 Then again, it sounds like Swing might be old...

It sounds like Qt (with C++?  or Java?) might be an even better choice than
Java Swing?  (Possibly with C++, Visual Studio for Windows, Eclipse for
Linux / Mac)?  I'm starting to think that Qt looks more promising.  Here is
Qt's doc ( http://qt.nokia.com/doc/4.6/qtmac-as-native.html ).

I also heard about REAL Studio (
http://www.realsoftware.com/movies/intro_video_full.php ) (
http://www.realsoftware.com/support/choosingadev.php ).  It seems to focus
on cross-platform IDE and GUI...  Of course I'm skeptical about it competing
with Qt (and it's kind of expensive), but it still might be a good possible
choice.  They seem to at least be trying to claim that they do a better job
than Qt on the Mac OS X support for cross-platform GUI stuff.

On Sun, Apr 4, 2010 at 7:41 PM, Elfen <pem.accounts.spam at gmail.com> wrote:

> @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/93690e63/attachment.html 