[Ardour-Dev] GTK+ (concepts and advice)

[Paul Davis]

On Mon, 2008-06-16 at 08:01 +0000, John Emmas wrote:
> Hi all,
> 
> Earlier in the year I completed the functionality for an Ardour "session
> merger" whereby two Ardour sessions can me merged together.  In fact, if one
> of the sessions was non-existent, it could also provide a "Save As" feature
> (allowing a session to be renamed) although I haven't got that far yet.

"Save As" is a *lot* more complicated than that, unfortunately.

> Being a Windows programmer, I haven't yet tackled a GUI for Ardour.  In
> fact, the only step I've taken is to buy a book about GTK+ development and
> I'm trying to get to grips with some of the concepts.  The book I bought is
> called "Foundations of GTK+ Development" by Andrew Krause and although
> it's well written and authoritative, I can't help noticing that some of its
> concepts would be considered total herecy for a Windows programmer!! 

Most good, modern programming concepts are a total heresy to windows
programmers. I hate to be so partisan. No, actually, I don't! :) 

> model which alleviates this problem to a great extent.  Nevertheless, it's
> considered 'bad form' to assume that GUI object addresses will remain
> persistent.  Windows maintains handles for objects (which DO remain
> persistent).  Therefore, if you need the address of a GUI object, you find
> it out from knowing its handle.  I just wondered if there was any similar
> concept in GTK+.  I can't see anything from my book but I don't want to
> start programming with a fundamental misconception as big as this.

Unix programming doesn't use "handles" very much, because its more or
less always had virtual memory, and so this nonsense of illegal pointers
(let alone the old "far" pointer mess from) has never existed.

The term "handles" in POSIX land tends to be restricted to the handling
of objects that are supposed to totally opaque to the
program/programmer. A good example would be an XWindow in the XWindow
API. The data structure for an XWindow is not accessible to the program,
all you ever use is the address of the data structure. Another example
is the return from dlopen(), used for run-time loading of explicitly
requested shared objects (e.g. plugins). The pointer you get back from
this function points at something, but you don't get to know what it is.

> Another thing I've noticed is that GTK+ seem to be remarkably 'non'
> object-oriented.  There seems to be a heavy reliance on global functions
> which get used to manipulate objects, rather than the objects knowing how to
> manipulate themselves. 

C is not an object oriented language, and thus any attempt to do OOP
with it involves making some decisions. There are generally two
approaches to the issue. One is to try to simulate member functions
directly:

	struct SomethingOrOther { 
	     ....
	     int (*aMethodThatReturnsIntAndTakesFloat)(float);
	};

	SomethingOrOther* foo = /* make a new SomethingOrOther */
	int val = foo->aMethodThatReturnsIntAndtakesFloat (3.14159);

some people like this, others think its wrong to try to turn C into C++,
and prefer the other approach:

	struct SomethingOrOther {
	    ...
	};

	SomeThingOrOther* foo = /* make a new SomethingOrOther */
	int val = something_or_other_compute_val (foo, 3.14159);

the first method is quite hard to use if you want to do "virtual"
methods like the ones in C++. at least, its quite hard to get right. the
second one is ugly and tedious to write, but you can implement most of
the features of OOP reasonably efficiently and reliably.

>  Even the most basic things like object placement,
> or setting the text for an object - these actions seem to be unknown to the
> objects themselves.  Is this a concept that I'll just have to get used to or
> should I buy another book??

No, the answer is much easier than this. None of Ardour's GUI is written
in GTK+. We use gtkmm which is C++ thin wrapper around GTK, and gives
you a nice C++-idiomatic GUI toolkit.

	Gtk::Window win;
	win.set_title ("Yow!");
	win.show ();

etc. etc. etc.