A GUI library huh? Last I checked, wxWidgets wasn't really a gui library. Sure, it has a gui api. But it also has wxSocket, wxFTP, wxHTTP, wxDB, streams, file systems, logging stuff, wxDebugReport, wxStackWalker, and a myriad of other bloat which has nothing to do with GUI. This bloat is adding additional strain on the maintainance of this project which is already bad enough. wxWidgets is not just a GUI library, its an entire application development suite, full of implementations of everything including the kitchen sink which aren't as good as the implementations provided by other libraries deticated to a particular purpose. Compare wxSocket vs Asio. libcurl vs wxFTP, wxHTTP, wxURL, and co. Why is there a need for these things in wxWidgets? Surely it cannot be licensing issues, as libcurl uses MIT/X license, and asio uses the boost license, both of which are "just as free" as the wxWindows license when compared to GPL. I can't think of a good reason why any of these things should be in a GUI library.ABX wrote:Well, let me tell you some other story: since more than ten years there are well known two open sourced multiplatform C++ GUI libraries with large code base
You forgot a few things...1) API is not easy to use
2) templates and namespaces are not used
3) own solutions are used instead of reusing things like boost
4) ports are in different states of implementation and has different interface
5)binary backward compatibility is not supported
1. Fundamtenal API design flaws
It is obvious to anyone who actually looks at the wWidgets API in any sort of detail that the majority of it was copied directly out of the windows api, at least in my biased opinion with windows programming background.
Case in point number 1: Ascii and Unicode builds. These still exist, and the only reason they existed at all was because Windows did it like this. Not only are ansi builds completely pointless in a modern environment, they create incredible maintainance overhead as both ascii and unicode versions of the library must be tested, compiled, and maintained. Add onto this static and dynamic builds, and this is already 4 copies of the library that must be maintained instead of two (static vs dynamic).
Point 2: wxListCtrl anyone? This control is only native on windows as the API was more or less copied directly from windows. Will this control ever be fixed? Of course not. Why? For the same reason none of the other cruft has ever been removed from the library: source compatability back to versions of the library that were in use 5 years ago. This control obviously has a horrible API and is in need of fixing, but nobody will allow it to be fixed.
Point 3: wxHSCROLL and wxVSCROLL styles for wxWindow. Only MSW can do this natively, yet these styles still exist, even in the presence of wxScrolledWindow. Surely it is easy to see how much of a pain it would be for any port other than MSW to implement obviously non native features like these.
2. Refusal to fix that which is obviously broken
I'm looking at you (again) wxListCtrl. Will this ever be changed?
3. Living in the past (Or, C-with-classes)
The insistance of supporting compilers that are over 10 years old has certain negative side effects on the library itself. Any code that remotely resembles modern C++ cannot be used because some ancient compiler doesn't support it (case in point: msvc5 and namespaces.) This happens to prevent namespaces, and anything from the C++ Standard Library from being employed.
Macros to define dynamic arrays? wxString? Lets wake up and smell the C++98.
4. Implementation flaws
Focus handling on wxGTK? Yeah, I'll leave it to M.R. to try to sort through that mess.
I could point it out all I like, but it wouldn't do much good. Any attempts to change an API to make it better would be hampered by the whole "we must support ancient compilers and code written for wx 2.0" attitude and ultimately be futile. See point 3 above.ad 1) point where API is not easy
I had considered proposing my ideas developed for OMGUI towards wxTNG, but I have not done so to date. What I know about wxTNG is that it will be based off of wx2, and as such doesn't really change or fix anything. This was from a very old discussion that I am remembering so things might have changed.ad 2) participate discussion and development of wxTNG (wxWidgets The Next Generation aka 3.0 based on modern C++)
I do not consider adding a "better" API which wraps an existing crummy API while keeping the implementation of the crummy API and possibly having the crummy API hurting the implementation of the new API to be fixing the API. Thats essentially what wxTNG is, isn't it? Something that builds off of wx2 and will suffer from everything that plagues wx2.
And what exactly would this do?ad 3) provide boost wrappers within wxCode for some wxWidgets components to easy transition
The design of wxWidgets lends itself to being binarily incompatible. The pimpl idiom is not employed which is really the only thing that could be done to enable binary compatability in C++ without restricting code changes too much. Adding pimpl is essentially a complete rewrite and as such would never happen.ad 5) point binary compatibility problems (which is supposed to work with 2.6.X AFAIK)
The wxWidgets codebase is so large and bloated at this point, and the changes I feel necessary to the API and its design to make it a "good" GUI library would entail so much work that I believed it was simply better to start over. Seriously, consider how much code needs to be changed if we were to completely remove wxArray and co and replace them with std::foo equivilants. No, I do not mean simply enabling wxUSE_STD or whatever the configuration option is called. I mean a true purge and updating of internal code to use iterators. I can gaurentee you that nobody on the development team wants to take the time to actually change all of that stuff, let alone add pimpl, clean up all of the implementation, remove the bandaid fixes and hacks, or fix the API. Quite frankly, I don't either. I am much happier with a clean slate, and that is what I have made for myself with OMGUI.
I could add a few more things here, like the not-so-friendly discussions on wx-dev, failing to meet deadlines, failure to even have a real roadmap, embarassing things being comitted into the trunk without much thought (inlined reserved virtuals for binary compat? hah!), but I believe I have made my point. I may be a hypocrite, but this is what I think about wx.