First, a word of reassurance: there are no sweeping backwards-incompatible changes in wxWidgets 3.0 compared to 2.8. We did have to break compatibility in a few places but fixing the existing code to compile with 3.0 will be trivial, if needed at all, unlike 1.0 -> 2.0 transition which required rewriting it.
Second, the main change in 3.0 is the rethought support of Unicode. While wxWidgets supports Unicode since quite a long time, so far it did according to Win32 model: there were two different builds of the library, one ANSI and the other Unicode and you could either use the former to use the familiar char * strings but stay limited to a single encoding or choose the latter one and be able to use Unicode in the GUI but at the price of working with wchar_t * string only which implied using ugly-looking wxT() macro in a lot of places for example. wxWidgets 3.0 will have only one build (which on its own is a great simplification for developers, packagers and even users who won't hesitate between which one to choose) combining the best features of the two: it will always use Unicode internally but support char * string and simply convert them using the current encoding transparently. In other words, you will be able to write code in exactly the same way as with the old ANSI build if this is all you need but profit from the full Unicode support at the same time. This is especially nice for the existing wxWidgets applications which weren't always written with Unicode in mind and so often didn't even compile with the Unicode build of wx -- now they will and it will be possible to extend them to deal with Unicode at leisure instead of spending a big initial effort on wxT()-izing them first.
wxWidgets 3.0 is still work in progress, in particular documentation hasn't been updated to reflect the changes yet. However the API and the code are believed to be stable enough to be used and we'd welcome any feedback on the new API. In particular, please try recompiling the existing code with the version currently in the svn trunk and let us know about any problems you may encounter (other than those which are mentioned in docs/changes.txt: please read it first!).
There are, of course, many other new features in wxWidgets 3.0 (without speaking about the bug fixes...):
- The new wxDataViewCtrl class provides all the features lacking in wxListCtrl and a much better and simpler API to use them.
- There is a new wxDFB (DirectFB-based) port especially suitable for the embedded devices.
- wxGTK (and wxDFB) are also more efficient internally because they use UTF-8 for the string representation, instead of wchar_t and so avoid the conversions between the underlying toolkit strings and wxString.
- New and improved wxFileCtrl (thanks to Google summer of code).
- Many enhancements to wxRichTextCtrl.
- Important improvements to several controls under wxGTK, including wxToolBar, wxStaticText, wxHyperlinkCtrl and others.
- Support for auto-completion in wxTextCtrl and wxComboBox.
62 comments:
Sounds great. I've got two questions:
- is wxString now std::string/std::wstring-based by default (in 2.8 there is a configure-option)?
- will there be support for cairo-based drawing?
1. No, this is still optional (wxUSE_STL) but wxString is interoperable with std::[w]string, i.e. you can implicitly convert between wxString and them
2. Yes, see wxGraphicsContext and related classes.
I wonder a bit about the decision of not changing the API much. The main criticism i read about wxWidgets is often its old-fashioned API that doesn't use modern C++ features. What does that mean, you're keeping the old style for another ten years? I personnaly would have thought that a major version change was the perfect time for some refactor (e.g. get rid of some macros and use templates, etc.)
Hello,
It's good to hear 3.x is 2.x compatible... :)
I'd rather have a backward compatible API rather than whole fresh API...
"use templates" has been stated in wxWidgets goal why is it not being used...
Peace :)
this project is great!
Concrats about the upcoming change. I use wxWidgets very intensively and (of course) have tracked the changes. It's worth a 3.0 for sure. Thanks a lot for all the work!
Is the ansi- and unicode-thing now merged in the current SVN?
How can I build it now? USE_UNICODE is not there?
I haven't used WXWindows yet, but improved Unicode support makes it sound even more attractive than it already does. I look forward to trying it out!
The number of inline functions needs to be reduced - compile time with gcc4 excels any orbit even for simple Hello World programs :-(
As for Unicode, this is wonderful news. UTF-8 is what normal people use, even for char*- I never got the idea why WX needs Unicode (except for interfacing with the UTF-16 Windows libs - but Windows, oh well, different story)
Question: Will this new wxWidgets look native on new Windows platforms? The current one does definitely not fit with the WPF.
>Question: Will this new wxWidgets >look native on new Windows >platforms? The current one does >definitely not fit with the WPF.
The current one looks perfectly native on Windows Vista. WPF is not the 'native' look on Vista.
Will wxDatagramSocket support BROADCASTing now?
Great news. I plan to use wxWidgets the beginning of next year. Hopefully version 3 will be out then.
I get the impression that more people are using wxWidgets. FileZilla was recently ported to it.
Thanks for the great work. I use Python/wxPython for development.
For future release I like to see some chanches related to xrc... maybe having something like ms xaml or xul.
Awesome news about UTF8 support... I'm starting a new project with wxWidgets. My biggest concern was the supposed lack of complete Unicode support...
This is an excellent development :) I'd still like to see my two biggest beefs with wx addressed though:
-A unified image type that's used everywhere. At the very least a documented wxRawBitmap.
-Documentation for every object of how it should be handled memory management wise.
I am really looking forward for the new version.
I would like to know any enhancement in wxGraphicsContext.Is it a good replacement for wxArt2d?
Question: will compiled with wxWindgets v3.0 application run on Windows 95 and Windows 98?
I mean on platform which does not support Unicode?
Or should user install additional DLL in order to enable Unicode support in this case?
>wxWindgets v3.0 application run on Windows 95 and Windows 98?
>I mean on platform which does not support Unicode?
>Or should user install additional DLL in order to enable Unicode support in this case?
See at www.wxwidgets.org/wiki/index.php/MSLU
I have compiled the mdi sample from 2.8.6 as unicode and with MSLU it run on Win98 (Win95 doesnt show the toolbar icons and statusbar)
Hello!
I have tried to compile my application with wxwidgets 3.0.
So far it seems to be working.
I have some problems with XRC-Resource Loading.
1) Colour attributes in the form #FFFFFF will currently not accepted by wxwidgets 3.0(which worked well in 2.8.7)
2) Some crashes while loading XRC-Resources (even sample-XRC Project crashes)
Anyway. wxWidgets is great! I am looking further to version 3.0.
I also embrace this Unicode rework and the other enhancements. But is this really all you did?
No cleaning up of the API? No Template support?
WxW is very slow and big, it takes ages to compile.
Oh and will there also be a new book soon on OReilly about V3? :)
wxWidgets totally rocks! I am definitely an amateur programmer and yet because of wxWidget's simplicity I was able to create IMHO a world class programmer's editor as my very first GUI project ever! See ZionEdit.org. Sorry don't I mean to advertise, but this just shows how EASY the toolkit is to use. I had previously toyed with GTK, Fox Toolkit and MFC, but except for the Fox Toolkit, they were all scary to jump into. Two years later, I don't want to use anything else, not even a scripting language, for any coding. Okay what I am saying is, you guys rock. You made a programmer out of me. Thank you, thank you, thank you!
It's always good to see great tools continuing to be developed so I welcome the news of wxWidgets 3.
BUT ... although I always welcome consistency and compatibility between versions, there are times when changes must be made that do break some backward compatibility -- and the release of a new major version is a good time to consider making such changes.
It is high time that the wx APIs were restyled to be within a wxWidgets namespace rather than having a wx prefix on every name. Namespaces are an important C++ feature that has great utility in preventing name clashes -- now is the time to embrace them. Don't leave it another 10 years!
Good news!
Can't wait for the 3.0 release... I think that I will finally abandon Zync Application Framework,.
What about a redesign of the threading classes. See this comment from VZ:
"...The design of wxCS/wxMutex classes is really bad and confusing and should be redone one of these days..."
I really love wxWidgets and use it (along with wxPython) on all of my projects which require GUI, but I think calling this a 3.0 is wrong.
I hate to be harsh way, but have some balls and make this a 3.0 release that deserves the number. The whole point of major number release *is to break compatibility*. If you don't its just a 2.9 masquerading as 3.0.
The very shallow arguments against using modern C++ (like the use templates...) listed above is non-sense. Its been many, many years since that was written. I think even boost supports more compilers then wxWidgets, and it does so using *every* modern C++ features possible.
Things I would like to see:
* wxUSE_STL on by default with better support, and possible dropping of non-STL container interfaces.
* Namespace usage wxFrame -> wx::Frame
* Use templates to eliminate the usage of macros in the event system
I also use wxWidgets a lot, with and without wxPython and consider it an excellent project. Good work!
But I also second to the opinions given above, the 3. release should really should use STL (possibly with boost), namespaces and templates.
The WTL (http://wtl.sourceforge.net/) project is a rather nice template-based wrapper around Win32 API, some conceptual ideas could be drawn from there for the Windows port. Also, the Dabo project (http://dabodev.com/) and the quite informed critique from one of its authors given in http://dabodev.com/pycon2007 (seek forward 5 minutes from start for wxWidgets-specific discussion) the should be considered. The main problems outlined are naming and consistency, there are too many widget-specific ways to do the same thing, e.g. set a text label of a widget (button: setLabel(), grid column: setColLabelValue(), menu: setTitle(), tree node: setItemText()), event handling should be simplified etc.
Alternatively, a 4. backwards-incompatible release with the goals set above should be started better sooner than later.
MODULARIZATION
It would be terrific if you could modularize wxWidgets, preferrably down to the widget/control level.
Even the simplest of applications is required to carry around way too much baggage and should only be required to take along the minimum necessary.
Perhaps have a core minimum-required library necessary for use by all widgets, then any additional widgets can be included as necessary.
This might be a bit of extra work up front for developers but it would greatly reduce the size (bloatware) of wxWidget applications.
Thanks!
I agree with many posters that mentioned the needed support for STL containers (and algorithms) and namespaces. I would also add exceptions. After working with Java and going back to C++, I don't feel at all like checking the return value of every function call, really!
That sounds great! But I've got a question:
Will the wxRichTextCtrl be able to paste images and styles i.e. from Word, Firefox...?
I agree with all of the above. Gj. A bit more face lift and you could bring it to this millennia. After that how about calling it wx::Widgets? :^)
wxDFB - I am very excited about this.
I am unhappy about forcing unicode as underlying method, forces bloatware, doubling of memory used and extra conversions (would prefer to have option of instead going 8 bit, [or perhaps utf-8 if fast enough] ).
(extra comment to add to last one, it does make a BIG difference when you are doing database like work in RAM rather than disk files to have size and efficiency of strings twice as bad)
Great project!
Thanks for sharing.
Regards,
Drumms.
Another vote for namespaces, templates and stl
kim123wxwidget is suppose to be portable,common elements for all platforms. WTL wont run on Linux, if you want STL. include the headers and start programming for it.I like UTF but windows and global markets is forcing Unicode.
exceptions handling may be platform dependent.
it almost impossible to make templates, exception handling to compile and run on Windows,Linux,Unix,max and others.
besides wxwidgets is for GUI
I also believe that wxWidgets should use namespaces and templates, instead of those stupid old macros. Exception handling would also be nice, but that is not really needed, and they can give problems in some systems.
Those who need backward-compatibility can just use the 2.x branch.
Think about it, and make a toolkit ready for the new millennium! :)
(oh, and dropping those custom containers and using STL would also be good)
..great product. As a novice-grasshopper-beginner wxWidgets/c++ programmer, though, I would like to have available more basic/fundamental wxWidgets examples to relieve my syntax headaches. However, "we" are progressing and have come a long way...
Great work - onward !
jb
I'm looking forward to the unicode feature, but I'd join the criticism that this is rather a 2.9 than a 3.0 version.
What annoyed me most is the excessive use of macros, especially for event handlers and creating containers!
Getting rid of these macros and the use of templates I'd consider essential for a 3.0 version.
I have admired wxWidgets / wxPython for a long time. I would like to echo the many comments about using modern C++/STL/Boost. We took a hard decision to do that in some internal projects years ago and I have not regretted it.
Assuming that you consider more standard containers and Boost. Then I would also strongly consider Boost::Python for a far richer and better performing binding to Python. It is far slicker and more integrated than SWIG in my opinion.
wxGuys are avoiding STL for a good reason. STL is a major drag on C++ in my opinion. I would greatly appreciate Smart and Zeitlin designing their own 'WX Template Library' now when templates are finally well supported. It would surely be smarter and better designed, no doubt, I still much admire all the clever stuff that goes into that wx macro stuff, from the visual standpoint I still prefer Add(), Count(), to push_back() size() etc. I always thought STL was a default/basic library example not a paradigm.
The UNICODE/ANSI merging based on UNICODE is a move I did a long ago, its the only right conclusion.
Cheerz and party on WX.
Sorry my English is not very well.
I cooperate with one French firm.
This firm is programing to same international firm and they have got problems with Unicode. They programing in Delphi.
In Windows all no Unicode function call a function to convert all char* parameters to wchar_t* with current system codepage. After this no Unicode function call its Unicode version.
For example: when employee (from international firm) go to from Czech to French he want view his work in French but hi must change you system code page to view valid data without any border char.
Next example: I get no Unicode program from net. This program is in version: Norwegian, Russian, German. I from Poland and i view it Russian. But I do not view it OK. I must change system code page.
I like wxWidgets with Unicode but I do not like it without.
I don't think templates is a much needid thing for a UI framework. Simple C++ is enough good, there is no reason to change to a "more modern" (= more complex without any good reason) model. (I like templates and their power, but why to use them if you can solve a problem without them?)
Some warnings from the Intype guys:
http://intype.info/forums/discussion/620/new-unstable-release/
"It’s not that SmartWin itself is a bad toolkit, it just don’t fit Intype’s needs for the UI anymore. Due to it’s C++ template architecture, the compile time was too demanding. Compiling SW required like 1GB of RAM, and took like 10 minutes to build whole release. The new framework is based on good old school with simple dependencies, is much more powerful for building custom widgets and it cost us like 1 minute to recompile whole project."
I only wish you would take this opportunity to develop a wxQt port, preferably as a binary compatible drop-in replacement for wxGTK. At the moment, wxWidgets developers are using wx because it provides a native look on many platforms, but KDE, used by over 50% of Gnu/Linux, and even more *bsd users, is getting a non-native look. even if we use gtk-qt engine for the widget style, the file dialogs are still completely different, one of the most iportant places for a platform to have consistency. A wxQT port would be great for cross-desktop consistency in free software. And if licensing is a problem, two points:
1> Since QT is now available for all platforms under the GPL, why not just release wxQT as GPL. If, when they build the program, the proprietary software dev uses wxGTK, he'd be compliant with it's license, since he is not
2> When you can make wxWIN32 for a completely non-free API, what trouble is there exactly with a port for Qt.
For the case of an app which uses many strings of one encoding, this 3.0 change is not good. I've got the case of russian encoding. The app will require twice memory now. Sad. Please support at least wxString to char* and to wchar_t* and back conversions. Seems like there will be no choice to escape from unicode.
but wxWidgets itself is great, no doubt.
If wxString is being overhauled a bit it would be nice if the "smart" pointers associated with wxStrings were more thread safe. wxStrings are wonderful to work with except when multiple threads are involved.
Better yet - replace the smart pointers with boost smart pointer (or at least pattern after them).
They ARE thread safe - without the need for critical sections or mutex's.
For those of you who are whining for templates need to do research. They're not that great and are a complete bitch to debug. Macros on the other hand are far easier to deal with and aren't frustrating to debug.
Exception handling isn't practical for wxWidgets because of the frameworks it works with such as wxGTK of which is pure C.
Unicode is a good thing to move on to support by default and using UTF-8 (most likely doing special UTF-16 handling specifically for Windows unicode support) because everybody wants to support more than Latin characters in their software and this just makes it easier for both wxWidgets developers and their users. And no unicode doesn't automatically mean twice memory used, that's yet another myth just like those who believe 64bit means twice memory used of which only applies to pointers and not data memory usage. Now UTF-16 uses at least two bytes per character, but UTF-16 so far is specifically used only on Windows for unicode (because wide character unicode is the only unicode supported on Windows).
Now I read somebody complaining about wxMutex and such, apparently you've never done any embedded hardware development else you would know better. wxMutex is perfectly fine and it does exactly what it is suppose to do. If you want anything more fancier then use pthreads API instead.
About wxString not being thread safe.... It isn't suppose to be thread safe, that is your job and responsibility by using wxMutex or other mutex means. Because wxString is just like any other memory resource like int, char, etc... if you have more than one thread accessing it at once then you must lock and release it to prevent corruption or other race conditions. Please use common sense.
For those of who want to use STL and boost related algorithms and what not. Why don't you just go and use them yourself instead of wanting wxWidgets to become even more bloated? I refer to my earlier comment: Please use common sense. Nobody is forcing you to not use STL or boost, instead you can still use it on your own. That's what makes the world of C/C++ great because the language gives you the ability to do pretty much anything you want to and it is extremely flexible. Just make use of it.
Enough of my rants about others comments, it just bothers me the way people think and want a particular framework to mimic all the wrongs other frameworks have done.
I completely agree with the v3.0 changes and outlook, really good decision making for not having unnecessary changes being done to the framework. Really good work. I thank you! :)
"For those of you who are whining for templates need to do research. They're not that great and are a complete bitch to debug. Macros on the other hand are far easier to deal with and aren't frustrating to debug."
I don't even know how to respond to that.
I am use wxWidjets. Its wery useful SDK, but I cant work with text in*.rtf formats and not always useful HTTP work (particularly when need ulod files by HTTP in unicode assemblage of wxWidjets). Also not useful work with scanner (off-site conponent wxIA not work in unicode mode without change src), wxPNGHandler not use all facilities of png lib (nan't change number of colors), wxQtMediaBeckend not full implemented by Window.
I like this library. Thanks to wxWidgets I dont must write many diferent code. Thank you for you library.
nice post
It looks fine, but unfortunately
you do not support any database
connectivity at all. All of my
applications need database (MySql + Firebird), so how can I do it with WxWidgets ???
You can use just about any other database library together with wxWidgets, e.g. see this thread for some possibilities.
Is it possible to download a current snapshot to test it?
The {new version} changes above look good. (I don't want to get into the whole 2.9 vs 3.0 debate - it's a distraction)
For all those above who are worried about being 'forced' to go unicode and the perceived 'memory bloatware' / doubling etc - then (reading between the lines)wxString will be utf-8 internally, so if using us-ascii there will be no memory increase - and a proportional increase of up to 4 (well 6 sometimes) bytes per char depending on the nationality of the script you are parsing - but also remember if it's xml a lot of the chars are tags (us-ascii) rather than content so the increase in size will not be nearly as noticable.
... and for the person that said "I like UTF but windows and global markets is forcing Unicode." - time for some Googling to get a better understanding of what both those terms mean ! (and your starter for 10 is that UTF is a series of encoding standards for unicode code points - how many varieties of UTF are there ? - for an additional bonus - how many of those are fixed length and variable length - and for a further bonus explain the concept of surrogates !)
First excuse me for my bad english ! I think that for me the only thing missed (intentionaly)in wxWidget is themes support (like Qt & Gtk) wich is very important in modern gui application. Is there any theme support in 3.0 version of wxWidget ??
Well, I hope that the developers of wxWidgets 3 would also be concerned about bloated statically linked executables. Many developers prefer static linking because of easier deployment of their applications without the need for any dynamic runtime libraries. For many years, the development team of wxWidgets doesn't seem interested to resolve this issue.
For new features to be added in this new release, it would be nice to include one which prevents bloated statically linked executables.
Using UPX or any packing utilities is not an excellent choice either. Every time the application is loaded, there is a delay in starting up because it needs to unpack itself first which is causing the delay.
Well, I hope that the developers of wxWidgets 3 would also be concerned about bloated statically linked executables. Many developers prefer static linking because of easier deployment of their applications without the need for any dynamic runtime libraries. For many years, the development team of wxWidgets doesn't seem interested to resolve this issue.
For new features to be added in this new release, it would be nice to include one which prevents bloated statically linked executables.
Using UPX or any packing utilities is not an excellent choice either. Every time the application is loaded, there is a delay in starting up because it needs to unpack itself first which is causing the delay.
Post a Comment