Wed, 01 Nov 2000 Lonnie Ezell wrote:
What the callback will cost you is basically an additional function
call in addition to any time you spend converting data to be in
a callback friendly context. Comapred with the amount of time
it will take to draw your widgets or do anything the speed difference
is really not humanly noticable.
Callbacks give you flexibility for future development, and often
make the actual programming process faster at a latter date.
That’s what I was aiming for. Basically a “template” (not in the C++ means)
where all I would have to do for other projects is tell it what graphics to
use, and allow me to tell it what to do when certain events hit it.
Basically, a stripped down GUI.
This is pretty much what the GUI toolkits used with some audio plugin APIs are
doing. (Although they generally don’t use any direct access style low lever
APIs.)
The most common (and simplest) approach seems to be to say “every widget is a
pixmap”, and then you just pass onClick and onMouseMove style events to the
client, which sends back StateChange actions to the widgets. Widget state can
affect visibility and index into a table of different images (button_down,
button_up, button-hilite etc), but not much more; ie you can’t build real
sliders/scroll bars that way, as that would require moving one pixmap around on
top of another pixmap.
Might seem limited, but as a matter of fact, many professional audio plugins
use GUIs built that may.
Any suggestions/feature requests that anyone has for the implementation
would be great, as I’m just now entering the planning stages. It will be
release open source for all that can benefit.
I’m “working” on a similar project, originally started on svgalib, then ported
to GGI. I’ll port it to SDL, and make it ready for an alpha release the next
time I’m playing with it. (It’s based on a homebrew low level framebuffer access
library, which ports rather easily to just about anything with some linear
framebuffer compatible interface.)
Not that you can see much of it in the current code, but the basic idea was to
stay away from the traditional idea that a widget is a hardcoded, black box
object. Instead, the only low level/built-in widgets would be basic rendering
elements, such as 3D bars, holes, depressions, images and other graphical
items. The actual widgets would then build on this, using either “normal” code,
byte code compiled/virtual machine code, or interpreted scripts.
For example, a slider would be one widget aligned so that it can only move as
desired insede another widget, sending “onDrag” events to an event handler, or
receiving “move” commands. There would be no slider specific code involved in
the rendering or movement control - the alignment system would deal with that.
Seen in another way, the basic idea is to implement a structured 2D graphics
engine with a very simple “physics engine” to keep track of moveable objects.
What normal toolkits would call “widgets” is implemented as a “build” function
that creates the low level objects for the widget, and an interface that
interfaces low level events from the “physics engine” with the application.
So, why creante something as weird and messy as that!? Well, first of all, it’s
just an experiment to see if it’s possible to implement at all, in a sane way.
If it works, the idea is to incorporate nice and simple ways of building new
widgets and interfacing with applications, somewhat similar to web
browser/server interaction. Finally, I’d wrap that up as MuCoS plugins (see
…sig) and use it to build GUIs for audio systems and that kind of stuff.
Of course, I’m also having perverse ideas about building games using the same
tools. 
David Olofson
Programmer
Reologica Instruments AB
david.olofson at reologica.se
…- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
------------> http://www.linuxdj.com/mucos -' | Open Source Advocate | ..- A u d i a l i t y ------------------------. | Singer | | Rock Solid Low Latency Signal Processing | | Songwriter |—> http://www.angelfire.com/or/audiality -’ `-> david at linuxdj.com -’