Re: [linux-audio-dev] LADSPA and JACK

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LADSPA and JACK
From: Stefan Kost (kost_AT_imn.htwk-leipzig.de)
Date: Mon Mar 11 2002 - 18:53:02 EET


>>Anyway, *why* are people doing this "hidden event loop" thing over
>>and over again...? I've implemented several simple GUI toolkits for
>>various environments, and I haven't really seen a case where chosing
>>between that model and an "open" read_event() + process_event() style
>>interface is critical to the implementation. It's basically just a
>>matter of wrapping some parts of the loop up as API calls, and then
>>moving the loop into the application. I have yet to see a platform
>>where it's not possible to use either approach.
>>
>
> i think there are a couple of reasons. an event loop featuring only
> one source is trivial to write. it gets more difficult when it
> involves more than one, then more difficult still if the event sources
> are of different "types", and even more difficult if you want to code
> it in a fairly platform independent way.
>
> toolkit writers these days are aiming at Linux/Windows/Solaris/MacOS
> compatibility, and this frequently means starting with code in a
> general portability library. for GTK+, this means glib, which
> encapsulates event loop control in a completely platform independent
> way. of course, it isn't used by Qt or FLTK, so you can't use it with
> either of them.
>
> if they don't do this (and note: glib 2.0 has split the event loop
> into several smaller pieces to make it theoretically easier to
> integrate it with other approaches the same problem), then they push
> the task of platform independence on the developer, and they also
> force the developer to handle different event source types. keep in
> mind that under windows you can sleep on a semaphore (something sorely
> missing under POSIX).
>
> what would be nicer is a toolkit that knows about various portability
> library event loops, and offers functions to provide access to the
> relevant data in formats that can be used to hook the toolkit into
> those libraries' event loops. for example, a toolkit would provide
> access to its connection to the X server as a g_io_channel for glib,
> and in some other form for, say, Qt.
>
> AFAIK, this hasn't happened yet. if it did, then you could use GTK+
> directly "inside" the Qt (non-GUI) event loop handler, or FLTK
> "inside" an application using glib (with or without GTK+).
>
> and pigs might fly .... :(
Well maybe the can fly some day ;-)

I am writing a meta toolkit (as part of my PhD), with a fairly high abstraction and render plugins as backends.
Clients supply interface description as xml (surprise surprise) and a
core library forwards this to the choosen renderer. The basics already work, but there isn't much to see yet.
The system aims at not too overcomplicated GUI as it even allows e.g.
blind people to use them with a braile keyboard or e.g. a mechanic to uses a speech i/o system to control it.

A system like this could easily generate a simple plugin GUI (like a array of sliders) in whichever UI-toolkit

as there are plugins for.

Stefan

-- 
       \|/
      <@ @> Stefan Kost  private                   business
+-oOO-(_)-OOo------------------------------------------------------------- - - -  -   -
|        __    Address  Zwenkauer Str. 24         HTWK Leipzig, Fb IMN, Postfach 300066
|       ///             04277 Leipzig             04277 Leipzig
|  __  ///              Germany                   Germany
|  \\\///      Phone    +49341 3910483            +49341 30766101
|   \__/       EMail    st_kost_AT_gmx.net           kost_AT_imn.htwk-leipzig.de
|              WWW      http://www.sonicpulse.de  http://www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - -  -    -


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Mar 11 2002 - 18:45:00 EET