I agree that using macros in a C++ code is a bit awkward but wxWidgets was desigend far before the advanced C++ language features.

Yes, they are using this well-known excuse for many years now. I think it is quite a lame excuse, if you will padon my saying so.

It's like saying "Yeah I know asbestos causes lung cancer, but I don't care because I built my house before that was discovered".I mean, seriously, what kind of an exuse is that...

It is true that macros have a good use. Sometimes, rarely, but yes they do.However, there is simply no excuse, except being plain ignorant or lazy (or both), why someone would insist on writing DEFINE_BLAH(SomeClass) instead of deriving from a base template.I would not mind if the answer was "yeah sorry, we know about it, but we did not have the time to fix it". But the (transliterated) answer "hey, we were here first, screw those art nouveau C++ features" is not satisfying.The same is true for macros like XRCID and XRCCTRL, and many others.They are not only unnecessary and unsafe, some of them are strictly speaking illegal, as they call a macro from inside a macro. As it happens, it (accidentially) still works, but only if the order of inclusion is done correctly (...and is that a good thing?).

Another example:How many programmers have fallen for wxMessageBox and wxMessageDialog! The former returns wxOK, but the latter returns wxID_OK, which are, as it happens, different numeric values. Fair enough, they are different constants, but they look similar enough so they can be easily confused. What happens? Nothing. No error, no anything... except your program does not work as expected.If constants like these were typed as enums, then the compiler would not allow you to make such a mistake at all. That's why compilers are so pedantic, it really helps to avoid stupid errors.

I agree that it is absolutely not trivial to implement such massive changes on a huge thing like wxWidgets. However simply saying "hey, it's been like that for 20 years" is not good.

Logged

"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

In short, basically something agreed by wxWidgets and OMGUI developers is that the wx2 API is really outdated and not the most clever (it was based on MFC anyways), but not much can be done in the 2.x branch about that, the reason is backward compatibility.And another thing agreed is that wxWidgets haves currently the best real world working implementation of native widgets on each platform.

So the developers are aware of the issues of the API, and everything will change in wx3.x branch for a really up-to-date API (of course, it will not work in older compilers like VC6, GCC2, etc), and this means using templates everywhere, shared pointers, selected boost libraries, external and better APIs included (ie. like currently wx uses libpng for png's, it will use other libs for networking, sockets, etc instead of reinventing the wheel), signals and slots, no macros usage, usage of STL everywhere, etc.

I 'm using Qt 'cause it's just too damn easy to use it. The meta compiler stuff is scary and certainly non standard but it saves a lot of trouble and provides the signal - slot interface that I 've yet to see something as easy to use and understand (for me that is). The widgets are not native in windows (but very well resemble the native ones and you won't notice any difference), in linux Qt widgets *are* native widgets (What is native linux widgets? There is no such thing ). The community is not that large but you'll resort there in rare cases, the documentation is excelent. Bottom line, Qt is easy, cross platform, with an exellent (Java-ish I might say) style, great naming of classes methods etc. and the best available documentation. I have also used wxWidgets and FLTK, for me no comparison...

Logged

Life would be so much easier if we could just look at the source code.

I tarted with wxWidgets, but I had some problems with it, so I switched to FLTK, but I didn't like the non native gui. Now I am using VCF.That is all because I have to program cossplatform.

I 've just seen in their website that there are instructions for using the toolkit with codeblocks (installation and usage). I 'm going to give it a try for some side projects in work that I need an open source toolkit (and IDE and compiler).

Logged

Life would be so much easier if we could just look at the source code.

I've used "flat" Win32 (not MFC) for about 3 years, now, but I'm transitioning to wxWidgets for the multi-platform aspect of it.

As it turns out, wxWidgets makes it a lot quicker to develop applications. I was already using most of the same object hierarchies (I had my own simple Win32 widget library that has since been deleted in favor of wx), so the transition is pretty easy.

I was also a die-hard Visual Studio fan before I discovered C::B. They may not be exactly alike, but that isn't necessarily a bad thing. I will sacrifice some of the conveniences for the added features, faster load times, straight-forward project configuration, and lack of 4+ GB of bloat.

I agree that using macros in a C++ code is a bit awkward but wxWidgets was desigend far before the advanced C++ language features.

Yes, they are using this well-known excuse for many years now. I think it is quite a lame excuse, if you will padon my saying so.

It's like saying "Yeah I know asbestos causes lung cancer, but I don't care because I built my house before that was discovered".I mean, seriously, what kind of an exuse is that...

It is true that macros have a good use. Sometimes, rarely, but yes they do.However, there is simply no excuse, except being plain ignorant or lazy (or both), why someone would insist on writing DEFINE_BLAH(SomeClass) instead of deriving from a base template.

I don't agree with this point of view. It's true that would be better to have a more modern library, with templates and better coding and so on.... but for now I don't see any better library, with more portings, features and last but not least quite easy to learn for windows programmers.

here http://wxforum.shadonet.com/viewtopic.php?t=5642 there are people that say "we want templates, modern coding, ecc ecc", and 5 minutes later "ah, of course that must be binary and source compatible with 2.6 !!!".... well, I'd like to have a car with 400 HP that does 1000 Km with 1 liter gas, but it seems to me quite impossible :mrgreen:wxWidgets is far from perfect, but it works.The only thing that could make (almost) all people happy would be to publish a 3.0 'modern' version, still mantaning the 'old' 2.6.x.... quite a hard job for development team....Other widget libraries I've looked for have each something missing, portings, features, appearance, documentation, license... you can of course find some libs with more 'modern' coding, some more efficient, some more good looking, but none with all together.

dmivs

I'm using for now wxPython (wxWidgets wrapper for the Python) for my PC applications, but thinking about move to MinGW (and, accordingly, to C:B)

So more points of comprassion here:- Do specific widget has qualitative IDE?- Do specific widget has wrappers for another programming languages like Python or PERL?- Is specific widget just GUI library or full-scale framework? If we use it, we do not want to use any platform specific API call, do we?

I voted Win32API as it was the first I learned. (Well, that's not a GUI library, but native API, but anyway...).

As for cross-platform GUI library the best I EVER used is FLTK. Never gave me problems on both Windows and Linux.It simply is light, fast, easy to use, easy to build, comes with GUI builder, and has cool themes (although doesn't have native look).When needing to have native look on Windows I use Win32API. But I prefer custom look anyway, so FLTK is perfect.I agree that the website has bad layout and is bad for newbies coming to try.But what really got me into FLTK were these videos http://seriss.com/people/erco/fltk-videos/ and these tutorials http://www3.telus.net/public/robark/Once you watch them, play a bit with FLTK (especially Fluid UI designer), FLTK WILL BE your favorite GUI Library.When I reformat my hard drive, the first things I allways install are my c++ compilers/IDEs/editors and FLTK. What I really like about FLTK is that I really understand the code generated by Fluid. It's pretty clean code.FLTK is my true love.

As for WxWidgets, looks too bloated to me. Anyway, I'm trying it just because there's a nice IDE called wxDev-c++. But I really never tried to learn it. Maybe can be usefull for big projects that the bloat won't count that much.

Ultimate++ is a nice project that unhappily isn't used/known as it deserves. Very nice IDE, library and helpfull forum. It's not as light as FLTK, but it is lighter than wxWidgets, plus the source code tends to be very shorter as it uses modern C++ features. I'm a C guy, and don't know much about C++, but I could use this library just because it's very well coded. Give it a chance. Try it!

The other libraries I just didn't have a close look as I didn't like them by first look.

I'm kinda "choose one and live with it" type.Although this "choose" is a very hard/slow for me.

My toolkit history:- self made (DOS)- TurboVision (DOS) (Borland) (Incredible but, I still have customers using my programs written with it)- VB3 (MS) (I'm still using it for legacy projects)- Fox (3-4 projects)- wxWidgets (I'm using it for about five years)

I evaluated/read many of the gui libraries out there. Wrote some projects using Fox. Then decided to usewxWidgets.

Oh, my Holy S**t! There is a toolkit FLTK - this article pointed me to it (thanx Thomas). Surely cool. I couldn't vote for it because it's absence in the list but I would do it if it were. And a fltk.org does not seem as creepy as rumors say. With just a half of brain in the head (hope i have it) it is not a problem to get the things in 5-10 mins.

I have a questions to WX elders: Could Code::Blocks be implemented using FLTK - would it be as simple (sorry, devs, just a pun probably ) as with WX? Or does FLTK have serious limitations?

The main problem of lots of GUI libraries, that they don't have any native development environment. In that case there is a gap between development of GUI designer and library development. The most successful story there in Borland IDE. They created a GUI library + developer, based on that library. When wx team will understand that - our life will be easier. As a result I am using wxDevCpp and wxFormBuilder for GUI development and compile project in Code::Blocks :shock:. If BYO will create something useful - probably even wx team start supporting it. The main criterion here is to create a GUI designer with few sometimes contradicting tools:

Platform independent.

Customizable - you will be able to add your own packages of tools.

Automatical event handling - you will be able to add an event handlers with mouse clicking, without any troubles like in wxFormBuilder, where you have to write your own handler.

MLU support - to see the GUI structure + MLU based development.

XML support - to import/export your GUI. Probably the GUI designer should be written around it.

Finally if BYO will implement only first three tools - the wx palette will start grow very fast, like it was happened with Borland IDE. In borland IDE you may create a huge GUI with smallest coding.

QT - umm yeah, but what is this meta-compiler thingamajig I keep hearing about?

I voted QT... the meta-compiler thing bugged me at first too, until I figured out a way to integrate the meta-compilation into the codeblocks build process fairly effectively. There's a thread I posted the method in somewhere around here, but once you set it up, it's very simple.

Basically, there's a tool in the QT distribution that you want to run your headers through if they use the signals/slots mechanism. The tool creates C++ code for you to compile into your project. It would be a pain to do it manually every time, but it's pretty easy to set it up once for each header file, and then just forget about it totally.

I use wxSmith for everyday work, and it works. So please, don't tell that my stuff is useless. I see that it does not meet your requirements (and you keep stating that for few months now), that really makes my "work" here harder (simply because it makes me discouraged).