[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-devel] gtkmm instead of gtk
From: |
Nick Brown |
Subject: |
Re: [Pan-devel] gtkmm instead of gtk |
Date: |
Fri, 13 Oct 2006 14:32:15 +0100 |
Charles Kerr wrote:
> Nick Brown wrote:
> > I notice that C++ re-write of Pan still uses gtk directly from C.
> > Is there are reason for this, instead of using the C++ bindings for
> gtk?
> > These provide a true C++ object interface to gtk.
> > http://www.gtkmm.org/
> >
> > Would a port to gtkmm be possible/desirable?
>
> Hm. This may sound snarky, but it's an earnest question: other than
> another library dependency, what would gtkmm do for pan?
Taken straight from the FAQ:
http://www.gtkmm.org/docs/gtkmm-2.4/docs/FAQ/html/index.html
1.4. 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:
gtk_button_set_text(GTK_BUTTON(button), "sometext");
gtkmm C++ code is shorter and clearer. For instance:
button.set_text("sometext");
6. There's no need to worry about GTK+'s inconsistent
reference-counting policy.