“Novell has lifted the lid on enhancements integrated into the next major release of Mono, its development platform for enabling Microsoft .Net applications to run unchanged on Linux. The forthcoming version, due to ship next March, will implement a native Visual Basic (VB.Net) compiler and Windows Forms (WinForms).” Read more at vnunet.com.
Novell Turns Up the Volume for Mono 2
About The Author
Adam Scheinberg
Technology Executive • Web Developer • Father • Foodie • Music Snob • OS enthusiast
Follow me on Mastodon @[email protected]
Is the replacement for VB.Net and WinForms going to work on Windows?
Yes the VB compiler and Windows Forms will run on the windows port of Mono.
would be nice to be able to run .asp files (vbscript at server)
if it runs .net vb, why not?
Are we to the point that hardware drivers could be used irrespective of operating system? Oh, the heaven this would be…
New GUI designer to replace Glade? Miguel said it would be avaliable in Mono 1.2 on the mailing list.
Is it?
Here we go, found it.
http://lists.ximian.com/archives/public/mono-list/2004-July/022118….
”
There are a number of areas in which we are focusing for the Mono 1.2 release:
[…]
* Gtk# improvement and GUI designer.
“
Hello, I mainly use Visual Studio.NET @ work, but I have a Mac with Mac OS X and would love to code (with nice code completion, etc.) and then just compile under Windows (in a future in mono, but all I’d love to have is a nice editor). It would be great if SharpDevelop were cross-platform… something like that would be lovely.
Any Ideas? I have tried some “syntax” highlighting editors for Mac OS X, but none can replace or come close to the ‘power of vstudio’. -did you get my point?-
Mono is improving very fast, I hope the WinForms implementation works with cocoa or something like that. Wouldn’t it be great if you could create a form with <xxxx> and compiling under Mac OS X were as easy as just that.. compile; then you’d have your “cocoa/carbon” window…
That’s dreaming too much.
Cheers.
Why replace Glade? Glade works really well for designing interfaces, the only thing that is missing is to integrate it with MonoDevelop. Wouldn’t that make more sense than reinventing the already quite good wheel?
Are we talking about having the native (Windows) Winforms as opposed to some hack with wine?
So that one could code an app with Visual Studio and use winforms to generate the ui, then run this straight out of the box on Linux??
That would be incredible if thats what they are looking towards…
@anton:
Yes!
Ack vbox/hbox are lame. I just want to place/resize widgets easily.
If I remember right DotGNU does run WinForms native… and Mono and DotGNU are share someparts of the CLR API (WinForms, as fare as I remember)
Excellent!!
I just couldn’t stand vbox/hbox!! Sorry to those that like it, its just my personal preference…
I’ve been pysching myself to learn Mono, but it isn’t comfortably installed on the distribution I usually use, Slackware. The tested binary packages are available for RedHat, Fedora and SuSE. I like SuSE 9.1 a great deal, but Mono is at home in Gnome, and so am I. In addition, some other nice tools, like Red Carpet, are available on SuSE.
So, if I want to use Mono on SusE, is my choice to use KDE or try (again) to build Gnome on SuSE? Or, is there a secret trick to putting Gnome 2.6/2.8 on SuSE?
http://www.slackcare.com has packages for mono, and they work quite well.
Only nuisance is that you have to register (for free as in beer) with them…
Mono Packages for Slackware can also be had here:
http://packs.slack.it/?mono
Without any registration pain… Although the packages there may be somewhat dropline specific, although I can’t imagine what difference it would make for those.
This is where I got my Mono packages from, and I haven’t had any problems with them. Although I do use Dropline and slack current.
I wonder what will be Microsoft’s strategy to counter-strike.
They just can’t let it happen. Can you imagine running natively ASP on a FreeBSD machine. It would mean:
– No more in need of Windows servers for Windows-friendly developpers who use ASP.NET
– More security and performance server-side
– No more Microsoft tax
Not to mention applications in VB, C#, etc…
Creazy…
—
Charles.
“Did you have your Win dose today?”
Just because of the default Gnome desktop, Fedora may seem the best distro for Mono. However, Gnome is easily installed in Suse, using Yast or if you have the Professional version, from CD. IIRC, the free downloadble CDs even have Gnome. No need to change distro’s just for Mono. There is also Red Carpet for Fedora, but it’s not yet 100% stable and ready.
Because people aren’t using Windows.Forms on Windows, I wonder how it will work out on Linux.
You think that just because they will have the chance of deploying on Linux, it will change anything? I mean, the majority of the desktop is on Windows, and they don’t have Windows.Forms applications installed.
Also, check out “Is Windows.Forms dead?”:
http://weblogs.asp.net/mharsh/archive/2004/09/20/231888.aspx
According to de Icaza, the WinForms API will be implemented for Linux using the Gnome GUI libraries including Drawing.2D for graphics.
Uhmm, I thought the only dependency for winforms on Unix was Cairo…which I believe has nothing to do with Gnome. So I’m assuming this article got the Gnome dependency or has something changed lately?
In any case, it’s good too see the Mono crew finally ditching the Wine-implementation of winforms.
Since Longhorn and Avalon are a minimum of two years off, Winforms and C# blows away win32 api and MFC, and since windows developers aren’t going to touch gtk#, this is a good move.
Its good that they finally realized that the Wine hack was a bad move.
Anton: The last I looked at Slackcare, it had outdated Mono packages. Now, it seems unregistered guests can’t even see a list of the titles available for download. Have that updated?
Best: Thanks for that pointer.
Man-at-Arms: I own a copy of SuSE 9.1 Pro. It uses Gnome 2.4. I’ve not been able to install the unsupported Gnome 2.6 files SuSE provides and keep a stable system. Frankly, the combination of Gnome 2,8, Mono, and things like dbus and hal is rather interesting.
. . . required me to re-install mozilla. I got the packages from one of the aforementioned sites (forgot which), installed them, and then reinstalled moz pkg after seeing monodevelop complain about it missing. I don’t use a gnome session, just fluxbox. I haven’t played with monodevelop much yet (I currently do my c# coding at work under Win2k/.NET framework/SharpDevelop), but it does seem to run properly.
Well Cairo is used for the drawing, xlib is used for windowing. Gtk is not used as an underlying driver, however with our theming support it could be. See:
http://primates.ximian.com/~jackson/blog/archive/2004/Sep-21.html
could’nt you just install mono using yum ?? so whats the problem ?
Snake
Having automatically resizing windows/widgets is great. Screw the absolute positioning shit. Also, don’t forget that GTK-style layout allows for better internationalization and such. Also, you can do fixed positioning of widgets in GTK. You just use the fixed positioning widget.
Sorry, but Windows.Forms support on Mono sounds like a dead-end. But not all is blues, as there are many features, and W.F is just one more. Too bad for Microsoft if they don’t intend to fase out W.F, though. 🙂
have you tried XCode? code completion isn’t turned on by default, you have to enable it in the editor preferences, but it’s just as useful as visual studios.
I thought Microsoft had some patents in regard to WinForms? Could someone enlighten me?
Oh Yay, but xCode works with Java, C, Objective-C, etc. Not with C#; I mean, xcode knows anything about C# (and .NET for the matter)
Too bad, because I like it
Yeah, but they implement it differently. So it is ok….
Why put effort into cloning winforms? Why not just improve gtk-sharp and improve its cross-platform capabilities and then people who want to write cross platform stuff just use gtk-sharp in the same way people use wxGTK or QT and it works everywhere. That seems a lot safer and better because then it will be the gtk/gnome way instead of MS’s way which, if windows.forms takes off on mono will displace some gnome development and fragment it (i’m just assuming that the windows.forms stuff will at least visually integrate with gtk/gnome right?)
HBox/VBox are part of most layout-managed APIs. GTK+ has had this for years, and CLIM and DUIM have had it for even longer. Such constructs are essential to proper internationalization, font-sensitivity, and for scalable UIs. Microsoft will be catching up with the early 1990’s with regard to GUI toolkits when it releases the 2.0 release of the .NET toolkit, which will be layout-managed.
In case you didn’t notice, Debian is a nice Mono platform.
apt-get install mono monodoc monodevelop nant muine blam f-spot
It’s just apt-get away.
Exactly.
When you are making decent guis the amount of time you spend writing resizing code is disgusting. swf has the concept of pinning that can help with basic resizing in basic cases, but once you try to do something useful it falls apart. Static positioning is only good for creating user hostile, non resizable, non internationalized, non dpi independent, non customizable guis. Unfortunately this describes 90% of the present windows guis. I am so glad that avalon will bring windows in the the modern hbox/vbox world.
ps. What is with all these “no one uses swf” comments? swf is the least bad toolkit microsoft has put out. You would have to be nuts (or concerned about deploying a .net app to users who do not have .net installed) to not use swf on a new app.
The patents are difficult proble. But IMHO the patents can kill linux in any case: with word doc, or xls formats, with SMB, etc.
Microsoft will be catching up with the early 1990’s with regard to GUI toolkits when it releases the 2.0 release of the .NET toolkit, which will be layout-managed.
The Next AppKit (now Cocoa) has had a layout-managed, fully localisable GUI toolkit since 1988. You add springs and struts visually the the .nib file in Interface Builder. And nobody has actually caught up with Interface Builder either in the intervening 16 years. Apparently the current state of the art is supposed to be composing xml by hand – yeah right..
Don’t be so harsh… nobody actually looks inside the xml of glade files (and nobody will do with the xaml files)… xml is just a storage format.
On the other hand, an automatic procedure could do stuff on them, since they are easily parseable.
Cocoa IB .nib files are xml files too these days. Both Glade and Qt Designer also use xml based file formats, and I wasn’t intending to be harsh on those. But there is no place for hand crafting xml UI files without a visual tool in the early 21st century. I couldn’t believe the recent article on IBM DeveloperWorks called ‘Reflective ui design’ or something, which was suggesting doing just that. How come there isn’t a standard java visual ui designer for Swing? You can’t just leave these things out without expecting some harsh critism from people who have been using high quality UI tools for *years*.
What plans to Microsoft have for a visual UI design tool – the only thing I’ve read about is how wonderfully declarative the xml file format is?
why put effort into cloning winforms? Why not just improve gtk-sharp and improve its cross-platform capabilities and then people who want to write cross platform stuff just use gtk-sharp in the same way people use wxGTK or QT and it works everywhere.
While improving GTK+ would be safer, it’s not practical. One of the points of Mono is to make it simple to port applications from Windows to non-Windows (Linux, Mac OS, *BSD, etc.). The emphasis is on simple: ideally, no work should be required to move an application; it should Just Work.
Requiring developers to re-write their GUI is not easy. It is, in fact, difficult for many developers, and would thus be an impedance to supporting Linux.
The easier .NET applications can be moved to Linux, the better — it will permit more applications, more developers, more mindshare, and more users. At least, that’s the hope.
…if windows.forms takes off on mono will displace some gnome development and fragment it…
I believe that this is highly unlikely. Most developers will want to stick with what they’re familiar with, so Windows developers will go with Windows.Forms, GTK+ developers will go with Gtk#, and developers who like to go the extra mile for their users will write multiple front-ends for each toolkit. Fragmentation will be minimal, as I imagine these groups don’t overlap much in the first place.
What we’re getting, then, are two paths to portability: from Windows via Windows.Forms, and from Linux via Gtk#. Surely this is duplication of effort, but some times duplication is required.
The alternative is to only support Windows.Forms, which won’t fly — many people hate its layout scheme, as it’s not i18n friendly, plus it’s from Microsoft, which many dislike. Or, we only support Gtk#, which won’t work, as this would prevent the largest group of .NET developers — Windows developers — from easily supporting Linux.
Do you honestly believe that Microsoft will NOT ship a visual editor with the next generation of Visual Studio, Visual Basic, Visual Whatever?
It simply won’t happen, whatever their PR department is saying this week. Those tools are regarded as “simple” and “highly productive” (mostly) by clueless devs only because they have visual gui editors.
Take them away and I’ll hear the howls of pain from this side of the pond…
Do you honestly believe that Microsoft will NOT ship a visual editor with the next generation of Visual Studio, Visual Basic, Visual Whatever?
No I suppose not, but why do they talk so much about the declarative xml stuff? I think the only real point I was trying to make, is how come this Windows.Forms was designed so recently, and yet lacks something as basic and obvious as a layout management system, and why is it being scrapped and rewritten almost immediately? I’m just a bit baffled that’s all..
🙂
I’m never baffled by MS lack of organization when managing the releases of half-baked softs/apis/whatever.
I strongly agree with you that the lack of layout management is terrible, and leads to the usual ugly VB apps we all know. I normally can spot that something has been written in VB by just looking at the interface.
I think that all the fuss on XML is really just the current fad, and xml is the buzzword of the year. What could be useful of xml interface declarations however is the fact that it is machine parseable, and so could be modified in a programmatic way if needed.