Engineer Adhamh Findlay sent us in the first status report and screenshots of the Cocoa# toolkit community project: Cocoa bindings for the Mono runtime. Adhamh writes:“We are currently in the planning stages for 0.2 release. We don’t have a time table yet for it but current planned features are to remove a lot of the debugging code, get rid of the glue code, and to start using “gac”. Some of this has already been done in CVS.”
The first shot is a Cocoa# WebBrowser that Geoff Norton wrote in about 88 lines of C# code using the WebKit Framework. The other shot is showing MonoDoc running in Cocoa#. At the bottom of each screen shot you can see a terminal window with debugging output.
Let me see if I have this right…
There’s gtx# (or what ever)
Then there’s Cocoa#
Then there’s <insert some other os dependancy here>
So an application written utilizing <toolkit x> that depends on <os y> will only run on <os y>.
Did I get that right?
HTML characters are presented a-ok in the preview, but not in the final post. WEIRD!
gtk works on both windows and OSX, and as such so does gtk#. Cocoa# only works on OSX though.
The iFolder project has shown that proper backend/GUI interactions can make xplatform development a reality, whether you chose to use gtk# everywhere, or different toolkits for different platforms.
Peter, GTK only works via X11 on OSX, which is a route that most OSX users don’t wanna have to go through (plus, X11 doesn’t get installed by default with the OS).
GTK/GTk# on the other side, works natively on Windows. There is a big difference on this, so creating Cocoa# bindings at this time makes maybe more sense than trying to port natively the whole GTK+.
I wanted to say the same thing. It’s great for Mono that it’s being interfaced with WINE, GTK, Cococa, and Qt, but without some unified API it will be…well, subobtimal.
Sometimes I wonder if it’s really that hard to make something work on all those GUI toolkits. I mean, at the base it’s just a bunch of nested widgets with actions attached to some events, right? So with some cleverness it should be possible to put an interface description somewhere (in XML or s-expressions or whatever) that specifies the widgets and the events and actions (much like onclick and friends in HTML), and then load that interface and render it with the toolkit du jour. Many toolkits actually have such an XML language; at least wxWidgets, GTK, GNUStep and Cocoa do.
88 lines of code in c# versus 0 lines of code in objective-c (with interface builder).
I’m aware of the X11 restriction of Gtk, i was just trying to point out that although not perfect, there really are xplatform solutions using mono. I completely agree that Cocoa# is a wonderful idea. (i wasn’t trying to bash it when i said it only worked on OSX, just stating a fact)
Unfortunately I’m not as familiar with Mono and .NET as I should be so I’m not quite sure that I’m understanding what exactly Cocoa# is. Is it just a way to let C# programs access the Mac OS X Cocoa API on Mac OS X?
I think this is much better. Experiance has shown that for a serious product having one global frontend for all OS/DE/GUI’s is wrong. Look at how abiword does it.
Having a seperate gui for each OS means that the application dosn’t feel out of place and it will integrate with that platforms underlying technologies (like printing and system plugins/components) and also will be able to follow the look&feel of the underlying platform (The preferences dialog is probably the biggest example with instant apply/ok apply, dialogs/sheets, modal/non-modal, and other things like button order, menu layout, help system, and so much more)
After all, unless your program’s features are purly gui ones, then the gui should be the least problomatic, and the application logic should be the main focus.
Anyway, if you really want a more multipurpose toolkit for mono, take a look at:
http://wxnet.sourceforge.net/
Look at it in the broader sense: if you want to write a native, tightly integrated application, Mono gives you this wonderful ability. Do you want to write crossplatform code? No problem. Mono also gives you this wonderful ability.
Its like a Big Mac without the secret virus The Goverment has been injecting into the hamburger patties.
Which isn’t 0 lines of objective-c considering its frozen in the nib; this is 88 lines of everything being created programatically (NSAutoReleasePool/NSWindow/NSButton/NSTextView/WebFrame); please do reasearch before you make comments.
If we used a NIB we could do it in 0 lines too; there is nothing impressive about that; (and yes Cocoa# supports nib loading)
Sure, this sounds like a great achievement or whatever, but where’s the advantage? If you take the time to learn Objective-C, you can exploit the great features it offers you, but you certainly lose out in using C# to access Cocoa. Remember, Cocoa was designed for Objective-C, and designed to exploit its features.
What would probably make more sense to me is Objective-C bindings to Mono/.NET. That would be very useful!
What exactly do you lose out on by using Cocoa#?
Have you looked at what Cocoa# can do?
Remember, the idea here is it to provide Mono/.Net developers a way to get their applications to run on OS X with a native Cocoa interface.
The idea is not to get ObjC developers to use Cocoa#.
If you want ObjC -> Mono bindings see the Objc# project.
If you want ObjC -> Mono bindings see the Objc# project.
Great! I might do just that.
What exactly do you lose out on by using Cocoa#?
I’m saying that you’re losing out on features provided to you by using Objective-C, that aren’t provided to you in Cocoa#/using C#. Dynamic typing/binding and categories, come first to mind, though I’m sure there’s others.
Pretty simple case: ‘I want to write Mac applications, but I either know, like, or love (.NET compatiable language here), and I don’t really have the time to learn a new language, and then a new API.’
Of course it actually creates Konqueror and embeds it in a winforms window (working on how to make it MDI)
DCOP + XAPPGROUP == cool demo
Sadly it works only on dotgnu
http://dotgnu.org/screenshot12.html (XAPPGROUP) + http://demo.dotgnu.org/~t3rmin4t0r/kdcop2.png (DCOP)
Hmm.. make that 11 lines with 3 using XX statements
I think, as otheres, any serious application will probably, at one point, need native GUI support. I haven’t taken on such a project but good program design seperates logic and UI stuff. What’s nice about mono is it’s one enviorment that gives you access to it all.
WIll see how well it actually all works out…
Isn’t the Cocoa#/GTK#, etc# just the presentation layer for providing Windows.Forms?
Are the bindings hard-coded into programs, therefore making your programs non-cross-platform?
Thanks!
What are all those bindings for? When I want to program a Cocoa/MacOSX application then I’ll use ObjC + Cocoa.
As long as there isn’t a plattform independant WIndowForms implementation, C#, .Net and all this stuff is useless for desktop development.
@Jason:
GTK#, Cocoa# are C# language bindings for the respective toolkit. Basicly this means that it provides an API to use these toolkits from the C# language. It has nothing to do with Windows.Forms, which by the way is “emulated” using libwine IIRC.
Hope this clears things up for you 🙂
The most optimal thing would be to create the GUI in a language/os/enviroment neutral way. Then the toolkit could be selected by Mono depending on the enviroment the user is running, be it Windows (windows.forms,avalon), GNOME (gtk), KDE (qt), OS X (cocoa) etc.
Don’t think this is technically possible though.
Nice binding. Does anyone following the project knows how well it works with the GNUstep libraries? And if it supports the Renaissance toolkit? I love the openstep (capitalise as per taste ^^) specification, and if such a project can convince some new developers to have a look at it, that’s good news
.
Thanks.
“The only HTML/UBB tags allowed are for bold and italics.”
– below the posting box
now the only one missing is SWT#
seriously though i wish gtk on os x would not require x11
and was more integrated. qt is much better here.
i’ve been waiting for this! i like C# alot, but only ugly gtk# was available for for mac
[not ugly in “ugly” way, doesn’t just work natively how the rest of the OS X]
You have to design your application to take advantage of this.
Using patterns like Model-View-Presenter allows you to do this.
See http://martinfowler.com/eaaDev/ModelViewPresenter.html
Basically you have a core set of libraries that store, and calculates your data. This your “Model”
You have a “Presenter” that is an abstracted model of the UI that manipulates your data.
Then you have your “View” which is created with a specific graphics toolkit (Windows Forms, GTK, Cocoa, etc). The forms and objects of the View implement Interfaces exposed by the “Presenter”.
For example a File Dialog would implement IFileDialog exposed by the Presenter. IFileDialog would probably only have one method filename, location, and a show method. The actual FileDialog object created by GTK, WinForms, or Cocoa would implement this interface.
So when you are ready to ship. You create your application with the same presenter and model libraries but with different view libraries depending on the platform you are deploying.
I really don’t see any point in Cocoa#, I thought the whole idea of Mono is that it is portable, and easily runnable on other machines.
E.G. If i create an app on Mac OS X using cocoa#, it definitely isn’t going to run on Windows or Linux.
Gtk# is just as bad, it is yet more libraries and dependencies, e.g. If i create a Gtk# Application and want to run it on Windows, I need to install Gtk+ and Gtk#
I think C# is a good language, but it is simply creating more and more libraries, dependencies and more hassle for end-users.
For Mono to be of any use, they should create a fully working implementation if Windows.Forms which will use whatever GUI library the system is using, e.g. QT or Gtk on Linux.
i agree with you twob, and i think a lot of this goes back to what Joel Spolsky said back in january ( http://www.joelonsoftware.com/articles/PleaseLinker.html ).
why would i want to write .Net/Mono code if i still had to rewrite the GUI for every system i wanted it to run on? why not write common libraries in Mono/.Net and write the GUI in a native toolset?
to me, the appeal of .Net which Microsoft totally won’t take advantage of, is its cross platform capabilities (something Java got right). Write code once, compile code once, run sandboxed code anywhere.
Instead of writing a thousand different interfaces which only work on one platform, why not get a good implementation of Windows.Forms that can be designed to work on multiple platforms (like Qt), and then make libraries like Cocoa# that bind to Windows.Forms (which in turn would bind to Cocoa or GTK/Qt/Whatever in Linux or would be the last step in Windows), so when i compile my program my only external dependency is Windows.Forms which is *assumed* to be available on any system running .Net/Mono.
no one says “i don’t want to write code for X11, i’m going to create my own window server” when writing an app on Unix-like OSes, so why should a new GUI toolkit be made for every platform Mono runs on? In my opinion, this is the same problem (mistake) Microsoft left us with in the first place: cross platform ability, but locked to a single platform. sure, you still get sandboxed code, but that’s only half the benefit of Mono/.Net to me.
Why not use SWT as an example of a unified API which allows cross platform, native graphical interface applications? Basically, wrap a frigging higher level API around all of these disparate bindings.
With Java and SWT, at this very minute you can write a complex, crossplatform application with a graphical interface which uses NATIVE components on the target platform. Why not leverage this existing technology and convert SWT to C# or make something similar.
Also, with GCJ you can create native executables with SWT GUIs for multiple platforms. I don’t understand why this technology isn’t receiving more attention. Instead, all I hear about is C# this, Mono that.
I just wanted to comment on something.
A lot of people seem to think that Mono is solely a project to bring cross platform development.
I must disagree. It serves a larger purpose. A simpler one that a lot of people are ignoring. It’s a C# implementation that is cross platform.
C# is very nice, and the basic framework is solid. If people want to use GTK#, WX, etc. to develop cross platform UI, so be it.
The usefulness of Cocoa# for me is that I can develop OSX apps using C#! Kick ass.
Actually, there is a SWT port to C#. http://sharpwt.net or something. The main problem with that is it is not being maintained that much anymore and I consider it a rather limited toolkit (at least without JFace or whatever).
yes yes, what about Java? it is a great multiplatform solution for writing applications (not only web browser’s applets), and Java works very well with OS X! (it is Cocoa’s second native language)
So, if I use Cocoa#, I can write a web browser in 88 lines of code?
Funny, but it seems to me that I can do the same thing without Cocoa#, with NO lines of code.
What’s the point of this exercise, again?
Hi, just wanted to try and clear up a miscomunication.
The CocoaSharpBrowser takes 88 lines of code because it doesn’t use a nib file. It would still take some lines of code even if it used a nib though.
WebKit is probably not a good framework to use for example projects because it is very well integrated with Cocoa.
Also, how many lines of code would it take to write an application that has a native GUI on OS X, Gnome, and Windows? That’s the real point of Cocoa#.
@paul
What about Java? People don’t like writing client-side java except maybe for the miniscule world of apple.
@J.Random apple dude
Let me guess, you work in the warehouse up in Cupertino or something? Let me explain slowly. There’s no gui builder for cocoa# that’s why it’s 88 lines of code. You can now go tell jobs that nobody cares about objective-c and less people everyday care about apple computers.