Subject: Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Jan 16 2002 - 03:22:36 EET
>Would messing with the GUI internals even be possible from Python without
>modifying the bindings?
on the level i'm referring to, yes. GTK+ makes it possible to
fundamentally change the way events get handled without modifying
widget code. for example, gtk_signal_emit_block_by_name() is a very
useful function for changing such things. similarly, you can
completely bypass the entire GTK+ focus model, which is a severe
liability in a program as complex as a DAW, and handle all keyboard
events directly.
> a simple example: when you click on a
>> record enable button, it cannot turn "on" directly from the "click"
>> handler/callback/whatever.
>
>I'm not sure what you mean by this.
for the purposes of the click, the button is just a controller. when
you click on it, its only role is to send a request to change the
state of the model. when the state changes, it assumes the role of a
view, and thus its appearance changes to reflect the new state.
imagine that i have depressed the "all-safe" button in ardour. no
clicks on any rec-enable button should do anything. ok, you say, just
put
if (all_safe) {
return;
}
in the click handler. but wait - this particular state of the model
can be controlled by MIDI Machine Control and regular MIDI CC's too,
not to mention keyboard bindings and the fact that for each track,
there are typically 2 such buttons (one in the mixer, one in the
editor). we'd have to duplicate the entire logic of "when is it safe
to rec-enable" in every handler for every controller. not good.
so, this logic goes into the model. buttons (and MMC messages, etc.)
function first as controllers. buttons then act as views if the state
does in fact change in response to the controller's action.
>Audacity (which uses wxWindows) currently uses two custom widgets which
>have capabilities not provided by the corresponding wxWindows classes:
>mainly, that they use custom images for drawing. Each of these widgets is
>a class that derives from wxWindow (which acts as the "generic drawing
>area" you describe), and both are between 100 and 150 lines.
>
>I don't think that's unreasonable.
but if each one of these has a different drawn content, and if most
buttons have to work like this, you've replaced the button widget of
the toolkit with a drawing area. same for any other MVC-style
elements. pretty pointless, if you ask me.
>Also, though the resulting code is portable to several platforms where
>wxWindows has been ported, it's *extremely* non-portable to others,
>because wx-isms seep into every part of your code.
right. in my experience, you can't avoid this. thats why i think
"toolkit wrappers" are really rather silly. you're just trading in one
set of "isms" for another, with possible changes in portability.
>I think this question of cross-platform toolkit or not will become more
>significant as the toolkits become better and as OS use diversifies (more
>people are using Mac and Linux all the time). What I've done with my most
>recent project is write as much as possible in portable C++. For the
>rest, I use small cross-platform libraries (as opposed to a monolithic
>beast like wxWindows), and small abstract classes to encapsulate the
>platform-specific functionality. Porting to a new platform will hopefully
>be as simple as implementing these classes.
i find it almost impossible to imagine rewriting ardour/gtk in a
different toolkit, let alone wrapping the functionality i rely on from
GTK+ and/or gtkmm in a "small abstract class". the GUI code is more or
less as complex as the internal "engine" code in ardour, and it relies
on its toolkit "isms" heavily.
i have grown fonder of the idea of a pyGTK version of ardour/gtk, just
to cut down on compile times, but i doubt that it will ever happen.
--p
This archive was generated by hypermail 2b28 : Wed Jan 16 2002 - 03:13:38 EET