Hey,<br><br>Thanks for that overview of how the Canvas is structured.. I had wondered how it was done.<br>And figured I'd better leave it until I better understood the Gtk toolbox.. <br><br>Nice to read a concise description of how its working internally... You could say ill<br>
never look at Ardour the same again. (Bad pun intended ;-)<br><br>Cheers, -Harry<br><br><div class="gmail_quote">On Mon, Jun 28, 2010 at 2:38 PM, Paul Davis <span dir="ltr"><<a href="mailto:paul@linuxaudiosystems.com">paul@linuxaudiosystems.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">the key point is that the objects on the canvas are not widgets that<br>
can be used without the canvas. they are canvas items, whose internal<br>
implementation is closely tied into the internal design of the canvas<br>
itself. its still quite object-oriented in all the right ways, but not<br>
using widgets that could be re-used in a totally different context. to<br>
give a specific example: some of the ideas about how ardour draws<br>
waveforms come from something that was called GtkWaveView. that was a<br>
regular GtkWidget which could be used just like a toggle button,<br>
textview or whatever. but the current (and foreseeable future) design<br>
of GTK means that you can't use widgets the way that you need to<br>
create the experience you expect from a non-linear, non-destructive<br>
multitrack editor. so some of that code ended up in the<br>
CanvasWaveViewItem object, which draws itself onto a canvas. its<br>
modular, its compact, but its also useless without the canvas.<br>
<br>
there is still a heirarchy of objects/items on the canvas, specific<br>
track types etc. etc. - they just don't involve "widgets" in the<br>
normal sense of a GtkWidget.<br></blockquote></div>