The Mono team just released Beta 3, the final beta before we see the 1.0 release candidate and final. Elsewhere, the Cocoa# developers got their first window showing on the MacOS X, and they also got inheritance working. This is a young binding, but here is a screenshot of what it looks like.
Mono 1.0-beta3 Released; Cocoa# with Mono Moves Along
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
API bindings for C# are always cool, but the problem ist that now we have GTK# for Unix/X11, WinForms for Windows and Cocoa# for Mac OS.
Hmmmm, so I won’t have any reason to actually use C#, since the only reason would be cross-platform (and a nicer API than Swing, maybe).
I have to agree on this.
I would prefer if Novell was taking the time to *properly* port GTK+/GTK# to Windows (the current port is dreadful) and also port it to OSX too.
I don’t see it in a bad way, if it compiles with the minimun changes to the code in Linux, OSX and Windows and use the native widgets that would be nice, if that the case Congrats. to the mono team.
Then port it as GNUstep# and it will be quite OSX/Windows/GNU/Linux cross platform.
The problem with writing cross platform code is that you have to code for the lowest common denominator. You lose the advantages that each platform could give.
Surely it is good design to ensure the code for the look and feel is as loosely coupled as possible from the rest of the application being developed?
If that is the case, it shouldn’t be too difficult to port an application originally written for say Windows and Windows Forms to Linux and GTK# or OSX and Cocoa#. At the expense of rewriting the user interface layer for each platform the app looks a little more professional and the developer avoids duplicating what the underlying platform already provides.
I agree that cross-platform Gtk# would be extremely nice, but as a previous poster pointed out, you don’t reap the benefits of an application integrated with your desktop. Gtk# is really nice for designing applications that integrate with and take advantage of a GNOME desktop, but it doesn’t work so well when you move to another platform like Windows or OS X. Likewise, Even if Winforms were complete for Mono, it would remain a pretty crappy way write an application for Linux.
I just wish that the Mono folks would’ve ported SWF on top of gtk+, not gtk# and not using Wine as its backend. I know the reasoning for using Wine, but all the current solutions aren’t exactly great.
It looks like F-spot decided to write different front-ends for windows and unix.
I would prefer if Novell was taking the time to *properly* port GTK+/GTK# to Windows (the current port is dreadful) and also port it to OSX too.
You’re right. GTK on Linux is bad enough, but on Windows it is a no go. Given that the Novell/Ximian people have talked about porting Evolution to Windows how can they feasibly do this with GTK as it is on Windows?
Unfortunately, doing that costs time, resources and money and Novell just does not have those to waste on numerous free software projects, especially in view of the fact that there are other cross-platform toolkits that work very well.
If it isn’t one thing that needs improving it’s another, and as Novell look at migrating their desktops they’ll find that out. Before you know where you are you’ve brought the major development of an entire development toolkit across many platforms, a desktop environment and all of the applications in-house and you’re giving it away. That’s not the way open source development works as it is based on companies and individuals coming together and sharing the workload. Novell just going out and *properly* porting GTK+/GTK# to Windows and OS X is just not feasible.
The problem with writing cross platform code is that you have to code for the lowest common denominator. You lose the advantages that each platform could give.
If done right, not necessarily no. You’re never going to be able to take advantage of specific APIs in each OS, but adaptable look-and-feel should be possible. Sun have never seen the wisdom of working hard on this for Java, and it seems to have passed straight over their heads. Mind you, when it comes to the desktop most things pass straight over Sun’s head, as we’ve seen from the much vaunted Network Computer, Java Station and the Java Desktop.
Is there a convenient site for what this is actually doing? Is this a wrapper on the Cocoa functions so that they can be accessed in C# through Mono or is this a port of Objective-C to the CLR so that generic ObjC code can be used to call any of the API’s in a running CLR? If it’s the latter than yippeee…GNUstep.NET could be a reality!
Likewise, Even if Winforms were complete for Mono, it would remain a pretty crappy way write an application for Linux.
If code can be re-compiled cleanly, without any changes, then no it wouldn’t.
I just wish that the Mono folks would’ve ported SWF on top of gtk+…
I sincerely hope you’re joking…
…not using Wine as its backend.
Well, Wine is one of the options that you can use, but it isn’t the only one.
Cross platform guis are a terrible thing usability wise. The best way to do things is to keep the gui code seperate and implemnet different guis on different platforms. Novel’s example with iFolder is the right way to do things. The have a common core that can be used with gtk#, cocoa#, or swf fron ends.
Even if you have a cross platform toolkit, just using the same gui on all platforms does not work. The look and feel can for anything more than the simplest guis will never be right on on all of the platforms.
Cocoa# is my dream come true… god I hope this pans out well…
all we need now is a nice Interface designer Ah-Lah C#.net that is part of monodevelop (and make it cross platform, which if it is written in C# should not be hard to do) and we have a great development platform!!
it would be nice if tehy included a wxWindows# and a QT# in the bindings in Mono so that people can use some more universal tool kits. then I can write assignments in C# on my mac that use a GUI and run it with out a problem on a windows or Linux machine.
i don’t know about any wxWindows# project, but there is a wx.NET project, and they just released version 0.5 beta a few days ago:
http://wxnet.sourceforge.net/
Question: Is there project page for Cocoa# ?
that will become the cross platform widget set of C# for sure.
Hmm… I thought DotGNU did an Aqua GUI first ?.
http://dotgnu.org/screenshots/14.png ?.
This looks to be very old (and a better wrapper ?)
“all we need now is a nice Interface designer Ah-Lah C#.net that is part of monodevelop (and make it cross platform, which if it is written in C# should not be hard to do)”
I don’t think monodevelop will be crossplatform without gtk#.
“I just wish that the Mono folks would’ve ported SWF”
There was a port happening (not by mono) but the wiki says it’s dead – http://wiki.sharpdevelop.net/default.aspx/SharpDevelop.SharpWT
There was an interesting post on the mono-list last night from someone from improve-technologies.com – here is some of the post:
[snip]
I’m working on the Improve C# Plugin for Eclipse
(http://www.improve-technologies.com/alpha/esharp/) to make it work with eclipse 3 and mono 1.0.
The final version of the plugin will be ready after the release of eclipse 3 and mono 1.0
The plugin will be under the CPL license http://www.eclipse.org/legal/cpl-v10.html
[/snip]
I don’t know what features will be added (the post was asking for developer ideas) but I don’t love the current version at all. I’m not shooting down VIM by saying it is a much better than that plugin in eclipse. VS .net, c# Builder (Borland) or sharpdevelop are the best options that I can see for now but it’s unclear to me how a cross platform gui toolkit could be integrated into those platforms without actually being on that platform or an emulator.
you could go the “common ground” route but I think that is kinda boring and looks harder than it’s worth. Why not take advantage using platform specific stuff?? Beyond that I also think it’s interesting to see how other toolkits/bindings work – food for thought. You can still make everything but the presentation layer available to all your ports as is.
PS. can’t wait for the Cocoa# stuff to get usable!!
Hmm… I thought DotGNU did an Aqua GUI first ?.
infact this is wx.net wrapperscreen shot.
Is Java not going more and more in this direction anyway?
While duplicating code (different UI’s) is never perfect the end result will almost certainly be better. If the code was organized such that the logic and interface are well divided this doesn’t seem to be a bad path to me.
I like to get dreamy sometimes and the thought of having monodevelop one day being capable of doing SWF, GTK, and Cocoa is as dreamy as it gets. I think I’ll just be excited about GTK# for now.
On another note GTK window bindings would be nice. I have often thought that getting Evolution on the windows platform would be one of the most beneficial things that could take place for open source software. There would certainly be advantages for Novell since Evolution, IMO, is better than their much-improved Groupwise 6.5 client.
I love C# and I love Cocoa, but I will never use Cocoa#, because when the day is done, Objective C is a better language than C#, because of its dynamic nature.
As to the UI question, I would rather write the back-end code in a cross-platform solution and then bolt on an OS-specific UI. And in fact this is what anyone writing commercial cross-platform software does anyway, especially for the consumer market, because most users will reject software whose interface sucks.
As I’ve said a million times: Cross-platform is great when you need it, but I think it’s needed a lot less often than people think.
anyone know of any for those of us with minimal programming experience?
GDK is a thin wrapper around X11, intimately tied into X11’s event model and tied into GTK’s ugly over the top signal code. Look at the Windows port, most of the new code is geared towards faking X11 behaviour.
For a port to be successful it requires developers with a deep understanding of the native API, X11, GDK and GTK and their event/signalling models. The level you need is closer to those who developed the API’as rather than just use them, you need to know what fires events and how they propagate rather than just how to respond to them. Chances are your typical porter might know the native API fairly well, not the others.
Then you have to put up with GTK being nearly possible to debug. Anyone designing a GUI toolkit should be made to step through the updating of a gtk_status_bar, just remove any sharp implements from the room first. Also stock up on food and drink, and remember to look away from the screen every now and again, you’re going to there for some time.
As previous posters already pointed out, I also think a C# binding for wxWindows is a good way to go. wxWindows is our solution for cross-platform GUI development at the moment, but at the price of using unmanaged C++ – which isn’t too terrible for an experienced programmer, regardless what the C# marketing is trying to tell us. However, one probably cannot stay with C++ forever and I do enjoy the benefits of managed Java.
The advantage of wxWindows is, you get native controls from the same source code, so you do not need to implement your GUI three times using GTK#, WinForms and Cocoa#. Although it is very true that good software design separates the GUI code, implementing the GUI three times means more work and more development costs. As in most cases the income for a product is mostly coming from Windows and not from Linux and OS X, I fear that this is counterproductive to encourage developers to port their applications to Linux and OS X. You can only get people to consider a Linux port when there are _minimum_ efforts and costs, not the requirement of a complete GUI rewrite. I currently do not see Mono as a solution to this, but I am well aware Mono is improving quickly, I don’t mean this as “It sucks!” statement. And I’m only talking about GUI stuff, I know Mono offers more.
As a sidenote, wxPython is great stuff for cross-platform GUI programming, too.
Actually I’d argue Objective-C is of a LESS dynamic nature than C#. Objective-C doesn’t use a VM. The runtime environment is not as rich in introspection as C#’s. It’s impossible to generate new classes in runtime. The Objective-C runtime might look nice at a cursory glance but if you look closer it has small issues that makes it unsuitable beyond the scope of the Objective-C way of sending messages to objects. It’s unfortunate because if Objective-C had a complete set of runtime supports it could provide so much more but currently it’s crippled.
Sometimes I feel a bit down, as much of the development nowadays is based on html stuff. And when we talk about GUI toolkits, we never have the best solution, which I suppose would be QT.
The needs vary greatly, though. Some people need GUI toolkits just to bad mouth them. Others will use anything to get the job done, even if it sucks compared to other toolkits.
I will tell you what. Build me a VCL-like library in any GUI toolkit, and I will use it! 🙂
The first VisualBasic used about 25k lines of code. Don’t you think you can build something similar in your preferred language+GUI toolkit? Build your VB, your VCL, your Access, and be happy!
I am a novice C# devloper. I am teaching myself and do it because I find it interesting. I have done some VB but have moved to C# and like it a lot more. I have so far only used VS.net. I dont’ quite understand the GTK#, windows.forms cross platform thing. Well not completely. If Windows.Forms was complete an ported does that mean that software written in VS.net, running on windows would be able to run anywhere without changes? Would the GUI have a native “look and Feel” If I used Wx.net would that do the same thing, native “look and feel” across the board? Is the actual gui code between GTK# and the equivlient for Windows.form the same or is the code you write actuall different between the two? I realize that this might not be the best place to ask this but the people on this board are the best people I know to ask. Or if there is anyone that knows of a webpage that can explain it that would be great.
Thanks all
Dave
So, I’m one of the people working on Cocoa#. We are much too early in the process to provide anything offical. We were surprise when Miguel posted the screen shot.
The idea with the Cocoa# is to call Cocoa code from Mono. The project is actually to provide a fully functional bridge like the PyObjC bridge.
We will have more publically info available as we progress.
If Windows.Forms was complete an ported does that mean that software written in VS.net, running on windows would be able to run anywhere without changes? Would the GUI have a native “look and Feel”
It should run anywhere where SWF is implemented. But a 100% complete port is almost impossible. It will not happen. And even if it did happen, it would always look like a Windows 2000 application. Nothing native. In fact, does Windows.Forms look native on Windows XP yet? (XP scrollbars, XP buttons, XP tabs, etc.)
If I used Wx.net would that do the same thing, native “look and feel” across the board?
Wx.NET should indeed give you the native look and feel, for as much as that is possible. If you use features that aren’t natively available, they will be ’emulated’. That is, the look of that specific feature will not be completely native, but it will try to make it as close as possible.
Is the actual gui code between GTK# and the equivlient for Windows.form the same or is the code you write actuall different between the two?
The APIs are different. You cannot simply apply SWF code to GTK#. If that was the case, then we wouldn’t need SWF at all.
wx.net 0.5, the beta, is on its way here – and it seems the developers have finally taken the .NETisms to heart. There’s an actual event system now, as opposed to creepy C/++ macros. They even use Point structures in some places!
The next release will be good, I think.
Thanks that helps. I think I will start keeping an eye on wx.net as it seems to offer, or will, what I am looking for.