wx.NET 0.5 official has been released. Their webpage has also been updated: user manual, API reference, class status, and screenshots.
wx.NET 0.5 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
Nice to have a sample that goes beyond “Hello World” there. Looks very promising!
If wx.NET is thought as a replacement for SWF then why not use it under mono project … there is a tremendous work at wx guys , why dont they help on mono development ? why dont they interfere more ?
because, wx.net is based on wxWidgets and wxWidgets is a seperate project both from GNOME (ximian, GTK) and from KDE.
and what is more, wx renders in GNU/Linux via GTK1 [ugly].
I hope they fix this soon enough [that fix does not depend on wx.net guys nor is it a simple one as it seems]
I only know that wxNet guys like DotGNU more than Mono [i got the impression that wxNet likes DotGNU, and Mono likes GTK#] ofcourse it works under mono very well. wxNet now supports the event system that is the standard ATM in C#. this is a huge step forward. Well done!
and what is more, wx renders in GNU/Linux via GTK1 [ugly].
I hope they fix this soon enough [that fix does not depend on wx.net guys nor is it a simple one as it seems]
Unfortunately, the Gnome API is constantly changing between major releases. This means that it is difficult to upgrade to applications that do not follow the MVC (model virtual control) policy of separation of design and implemntation very well. Hope I’m not generalizing too much, but you see this often in the open source world, where the goal is to having a working product, not to necessarily have the best code organization. I find this frequently comes from a lack of experience, not from laziness. This code works, but it is not maintainable when large changes need to be made, like implementing a new display API. Sadly, I don’t see this changing in the open source world, either.
MVC == Model View Controller
“and what is more, wx renders in GNU/Linux via GTK1 [ugly].”
By default, and most packagers use this option, but one can throw a line at the configure script to get gtk2 instead. I’m not sure how well it works with the 2.4 codebase, but I was using gtk2 for 2.5 for a while and never saw any problems come up.
I’m curious, has there ever been any speed and memory use comparisons betwean swt and WxWidgets?
Actually, the preferred bindings is to gtk2.x, and has been for a while now. In fact, the gtk1.x bindings were broken a while back. The main developer was going to look into it, but I don’t know if it ever got resolved.
It seems like a lot of layers to go through:
wx.NET –> wx-c –> wxWidgets –> GTK+ –> X11
Doesn’t that result in a *lot* of function call overhead and thus a ..s…l…o…w.. GUI toolkit?
Actually, it’s wx.Net –> wx-c –>wxWidgets –> GTK+ –> GDK –> X11, when I was playing around it on a p166(a while ago), with bindings to GTk1.x it had decent speed. It was a helluva lot faster than any Swing app on that machine.
Unfortunately, the Gnome API is constantly changing between major releases.
Well, there have only been two major version numbers of Gnome so far: 1.x and 2.x and by definition (in the Gnome project and elsewhere) a major version number change is an API incompatible change. So I’ll assume you mean minor releases as in 2.0, 2.2, 2.4 & 2.6 in which case you are completely mistaken. The entire 2.x series has been API as well as ABI stable.
A quick look at the wx.NET screenshots on Linux indicates that it is using GTK2. The high quality anti-aliased fonts are obviously GTK2. It should be easy to see for anyone who has used both GTK2 and GTK1.
thanks for keeping the coversation up.
as to the last guy chemicalscum, I know that even wxWidgets 2.4 (the stable one) does gtk2 but I’m not aware of any distro that has this the default. So first read what the others users said already here, and then come up with “easy to see for anyone who has used both GTK2 and GTK1 comments”. No offense.
What I want to ask the unstable users of wx (that also uses GTK2 to render) is this:
Do they added at last the ability for a button to have an icon like in GTK2? If not, then yet again, their main focus in the Windows Enviroment. What I want to say is: “I and others would use wx if it was the almost the same with GTK2”. Now it’s not, so I can pass. After all, someone can understand where wxWidgets devs have their target. I just remind to everyone that wxPython is something like the main GUI in Windows these days for PythonDevs. So Windows yet again..
Wow! Another wxPython user. Cool!
But you seem to be saying wxWidgets doesn’t provide you will all you need in GTK2? I cannot comment on that, but assume you’ll instead look into Glade and GladeGen for GTK+ development.
Recently, I’ve looked into both wxPython with PythonCard, and the Glade/GTK+ options for a cross-platform GUI. Both seem to have their issues. wxPython seems to have undergone some fundamental changes in v2.5 due to underlying changes in wxWidgets (see http://wxpython.org/MigrationGuide.html), so some of the documentation seems to be a bit out of step. On the other hand, I’m not soooo taken by GTK+ as it looks and feels on Windows (I much prefer a native-looking GUI). As well, Glade seems to crash on me from time to time when I appearantly do something it doesn’t like.
Personally, I’d like to see more cooperation amongst the open source GUI teams (wxWindows, GTK+, Mozilla/XUL, etc.) to provide greater modularity and code-sharing amongst each other.
…but what’s with all the “duplicated” structures that are already present in System.Drawing? The wx.Color structure is pretty pithy compared to the System.Drawing.Color structure. S.D is pretty abstracted from GDI+ (to the point where P.NET has a robust implementation and Mono is getting there), so why reinvent the wheel for all of this? wx.Bitmap, wx.Color, wx.YourMomma, …
I like that wxPython is the main GUI for Python these days. But this also shows how much wxWidgets and Windows Devs go hand-by-hand. All I said was that if they don’t do something quickly with GTK2, then GTK3 will be out and those wxGuys will still be stuck on GTK1.
as to the other thing, about duplicated, I only think that this is because of the different represenation of Colors in wxWidgets and SWF.
So my friendly advice to the wxDevs is either you continue on Windows-only base, or you should consider a HUGE STEP forward in the freeOS area.
and as a sidenote, I know you really like native-GUI, but there is also WIMP (GTK theme that mimitates XP) [see it in latest win32 gaim port].
“and what is more, wx renders in GNU/Linux via GTK1 [ugly].”
By default, and most packagers use this option, but one can throw a line at the configure script to get gtk2 instead. I’m not sure how well it works with the 2.4 codebase, but I was using gtk2 for 2.5 for a while and never saw any problems come up.
GTK+ 2 works great for wxWindows/wxWidgets 2.4.2! In fact, I daresay it works better than the default GTK+ 1 bindings. I have no clue why it isn’t the default yet; it really should be.
Here’s what I do, and would recommend anyone wanting to use (C++) wxWindows do for now: Pretend like you’re on MS Windows and skip downloading your distribution’s version of wxGTK entirely. Instead, download the source and compile it yourself, configured with –with-gtk2, and then build it as a static library (aka: –disable-shared). That’s the important step. Now your eventual users won’t get (or use if they have) the shoddy GTK+ 1 bound version of wxWindows, and the only cost will be a couple of extra megabytes for your application. Hard-drive space is cheap these days.
Hi all. I did not know about this post until now. I recently started working on the wx.NET project to provide a true platform independent toolkit for .NET that uses native widgets. wx.NET and Qt# are really the only games in town for this.
Some quick replies to comments made here:
+ The pre-build libraries/samples available for download use GTK2. If you built from source wxWidgets will be built for you using GTK2.
+ Mono is pushing hard Gtk#. Unfortunately, this requires an X windows server on the Mac and does not use the native Mac aqua widgets. And on the PC it also does not use the native widgets and works very much like Java SWING.
+ We are .NET runtime agnostic. I would suggest people use Mono on Linux and Mac; however, PNET is an option too and we certainly don’t want to lock someone into a runtime (not that we could!).
+ wxWidgets and thus wx.NET uses the native UI engine/toolkit on each platform. This has pluses and minuses. Big pluses: performance, can get the native look-and-feel without emulation tricks, have access to the underlying UI engine’s widget handles if you need to do something platform specific. While normally a negative of the common wrapper approach is only providing the “lowest common denominator,” the wxWidgets team has done a good job of implementing platform-specific functionality when appropriate. For example, MDI is available on GTK and Windows.
+ Just because you have a few layers on top of a call to create a window does not mean that it slows things down. They key is that the underlying UI is using the native toolkit is being uses vs. something like SWING where everything has to be emulated via graphics calls. Under wxWidgets when a button is created it does little of the work: WIN32 API does the work, GTK+ does the work, etc.
Regards,
-Mike M