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.

[thomas]

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.

[krisz]

I can only accept what the wxWidgets guys say (:roll:) and the mean time I agree with you. 

I think everybody would welcome removal of macro things, and using templates instead.  :!:

[takeshimiya]

All the arguments against wxWidgets 2.x are addressed here: http://wxforum.shadonet.com/viewtopic.php?t=5642

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.

So I have hopes for either wxWidgets 3.x (aka wxTNG) or OMGUI.

For anyone wanting to know more about it: http://www.wxwidgets.org/wiki/index.php/WxWidgets3 and http://www.wxwidgets.org/wiki/index.php/WxWidgets3:Goals

[yop]

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...

[yop]

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).

[kidmosey]

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.

[mdelfede]

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.

Ciao

Max

[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?

[iw2nhl]

Here you can find a little discussion between wxWidgets and Qt:
http://forums.codeblocks.org/index.php?topic=3603.0

[Freddy]

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.

Sorry for my poor english

[hd]

Hi,

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 use
wxWidgets.

Note:
There is another toolkit: Juce
GPL, or Commercial license
http://www.rawmaterialsoftware.com/


--
Regards,
Hakki Dogusan

[Roman]

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?

Roman

[Grom]

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.

[valkenar]

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.

[byo]

... If BYO will create something useful ...

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).

BYO

[Roman]

I use wxSmith for everyday work, and it works.

It IS USEFUL, but is rather SCARY, especially for newbies. When a man (or girl) looks at wxSmith for a very first time he (or she) has a predisposition to be scared (all the new things are scary). wxSmith IMHO must kiss a guest with a pretty appearance. Change a background in the Form Designer to something cute and noobs wouldn't run away with panic. Buttons at the right IMHO also produce an impression of something hardcoded.

Best Regards
Roman

[mike__t]

I find wxSmith quite useable, and appreciate the effort behind it.  It's really quite quick to build a reasonably complex dialog, and is quite stable in day-to-day use.

The convenience of having it built into the IDE outweighs any small disadvantages it might have in comparison to wxFormBuilder, and unlike wxDev-cpp, it is cross platform.

I will say that I had to show another developer where to find the resource tree, and without that it's a little harder to use.  Perhaps something could be done to make that easier to find (e.g. switch to it when the dialog editor is opened).

-Mike

[Roman]

And a fltk.org does not seem as creepy as rumors say

Sorry, I didn't look at their forum

Best Regards
Roman

[Grom]

... If BYO will create something useful ...

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).

BYO

I do like your work. I wont to have as fast as you can provide packages and custom controls. To have something similar to the Borland's IDE. You have probably largest chance to do that.

[Biplab]

Yesterday I wrote a reply and unfortunately I couldn't post it.

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.

Their tool cost an Arm and a Leg of a Developer. Especially if the developer belongs to developing country. The price is equivalent to 5-6 months' salary of an average software job. Forget about students, it may take their one year's study cost and living cost to buy that. So no wonder why it is so easy to use and customisable.

If wx team could've offered such alternative, it would've been nice to all. But I don't expect more from a free tool.

... If BYO will create something useful ...

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).

I agree with Byo. He had to put a lot efforts to do that. Just look at the amount of code he has contribute and you'll start appreciating his efforts.

Perhaps something could be done to make that easier to find (e.g. switch to it when the dialog editor is opened).

Good suggestion.

Regards,

Biplab

[mandrav]

I use wxSmith for everyday work, and it works.

It IS USEFUL, but is rather SCARY, especially for newbies. When a man (or girl) looks at wxSmith for a very first time he (or she) has a predisposition to be scared (all the new things are scary). wxSmith IMHO must kiss a guest with a pretty appearance. Change a background in the Form Designer to something cute and noobs wouldn't run away with panic. Buttons at the right IMHO also produce an impression of something hardcoded.

Scary? And I thought I had heard it all...  :shock:
It's a form designer. The way you work with it is by "playing" with it: put controls in there, move them around, change their attributes, etc. What's so scary about that?

@all:

Byo is doing a fantastic job here. wxSmith has come a long way since its first releases. It's pretty stable already for everyday use. It already supports most standard wx controls. And for what controls it's missing, I gladly use "custom control" until Byo implements them.
I have been using wxSmith for a big side project of mine and it's working like a charm.

Sure, it has its share of bugs and needs for improvement but what doesn't? This is an on-going process and you should all be happy that Byo is still working on this alone and producing this quality plugin.

So, please, stop being ungrateful. Stop attacking Byo.
Report any wxSmith bugs you find, post any feature requests you may have. Byo listens to all of them and he listens good.
Even better, offer a helping hand instead of whining...

"Save Byo" :lol:

[darthdespotism]

Is using GTKmm "GTK2" oder "Other"?

Nice Toolkit, Clean C++ all you need and it really looks great on GNOME

[hollingsworthd]

"Other"


I've been using JUCE ( http://www.rawmaterialsoftware.com/juce ).  Code::blocks already works great with JUCE, and the author provides the sourcefiles for the lib (which is a C++ GUI and general utility library... e.g., threads, strings, io, opengl support, audio...).

I also use Premake ( http://www.sf.net/projects/premake ) in conjunction with JUCE, CB, and my own project.  Premake is just a simple way for me to setup my CB workspace and project--as opposed to using the UI in CB... I just write a LUA script, run premake, and my project file is generated.

BTW, thank you, CB devs for a great IDE.  You guys should sell CB t-shirts as a fundraiser--so I can buy one

-dh