According to reliable sources DotGNU is using Qt for their Windows.Forms backend. The project is not using Qt’s widgets – they are simply using Qt styles (or was it themes) on an offline XPixmap , and blitting it over onto the screen. Here’s the obligatory
screenshot.
DotGNU’s Win.Forms Use Qt Painters
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Semi off-topic:
Imagine my surprise when I updated my debian unstable system and typed apt-get install monodevelop just for fun.
Monodevelop is in debian unstable, as are quite recent builds of mono. Combine this with the excellent work of the dotgnu people, and we will have two working implementations of .NET under linux soon.
I also like that both projects take different approaches. Since I am a KDE fan I will probably use the dotgnu implementation of Windows.Forms, but the mono VM is way ahead of the dotgnu interpreter. Fortunately they can be combined: you can use the dotgnu class libraries such as S.W.F. on top of the mono VM.
These guys are fscking great!!!!!!!! I’m starting to favour DotGNU over Mono, as DotGNU impresses me with new things almost every week. I hope it is speedy though, when blitting it to an offscreen Pixmap.
tuttle, you’ll be happy to hear that Southern Storm’s latest project – libjit (“libjit implements Just-In-Time compilation functionality. Unlike other JIT’s, this one is designed to be independent of any particular virtual machine bytecode format or language”) – will be integrated into portable .net within the comming weeks which will certainly mean a speed up for the runtime.
You are right that mono’s JIT outperformes ilrun (CVM) in many cases, but you should keep in mind that CVM is still the fastest IL interpreter available.
It is really impressing what both projects achieved so far!
Speaking of the Qt WinForms backend, it should be noted that Qt will not be required to run pnet’s WinForms (as the news might indicate), so it won’t be “the” backend, just an option.
> Speaking of the Qt WinForms backend, it should be noted that
> Qt will not be required to run pnet’s WinForms (as the news
> might indicate), so it won’t be “the” backend, just an option.
The email archive clearly says that “Qt backend if you’re running KDE , Gtk-theme if in Gnome , XP in WinXP etc…”
Native Look & Feel
.. sound right since pnet’s SWF is built like Swing 
> You are right that mono’s JIT outperformes ilrun (CVM) in
> many cases, but you should keep in mind that CVM is still
> the fastest IL interpreter available.
CVM is not just an IL interpreter
Read http://www.sys-con.com/dotnet/article.cfm?id=264
I have a local hack on my box that lets me use CVM to interpret JVM code … (though my verifier is limited to integer/float/long operations , branches and method calls without any exception support or thread safety or anything).
It’s proof of concept – but CVM is a very flexible portable VM with a clear interface (read the ILCoder API). (what I have is what remains of http://jilc.sf.net).
But I’d better not get too distracted from IL
And what about the QT license?, do I have to pay a license to use it?
What about it? It’s GPL.
I’m not the anonymous poster but I was thinking about license problems as well. Of course Qt is GPL. There are going to be lots of closed-source program using SWF. Is there any legal problem with closed-source programs using the Qt backend of DotGNU? Has there been any situations where something like this has happend in the past?
SWF is kinda limiting and a lot of SWF programs use PlatformInvoke to give themselves more control. Since they are doing the native widgets thing, this means that there is no chance of supporting those applications… correct?
Read the following thread :-
http://dotgnu.org/pipermail/developers/2004-June/012370.html
Also for the PInvoke thingy , those are anyway not going to
be supported by DotGNU . Anyone who PInvokes into kernel32.dll
is giving up portability in any case .
Btw, read the post again, this theme support is available
not only for standard controls, but for anything that uses
ControlPaint to draw
Yeah, if it uses Qt then there’s unlikely to be a GPL (or even non-commercial) Windows version.
Please don’t cripple DotGNU by giving it Qt licensing problems.
Someone mentioned earlier, this is just one particular backend. SWF can be used without it.
“Also for the PInvoke thingy , those are anyway not going to
be supported by DotGNU . Anyone who PInvokes into kernel32.dll
is giving up portability in any case .”
okay, I thought so. I believe mono is apparently trying to use Wine for implementing SWF for maximum compatibility. It would be nice if there was a way to use DotGNU’s SWF but to fallback on Mono’s if it doesn’t work. That is, once both of them work.
There shouldn’t be any licensing issues with the GPL qt being available as a drawing backend. Since a number of backends are available (gtk, winxp), and since this is something that is controlled by the end user, there shouldn’t be problems with commercial apps using this. They simply conduct all development of the app in question without qt support installed, and then there can be no question about any gpl related problems.
Excuse me bothering … but what is this SWF you are talking about ? i guess is not shocwave flash isnt it ?
If it is then anyone thinking at it should be OUT!!!
It is totaly crap for intense UI stuff…so be out…
The total portable best abstractable and crosplatformatizable UI toolkit should be MOZILLA XPTOOLKIT/XPFRAMEWORK.
SWF=System.Windows.Forms.
> I believe mono is apparently trying to use Wine for
> implementing SWF for maximum compatibility.
Wine has stability issues which are more related to providing
actual binary compatibility to native code rather than
the actual functionality.
Pnet’s SWF is a lightweight toolkit and has its own pluses
and minuses correspondingly – it’s harder to do , but it’s
more interesting from a developer’s point of view to have
fine grained control over the UI.
Btw, if you throw out Mono’s winforms and replace it with
DotGNU’s it used to work (I think Beta2 broke something in
mono’s PInvoke, it isn’t working here)..
Why do “QT makes little sense.”? The widget it self? The License? Both? Others?
Why not use gtk ? or Tcl/tk ?
QT makes little sense.
You are free to code your own GTK-only version. If you don’t plan on writing it yourself, then its toolkit impelementation should not matter one whit to you.
In the end, you’ll get dialog boxes with little X’s in the corners and you won’t know the difference.