Ximian released today GTK# 0.17 while MonoDevelop is also under way (new screenshot).
GTK# 0.17 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Just wondering which one of these two projects where the furthest along.
Damn that screenshot does look awesome.
can someone tell me the difference between mono and GTK# and dotGNU. are they are trying for .NET compatablity??
thanks,
Jon
GTK# is just a toolkit based on GTk+ that should, in theory, work on dotGNU, .NET, and Mono. Mono and dotGNU are basically both striving for the same thing. dotGNU people will go on about the GNU and all that business. Basically its a wasted duplication of effort. dotGNU is also doing an implementation of Windows Forms that rides on top of X on unixes and gdi on top of windows. Also, dotGNU’s C# compiler is written in c so its fast and doesn’t have the bootstrapping problem that mono does. dotGNU does not have a JIT at the moment, even though I hear they use some JIT techniques in the VM. Mono is more mature, more feature complete than dotGNU. dotGNU runs on more platforms than Mono because the JIT on mono is much harder to get running on different platforms.
Assemblies(shared libraries) should(once again, in theory) be interchangeable between the different implementations. I hear GTK# does not work on dotGNU right now.
<p>gtk# is a binding of gtk to .net land – and doesn’t try to be compatible with any ms libraries (eg. win forms). dotGNU and mono do have similar goals but diverge in some pretty key areas and politics as well I believe. There is probably some level of sharing between the two but are definitely separate projects. I think that mono is more complete and more accepted but I’m kinda pulling that out of the air. They are all trying to be .net compatible as you put it but mono has added/supported tons more that falls outside the marketing of all things microsoft .net.
<p>MonoDevelop is going to be awesome when it is released! I think that there will be an official website up soon too.
looks good but what is it?
As much as I love wx.NET, GTK# is a fair ways ahead.
wx.NET still has some of the uglies from wxWidgets… in particular, the nasty, ugly macro-style way of creating events. Sorry, but I like .NET’s event system.
Also, development seems to have slowed to a snail’s pace, or stopped, perhaps (not quite sure).
looks good but what is it?
Its an initial implementation of the SharpDevelop http://www.icsharpcode.net IDE for linux and mono with its homepage at http://www.monodevelop.com
BUT: Microsoft has patents concerning .NET and said they’ll enforce them. Also, while the core is fully standardised, the libraries are either not so open or even completely hooked into Windows (like Windows.Forms).
I’d prefer C# over Java, but before that I have to see an open platform emerge and be adopted by several vendors (maybe not Sun, but Apple, IBM, and the Linux community).
Open the stuff, create a good cross-platform Graphics API (i.e. no WinForms, no GTK) and I’ll be switching again.
To speak with the author of the screenshot: “ooooo, pretty picture” !
/me likes
What do you mean by “C# over Java” ?
http://www.go-mono.com/faq.html#patents
This comes up time and time again. Mono has no Windows.Forms, but instead targets GTK#.
Microsoft has patents concerning .NET and said they’ll enforce them
That’s a bold statement. I assume you’re a high-level Microsoft executive who has some inside info on Microsoft’s plans.
‘d prefer C# over Java, but before that I have to see an open platform emerge and be adopted by several vendors (maybe not Sun, but Apple, IBM, and the Linux community).
Open the stuff, create a good cross-platform Graphics API (i.e. no WinForms, no GTK) and I’ll be switching again.
Well, nobody is stopping anybody from creating another .NET/java “open platform”. Go ahead and start one, and then maybe in 20 years or so we’ll see if it’s usable or not.
@JCooper
– Mono does too have an implementation of Windows.Forms. The majority of their effort has gone into a wine-based solution. They also have an implementation that sits on top of gtk#, but it doesn’t seem to have many developers right now. Personally, I like the dotgnu approach. It’s not going to run windows specific stuff, but it seems to be a lot easier. I have no idea if the dotGNU approach is themable though or the mono approach for that matter.
Mono does too have an implementation of Windows.Forms
Sorry, what I was meaning to imply is the preferred solution for gui apps is GTK#. I was aware of some work but like you said, the actual implementation has stalled.
I think for mono to be successful, not having a direct implementation of System.Windows.Forms is a good thing. When porting apps from mono to .net and back, the core business logic should be seperate from the interface. The data structures, algorithms and functionality should not be included directly within any GUI elements; they should merely provide an interface to that code.
Further to this, it seems far more sensible having different interfaces for the same functionality on different platforms. The GTK# gui for gnome/linux can follow one HIG, while a SWF based gui in Windows can follow the Windows HIG, but ultimately the same functionality will be available in both applications.
Windows.Forms is one of the worst-designed parts of the whole .NET library. And it will be replaced by a new GUI toolkit when longhorn comes out. It is just a stopgap until Microsoft can come up with a better solution (Avalon?).
So I do not see the attraction of being compatible with Windows.Forms. It would be much better to design an independent cross-platform toolkit and implement System.Drawing to make porting easier.
Does GTK# use the System.Drawing namespace?
It use Canvas.
Windows.Forms is one of the worst-designed parts of the whole .NET library. And it will be replaced by a new GUI toolkit when longhorn comes out. It is just a stopgap until Microsoft can come up with a better solution (Avalon?).
All of the current documentation for Longhorn shows that Windows.Forms will still be there, and is at a lower level than Avalon. From what they’ve said so far, you can use Avalon directly as a replacement, but Windows.Forms code will still work, can still be written for new programs, and will simply be interpreted by the layer that Avalon represents.
On the other hand, if you’re using GDI+, DHTML, and many of the other systems available for graphics in Windows, you may have to do significant rewrites to function under Avalon, because Avalon is being written as a replacement for all of these. Perhaps beyond Longhorn we’ll see System.Windows.Forms and System.Web.UI (the underlying frameworks beneath Avalon) replaced completely by Avalon itself, but at the moment all of the documentation shows Avalon as a layer above these two solutions.
Then again, you referred to Windows.Forms as a GUI toolkit, which couldn’t be much more incorrect. Windows.Forms is simply an API, part of the .Net framework, and it already functions under the GUI toolkits of Win2k and XP, which can be visually quite different, and which were designed and released without the Windows.Forms API in place.
JCooper: Thanks for the link. Seems like mono is quite safe to use
Glamdring owner: I meant all other things being equal, I prefer the design of C# (and the CLR) compared to that of Java (and the JVM), since it has some small improvements (performancewise, and for versioning, as well as delegates and explicit virtual methods IIRC).
Now if only there were a generally-accepted cross-platform GUI and more vendor acceptance as well…
P.S. where did you get that Glamdring? I want one too
Hi. I have never used C# and have a fair good knowledge about Java specifically in enterprise environment. Here are my questions:
– is there a common framework to develop enterprise application, a common framework to develop client application, and both could be run over MS .net or mono or any other CLR runtime?
– someone told me that all common data-type are all primitive and has no object counterpart (example: C# has a date primitive but not a Date object). Is this true?
“- someone told me that all common data-type are all primitive and has no object counterpart (example: C# has a date primitive but not a Date object). Is this true?”
.NET has a concept called value types. These are user-defined types that are allocated on the stack and therefore do not require memory management or garbage collection. They are called value types because assignments have value semantics as opposed to the reference semantics you get with references:
If you write x=y for value types, there are two different entities called x and y which contain the same value. if you write x=y for reference types, you have two references called x and y referencing the same object.
You can however use value types like reference types by casting them to an object reference. They are automatically “boxed”, i.e. copied on the heap as a real object. This concept of automatic boxing has been added to java1.5 to avoid frequent explicit conversions e.g. Integer=>int and back.
The nice thing about the .NET type system as opposed to the java type system is that you can define your own value types. Examples for this include the .NET DateTime type and the Decimal type. But this capability is also extremely useful for stuff like vectors or complex numbers.
hth,
Hi
is there a common framework to develop enterprise application, a common framework to develop client application, and both could be run over MS .net or mono or any other CLR runtime?
no. you will have to use whats available currently
– someone told me that all common data-type are all primitive and has no object counterpart (example: C# has a date primitive but not a Date object). Is this true?
no. all types are objects. for speed they are boxed and unboxed into primitive types
this is what java 1.5 does too
basically if you want cross platform development java is a safer option than mono would be
“All of the current documentation for Longhorn shows that Windows.Forms will still be there, and is at a lower level than Avalon. From what they’ve said so far, you can use Avalon directly as a replacement, but Windows.Forms code will still work, can still be written for new programs, and will simply be interpreted by the layer that Avalon represents. ”
Of course it will still work. Just like VB6 applications will still work. But there have already been articles about porting Windows.Forms applications to Avalon. This would not be nessecary if Windows.Forms were a first class citizen in longhorn.
“Then again, you referred to Windows.Forms as a GUI toolkit, which couldn’t be much more incorrect. Windows.Forms is simply an API, part of the .Net framework, and it already functions under the GUI toolkits of Win2k and XP, which can be visually quite different, and which were designed and released without the Windows.Forms API in place.”
You should work on your reading comprehension. I never said that Windows.Forms was an independent GUI toolkit. I just said that it will be replaced by one. It is a thin wrapper over Win32 which exposes all the gory details like pointers and handles end even lets you overwrite the WndProc. That is why the mono project has to use WinE to provide a full implementation. And just because Win2k and WinXP look different does not mean that they use two different toolkits. The look of e.g. KDE is extremely customizable, but it is still the same toolkit.
“no. all types are objects. for speed they are boxed and unboxed into primitive types”
That is wrong. Only ValueTypes are boxed and unboxed, and java does not allow you to define your own value-types, so in java you only get the performance benefits of value types when you use the primitive types like int. This is a very severe limitation of java.
hi
“That is wrong. Only ValueTypes are boxed and unboxed, and java does not allow you to define your own value-types, so in java you only get the performance benefits of value types when you use the primitive types like int. This is a very severe limitation of java.
”
a class is a data type and you can use java to derive data types out of existing ones. the class library allows that. what are you talking about?
give me some code examples
OK. In C# or other .NET languages I can define my own value types. This makes most sense in cases where you want your data types to behave like numbers, e.g. dates and times, complex numbers, vectors, matrices, quaternions etc.
In C# I can define a complex number datatype like this:
struct Complex {
double re,im;
…
}
When I create one of those it will be created on the stack without burdening the GC and memory management. And complex numbers I create will have value semantics:
Complex x,y;
…
x=y; //They are still two different variables that just contain the same value. In java this would be two references referencing the same object.
x.re=0; //This has nothing to do with y. In the java case y would be changed by this.
Value semantics makes a lot more sense for any kind of numbers. And they also have a *huge* performance benefit.
To store 1000000 complex numbers in java, I would have to write
Complex[] data=new Complex[1000000];
for(int i=0;i<data.length;i++)
data[i]=new Complex(0,0);
This creates 1000001 objects on the heap. One for the array and 1000000 for the numbers.
In C# the syntax is almost identical:
Complex[] data=new Complex[1000000];
for(int i=0;i<data.Length;i++)
data[i]=new Complex(0,0); //This is not strictly nessecary since C# initialized structs to their default value which in this case would be re=0,im=0
But this creates only *one* object on the heap (for the array), so it is five to ten times faster and more memory efficient.
I am a mathematically inclined person, so most examples I give have to do with vectors or complex numbers. But this also makes sense for stuff like dates (.NET DateTime type) or Decimal numbers (The .NET decimal type).
For me it is really strange that java which is a language that is used at financial institutions does not have an easy to use decimal data type.
Hi
You should be using the class library for that. we have third party financial libraries too. check out sf.net and freshmeat
You should be using the class library for that. we have third party financial libraries too. check out sf.net and freshmeat
I think the point is you can define your own value types instead of having to use someone else’s third party financial library. =D
I give up. You don’t get it. It is *IMPOSSIBLE* to get the semantics or the performance of user defined value types in java. The language just does not permit it.
Hi! The release site on monodevelop.com (http://www.monodevelop.com/release.aspx) says that “MonoDevelop packages for the 0.1 release will be released on or after Friday, February 27th, 2004.”. AFAIKS there hasn’t been any packages released yet.. And the snapshop from 24th feb fails to build for me. Anyone knows when we can expect .1? Thanks!
omg, that site looks nice and clean, really good
As much as I love wx.NET, GTK# is a fair ways ahead.
The wx.NET wrapper is approximately 90% complete. Creating fully-featured GUIs is more than possible.
See the API reference on the documentation page to see what has been implemented.
Unlike GTK#, wx.NET’s API is stable (since it is already set by wxWidgets), so you won’t find yourself fighting with every new release.
wx.NET still has some of the uglies from wxWidgets… in particular, the nasty, ugly macro-style way of creating events. Sorry, but I like .NET’s event system.
True. That will be added in the future. However, wxWidget’s way does have the advantage of being able to capture the events of sub-components on a form.
Also, development seems to have slowed to a snail’s pace, or stopped, perhaps (not quite sure).
Not at all. In the past 2 months, several more samples have been created; wxGrid, wxHTML, and many others have been expanded. A new release will be out very soon.
The wx.NET wrapper is approximately 90% complete. Creating fully-featured GUIs is more than possible.
I was basing my judgement on the wx.net ‘status’ page. It looked sort’ve incomplete last time I checked… does it need updating?
Not at all. In the past 2 months, several more samples have been created; wxGrid, wxHTML, and many others have been expanded. A new release will be out very soon.
I’m sorry, I hadn’t realized. The last news update wx.net had was, I don’t know, September, November? And the mailing lists are as quiet as death itself. Not a whisper or peep from someone who looks like a developer on the project.
A new release will be out very soon.
I’ll be sure to check out the release. Thanks for all the hard work you’ve put into it.