General cross-platform issues and considerations

[Andrew Brehm]

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?

[duanew]

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@...> 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@...
http://lists.ximian.com/mailman/listinfo/mono-osx

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

[Andrew Brehm]

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 <[e-mail]> 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
> [e-mail]
> http://lists.ximian.com/mailman/listinfo/mono-osx
>

_______________________________________________
Mono-osx mailing list
[e-mail]
http://lists.ximian.com/mailman/listinfo/mono-osx

[Stifu]

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...


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 <[e-mail]> 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
> [e-mail]
> http://lists.ximian.com/mailman/listinfo/mono-osx
>

_______________________________________________
Mono-osx mailing list
[e-mail]
http://lists.ximian.com/mailman/listinfo/mono-osx

[matteot]

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@...> 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@...> 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@...
>>>> http://lists.ximian.com/mailman/listinfo/mono-osx
>>>>
>>>
>>> _______________________________________________
>>> Mono-osx mailing list
>>> Mono-osx@...
>>> 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@...
> http://lists.ximian.com/mailman/listinfo/mono-osx
>

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

[Andrew Brehm]

I have heard of Qt for .NET.

But I don't really "like" Qt since I don't really know it at all. I don't know C++, for one thing. :-) I always avoided it.

Also, I think adding another GUI toolkit to the mix will only complicate matters.

(I wonder if this .NET bridge to Qt even works well on Mac OS X...)

Stifu 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]

The original implementation of Windows Forms for Mac OS X was based on X11. They moved it to Carbon. I don't think it's very usable although it is technically working.

The X11 version can still be used, I think, with some kind of parameter for Mono.

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)

[Stifu]

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 <[e-mail]> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> http://lists.ximian.com/mailman/listinfo/mono-osx
>>>>
>>>
>>> _______________________________________________
>>> Mono-osx mailing list
>>> [e-mail]
>>> 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
> [e-mail]
> http://lists.ximian.com/mailman/listinfo/mono-osx
>
_______________________________________________
Mono-osx mailing list
[e-mail]
http://lists.ximian.com/mailman/listinfo/mono-osx

[Alexander Shulgin]

Andrew Brehm wrote:
> The original implementation of Windows Forms for Mac OS X was based on X11.
> They moved it to Carbon. I don't think it's very usable although it is
> technically working.
>
> The X11 version can still be used, I think, with some kind of parameter for
> Mono.

Yes, just set the MONO_MWF_MAC_FORCE_X11 environment var when running
mono MyApp.exe.

--
Alex

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

[Stifu]

So, like, doing:

mono MyApp.exe MONO_MWF_MAC_FORCE_X11

?

Or I also read about doing MONO_MWF_MAC_FORCE_X11=1.

Thanks for confirming.

Alexander Shulgin wrote:

Andrew Brehm wrote:
> The original implementation of Windows Forms for Mac OS X was based on X11.
> They moved it to Carbon. I don't think it's very usable although it is
> technically working.
>
> The X11 version can still be used, I think, with some kind of parameter for
> Mono.

Yes, just set the MONO_MWF_MAC_FORCE_X11 environment var when running
mono MyApp.exe.

--
Alex

_______________________________________________
Mono-osx mailing list
[e-mail]
http://lists.ximian.com/mailman/listinfo/mono-osx

[Alexander Shulgin]

Stifu wrote:
> So, like, doing:
>
> mono MyApp.exe MONO_MWF_MAC_FORCE_X11

Like this:

MONO_MWF_MAC_FORCE_X11=whatever mono MyApp.exe

Or

#!/bin/sh
export MONO_MWF_MAC_FORCE_X11=whatever

mono MyApp.exe

--
Alex
_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

[matteot]

I tried
export MONO_MWF_MAC_FORCE_X11=1.

and it works.
My application seems to work a lot better,
the ony thing I noticed is that main menus items, after being used,
they did not work again,

Thanks
Matteo

On Thu, Oct 15, 2009 at 3:54 PM, Stifu <stifu@...> wrote:

>
> So, like, doing:
>
> mono MyApp.exe MONO_MWF_MAC_FORCE_X11
>
> ?
>
> Or I also read about doing MONO_MWF_MAC_FORCE_X11=1.
>
> Thanks for confirming.
>
>
> Alexander Shulgin wrote:
>>
>> Andrew Brehm wrote:
>>> The original implementation of Windows Forms for Mac OS X was based on
>>> X11.
>>> They moved it to Carbon. I don't think it's very usable although it is
>>> technically working.
>>>
>>> The X11 version can still be used, I think, with some kind of parameter
>>> for
>>> Mono.
>>
>> Yes, just set the MONO_MWF_MAC_FORCE_X11 environment var when running
>> mono MyApp.exe.
>>
>> --
>> Alex
>>
>> _______________________________________________
>> Mono-osx mailing list
>> Mono-osx@...
>> http://lists.ximian.com/mailman/listinfo/mono-osx
>>
>>
>
> --
> View this message in context: http://www.nabble.com/General-cross-platform-issues-and-considerations-tp25888867p25909081.html
> Sent from the Mono - OSX mailing list archive at Nabble.com.
>
> _______________________________________________
> Mono-osx mailing list
> Mono-osx@...
> http://lists.ximian.com/mailman/listinfo/mono-osx
>

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx