[Mono-osx] General cross-platform issues and considerations
Stifu
stifu at free.fr
Thu Oct 15 08:26:06 EDT 2009
Well, I'm working on a WinForms app, and it works on Linux but not on OSX. I
don't have a Mac so it was hard to report bugs, but I still managed to
report 2 bugs (neither fixed yet). For example, I found out that on OSX,
control events are fired even if controls are disabled (which crashes my
app)...
matteot wrote:
>
> Does anybody knows of windows.forms apps running on osx at the moment
> ? In my opinion, a part from the left-to-right issue, the mono
> Windows.Form implementation is very good on Linux and it is a good
> option for porting windows apps, but to me it performs very bad on OS
> X now and make apps unusable.
>
> Given that the WF on OSX problems are mostly related to the carbon
> driver, anyone has taken in consideration the option of providing a
> X11 version of Managed Windows Form by pathching the X11 linux
> driver, given that X11 must be present in any case? at least until a
> working native driver will be written?
> May be this an option? have already be taken into consideration ?
> (sorry to repeat if this is the case)
>
> Thanks,
> Matteo
>
>
>
>
> On Thu, Oct 15, 2009 at 12:54 PM, Stifu <stifu at free.fr> wrote:
>>
>> At the risk of telling you something you already know, there is a Mono /
>> .NET
>> version of Qt called Qyoto. However, it's not very mature from what I've
>> heard (you might want to check out Synapse which uses it:
>> http://synapse.im/). But if you like Qt, you might want to try and push
>> Qyoto forward...
>>
>>
>> Andrew Brehm wrote:
>>>
>>> Yes, ideally the UI should be rewritten.
>>>
>>> I just think it's ironic that cross-platform tools like REALbasic or QT
>>> can give you (somewhat) native-looking applications based on the same
>>> code
>>> while Mono, with its ability to run even the same binary on all target
>>> platforms, cannot. There is a certain disconnect there.
>>>
>>> And when I have to rewrite the GUI for each platform I can also
>>> recompile
>>> the non-GUI code while I am at it and most of the advantage of managed
>>> code goes away.
>>>
>>> My particular problem is that Mono's Windows Forms does not support
>>> right-to-left writing on Linux and Mac OS, otherwise a Windows Forms
>>> version of my program would at least run on all three platforms. (I
>>> really
>>> have to try whether Gtk# works with right-to-left scripts! Anyone know?)
>>>
>>> Ignoring the right-to-left script issue, I think the best solution is
>>> this:
>>>
>>> I Put everything but the GUI in a DLL.
>>>
>>> II Write a GUI for each targeted platform and one GUI that runs on
>>> everything.
>>>
>>> III Offer four downloads:
>>>
>>> 1. Mac OS X (Monobjc)
>>>
>>> 2. Linux (Gtk#)
>>>
>>> 3. Windows (WPF or Windows Forms)
>>>
>>> 4. cross-platform (Windows Forms or Gtk#)
>>>
>>> Download #4 should have a functional GUI without bells or whistles.
>>>
>>> The DLL itself should be perfectly cross-platform with everything
>>> platform-specific abstracted within the DLL.
>>>
>>>
>>>
>>> duanew wrote:
>>>>
>>>> Not an easy answer. The conclusion I have come to is that the UI most
>>>> always be rewritten for each platform. One goal that I have when
>>>> writing
>>>> an
>>>> application is that it offers the best UI experience possible. At
>>>> least
>>>> so
>>>> far, any cross platform UI is going to diminish the user's experience
>>>> with
>>>> your application, which makes your application look inferior. Separate
>>>> the
>>>> logic as much as possible, but use native UI tools to develop the UI.
>>>>
>>>> Thanks to mono we have the ability to reuse large portions of the
>>>> library.
>>>> To me implementing the UI in native tools and recompiling is trivial
>>>> compared to the cost of writing in C, C++, Objective-C or using a
>>>> non-standard cross-platform GUI toolkit.
>>>>
>>>> Bset of luck.
>>>> Duane
>>>>
>>>> On Wed, Oct 14, 2009 at 6:49 AM, Andrew Brehm <ajbrehm at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> I have been working with Delphi Prism for a while now and can
>>>>> recommend
>>>>> it
>>>>> to
>>>>> anyone who wants to do Mac development in .NET. Any criticism below is
>>>>> not
>>>>> to be understood as criticism of Delphi Prism. It's just the tool I
>>>>> use
>>>>> because I think it is the best for the job.
>>>>>
>>>>> Between Windows Forms, Windows Presentation Foundation (WPF), Monobjc
>>>>> (Cocoa
>>>>> bindings), and Gtk# we have ample GUI toolkits to choose from, but
>>>>> this
>>>>> also
>>>>> means that the ability of .NET/Mono binaries to run unchanged on any
>>>>> platform is somewhat diminished, to say the least. I found that Mono's
>>>>> implementation of Windows Forms on Mac OS and Linux does not support
>>>>> right-to-left text. I haven't checked with Gtk#. (In fact I have never
>>>>> really looked at Gtk#.)
>>>>>
>>>>> So currently the best solution for cross-platform .NET development is
>>>>> to
>>>>> create separate binaries for each platform which, as I said,
>>>>> diminished
>>>>> the
>>>>> advantage of being able to run the same binary on any target platform.
>>>>>
>>>>> One year ago I managed to create a test program that would check
>>>>> whether
>>>>> it's running on Windows or Mac OS and then use a Windows Forms or a
>>>>> Cocoa#
>>>>> (back then) GUI depending on the result. A single binary worked on
>>>>> both
>>>>> systems again, with decent results on both targets too. But this
>>>>> configuration is not easily supported by IDEs or build scripts and
>>>>> doesn't
>>>>> play well with Apple's (excellent) concept of bundles.
>>>>>
>>>>> But then even checking which OS one is running on is difficult since
>>>>> Mono
>>>>> reports UNIX when running on Mac OS (at least it did the last time I
>>>>> checked).
>>>>>
>>>>> How is the Gtk# implementation on Mac OS? Is it better than Windows
>>>>> Forms?
>>>>> Would Gtk# be a good solution for a single binary for all three
>>>>> targets?
>>>>> (On
>>>>> Windows, can I just include Gtk# DLLs or does the user have to install
>>>>> Mono
>>>>> or Gtk# himself?)
>>>>>
>>>>> I like Monobjc and the Cocoa GUI it makes available to .NET programs.
>>>>> But
>>>>> porting the GUI part of an app to Monobjc is (doable but) an effort
>>>>> that
>>>>> seems ironic considering .NET/Mono is inherently a cross-platform
>>>>> development environment.
>>>>>
>>>>> So what's the best way to go for cross-platform apps? Three separate
>>>>> GUIs?
>>>>> Gtk# for all? And if the first, should it be a single binary checking
>>>>> the
>>>>> OS
>>>>> and then using the right GUI or should it be separate binaries?
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/General-cross-platform-issues-and-considerations-tp25888867p25888867.html
>>>>> Sent from the Mono - OSX mailing list archive at Nabble.com.
>>>>>
>>>>> _______________________________________________
>>>>> Mono-osx mailing list
>>>>> Mono-osx at lists.ximian.com
>>>>> http://lists.ximian.com/mailman/listinfo/mono-osx
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mono-osx mailing list
>>>> Mono-osx at lists.ximian.com
>>>> http://lists.ximian.com/mailman/listinfo/mono-osx
>>>>
>>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/General-cross-platform-issues-and-considerations-tp25888867p25906478.html
>> Sent from the Mono - OSX mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Mono-osx mailing list
>> Mono-osx at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-osx
>>
> _______________________________________________
> Mono-osx mailing list
> Mono-osx at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-osx
>
>
--
View this message in context: http://www.nabble.com/General-cross-platform-issues-and-considerations-tp25888867p25907611.html
Sent from the Mono - OSX mailing list archive at Nabble.com.
More information about the Mono-osx
mailing list