Subject: Re: [linux-audio-dev] EVO status...was: (open-source like hardware)
From: Joshua Haberman (joshua_AT_haberman.com)
Date: Wed Jan 16 2002 - 04:52:23 EET
* Paul Davis (pbd_AT_Op.Net) wrote:
> >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 can see why they would be silly for something like Ardour, but for a
project:
1. whose target audience spans several platforms
2. that utilizes a significant portion of the wrapper's functionality
3. whose requirements don't significantly exceed the wrapper's
capabilities
...they could be just what the doctor ordered. Especially with one as
well-maintained as wxWin.
Not to mention that I'd take native widgets over foreign-looking ones any
day (I especially dislike Tk).
> >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.
Hah, I wouldn't dream of suggesting the "small abstract class" approach
for something like Ardour! I should have mentioned that the project I'm
testing this theory on is infinitely smaller, and an approach I would
never consider for software of significant size.
> 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.
Are their cons to this approach? How much work is it to write bindings?
What are the performance penalties? Would the overhead of an interpreter
rule out embedded systems?
I appreciate your comments. I don't mean to be antagonistic, just trying
to gain perspective.
Joshua
-- Joshua Haberman <joshua_AT_haberman.com>
This archive was generated by hypermail 2b28 : Wed Jan 16 2002 - 04:45:03 EET