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

[John Emmas]

----- Original Message ----- 
From: "Paul Davis" <paul at linuxaudiosystems.com>
Subject: Re: [Ardour-Dev] GTK+ (concepts and advice)
>
> Unix programming doesn't use "handles" very much, because its more or
> less always had virtual memory
>
Fair enough....  I just wanted to be sure about that before I go too far
;-)

>
> C is not an object oriented language, and thus any attempt to do OOP
> with it involves making some decisions.
>
Haha - I've been reading this book for over a week without even realising
that GTK+ is written in 'C'.  I suppose I was fooled by the '+'

>
> 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.
>
Thanks.  That's the kind of advice I'm looking for.  What is 'Glade' BTW?  I
thought about using it to design GUI interfaces but it seems to design them
as XML resources which (I gather) get interpeted at runtime.  Is that
useful?  And are there any examples where Ardour uses Glade?  I can see a
library called libglademm but I don't know how or where it gets used.

>
> "Save As" is a *lot* more complicated than that, unfortunately.
>
To do it without re-loading the newly created session would be complicated
(which is the main reason why I haven't done it) but the process itself
isn't difficult (although it's very time consuming if native media is
involved).

John



----- Original Message ----- 
From: "Paul Davis" <paul at linuxaudiosystems.com>
To: "John Emmas" <johne53 at tiscali.co.uk>
Cc: <ardour-dev at lists.ardour.org>
Sent: 16 June 2008 14:44
Subject: Re: [Ardour-Dev] GTK+ (concepts and advice)


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