Why I don't like wxWidgets.

Post by **upCASE** » Thu Dec 22, 2005 8:20 am

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

I guess none of them except ABX has read this discussion so far, as I suppose most of them don't visit here, but use the mailing list instead. Which again proves my point in some way: There's a missing link between them.
Normaly the forum is used mostly by users, not by devs. I do read the mailing list from time to time, but i'm not subscribed, nor do I post there. For me it's a personal thing as I like forums better. That's the reason I suggested a new developers corner, where one could have all the info, maybe with a little wiki or forum of its own. The actual assignment of tasks to be done could be carried out by using a tracker like we have fo this forum. It should not be done IMHO via sourceforge. Sourceforge is good for tracking bugs and fixes, but this "big change" should not be done there.

leio · Post by **leio** » Thu Dec 22, 2005 9:15 am

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

I have kept quiet here (at least until I find a bigger chunk of free time to write out my thoughts properly), because I'm involved in both projects (wxWidgets and OMGUI).
Me and ABX pretty much sum up the wx developers who regularily visit this forum.
Kevin H sometimes checks in here, and Julian has made release announcements.

priyank_bolia · Post by **priyank_bolia** » Thu Dec 22, 2005 11:09 am

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

I guess that its ultimately the users, who will be using the wxWidgets, so there feedback about the wxWidgets future, should not be ignored. I don't see any problem in using this forum, but the title should be different "Why I don't like wxWidgets." so that the newbies visiting this forum, would not get distracted.

Post by **upCASE** » Thu Dec 22, 2005 11:40 am

priyank_bolia wrote:I guess that its ultimately the users, who will be using the wxWidgets, so there feedback about the wxWidgets future, should not be ignored. I don't see any problem in using this forum, but the title should be different "Why I don't like wxWidgets." so that the newbies visiting this forum, would not get distracted.

I didn't say that user requests should not be taken seriously or ignored. On the contrary: They are very important!
But this is about changing wxWidgets "under the hood" and add "modern" compiler features and constructs. As these changes are rather drastic concerning the inner working, I suggested the development freeze where no *new* features would be added. They will however be noted down as normal for later implementation after the changes were done.

The title of this discussion is rather fitting IMHO. What we are talking about now is a result of the previous posts. This thread is not meant for discussing how and when the "changes" should be done. I just noted my ideas here, because this discussion made me.

mispunt · Post by **mispunt** » Thu Dec 22, 2005 3:26 pm

Is it usefull to have a wrapper. or what ever, between STL and wxWidgets containers? So people can easily switch from wxString to std::string or something like that.. A is just a small step in the "right" direction, but "we" need to start somewhere

btw. where can I found information about the current c++ standard? I searched but never found it...

priyank_bolia · Post by **priyank_bolia** » Thu Dec 22, 2005 5:27 pm

mispunt wrote:Is it usefull to have a wrapper. or what ever, between STL and wxWidgets containers? So people can easily switch from wxString to std::string or something like that.. A is just a small step in the "right" direction, but "we" need to start somewhere

btw. where can I found information about the current c++ standard? I searched but never found it...

You can purchase the ISO C++ from http://www.iso.org/iso/en/CatalogueDeta ... scopelist=

BTW You can find the 1998 standard for free using Google.

Also I think that wxString is totally STL complaint, you can also jsut #define wxString to std::string, AFAIK.

mispunt · Post by **mispunt** » Thu Dec 22, 2005 9:25 pm

priyank_bolia wrote:Also I think that wxString is totally STL complaint, you can also jsut #define wxString to std::string, AFAIK.

Perhaps this works for wxString, but does this also works for wxArray, wxHashMap, etc.?

Post by **T-Rex** » Fri Dec 23, 2005 8:50 pm

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.

Maybe it will be better to open some poll where wx-users could point their opinion about if it will be better to eliminate the support of old compilers and/or compatibility to older wx versions?

Regards,
T-Rex

SnakeChomp · Post by **SnakeChomp** » Fri Dec 23, 2005 10:16 pm

This is sort of off topic considering the posts immediately above mine, but it is a continuation of the "I don't like wxWidgets" topic.

These two posts more or less sum up why I don't want to try to post anything relating to wxWidgets changes or OMGUI on the mailing list:

The entire thread:
http://thread.gmane.org/gmane.comp.lib. ... evel/68530

The first post I want to point out in this thread:
http://article.gmane.org/gmane.comp.lib ... evel/68679

The reply to this post:
http://article.gmane.org/gmane.comp.lib ... evel/68680

After these posts the conversation dwindled into something completely useless which had no impact on the toolkit and won't actually bring about any solutions to the real problem that Kevin has pointed out. This typically happens with most of the conversations I have witnessed, they are steered off topic, dwindle away, and bring about no changes. I probably wouldn't mind actually talking about the changes I'd like to see happen, but if this is what will be happening to the conversation, I'll do it with somebody else.

Post by **Ryan Norton** » Sat Dec 24, 2005 7:00 am

I don't mind discussions like this on the forum, and personally I hoped one day it could be used for more of them like this. For one thing the devs are so busy that a lot of times they barely have time to say a word at all so in some sense it makes sense to discuss some things here that arn't urgent and are future related etc..

This is a good thread/topic too. Maybe if I have time one day I'll say my piece too

.

cpp · Post by **cpp** » Wed Apr 05, 2006 10:36 pm

Here is MHO, if anyone cares to know it.

Why i dont like wxWidgets:

1) its too buggy! lets face it, too many things dont work as expected, some do work, but not all the time, some not at all. i think that the people developing wxWidgets should give top priority to fixing the bugs on the current features and ports, ----BEFORE---- even thinking about adding more features / ports. I would much prefer it if wxWidgets was only for MSW, Linux & MAC, working 100% in all ports, that the way it is now, ported for god knows how many things, with none of these ports being reasonably bug free.
As for its features, well, same as with ports, i would prefer it if wxWidgets had fewer features that work that it having tons of "usefull stuff" that are unreliable (wxGrid anyone????)

2) poorly documented Yes, i know, "wxWidgets has a very rich documentation", and it does!, the problem here is that it is extremely messy, in other words poorly organized, and in too many cases, poorly mantained. Heres an example of this: There are probably dozens (if not 100s) of wikis, posts, blogs, readmes, howtos on how to compile the library, Still check out the formums here, there are probably 1000s of topics on compiling related problems. Why? because for someone attempting to use the library for the first time, there isnt a single place he can go, and recive full from start to end instructions on how to do it, instead, he has to read the .txt on the distro to "get started", then check out wxWiki (if for example he wants to know about the issue about linking statically to the CRT), then check out the forum to maybe figure out why his app keeps asking for setup.h, and probably still ask a couple of questions about why he cant get the minimal sample to compile, before he can get the lib working.

3) the devs dont seem to listen to us (the users) This is probably the reason of most issues in wxWidgets. I dont mean any offense, but It seems that the philosopy of the devs is that they are developing wxWidgets for their own personal use, and are generously "sharing it" with us. If this is in fact the case, then of course there is no point in me still typing this. Buf it it isnt, then listen to us
Want an example of this? see point 2 above. That "small issue" about the need for a single complete (and i mean really complete) guide to building the library has been evident and "mentioned" since i started using wxWidgets, still, no such guide exsists.

4) There are probably other specific things i dont like about wxWidgets, like the "silly" (i say silly cause stupid sounds offensive) idea of passing a wxArrayString to a validator when a simple wxChar* or wxString would do, or the fact that it seems (again) "Silly" to have to include .cpp files, and put 2 macros just to say i want an array of objets, when a simple template would suffice. And some other things i dont remember right now.
But i realize that this are not problems with wxWidgets, the problem here is the fact that it is IMPOSSIBLE to please everyone, if they would change (for example) the issue with validators i mentioned above, im shure someone would complain, just like i complain about how it is now.

So, if i dont like it, WHY IN GODS NAME DO I USE IT???
The answer to that is actually very very simple.
Even with all its bugs, documentation problems, etc., wxWidgets still is (IMHO) the best library for writting apps using C++ in exsistance today.
Example: WTL? (what i used before), its too small, it is strictly GUI without and support for networking, database etc. And there is more to writting apps than just windows & buttons. Plus, it is, 100%, completely undocumented.
MFC? let me put it this way, if MFC were the only option for writting apps in C++, i would quit writting code for ever. Its competely restrictive, it tries to shove its "doc-view" arch. down your throat, and the result is you spend more time "hacking" the damn thing to do what you want, that coding your app.
Qt? I wouldnt mind (too much) dropping $3,000 bucks for it if i liked it, but i dont like the Signal - Slot stuff, and i absolutelyHATE the fact that to compile my apps i need the MOC, POC, PHUK (or whatever is called) "pre procesor" or "compiler" or whatever it is.
Java, .Net, etc? heh, dont get me started...

Bottom Line
It would be stupid (not just silly

) of me, to just point out the problems with out sugesting solutions, so:

1) Devs, please listen to us!, check out the forums more often, hear what we think!

2) Clean up the library, im shure im speaking for most users of wxWidgets when i say, get rid of the bugs before implementing new features or ports

3) Organize, extend & update the documentation. Like i said before, there is a lot of it, but its messy.

4) i also think i speak for most users when i say this:
If you are still using & supporting prehistoric C stuff & compilers because you dont have the time to do a full "overhaul", then we understand, well be patient and help out where we can. BUT if this philosopy is intentional, *****pleeease**** loose it!, there is no reason to support some accient relic like Turbo C, at the expense of the library being inefficient and full with arcane code.

Post by **Jorg** » Thu Apr 06, 2006 7:24 am

If you really want this to be heard,. post it on the wx-dev list. I have my share of frustration as well with wxWidgets and I share the vision you have. Actually, I wanted to switch to wxPython, under the impression it would work better there, but it is simply a wrapper.

The toolkit grown immensely. But it lacks an architect developer. Someone who keeps a strict eye on the consistency in the API, method names, and clarity. Testing has improved greatly, but there is no official procedure for this, hence the bugs. I work for a medical company, I have to adhere to the laws of the FDA (and really, they are STRICT). I have to test my code thoroughly in unit testing. If I can't I make a test app that incorporates the methods I just designed, and if the test app runs fine, it will work fine. All these 'disciplines' if you will, are nowhere to be found. I love wxWidgets for it's openess, its live community, and the friendly people that are around every day, but I think in the future, a couple of people should stand up and say, now let's make things more strict for the sake of the user base. Make it more friendly, bug free and clear (documentation).

As for your points

more features / ports. I would much prefer it if wxWidgets was only for MSW, Linux & MAC, working 100% in all ports, that the way it is now, ported for god knows how many things, with none of these ports being reasonably bug free.
As for its features, well, same as with ports, i would prefer it if wxWidgets had fewer features that work that it having tons of "usefull stuff" that are unreliable (wxGrid anyone????)

I am no dev, but I can share feelings. What if you are in a position where you would not have a wxGrid at all, people scream for having one, and along comes one guy who does a pretty good (but not complete) job. Would you say, nope sorry I am no going to incorporate this into my code base it is not properly tested? It goes for a lot of added stuff. Some people contribute, it looks good at first, but when people start using it, it appears buggy or incomplete... and OOPS the original author got fed up with wxWidgets too and switched to something else. Then you are left fixing someone else's code, next to the huge pile of work that is left for the next release. I don't say it is like that all the time, but wxCheckboxList, wxListCtrl and wxGrid (and probably some others) are all a pretty good example. Everybody complains including me, but not enough people actually do something about it, including me.

2

) poorly documented Yes, i know, "wxWidgets has a very rich documentation", and it does!, the problem here is that it is extremely messy, in other words poorly organized, and in too many cases, poorly mantained. Heres an example of this: There are probably dozens (if not 100s) of wikis, posts, blogs, readmes, howtos on how to compile the

Well that's inherent to a lot of people. Everybody has a better way of doing things. Everybody is enthousiastic, there is indeed NO good structure in it. How comes? wxWidgets evolves, the tutorials don't. It works on their PC, others might miss an obvious step, and it fails. Back to the next tutorial, or ask the forum.

I have discussed this with Kevin Ollivier who is busy with the new wxWidgets site. This was one of my points. Too much incomplete info. The wxWidgets site should *always* contain accurate info or no info at all. When people are lost, the wx site should be the place where a tutorial is hosted that is updated along with the wx2.6.3+ release that is issued, and keep older versions for people with older wxWidgets releases. Once again, coming from a company that has more SOP's (standard operating procedures) to do things then people to execute them, there should be a checklist for these things! New release? Ok what needs to be done;
1. Check build status on all platforms supported
2. Run unit tests
3. Verify the samples
4. Update the site tutorials
5. Publish the release

There is probably more steps to think of, but I have the feeling that not all of these are executed in an organized matter.

statically to the CRT), then check out the forum to maybe figure out why his app keeps asking for setup.h, and probably still ask a couple of questions about why he cant get the minimal sample to compile, before he can get the lib working.

I still vote for a generator tool (which I have in mind for bloody ages to write) which people get along with the toolkit, a friendly GUI shows the options, figures out how wxWidgets is going to be built or is built, and created the settings and a project for you. One downside of no dedicated IDE is that there are too many IDE's to manage. This I also topld Kevin, the wx site needs clear steps for EVERY major IDE how to set up the wx libary in any of their configs. But all of this is resource intensive, and nobody has the time (per usual)

3) the devs dont seem to listen to us (the users) This is probably the reason of most issues in wxWidgets. I dont mean any offense, but It seems that the philosopy of the devs is that they are developing wxWidgets for their own personal use, and are generously "sharing it" with us. If this is in fact the case, then of course there is no point in me still

I do not agree. You have to understand that some of the wx devs actually make a living out of this. Vadim is a consultant for companies, Julian sells software made with wxWidgets as well. So there is some mixed interests. Sometimes they need something, and yes then they generously share it (which is bloody great because it is FREE right?) and a select group of people who 'proved' they are capable enough of writing code will have write access too, and this model kind of puts an inertia on new ideas, suggestions etc. You are allowed to develop anything for wxWidgets. When it is good enough it will be incorporated (example is the wxIFM v.s. wxAUI library). There is some good consideration being made. But the problem is being heard in the noise of people wanting attention. Just check out the number of messages in wx-users and wx-devs, there is just too many of us shouting to do things different without realising how much effort that takes.

wxArrayString to a validator when a simple wxChar* or wxString would do, or the fact that it seems (again) "Silly" to have to include .cpp files, and put 2 macros just to say i want an array of objets, when a simple

API consistency should be done by one or two guys that have the sole function of approving new api calls and keeping old ones consistent. En example would be a forum where wx-devs debate on new API changes and the architect agrees upon the last change, then and only then it is incorporated in the CVS.

So, if i dont like it, WHY IN GODS NAME DO I USE IT???

If we all would shout hard enough it should get heard some day. But it also means we have to change drastically to do it. In most cases I explained above there is lack of structure and procedures, dedicated tasks and a clear overview of who is doing what. This can all be improved.

I love wxWidgets, but I am also concerned it is a timebomb that will go off as the user base grows.

With regards,
- Jorgen

alexcoppo · Post by **alexcoppo** » Thu Apr 06, 2006 7:40 am

Jorg wrote: 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 the past I was severely bitten by MS propaganda. They say one thing and then they do another one. .NET is emerging? well, name me one flagship MS application written with .NET (not supporting .NET but build with).

There are none. Even MFC, has been used only to build AppStudio (which is the thing you use to create dialogs in Visual Studio 5/6).

.NET is the reaction to Java, created when it appeared that Java would become the tool to develop client apps. Sun killed Java on the the desktop (because they are a server company and get 0$ from the client) so... rest assured that C++ won't go away.

Bye!!!!

P.S.: almost certainly your bills are handled inside banks by RPG/Cobol procedures....

priyank_bolia · Post by **priyank_bolia** » Thu Apr 06, 2006 9:16 am

What I feel and mentioned repeatly that a sense of business is lacking in the core group, they made a great thing, but only a few knows about it(wxWidgets). I feel a commercial model of wxWidgets focused on the windows/linux GUI only will help wxWidgets more. Like said above there is too much functionality and too much ports, but none is 100% bug free. We should use other open source efforts and provide just a wrapper over them instead of creating out from scratch. Only the GUI should be the primary focus. Also like I previously raised that allowing more user and company patnership with wxWidgets, will help it to grow further(Microsoft MVP, VSIP). Some components like wxGrid etc, can be created for commercial pupose also like few devs combine to create it and make it available for say 20$. The problem is that we don't have much commercial components also. I see effort from individual dev like wxToolBox, wxFlatNotebook, but nt much from the core group.

ABX · Post by **ABX** » Thu Apr 06, 2006 11:50 am

cpp wrote:people developing wxWidgets should give top priority to fixing the bugs on the current features and ports

Is there any research which shows it is not such a case? In particular is there any bug which you are sure wx-devs knows, knows how to fix it, have time to fix but intentionally ignore to fix it? Are you feeling bad with occurences of 'fix' (48 counting literally) in changlog between 2.6.2 and 2.6.3?

cpp wrote:poorly documented

Many brave persons proposed improvements for documentation but nobody seem to be interested in doing hard work. Browsing wx-dev mailing lists you can find lots of materials what needs to be done.

cpp wrote:the devs dont seem to listen to us (the users) This is probably the reason of most issues in wxWidgets. I dont mean any offense, but It seems that the philosopy of the devs is that they are developing wxWidgets for their own personal use, and are generously "sharing it" with us.

The idea of "sharing" is partially true. OTOH what can look as "sharing" is that some devs do not mess with code of other devs. So just because I read about wxGTK bug doesn't mean I'm able to fix it.

The other idea that devs don't listen users is not true, you seem to kidding here. Just count the anwers from Jamie, Mart, me in this forum or answers of Vadim, Julian, Stefan, Robin in wx-users mailing list. Devs are just humans. In hundreds of posts many is simply missed or wrongly judged. It's really hard work. Sorry if it doesn't meet your expectations.

It takes me daily more than three hours to went through all online sources, write answerts, review night builds. Some more hours if I want to fix somethings with all careful test builds for all ports affected. And nothing was payed yet so I have to work for my company. And finally should I visit my wife and children from time to time? I believe every dev has about the same real life.

cpp wrote:2) Clean up the library, im shure im speaking for most users of wxWidgets when i say, get rid of the bugs before implementing new features or ports

If you know how to fix them please provide the patch. If you know what needs fixing please provide bug report. If you know who made the bug write to him directly. If you are able to improve something then write about it to wx-dev. It's simple.

cpp wrote:4) i also think i speak for most users when i say this:
If you are still using & supporting prehistoric C stuff & compilers because you dont have the time to do a full "overhaul", then we understand, well be patient and help out where we can. BUT if this philosopy is intentional, *****pleeease**** loose it!, there is no reason to support some accient relic like Turbo C, at the expense of the library being inefficient and full with arcane code.

Sorry I don't see any reference to TurboC in the code

Could you please be precise? Please point exact part of the code which is unused/pointless nowadays and how did you reviewed it's not used.

(TurboC is mentioned in zlib/pnglib/jpeglib but they are not 'ours')

Thank you for your feedback thought I can't promise it will influence anything. Speaking for myself I do _every_ bit of my free time reviewing patches and bug reports which I'm able to fix, finding holes in the code, lining-up interfaces of the ports (for CVS Head to avoid braking 2.6.X compatibility) and adding missed features to ports (known to me) so they all behave same way. Every dev I know is doing such hard work. The new features are mostly added because they were asked by users which are listened heavily. And then after a few years of such hard work I came to the post where somebody is saying like the work all devs made was not made. Thank You!

Have a nice day

ABX

PS. If you address your post openly to all devs please write in the place all devs reside. Thanks to http://news.gmane.org/gmane.comp.lib.wxwidgets.devel/ it's as simple as writing to this forum.