Which widget library do you mostly use?

[Code Medic]

For the people who love using Code::Blocks for their daily development.
Please spend a few seconds to help others see which widget toolkits are popular and it will help improve support for them in Code::Blocks

FYI: If you choose "Other", please mention which one.

Thankyou for your time.

[Vampyre_Dark]

I use WIN32. It makes sense, and I like it. It was diffucult at first, but I was new to GUI and window system  type programming then. Now I find it very easy, and I can pick up the ideas behind new control types very quickly.

I just wish the MSDN site was better organised. It's a jungle on that site.

[bluekid]

i use FLTK library andd FLUID for GUI design for Linux and Windows
http://www.fltk.org/
http://www.gidforums.com/t-10094.html

[kkez]

I use WIN32. It makes sense, and I like it. It was diffucult at first, but I was new to GUI and window system  type programming then. Now I find it very easy, and I can pick up the ideas behind new control types very quickly.

Me too. Let's see who's the third one who voted winapi

I just wish the MSDN site was better organised. It's a jungle on that site.

Well, i always use google or my msdnsearch to search in MSDN, so i don't really browse it directly. But i agree that some arguments could have been divided in a better way... like MFC and Windows CE and winAPI (that all share many things) together in the same library. Sometimes I browse the docs through a windowssdk.msdn.microsoft.com subdomain, but i didn't explore it thoroughly.

BTW, some people told me that it's the best documented "widget"...

[David Perfors]

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. 

[sethjackson]

Well I started with the Win API..... Now I use wxWidgets. No I didn't vote for the Win API. I voted for wxWidgets.

Some thoughts on these toolkits:

QT - umm yeah, but what is this meta-compiler thingamajig I keep hearing about?
wxWidgets - this is the one I voted for/have used.
SmartWin++ - MFC replacement (Windows only).
Win32 API - Windows only. Not too bad once you get used to it. You have to use casts too much.
GTK2 - C interface. Looks quite bad on Windows.
VCF - this is the only one I have never heard of.
FOX Toolkit - don't like the website. (doesn't mean the interface is bad though).

Others:

FLTK - website looks horrible (doesn't mean the interface is bad though).  :lol:
OMGUI - weird interface (again IMO).
Ultimate++ - never used it.

[thomas]

Am using wxWidgets because I must (as Code::Blocks is built on top of it), otherwise use Win32 API for Windows, FLTK for Linux.

Win32 API
Win32 is a PITA, not a toolkit, and not cross-platform, either. But well, it still works, somehow.

QT
Meta-Voodoo is scaring me.

FLTK
Extremely cool, extremely high performance, lightweight toolkit. There is an UI designer coming with it, the toolkit is well-made, and FLTK executables only have a few dozen kilobytes of overhead (compare that to the size of a minimum wxWidgets program!). It does not have a gizmo for every gimmick like wxWidgets, but it has all you need to write a nice GUI program, and it is really low fat.
Unluckily, their website sucks big time which is probably why they don't have a community (and as much 3rd party stuff) as wxWidgets.
Information and the first impression for a would-be user is extremely bad. You start off with two sites (fltk.org and fltk.net) which apparently develop the same thing, but they look completely different and are run by different teams. The only thing they have in common is that they both look bad.
After a while, you find out that there is a 1.x branch and a 2.x branch, and you learn that 2.x is doing things like UI theming, but you still look for "how to use this thing in 5 minutes" in vain. Building FLTK under Windows is not quite trivial either, the readme tells you to look at another file which points at yet another file that contains instructions which don't work. In one word, it is a pain to get started (unless you use the binary DevPak). This is very counter-productive for acquiring new users and for finding developers. Luckily, it is much less of a pain under Linux, thanks to RPM.
All in all, this bad first impression that you get from FLTK is a shame, because I think that FLTK is really an excellent toolkit which could without any doubt be the number 1 choice for many people if the developers polished it up a bit here and there and made a few things easier to understand, but as it is now they scare off every user but the most hard-boiled ones.

wxWidgets
It's a piece of crap, but at least you can get it to work somehow, it has a big community, lots of 3rd party stuff, and it is widely supported. It is relatively easy to set up and very well documented (even though the documentation has some severe mistakes)
wxWidgets costs you endless hours of swearing when doing anything more complicated than a window with a menu bar and an about box. Many things are implemented very inefficiently and some make you bang your head on the table. In particular, the widespread macro abuse is a nuisance -- it is ugly to read, code completion does not handle it, error messages are misleading, and debugging is a nightmare.
However, on the good side, it mostly works somehow. Your executables are bloated and you'll never get top performance, but well... they still somehow work, and you can port them to many different platforms without having to do too many changes.

SmartWin++
Very cool, basically a huge collection of templates around Win32. Not cross-platform, and a project cannot be compiled without exceptions (which you sometimes might want to do for reasons of performance and size).

Ultimate++
Ulitmately scary code style. They do know C++ for sure, and they know how to write compact sources, and sure enough you can write programs that way, but the coding style is well... not my style.

OMGUI
Tried once a while ago, could not get it to run. Nevertheless it looks promising and certainly could become a very good toolkit some time in the future (presently in pre-alpha stage).
This is definitively something I'll be looking into again in maybe 6 or 8 months.

VCF
Never heard of.

Fox Toolkit
Looked at that once many months ago. The website is very nice, information is excellent.
Has even more macro abuse than wxWidgets, which scared me off within minutes. Maybe a wrong decision, as it might really be a good one.

[Code Medic]

Some time ago I was deciding on which widget to choose and stumbled on this article at freshmeat.
http://freshmeat.net/articles/view/928/

It is quite old but they talk about something called blocking/non-blocking main loop, in their comparisons.

Anyone has any idea what that means and how it affects performance?

Cheerio

[Code Medic]

wxWidgets
It's a piece of crap, but at least you can get it to work somehow, it has a big community, lots of 3rd party stuff, and it is widely supported. It is relatively easy to set up and very well documented (even though the documentation has some severe mistakes)
wxWidgets costs you endless hours of swearing when doing anything more complicated than a window with a menu bar and an about box. Many things are implemented very inefficiently and some make you bang your head on the table. In particular, the widespread macro abuse is a nuisance -- it is ugly to read, code completion does not handle it, error messages are misleading, and debugging is a nightmare.
However, on the good side, it mostly works somehow. Your executables are bloated and you'll never get top performance, but well... they still somehow work, and you can port them to many different platforms without having to do too many changes.

Things I like about wxWidget is its cross platform compatibility  and ability to use native widgets if available... or fall back to its own.

FLTK impressed me quite well but as you said.. its website and documentation seems scary... I think I shud use it for some small project and see. BTW, any idea whether they use native widgets as well?

Cheerio

[thomas]

called blocking/non-blocking main loop, in their comparisons.
Anyone has any idea what that means and how it affects performance?

Blocking means that the message loop blocks in a syscall, i.e. the thread is taken off the scheduler until an event occurs (at which time the kernel puts it onto the scheduler again).
This is slightly more efficient than non-blocking insofar as the message loop takes exactly zero CPU cycles as long as no messages arrive, whereas a polling message loop still burns a few cycles. However, it has disadvantages, too. Obviously, as long as the thread is blocking, it does exactly nothing. For some applications, that's exactly what you want, for others, that's the opposite of what you want (you can of course work around it, for example with a timer).
In the end, it probably does not matter much which one you choose. Both blocking and non-blocking are ok, each one has some advantages and some disadvantages.

any idea whether they use native widgets as well?

No (and yes... there is support for a native file selector box), but that's not really a disadvantage. Actually it is a pretty cool feature. As version 2 is going to be fully themable, you'll have look and feel switching pretty much like Java does. If there is one thing about Java/Swing that is *really* cool, then it is that you can switch the UI look and feel.

[David Perfors]

I think it is a disadvantage that a toolkit doesn't use native widgets. People are used to those native widgets (especialy those who don't like to work with the computer). That is why I stopt using fltk. But indeed I like the size of it.

VCF is for me a good alternative for wxWidgets, although they are using mixed case filenames, which looks evil on *nix

[Code Medic]

I think it is a disadvantage that a toolkit doesn't use native widgets. People are used to those native widgets (especialy those who don't like to work with the computer). That is why I stopt using fltk. But indeed I like the size of it.

I also believe that native widgets are better. First of all, they can provide an interface the user is used to and secondly it should be faster on highly evolved GUI systems ... but on the other side of it.. the stability and functionality are restricted by the native GUI. I guess on *nix it doesnt make any difference as the X doesnt have a high level widget system.

VCF is for me a good alternative for wxWidgets, although they are using mixed case filenames, which looks evil on *nix

but... isnt mixed case naming better?.. it makes the code readable and doesnt have to stretch the length of the variable/function name (with underscores)

[David Perfors]

VCF is for me a good alternative for wxWidgets, although they are using mixed case filenames, which looks evil on *nix

but... isnt mixed case naming better?.. it makes the code readable and doesnt have to stretch the length of the variable/function name (with underscores)

Mixed case naming in source code is better, but filenames not. On *nix you can have the file HelloWorld.c and helloworld.c. On windows you can not... IMO that is a problem which should be avoided. (this problem shouldn't be there in the first place, so hopefully Mic.... is going to change that..)

[Code Medic]

VCF is for me a good alternative for wxWidgets, although they are using mixed case filenames, which looks evil on *nix

but... isnt mixed case naming better?.. it makes the code readable and doesnt have to stretch the length of the variable/function name (with underscores)

Mixed case naming in source code is better, but filenames not. On *nix you can have the file HelloWorld.c and helloworld.c. On windows you can not... IMO that is a problem which should be avoided. (this problem shouldn't be there in the first place, so hopefully Mic.... is going to change that..)

oops....  how did i miss that word...!!! my eyes need a patch..!

[krisz]

Hi!

I use wxWidgets. For two reasion:
- Cross platform. When I switch paltform I have no the overhead of knowing another library. (This fits the intentions of C::B as well (at least in my opinion))
- Well documented and maintaned.

I agree that using macros in a C++ code is a bit awkward but wxWidgets was desigend far before the advanced C++ language features. I think once one got a grasp of it, it would not be a big disadvantage. However the support of the STL is a bit week but it makes me no overwhelmed.