Subject: Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
From: Joshua Haberman (joshua_AT_haberman.com)
Date: Wed Jan 16 2002 - 02:34:31 EET
* Paul Davis (pbd_AT_Op.Net) wrote:
> >* Paul Davis (pbd_AT_Op.Net) wrote:
> >> >I would like to code up a proto of the interface though. I was
> >> >planning on trying to do it with python and something like wxPython.
> >> >Mostly because Python is my new favorite language and I need a good
> >> >graphics project to work on.
> >>
> >> any chance you'd consider using pyGTK and python?
> >
> >Why do you recommend this in favor of wxPython, when wxPython buys you
> >two extra platforms for free (and an easier, better documented API)?
>
> [...]
>
> there are things i have wanted to do in ardour that wxWindows would
> make exceedingly painful because it involves deep messing around with
> the GUI internals, something wxWindows cannot allow (since it has no
> single set of "internals").
Would messing with the GUI internals even be possible from Python without
modifying the bindings?
> 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.
> with an MVC (Model-View-Controller)
> programming model, the click is simply a request made using the button
> as a controller. when the state of the model changes (i.e. a track is
> actually record enabled), the button is used as a view, and its state
> is changed to represent this. now, in GTK+, its fairly easily to
> subvert the usual handling of button clicks and so forth. but the
> alternative to this is to make every widget with this kind of
> behaviour (i.e. most of them in an MVC system) into a generic "drawing
> area" where you either dump a pixmap or draw some text and lines and
> stuff. this means that you are basically back to Xlib and don't
> actually have a toolkit working very hard at all to make your life
> easier. i don't believe you could possibly carry out this subversion
> with wxWindows in a portable fashion. i may be wrong.
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.
> finally, i'm not sure what the 2 extra platforms are. MacOS is the
> only significant one I can think of. GTK+ for win32 seems to exist and
> be pretty effective.
I wasn't aware that GTK+ on windows is a usable port. Well, if you count
MacOS 9 and X, then you have 2. :-)
> GTK+ also provides support, like Qt, for direct
> framebuffer systems, making it effective in embedded systems that do
> not run X Window, which wxWindow does not do correctly, i am told.
That's a good point. It seems that this should be possible with
wxWindows since it wraps GTK, but maybe wxWindows' other dependencies
prevent this.
My primary object to wxWindows is that it's so big, which would be
understandable if you use their logging, IPC, networking, printing, DnD,
Database, and threading functionality, but for just the GUI it seems
overkill. Also, wxWindows doesn't yet have the ability to load interfaces
from a resource file (ala GLADE) though I believe they're working on it.
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.
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.
Joshua
-- Joshua Haberman <joshua_AT_haberman.com>
This archive was generated by hypermail 2b28 : Wed Jan 16 2002 - 02:25:49 EET