Why I don't like wxWidgets.

[SnakeChomp]

ABX: Since you asked for it...

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

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.

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

You forgot a few things...

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.

ad 1) point where API is not easy

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 2) participate discussion and development of wxTNG (wxWidgets The Next Generation aka 3.0 based on modern C++)

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.

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.

ad 3) provide boost wrappers within wxCode for some wxWidgets components to easy transition

And what exactly would this do?

ad 5) point binary compatibility problems (which is supposed to work with 2.6.X AFAIK)

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.

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.

[ABX]

ABX: Since you asked for it...

Hmm, did I? I said "...ask them. I do not have need for it."

(Let me excuse first if I used below any strong word or inappropriate term, I still use some english words in wrong context not seeing this. Any offense was not my intention.)

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

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.

You could probably write hundreds of posts about how bad it is, but where are the posts by you how to improve this? As you know the text you quoted was in context of wxAUI not helping you to improve wxIFM. Keep the context which forced me to raise this story. Where are all the posts you send with ideas how to improve wxWidgets you send before decision about new toolkit creations. Mart is doing great work supporting wxGTK and wxWidgets regardles his opinions and that's what I find very wise: keep having ideas and improvements but also keep understand reality with its limitations.

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?

AFAIR because they were designed and created at the time other solutions were not available/sufficient/stable/known/licence-acceptable. Feel free to put some own wrappers to these toolkits and put them in wxCode or elsewhere.

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

You forgot a few things...

No, I didn't. I just listed points from OMGUI FAQ.

These still exist, and the only reason they existed at all was because Windows did it like this.

Feel free to participate wxTNG discussion in wx-discuss or wx-dev. For existing releases we still keep Windows supported as one of major platforms and Microsoft tools are quite widely used.

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?

Sorry, I'm really not familar with wxListCtrl problems (I don't use it in fact at all). Could you point me bug reports your refer? Or patches with improvements? Or past threads which could give me more background?

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.

I currently work on project which heavily use STL, has templated frames derived from doc architecture and lots of other goodies. And base completly on wxWidgets. Moreover there are places within wxWidgets CVS code where templates and namesapace are used internally. I don't know if VC5 is still supported for current CVS, I guess not. In other place you mention backward compatibility not supported, would introduction of namespaces and lots of templates help to keep backward compatibility between 2.6.2 and 2.6.3?

ad 1) point where API is not easy

I could point it out all I like, but it wouldn't do much good.

If you would do it in form of patches than it would be only good. The method is quite simple: is some api not easy in wxW2.2? Let's add alternative api in 2.4 and make previous deprecated and then let's remove old api in 2.6 and keep only better since now. Is it that much complicated? Of course without problems expressed earlier and patches delivered we can't do much for you

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.

I do not know what are you talking about and why you blow it out of proportion. There must be lots of irritation in you which you was unable to express earlier. For current CVS we have 2.4 support turned off but optional, and 2.6 support turned on but optional too. So... ?

ad 2) participate discussion and development of wxTNG (wxWidgets The Next Generation aka 3.0 based on modern C++)

I had considered proposing my ideas developed for OMGUI towards wxTNG, but I have not done so to date.

Hmmm, let me get it right, you had enough time to start OMGUI, create its website, write its initial source, do builds etc. etc. but... had no time to express your problems before this post so you created OMGUI because wxWidgets does not follow your not expressed wishes? I'm affraid I do not understand all of it. There seems some problem with methodology or I miss some of your past discussions.

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.

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?

I do not plan to use wxForum as a place to discuss wxTNG. The intention of creating wx-discuss was to keep discussions there and wx-dev to have technical discusions. Feel free to express your doubts and fears in any of them with some propositions what should/should't be done. I suppose with your irritation you will raise some serious fights but it's still better to have overview of opinions.

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.

Thanks, I appreciate you expressed all of this though I think you should do it long time ago, split into separated issues and partially replaced by actions with patches. I also believe you are talking about some other reality which is clean room with empty community of users who needs current support with current compilers on current platforms. Just like you pointed out to wxAUI: "It is clear to me that you have many more resources than I do to be able to come up with this system in far less time than it has taken (wxWidgets) to do so." So if you think you can do it all better with OMGUI rather than help wxWidgets to improve current and future state then feel free. I don't really mind and wish you good. If you will come with better library I will switch and will send you a letter (again) quoting you from wxAUI discussion: "You probably have a team of payed coders on this project, which would explain its rapid development and professional appearance."

Best regards,

ABX

[upCASE]

Hi!
Thanks for proving my point when saying that sometimes existing things just doesn't suit your needs, so you start another project. IHMO that's the case with OMGUI. Apparently you don't want to contribute to wxWidgets, but create something new instead.

A GUI library huh? Last I checked, wxWidgets wasn't really a gui library. Sure, it has a gui api.

Hmm...
I know what you mean, but this applies to many other toolkits out there, too. I guess that why multilib builds where introduced.
But: The main purpose and why wxWidgets was started in the first place is to serve as an x-platform GUI toolkit. And it does. Adding all the other classes was done for user convenience, as they didn't want to leave the framework.

The problem I see with this "discussion" is that this is no real criticism. Criticism for me is not only saying what you don't like, but giving a solution or at least a new idea, too.

Nobody wants to offend you. Nobody wants to talk wxIFM down. The responses you got were positive, people appreciate your work. But it seems to me like you don't appreciate the work of others. What do you expect? Most users want an easy way to do x-platform programming, but you want x-platform programming that works "your way".

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.

wxWidgets itself has more than 10 years on its back. wxTNG should use new features and deprecate others, true. But you expect the whole API and underlying code to change. Don't you think that with a code base this large, this would be a bit over the top, plus breaking existing code in many places?
The good thing for you in development of OMGUIi is, that you start now. Let's have a look at it when it is finished, wait 10 years and see what features are missing then...

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.

So, what's your proposal? Leave out anything that is not supported by all platforms?

Although I know that this may lead to further "discussion", I have to say that I don't like your attitude in this case. What's the point in posting here and tellings us that in the end wxWidgets is just a piece of crap with a hell lot of design flaws and unneeded features? I don't get it...

Personaly I worked with other toolkits, too. MFC, Qt, etc. For me wxWidgets is the best of them, but I'd never go so far to talk the others down. There are things I dislike about them and that I would like to see changed if I would choose them to work with, but that's only MY point of view and things won't change just becasue I want it. Sometimes you just have to accept the things that you can't change, sometimes it's good to change the things you can't accept.

Please excuse that english is not my mothertongue and that I lack some words and expressions to express my opinion properly. This whole "discussion" reminds me of current "discussions" in my country about politics. In the end, you can't change anything, but you should never stop trying.
In no way do I mean to offend you, scare you away or start a "personal" fight with you. If it sounds like that, sorry.

[Jorg]

I do not want to contribute to the feature and incompleteness war here. But I do compare wxWidgets to a heavy loaded ship sailing a certain course that is ever so hard to change when the ship gets more heavy (both with users and functionality), it also is surpassed by other technology that once was new and expirimental, and now becomes the next generation way of doing things.

So much for the metafor. Let's just put personal visions aside and look a bit broader.

I see .NET, I see paradigm changes, I see new ways of developing code where the datamodelling becomes more important then the functionality, a lot of things are done automated, made transparent, etc.

My main concern with C++ in general, and wxWidgets specifically, is that in future development, it will simply no longer cut it. I use if for one main reason only. cross platform development. I always felt that as one of the key elements, freedom of choice in OS and platform. If there is a .NET language that is just as good as wxWidgets and also x-platform, I will choose that instead. I rather not because I grown to like this community and put some of my own effort in it too, so I rather see it evolve.

Anyway, .NET is emerging. Managed C++ is the future, your own choice of language that can mix and mangle with any other .NET language, is the future. I observe the MONO project with great interest, because I hope one day it is easy to develop a .NET application and share it across platforms. My boss is pushing me towards the .NET language, where I will have to learn C#. Ok, it is similar to C++, but I rather stick to one language and become more professional using it.

Until xplatform .NET is a fact, I will stick to wxWidgets, but I also have the idea it is becoming too bloated, and still sticks to too old code concepts, uses macros too much and is still more difficult then it could be. I really think the documentation needs to be updated more regulary, and embedded in the code so it won't lead it's own life and is more manageable. I have in the past donated some ideas, or questions of why it was not done like this, but like that. Usually the answers were short, not helpful, or I received only answers from people who agreed with me. Ofcourse I know it is a large and complex code base. And ofcourse I can submit patches, but unfortunately I do not have the time for that, and I found my strongest capabilities were more on the level of being an architect and a thinker, then someone who actually codes it (I have numerous ideas, but too little time to realise them).

Anyway, I am concerned too about wxWidgets. I agree with SnakeChomp with most of his points. I also dislike wxListCtrl API as it is a monster. wxListView was realised to make it easier, but that is only a facade. The real monster is still inside. There are very modern templating concepts like signals, the whole std:: lib, etc. I know hard work is done there to implement it, but the level of keeping things binary compatible or API stable is simply rediculous. I would introduce two versions of wx at this point. A wx version that follows the course of modern implementation, and one that keeps things compatible. The new wx (wxTNG or wx3.0 or whatever) should literally start over by copying base classes to the new branch, strip them down or even rewrite parts (now this is one branch I would like to participate in). The old branch can be kept also for new functionality as long as it is not too much change.

The new branch people can expect changes and API changes that are drastic, without much prepect for keeping it backward compatible, the old branch will do this. The result you get is one very slim and technologically advanced wxWidgets API which keeps track of the latest developments in templating, paradigms, GUI design and more, and one branch that is kept as a backward source tree for people that need to support old code.

I strongly feel that a complete overhoul is needed, and even mandatory once every so many years or so. Sticking with too much old code makes it impossible to keep up with the modern compiler techniques, possibilities and even other languages.

As I do understand SnakeChomp's personal reasons to start a new toolkit (and me too will switch if he succeeds and it is very usable), I still believe in wxWidgets, but it needs to change course faster then it's doing right now.

My 2ct's

- Jorgen

[ABX]

I still believe in wxWidgets, but it needs to change course faster then it's doing right now.

I really want to turn this thread to valuable input but I will not take responsibility to keep all other developers informed. I encourage anybody who wants to contribute any further to post in to wx-dev (with exact code changes) or wx-discuss (with just ideas, dreams and suggestions). Thanks in advance. I'm looking forward to new productive threads there.

Thanks in advance,

ABX

[upCASE]

As I do understand SnakeChomp's personal reasons to start a new toolkit (and me too will switch if he succeeds and it is very usable), I still believe in wxWidgets, but it needs to change course faster then it's doing right now.

Good summary.
Then again we're at the point "it is open source". Now, if there is a precise summary of what changes have to be done and what code needs changing, instead of a very rough roadmap, I'd be happy to spend some time and do my very best to take wxWidgets to a new level.

Maybe this will fail, time will tell. The future I see is bloated with Bytecode languages. I personally don't think this is a good way to go, but we won't have a choice. Maybe it's just me being to slow to adapt...

Anyway: There's a lot potential in wxWidgets. And a lot of work. I think the best would be to have a new developer corner of some kind with at least the info I stated above. Neither this forum, nor the mailing list seems to be a good and accepted place for that.

[ABX]

Neither this forum, nor the mailing list seems to be a good and accepted place for that.

I don't really understand "accepted" word regarding mailing lists. Quoting http://www.wxwidgets.org/maillst2.htm:

Developers' list
A higher-bandwidth list for people involved in the development of wxWidgets. This is for technical discussion only.

Discussion list
A list for people to discuss the wxWidgets project, its future, etc. This is not for technical discussions.

Anyway if lists (with wx-dev accessible from gmane interfaces without subscribing) are not good, all the notes can be probably typed somewhere into http://wiki.wxwidgets.org/wiki.pl?Developers_Notebook

HTH,

ABX

[buildere]

Maybe this will fail, time will tell. The future I see is bloated with Bytecode languages. I personally don't think this is a good way to go, but we won't have a choice. Maybe it's just me being to slow to adapt...

In my opinion the way to go is "use the right tool for the job". Managed languages will drive most of the coding scene, but if you want certain things (faster-multiplatform code, no need to redistribute a runtime, etc), wxWidgets is the way to go. From that perspective, I see this toolkit healthy for the next 15 or 20 years; more than enough time to make it seem worth the effort supporting it.

[buildere]

The good thing for you in development of OMGUIi is, that you start now. Let's have a look at it when it is finished, wait 10 years and see what features are missing then...

Just add "OSS project + succesful + big + time" and you'll get "= bloated", no matter what. It is just that there are too many people from too different realities that mostly doesn't even know each other at all, triyng their best to make agreements, etc. Just take a look at how messy OpenOffice is becoming .... my point is, no matter how "correct" you try to be when you design your code in the begining, after some years there will be requirements that you couldn't predict and will need a solution in your code that is not as elegant as you may implemented if you were starting over again from scratch. Add tons of people from all over the world mantaining the big source tree your project has become (because anyway, you can't maintain a project this size alone anymore) and I warranty you your code will look just as bad as SnakeChomp say wxWidgets looks right now.

[Jorg]

ABX and others,

I was simply expressing my opinion. I have the feeling discussing this on wx-dev or wx-discuss will not do any good. It will result in a few opinions back and forth and it will die out eventually, and then we all will go on our merry way just the way we all were before this discussion..

I just wanted to give my opinion, please do not feel that you have to be the advocate of this towards the wxWidgets group

Regards,
- Jorgen

[phlox81]

Hm, this disscussion is funny

Most Projects, who aren't led by a single Person, and
not are forced due deadlines have those Problems.

And whats the point anyways, about an old library beeing old ?
There might be a lot of fancy stuff out there, but
not everything that is new, is good. Most of the stuff still
has to prove what it can do in the wild, in productive environments.
The point is, do I need a signal & slot Mechanism for example,
to click on a button ?
In fact, a customer won't understand it, why its something new,
and fancy, and has advantages, the click on the button is still the same...

So, there still some good reasons, to stick to the old and known way
of doing things, and still, new things need to improve the lib where they
can. wxTNG is a good stepstone there.

And a note to wxSocket vs. asio

Asio is a neat Library, but actually when writing Software, I wouldn't
choose it right now. Its good looking, that it will be taken into boost,
but it is also very young. 2 Month ago, I had a project, which is connecting
through a socket to Device on network. I looked at asio, and at wxSocket,
and my decision was for wxSocket, because it is much better documented,
and has proven its realibility. The Stable Version of asio, has almost no
documention, its showing only how to use timers...
And even if asio is one day is perfect, you still can choose to use it,
no one has to take wxSocket, its a free decision.

phlox

[SnakeChomp]

These still exist, and the only reason they existed at all was because Windows did it like this.

Feel free to participate wxTNG discussion in wx-discuss or wx-dev. For existing releases we still keep Windows supported as one of major platforms and Microsoft tools are quite widely used.

The reason I say this is because all modern versions of Windows are 100% unicode internally. The ascii functions convert the text to unicode before doing stuff with it, and then convert it back to ascii before giving it to the ascii application. The modern world uses unicode, and it uses unicode everywhere. There is no reason that an ascii build should still exist. Unicode should always be "on". What could be configured instead is the type of unicode to use. Internally represent things using UTF16 on windows or UTF8 on gtk, for example. This would save wxGTK from the conversions that currently plague it in unicode builds. There is some headway towards this as suggested by vadim, but he wants to keep ascii builds and add another utf8 build, which is laughable IMO. Keeping the ascii build really serves no purpose.

There is no argument for keeping the ascii build to support 95/95/ME because of unicows.dll as well as a Microsoft Layer for Unicode which is available to support unicode applications on these platforms.

I currently work on project which heavily use STL, has templated frames derived from doc architecture and lots of other goodies. And base completly on wxWidgets.

Thats good, but wxWidgets itself isn't using any of those nice features is it?

Moreover there are places within wxWidgets CVS code where templates and namesapace are used internally.

I saw this at one point to. It was a templated helper function to declare a Windows API structure and initialize it to 0. This hardly qualifies as "modern C++".

I don't know if VC5 is still supported for current CVS, I guess not. In other place you mention backward compatibility not supported, would introduction of namespaces and lots of templates help to keep backward compatibility between 2.6.2 and 2.6.3?

Obviously adding namespaces would not be done inbetween 2.6.2 and 2.6.3.

If you would do it in form of patches than it would be only good. The method is quite simple: is some api not easy in wxW2.2? Let's add alternative api in 2.4 and make previous deprecated and then let's remove old api in 2.6 and keep only better since now. Is it that much complicated? Of course without problems expressed earlier and patches delivered we can't do much for you

One change that I would propose would be using initializer objects to pass to constructors instead of large argument lists, ala wxSizerFlags which I believe uses the initializer class idiom. However, making such a change requires an unbelievable amount of work from me to implement the new stuff in a way that coexists with the old method. Do I want to spend all of my time doing this? No, I don't, because it doesn't fix any of the rest of the problems.

Hmmm, let me get it right, you had enough time to start OMGUI, create its website, write its initial source, do builds etc. etc. but... had no time to express your problems before this post so you created OMGUI because wxWidgets does not follow your not expressed wishes? I'm affraid I do not understand all of it. There seems some problem with methodology or I miss some of your past discussions.

You are right. I did not try to express my feelings about the state of the wxWidgets API to the developers before starting OMGUI. Was this a mistake on my part? I don't think so, as I honestly don't believe that the changes I would have proposed would have been accepted. Maybe they would have been, i don't know. Having done what I have on OMGUI I am in a better position to discuss the features I was considering because I have proven them to work. Its not just a theory if its already implemented and functioning.

[SnakeChomp]

wxWidgets itself has more than 10 years on its back. wxTNG should use new features and deprecate others, true. But you expect the whole API and underlying code to change. Don't you think that with a code base this large, this would be a bit over the top, plus breaking existing code in many places?

This is why I started OMGUI. It would have taken more time to try to re-write wxWidgets which would break a large portion of source compatability anyway than it would have to simply start fresh.

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.

So, what's your proposal? Leave out anything that is not supported by all platforms?

My proposal is to remove wxHSCROLL and wxVSCROLL. They serve no purpose because wxScrolledWindow exists, and only serve to cause implementational headaches for platforms which aren't Windows. This particular case is not an example of a feature which is not supported on all platforms. Its an example of inheriting too much from the Windows API. All platforms can have scrollable windows, but not all of them use HSCROLL and VSCROLL styles on an arbitrary window to achieve it. wxScrolledWindow was created for this reason, and that is a good thing. These two styles are simply leftovers from before wxScrolledWindow which haven't been removed yet. It is my opinion that they havent been removed because it would break source compatability with some old wxWidgets version (I don't know when these styles first appeared). I don't like decisions like these, ones that favor supporting old code instead of fixing obvious flaws.

Personaly I worked with other toolkits, too. MFC, Qt, etc. For me wxWidgets is the best of them, but I'd never go so far to talk the others down. There are things I dislike about them and that I would like to see changed if I would choose them to work with, but that's only MY point of view and things won't change just becasue I want it. Sometimes you just have to accept the things that you can't change, sometimes it's good to change the things you can't accept.

I also share your opinion that wxWidgets is the best of what is currently available. I still suggest wxWidgets to people who need cross paltform GUI kits. I do this knowing that I dislike its design. It is my belief that I will be unable to fully change wxWidgets to correct all of the problems I see with it, and that is what drove me to start OMGUI.

[upCASE]

I also share your opinion that wxWidgets is the best of what is currently available. I still suggest wxWidgets to people who need cross paltform GUI kits. I do this knowing that I dislike its design. It is my belief that I will be unable to fully change wxWidgets to correct all of the problems I see with it, and that is what drove me to start OMGUI.

So we're on the same "level" after all
Honestly, you're right that you wont be able to change wxWidgets. Be "we" could. The problem I see and mentioned above, is that there would have to be a new developers corner. The things that should be changed (not adding new features) would have to be properly listed like in a bug tracker. A timeline would have to be set.
The problem on my side (even with my personal projects) is, that I allways lack time. I've got a job and family. I'd be happy to spend some time on changing wxWidgets, but I'd require to know the "goals". Currently these are to "blurry" for me to simply start working on it.

My proposal would be to have another (l ets say 2.8 ) version release, then do a development freeze and not add new features or fix bugs. Instead, concentrate on the changes that would have to be made to polish the API and underlying code. Maybe when finished, make this version 3 and start work on bug fixing again. I don't see an alternative as working on releases like it is done now leaves no room for these "big" changes.

[mispunt]

Honestly, you're right that you wont be able to change wxWidgets. Be "we" could. The problem I see and mentioned above, is that there would have to be a new developers corner. The things that should be changed (not adding new features) would have to be properly listed like in a bug tracker. A timeline would have to be set
The problem on my side (even with my personal projects) is, that I allways lack time. I've got a job and family. I'd be happy to spend some time on changing wxWidgets, but I'd require to know the "goals". Currently these are to "blurry" for me to simply start working on it.

I think this is a good idea, I have also the problem that I can't find what should be done (as an outsider) so the only way a newcommer could participate is to write bugfixes... That is important of course, but as said before, it doesn't solve the problem. And I think most people have the same lack of time. I also have (although in januari I have to studie again )

My proposal would be to have another (l ets say 2.8 ) version release, then do a development freeze and not add new features or fix bugs. Instead, concentrate on the changes that would have to be made to polish the API and underlying code. Maybe when finished, make this version 3 and start work on bug fixing again. I don't see an alternative as working on releases like it is done now leaves no room for these "big" changes.

I think this is a good idea. But what do the (other) developers say?

When this is done, than it is possible to avoid the same problem of having old code. Developers should look to old code from time to time. Sometimes people find another (better) way to write some function, then do it. You have to do that to get wxWidgets better and better.

(hmm. I see that my english is not always correct, so I hope you can understand me well enough )