Nobody is forcing you to use GTK+ or gtkmm. If you feel the need to do it,
you are free to take inspiration from GTK+ for the object-oriented toolkit
that you are going to write...

Quite strange comment, me (and many developers even some firms I know about here in Hungary) uses GTK and not QT because don't know or don't want to code in C++. If you prefer C++, good. But please do not try to treat that C is the past and C++ is the future; I also know people treating the opposite: C++/Java is for stupid mouse wizard, and C or assembly for real men. However neither of these opinions are usefull, at least IMHO.

In fact, GTK+ is object oriented. Object orientation isn't about programming
languanges but about a way of thinking. C doesn't have any OO tools like
classes/inheritence and so on, like C++, Java and others. But that doesn't mean
that you can't do object oriented programming in it. GTK+ uses the GLib
libarary and its "GObject" object model, wich implements everything needed to
do object oriented programming, like for instance inheritence, classes, type
casting and garbage collection in the form of reference counting. 

It may be easier to use Java's swing. But what if you don't want to use java?
what if you prefer python? You can't use swing there. But you have PyGTK. Or if
you like C#, you have GTK#. Or even ADA, I could go on and on. One of the
greatest benefits of C is that it is easy to create those bindings for other
languages.

If you think Java's Swing is easy to use, you should defenitly try GTK# which I
find much easier.

try libgtk-java

I had similar thoughts regarding GTK+ in relation to the future.

You can explain endlessly that there is the "OO" toolset (mass macro and
procedural stuff) and that it fullfils the OOP task and works brilliant for
everything today etc., but judging on real use, it is a mess to deal with when
compared to what a clean OO approach can offer in terms of productivity and
maintainability (just compare creating properties with a few lines here and
with GObject...). There is a reason so many (new) people like to code with GTK#
for instance.

I agree that GTK+ should be evaluated to be ported to a real OOP language and
leave all the macro-magic behind.

Now the C# gang would like to have GTK+ for them, Java guys say do it in Java
instead and hey let's just do the OOP C++ thing and so on... ;)

However, everyone is arguing that each approach can not fullfil the
requirements and hence people stick to C because it "works" and can get "OOP-Thinking" applied. Infact many proposals result in way too big sacrifices.

C++ is really not a "modern" approach to OOP and a mess to deal with aswell,
other approaches fail due to being based on interpreted languages (which from
my pov. should strictly remaing binding-only!) and all fail on system level
ideologies.

Nevertheless, I think there might be a candidate that might solve (almost) all
issues but was yet not considered (that thing is coming right behind Ruby in
the language rankings).

The "D programming language" offers an easy learning-curve OO C#-like-syntax
approach, cross platform support, real garbage collection, native compiled code
(allows your "real-men" inline ASM), C ABI compatibility and MUCH more. 

http://www.digitalmars.com/d/overview.html (Don't take that site as a "company
commercial" thing from the first look, it's a serious language with proper
licences and an OSS-friendly community on other sites)

Ain't that what we have been waiting for in times of C#/Mono/GNOME debates? I
ported some C# alphablend GTK+ stuff in no time using D while ending up with a
native application and neater OOP than C++ could deliver.

If you study the language a bit you can see that it infact is a powerful "next
step" and solves practical issues that everyone has encountered who calls
himself at least a half-serious programmer. It is significantly easier to learn
for beginners aswell while giving you the benefits that keep yourself cheering
for C (or C#, or C++ ...).

A switch to D could even happen in a slow merge with some parts getting
rewritten.

All that is prolly NOT a request for immediate change but it should certainly
fill some bold bullet somewhere on the way in the future as I think such
requests as #1 notes are to be taken seriously for consideration.

Furthermore, the mailinglist is prolly a way better ground for this than the
"original" bugreport. ;)

> The question is can we expect to have real powerful object oriented framework
> based on current gtk+? The best way is to rewrite gtk on C++ with good object
> model similar to Qt.

Why not just using Qt then? It is free software too, so...

Exactly! If someone try to port (rewrite?) GTK+ in C++ that would result in something which is quite similiar to Qt. Why don't use Qt then? Reason of having Qt and GTK+ (and others) is the possibility to choose one to use (freedom means freedom of selection for your need). If you want to have a GTK+ which is quite similiar to Qt it would have got much more less reason to exist and choose. Current situation if perfect: I don't like C++, I dont' code in C++, I like C, I can code in C, therefore I choose GTK+ for my stupid little apps. If you need C++ API, best is to use a widget written in C++. Qt has got much-much more software based on than GTK would if someone ported anyhow. I don't even understand the point why it should be done ... 

(In reply to comment #5)
> I had similar thoughts regarding GTK+ in relation to the future.

> There is a reason so many (new) people like to code with GTK#
> for instance.

And they may continue to do so, if they like.  The GTK+ framework is flexible enough to allow basically any language to tap into it by writing bindings for themselves.  We have GTK#, ruby-gnome2, PyGTK, Gtk-Perl, Gtk+Haskell, gtkmm, guile-gtk, lambda-gtk, libgtk-java, and many more.

The fact that GTK+ is written in C makes it a hell of a lot easier for these bindings to be written/generated and I see no reason to limit everyone's choice to one predetermined "best" language.  C is obviously doing a pretty damn fine job and discussions like these are just a waste of time for everyone.

Sure. Also please note, that many people (including me) have _never_ want to develope GTK itself, so I don't understand their problem that GTK+ should be written somehow else since they will only meet with the API of GTK+. So the original problem should be about the C++ binding provided for GTK+, and not the language itself GTK+ is written in. Gtkmm (I don't know however) may do everything bad. Or good. However new bindings can be created if needed, esepecially for great area of languages, which is much more harder if GTK+ would be written in a higher level language. By the way I asked people several times about their point of opinions when complains about eg Linux kernel is not written in C++ or such while they're not kernel developers at all. I've never understand the these kind of problems ... So it there is problem with gtkmm I think it's problem of gtkmm (well, quite simple ...) and not GTK+. At least IMHO and AFAIK.