> But I would definitely recommend not using gtkmm.

You haven't really given a reason MA_D. Why would you not recommend using gtkmm? Have you had a bad experience with it in the past? Was it difficult to install along with all its dependencies? You should give actual reasons besides just saying not to use it.

It's unnecessary. It's just extra overhead. It likely makes use with c++ a little nicer, probably makes your c++ a little prettier. But in the end you are just asking your users to install gtkmm, glibmm and then gtk (they almost invariably have gtk). Not to mention, many apps require older versions of gtkmm, which is quite annoying.

I've never coded for it, only for gtk. So I can only speak for the niceties of gtk, but I am totally happy with gtk and can't see why one would want to put a layer between it and their app that doesn't add any portability.

http://www.autopackage.org
http://statifier.sf.net

solved your problem.

No.
Statically linking to gtkmm and glibmm would be quite rude.. It took me over an hour to compile gtkmm, it's quite large. It would be very rude to impose that upon your users..

I'd try coding in pure gtk first. And if you really can't stand it, use gtkmm. Just understand, you may get some complaints. More likely you'll just lose a few users (I've avoided apps for having gtkmm before, because I just didn't wanna install it). I finally did install it for inkscape, man that was a pain...

If you don't want to compile things from source, use binaries. Nobody should be scared away from using useful libraries because some users don't want to wait for the compiler - those people should not be compiling in the first place.

The whole discussion over whether you can statically link GTKmm or not is precisely so binaries can be produced easily.

Of course you *can* link it; I'm saying you shouldn't. It's wasteful.

One should consider how the popularity of a library they use may effect the usability of the applications for the user. If the library is not easily gotten by most users it will become a blockade that many will choose to avoid. This doesn't mean you can't use that library, it means it's a cost of using it. And so, one must way that cost against the benefits. In the case of gtkmm: I hold the opinion that the benefit is zero, because it's not really a library it's a language binding. A rather large language binding, that's not necessary (helpful maybe, but not necessary).

Anyway, it's up to him. But for the reason that gtk is accessible from c++ without bindings, and is very nice to code for in itself; I state that it is my opinion that it is entirely unnecessary and is just a hassle for the user more than a help for the developer.


I tried autopackage btw when I had to install gtkmm for inkscape. Autopackage wasn't much help in that arena. I do like autopackage though; but I don't see its relation to static linking. My understanding is that you do not lose dynamic linking with it, it just complicates it a bit more. Maybe I read wrong? But it still requires dependencies, and so I would assume it is not static linking.

Static linking could get quite bad if everyone did it on a linux desktop...

Hi,

I think pure GTK is actually quite Object Oriented even though it's written in C. As such I am quite comfortable with GTK and I see no reason to use GTKmm, so I guess it's just a matter of personal choice.

However, libglade is a more serious issue. I'm not yet totally convinced of the need to use libglade in place of code generation from Glade (which works quite superbly to be quite honest and I cannot understand why this feature is "deprecated").

I just think that libglade is an extra dependency. But I want experienced programmers' to help me here: how many extra libraries are used when you use libglade?

I agree, I just use glade to generate the code. It's prolly deprecated because they don't support the latest gtk. But I end up editing it up myself later anyway so I don't care. I just like it to take the painstaking work of writing 600 lines of repetitive code... It does it for me in minutes!

Why use gtkmm instead of GTK+?


1. gtkmm allows you to write code using normal C++ techniques such as encapsulation, derivation, and polymorphism. As a C++ programmer you probably already realise that this leads to clearer and better organised code.
2. gtkmm is more type-safe, so the compiler can detect errors that would only be detected at run time when using C. This use of specific types also makes the API clearer because you can see what types should be used just by looking at a method's declaration.
3. Inheritance can be used to derive new widgets. The derivation of new widgets in GTK+ C code is so complicated and error prone that almost no C coders do it. As a C++ developer you know that derivation is an essential Object Orientated technique.
4. Member instances can be used, simplifying memory management. All GTK+ C widgets are dealt with by use of pointers. As a C++ coder you know that pointers should be avoided where possible.
5. Less code. The GTK+ C object model uses prefixed function names and cast macros. For instance:
6.There's no need to worry about GTK+'s inconsistent reference-counting policy.

Gtkmm is not weird library. It is a common one. You can get gtkmm binary from your official distro repositories. So you can install it by apt-get, yum, emerge.... Gtkmm is not a third party like library.
If you are afraid that using gtkmm or libglademm will make the installtion hard for user, considering MySQLAdmin:
http://dev.mysql.com/downloads/administrator/1.0.html

It use gtkmm library.

Of course beside static linking, autopackage is a nice option. Sure you can program GTK+ with C++ without binding just like in GnomeMeeting or d4x. But you loose the advantages. Anyway it is a personal preferences. If you think gtkmm will make the installation harder but you want to use C++, why don't use wxwidget??? This library is more popular than gtkmm.... It use GTK+ anyway.

For Harishankar:
libglade comes with standard Gnome desktop. Gedit use libglade. So if you target Gnome user, you don't have to worry with libglade dependencies. The case will be complicated if you target fluxbox or windowmaker user..... then why don't use light weight library like fltk???

I do not want to target Gnome or KDE users. That's the problem. I just want to target any Linux desktop which would have GTK installed. Again, does libglade come only with Gnome dependencies?

The real problem is that I am striving very hard to prevent my apps from linking to the DE specific libraries (either KDE/Gnome) and link only to the underlying QT or GTK.

I would prefer wxWindows/wxWidgets to any other if that should be the case. But currently I prefer not to re-learn what I already have learnt and am comfortable with: namely GTK with C.

Libglade is not Gnome libraries. It is GTK+ library. There is Windows version of libglade anyway. To make it short: Gnome users already have libglade library. Abiword users, Gthumb users and Evolution users have this library too. So... libglade is a common thing. It is very rare that people don't have this library. I mean abiword, gthumb and evolution are popular applications right???!!!!!!

Ok, thanks. I will take a look at libglade anyway!

Gtkmm also. I like C++ so I think I'll try it out.

Autopackager I may use. But not statifier. It is against Linux principles to link statically so I will avoid it as much as possible.

Actually the Inkscape autopackages statically link GTKmm these days, it's not so bad.

I'd really use libglade, it's generally regarded as much better and so much stuff uses it, it's practically guaranteed to be present.

3.) is the only valid one you listed, that's a c lover's opinion .

Pointers should be avoided in c++, not in life .

I take that back, 1 is valid too, but 1 and 3 are awfully related points.

Yea, gtkmm is pretty common. But RHEL4 seems to lack it for whatever reason; and I loathe 3rd party rpm's (they never seem to be done correctly).