The DotGNU project is holding an international competition
in the area of collaboratively implementing the
System.Windows.Forms
namespace in the C# class libraries, a GUI framework that will allow developers
and end users to run and develop applications on many different platforms,
anything from GNU/Linux, MS Windows, OS X to even handhelds. Participants will have a chance of winning one of fifteen monetary prizes totalling US$ 4500. The full anouncement
is here.
ya dotgnu! w00t!
is this going to be some sort of visual basic langauge that allows windows to be drawn instead of written like in VB 6 ?
but with c# and .net ?
Snake
No, if this is successful it will allow programs created with the .NET tools and/or the C# language to be run in other operating systems than Windows, with full support for a graphical user interface.
The Mono project has been attempting this for a while but still lacks real support (last time I tried it) for programs with a GUI.
This means your C# and VB.NET apps you develop on Visual Studio or with plain old .NET you can run on linux, osx, handhelds. It means .NET cross-platform ability.
So they want to implement it from scratch at the graphics api level? Ugh. Yeah it’ll be themeable so it’ll *look* like anything you want, but how will the widgets *feel/act*? Like Windows? Like GTK+? Qt? Swing? XUL? Something new?
Also interesting is that from what little MS has mentioned in public about Longhorn, there is a new GUI library called Avalon coming. It’ll be based on XML descriptions of the UI (think old Windows dialog resources, but in XML!, or Mozilla’s XUL) fed to the rendering engine. Rumor has it that Windows.Forms and the GDI+ API it is built on are a dead end; GDI+ being a dead end because it isn’t all that fast (not hardware accelerated?) and because the new 3D accelerated API/engine will take on the low level drawing role for Avalon.
MS ought to change .NET’s name to Taillights.
Many of those new features can be the backend of Winforms while still supporting current technologies. Theres quite a big following with winforms now among .NET developers so I don’t think people are ready to up and trash their code to migrate again already.
Longhorn is due out in late 2005/2006 anyways, theres no reason why they can’t continue to support that later. Or if they introduce new controls, just implement them.
Plus half of this is speculation. Just like how MS claimed longhorn would require 256mb vram, and now its down to 64mb. Its all speculation because theres no real facts out there yet.
I agree that current Winforms users won’t want to migrate unless there is a big advantage (MS will probably cook up some kind of translation wizard for the UI’s anyways). I more wonder how much MS will let Winforms stagnate in order to prompt adoption of Avalon. And how many VB/MFC programmers that haven’t jumped on the .NET bandwagon will just wait it out. I guess that’s the price of “vaporware” announcements.
It’ll be interesting to see what is revealed at this PDC in October.
PS: Speaking of vaporware, with all this talk of 3D accelerated compositing UIs, couldn’t they render realistic fog in the UI? Now *that* would be vaporware!
PSS: I know Longhorn isn’t technically vaporware. I just needed to set up that last item
Let Winforms stagnate? Geez they’re adding dockable stuff and most UI widgets you see in VS.NET to Winforms for version 1.2 of the framework. It’s quite the opposite.
Good to hear. Is there anywhere public I can read about this, or will this stuff also be announced at the PDC?
Note: I did mention it was just rumors. Not very good ones apparently
And I still worry about this DotGNU implementation of Winforms being another “doesn’t quite feel like the native widgets” type library. Which platform’s behavior will be imitated?
Remember, I’m not talking about look (well, maybe a little). This is about feel (mostly).
In trying to find info on this a came across the mention that there will be new grid controls for Winforms. Cool. In my limited dabbling with Winforms the grid is one control I found quite lacking (compared to Delphi’s grid), and most of the 3rd party grids seemed overengineered and festooned with useless (to me) features.
Reference:
http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx#whidbey
ok so basically i ccan develop applications in .net or c# and they will run nativly in linux or will it be like java virtual machine ??
Snake
It runs in a type of Virtual Machine, where the code is translated to native system calls in real time.
The advantage is the code can be “Write(compile) once, run anywhere”.
is there any DOS support for Java based RDMS?
I wrote a list of pros and cons of the various GUI toolkits here:
http://primates.ximian.com/~miguel/tmp/toolkits.html
Miguel
For me it’s a waste of time …
People who need windows.forms run their applications on windows .. not on unix. And there are so many graphic toolkits on unix which can be bound with .NET and can work also on windows!
That’s a massively bad idea. Wine has been cloning the Win32 widget toolkit for years, and it still isn’t complete.
I think those guys don’t really understand the sheer scale of what they’re trying to do. While Windows.Forms is in some ways very primitive (no real containment based layout, no real XML form description system) the controls themselves are jam packed with features, as you’d expect for a toolkit that has undergone a decade of continuous development by a team of hundreds. The ListView control alone has over 10,000 lines of C code in the Wine codebase.
I’d be willing to bet that half their bugs will be to do with incomplete emulation of the widget toolkit eventually. Heck, unless they are planning to write a miniature word processor as part of this project, they won’t ever have a RichEdit control either, just like Wine.
That’s a pretty good writeup Miguel. You should put that on go-mono.com I think.
Rebol already does this.
Why reinventing the wheel only to imitate MS ?
Does it support Applescript yet? All my mission critical apps are written in Applescript?
I have a list of pro and cons of different toolkits for you too:
– GTK is C-crap and unsuitable for any development, just as Motif is. GTK is Linux legacy.
– Qt has a nice and clean API, which is ideal for large cross platform applications.
Nice flame-bait, Miguel. Don’t you guys ever get tired of putting us down?
Your write-up is flawed:
“Library is GPL with exceptions; But bait-and-switch licensing of their class libraries can mean anything.”
What the hell is bait-and-switch licensing? You should know as well as anyone that our C# library has the same license as GNU Classpath, and for the same reasons. The license is essentially like the LGPL, but works around the legal loophole that would allow people to write native code re-implementations of parts of the library (through internal calls to the engine or pinvoke) without releasing the source code for such clear modifications of the library along with their binary distributions. While this is allowed _legally_ under the LGPL, it essentially defeats the purpose and spirit of it.
“Partial compatibility with Windows.Forms: simple programs will run, but more complex ones will fail.”
The same could be said of any IL program that uses unportable code. Use of unportable features, such as pinvoking a win32 library, are up to the programmer. The programmer can also choose to embed native code in IL binaries with the MS .NET sdk. The portability safety nets of java don’t exist in .NET, so programmers targetting ANY non-MS CLR will have to make an effort to write portable code and not use the various unportable features. Once again, you should know this as well as anyone.
“Large Windows.Forms applications unlikely to work.”
Let’s come back to this once we get #develop working.
“Look is alien on every platform.”
Have you run any of the example programs? Have you seen any of the screen shots? Right now we only have a win95/98 look available because we’re doing that theme painter first. Once we’ve finished off that, we’ll be writing other theme painters. This not only means we can have native looking controls on any platform, but that we can test that look on ANY platform. On winXP, for full XP theming integration, we’ll probably pinvoke the XP api for drawing the controls (unless we can figure out a way to parse the XP theme format, whatever it might be, and convert that to something usable). Note, we’ll still have XP theme painters for the default XP themes that will require no pinvoking and therefore will run on any platform. Native feel may require a few extra hacks (for example the difference in behavior between win98 “smooth scroll” scrollbars and gtk scrollbars) but it can also be achieved.
No accessibility, poor rendering.
With respect to poor rendering, that’s just plain bs. Our controls are drawn in the theme painters to look like they should for that theme (currently only win95/98 look), we have screenshots from our win32 contributors to work off of, and we aren’t blind, so our rendering quality should be just fine. We use System.Drawing for drawing all our controls, and so whatever backend System.Drawing is using will determine our rendering performance. Currently we have a fully-functional Xsharp backend and a semi-functional Win32 backend. We can add in other backends later (e.g. OpenGL). As for the near-total lack of accessibility support, blame MS; that isn’t our doing. Your wine-based winforms will have the same problem. At the moment we’re just trying to get a compatible system working so developers can migrate from MS to pnet, but that doesn’t mean we’re going to stop at just being compatible. Once we’re as MS compat as possible, we’ll begin extending the system. You don’t have to explain to us what’s wrong with winforms; we already know. (We have to use it, remember?)
Rich
P.S. By the way, setting my subscription to the Mono mailing list to disabled delivery because I disagreed with Paolo on the DotGNU list is very childish. I do hope you (or was it Paolo?) can start growing up sometime soon. It might be nice to actually work in an environment not so closely resembling kindergarten.
“I think those guys don’t really understand the sheer scale of what they’re trying to do. While Windows.Forms is in some ways very primitive (no real containment based layout, no real XML form description system) the controls themselves are jam packed with features, as you’d expect for a toolkit that has undergone a decade of continuous development by a team of hundreds. The ListView control alone has over 10,000 lines of C code in the Wine codebase.”
We knew it wouldn’t be easy, but we’re already about half done, afaik. The hardest part isn’t getting all those features working so much as it is following the brain dead specs from MS. It’s a truly horrid API, but someone’s gotta port it. RMS wants us to make it as easy as possible to switch from MS .NET to DotGNU Portable.NET, and we’re doing a pretty good job of it so far, especially when you consider just how few of us there are working on pnet.
“I’d be willing to bet that half their bugs will be to do with incomplete emulation of the widget toolkit eventually. Heck, unless they are planning to write a miniature word processor as part of this project, they won’t ever have a RichEdit control either, just like Wine.”
Actually, that’s exactly what we’re planning. We already have a mostly-working TextBox control. We also have Rhys, the lead developer, a.k.a. Flying Fingers of Death, who writes more good code in one night than most hackers do in a year. With the prize money incentive, we should have winforms essentially complete by year’s end.
Rich
P.S. Don’t worry about competing with Rhys for the prize money. He’s a member of the DotGNU steering committee and is therefore not eligible to participate in the competition.