Slashdot Mirror
Mono's Cocoa# Underway, GTK# Takes on Windows.Forms
Gentu writes "OSNews posted some exclusive screenshots of a new project in the Mono community: Cocoa#. Apparently there are a couple of Apple engineers helping out the project that allows developers to create graphical Cocoa applications under Mac OS X using the C#, Python or Basic language. Mono seems to be doing well in the Windows land too, allowing developers to use GTK# instead of Windows.Forms to create multi-platform apps."
I wanted to mention that our path to indepedence
clearly goes through Gtk#, but we realize the
importance of giving users binary compatibility
so we are actively developing Windows.Forms and
Visual Basic.NET (gasp) for Mono.
A new from scratch implementation has started with
four of the top Mono developers that are now
locked up in Provo Utah working around the clock
to delivery the new implementation of Windows.Forms
(our previous Wine-based approach having too many
Mono/Wine problems to solve).
Miguel.
From the mono FAQ:
Question 131: Could patents be used to completely disable Mono (either submarine patents filed now, or changes made by Microsoft specifically to create patent problems)?
... The controversial elements are the ASP.NET, ADO.NET and Windows.Forms subsets. Those are convenient for people who need full compatibility with the Windows platform, but are not required for the open source Mono platform, nor integration with today's Mono's rich support of Linux.
I've been using wxWidgets for some corperate develpment and I don't think I can be more happy with it. Integrating Cocoa into Mono is nice with GTK and all (didn't read article- sorry,) but is it going to use native UI faculties that the operating system provides? wxWidgets even has .NET interpolabilito under development called wx.NET and you can use that with Mono too.
Huh? Pardon me, but how much Swing development have you done on OSX? I've done plenty as OSX was to be my primary development environment, targetting windows users. After about a month of that, I now do most of my development on an XP laptop.
There are NUMEROUS outstanding issues with Apple's JVM. First off, the perfomance is significantly slower than on Windows ( this is comparing my Dual G5 w/1GB RAM to a 2.2GHz Celeron w/512M laptop ).
Secondly, the setFont() function is completely ignored for JTextArea and defaults to monospaced serif fonts and white backgrounds.
There are too many problems to list here, but honestly, Swing/Java for OSX is nowhere near the quality of the Windows or Linux implementation ( even as much as I wish it was ).
Really. You'd think Microsoft could come up with something better than the grid-based layout they have been since forever. Once you start using a constraint based layout kit like Gtk, you never want to go back to the stone age and have to manually write window resize code and manually adjust the sizes of controls individually. I'm hoping to try out Gtk# soon for projects now that we are starting to use .Net as a development platform.
C# != .NET CLR
.NET runtime is a MS proprietary object.
The C# language may be a standard but the
If I point out that you are incorrect, making me a foe does not make you any more correct.
No, cygwin is not required to run Gtk#, only to build it from source.
Even better would be finishing up the GNUStep project.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
It would be nice to have a consistent multi-platform Objective C library period.
Forget about GUI bindings, all the different implementations don't even share the same root object.
I rarely criticize things I don't care about.
The reason behind the 1 button mouse was that it was painfully clear what the 1 button was to be used for. If you wanted "right button style functionality," hold down the option key and click.
Studies done at the time indicated that people made more mistakes with multi button mice and mice with multi button interfaces took longer for the user to accomplish what they want to do (because of the mistakes and confusion about what the other button was for).
For me, it is pretty damn obvious that the mouse button is used to provide the "primary operations" for the item clicked on. Holding down the option key when clicking to extend into "options" for the item makes perfect sense to me.
What really is the big deal with people's obsession on multi button mice? Honestly, I don't get it.
- Zav - Imagine a Beowulf cluster of insensitive clods...
That is only to build the software, you do not need to have Cygwin installed to run GTK# apps.
The number of people still using the original root class, Object, is vanishingly small. GNUStep has a perfectly good implementation of NSObject, which tracks the Apple implementation quite well.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
http://www.mono-project.com/downloads/
Mono 1.0.1 has been released and fixes a number of bugs.
You can look through the ECMA document for a Hello World example. Also check out last months Ars Technica Linux.Ars article on Mono as it provides a couple of examples too.
Quick little "Hello World" in C#:
using System;
class Hello
{
static void Main() {
Console.WriteLine("hello world");
}
}
Because .NET is the only platform that exists today that allows you to re-use code written in other languages *without* writing a single interface function. Although Mono only has a C# compiler today, I believe others will follow with compilers/interpreters for (managed)C++, Obj C, Ruby, Python, Java, etc.
So write your assembly in C# today, and re-use it tomorrow in Java, or give it to your co-working using C++.
Getting Gtk# running on Windows can be a bitch.
:)
So try this
Is this based on anything? It's slower than raw C or assembly of course, but quite fast overall.
More importantly, no language is faster than a programmer who doesn't know algorithms. Looking at the "S-L-O-W" code through the link provided, it's some of the shittiest toy benchmarking I've ever seen. It compares static strings through an inner method call and nested inside two loops! Even a freshman seeing that code would have had the sense to move the compares outside all that. So in 10 seconds, I was able to take code that was claimed 6x slower than Java and make it 2x faster than Java. Of course, it is still a toy benchmark that accomplishes nothing of value.
C# is an ISO standard too.
ISO/IEC 23270:2003
Information technology -- C# Language Specification
Basically it stacks up. But that's not the primary disadvantage of Objective-C. The primary disadvantage is that it's not kept pace with the times and nobody knows it. Why would you go for a C variant with wierd syntax that isn't fully garbage collected, when you can go for something very familiar, that is fully garbage collected?
Obj-C went nowhere for the same reason that Lisp and SmallTalk didn't : familiarity was more important to people than theoretical elegance. Next to that the badly designed ABI is peanuts.
Mono 1.0.1 has a new Windows installer that gets
you Gtk# working by default, it is no longer a
separate compilation.
Thanks to Paco and Gonzalo for making this
happen.
The studies done for the orignal macintosh that came to those conclusions was for first time computer users.
Which is quite understandable. But most people these days aren't first time computer users, hence the popularity of multi button mice
C# and Java provide "reflection" APIs for implementing things like this. It would be quite easy to create a class entirely analagous to NSUndoManager in either language
No it wouldn't. Check the documentation; NSUndoManager intercepts *any* message sent to it, and stores it for later invocation on a different target. You can't do that with reflection, which only allows you to call one of a fixed number of methods.
Another example: there are third party libraries that add higher order messaging to Cocoa collection classes. They allow you to write code like "[[array select] isFroody]", which will return all objects in array for which the method -isFroody returns true. Again, the initial "isFroody" message is intercepted, then forwarded to each object in the array.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
It sounds to me like your current approach is how it should be done. Make sure none of your other code depends on the UI and then just write several UI layers. That way it'll look native wherever you run it.
In my opinion, GTk# on Windows should just be used to run software that was never intended to run on Windows, as a compatibility layer in similar ven to Cygwin. If you are actually indending your application to be cross-platform, having several switchable GUI layers is the way to go. Later on, if it seems worthwhile, you can put a Cocoa# GUI layer on it too and you have a Mac version with no change to the guts of your application. You could even make a terminal-based user interface to parts of your core application as appropriate without changing the "interesting" parts at all. If your app is open source, other people might even contribute alternative interfaces for you!
C# is kind of like Java, but it's also kind of like VB, kind of like C++ and kind of like a dozen other languages. New languages are almost always an assembly of the most popular languages at the time of their development with a slightly different syntax. Personally, I like some of the C# advantages over Java a lot (e.g. modifiers that allow you to expose methods either by namespace/package or by assembly, delegate messaging, true properties, compiler directives and the fact that you aren't forced to declare exceptions). But I am the first to admit they're incremental.
Hey freaks: now you're ju
This is incorrect.
Perl, Python and Ruby standard implementations don't work by sluggishly interpreting each line of code everytime, like the old, putrid Basic interpreters from the 80's. They *do* compile the text source code to an internal, more convenient form: Python to bytecode and Ruby and Perl to an internal graph structure.
What do make Java and C# faster to execute is that type-checking is done at compile time, while in dynamically typed languages like those above the checking is done at runtime.
However, you get faster execution by having the developer of statically-compiled languages to explicitly declare every and all variables and parameters with the correct types, and this clearly is overkill for many application software.
Dynamically-typed languages get this burden off the developer by providing an execution environment which does exactly that at the cost of some execution overhead. The developer is then freed from the boresome and mechanical type declarations to worry about more important matters, such as actually making the code do something useful.
One would reply: "But you lost all benefits from getting correctly compiled code.", like as if the compilation stage doesn't report lots of errors in dynamically-typed languages or if the compilation itself was proof that the software is free of bugs and doesn't need to be thoroughly tested for runtime errors.
I ask, if you still need to go through the pain of testing thoroughly, what real benefits come from statically-compiled languages other than execution speed and perhaps some subtle runtime bugs difficult to discover? Is it worth to lose conciseness or development time just for it?
Here's a lovely trivial example in C#, using the standard .Net framework. This is how i declare a RadioButtonList webcontrol in ASP.NET:
Well, that wasn't so bad, and then there's semantic autocompletion of symbols (something M$ marketing dept calls "Intellisense") -- if you're using a featurefull IDE, that is -- which automatically provide you with a quick selection and online documentation of all available completions or operations for the symbol just left of the cursor. Yes, writing type declarations with such tool is trivially easy, though reading through them afterwards and mantaining the code-base is not. Don't understand yet? Here's a very nasty, and yet very common taste of stupid statically typed syntax, following the same example above:
No, i'm not kidding: this is how you preselect some item in a radiobutton list given a particular value from the same datasource. That is real production code from an app i'm working on here at work. Well, at least, in the end it could be worse: like most other people doing .Net development, i could be writing .Net code in VB! Ouch!
So, in the end, it's all a matter of what you value most: development time versus execution time; verbosity vs. conciseness. Noting that execution time should, for most purposes, be made irrelevant in about 6 months and faster and cheaper hardware.
I don't feel like it...