Subject: Re: [linux-audio-dev] proposed initial DTD for LADSPA-gui-xml
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Mon Nov 27 2000 - 18:16:24 EET
>| <!ELEMENT graphics_context EMPTY>
>| <!ATTLIST graphics_context
>| foreground CDATA #IMPLIED
>| background CDATA #IMPLIED
>| bg_pixmap CDATA #IMPLIED
>| font CDATA #IMPLIED
>| >
>
>Wouldn't graphics-context be the cannonical form? (sorry, that really
>*is* nitpicking!)
I don't know if `-' is allowed in XML element names. I'll check. No
wait, *you* know about this stuff! Sure, I'd prefer `-' to
`_'. Consider that change made throughout.
Note: the idea of the graphics context element is to provide specs for
things that are specifically *not* handled by images (pixmaps). I was
thinking of the case where you want to specify the background of the
whole GUI for the plugin, for example, or the font to be used when
labelling the GUI.
>How about fg_pixmap, or some way of displaying values more meaningful
>than the float value, otherwise I'm stuck with dB input values (which
>seem unpopular).
Well, I happen to like your use of dB values. Its much easier on
everyone except you :)
>I guess I could use vaue_displays, but yuk. Alternativly I could do it
>with active areas control (see later).
why yuk ?
>| <!ELEMENT controller (graphics_context?)>
>| <!ATTLIST controller
>| port CDATA #REQUIRED
>| xpos CDATA #REQUIRED
>| ypos CDATA #REQUIRED
>| label CDATA #IMPLIED
>| label_position (top | bottom | left | right | upper_left | upper_right
>| lower_left | lower_right) "top"
>| type (knob | hslider | vslider | spinner | image) "knob"
>| images CDATA #IMPLIED
>| >
>
>If you specify type="image" wouldn't it be neccesary to specify the
>active area you can move? eg. for a pixmap slider? The 'slider' can't
>move right to the top of the pixmap, if I understand how this works.
OK, you need to know how the object in my implementation
works. "images" is a regular expression that describes a set of
pixmaps. these are loaded (once; the backend keeps refcnts), and then
mapped to cover the full range of values handled by the port
(i.e. minval => first (alpahnumerically sorted) pixmap, maxval => last
pixmap).
as you adjust the knob/hslider etc using various GUI techniques (mouse
motion, cursor keys, etc.), the value of the port is adjusted and this
in turn causes a new pixmap to be displayed whenever a relevant
threshold is crossed. the result is that you can have a set of pixmaps
that transform in any way you want as the value is altered. the ones i
have now are simple - knobs that turn, sliders that slide. but you
could have an exploding object, or anything at all. typically, i use
about 32 pixmaps. you could use more or less.
so, no, you don't implement sliders by "moving" anything. you just
redraw the pixmap with the relevant one for the current value. this is
basically the same method used in libvstgui, although i was doing it
in Quasimodo anyway.
>| <!ELEMENT pushbutton (state+)>
>| <!ATTLIST pushbutton
>| port CDATA #REQUIRED
>| xpos CDATA #REQUIRED
>| ypos CDATA #REQUIRED
>| label CDATA #IMPLIED
>| label_position (top | bottom | left | right | upper_left | upper_right
>| lower_left | lower_right) "top"
>| trigger CDATA #FIXED "restart"
>| >
>
>What is trigger? Is it what happens when the control is used?
Hmm. I'm not sure this should remain in here. Its a hangover from
Quasimodo. I found when working on the GTK-- version of Quasimodo that
it was often the case that when you press a button, you want something
fairly drastic to happen to the plugin/module/thing. But the semantics
of this don't really apply to LADPSA, so consider it dropped.
I'd like to add a new element type, something like:
<ELEMENT control_pad (graphics_context?) ...>
which would implement Maurizio Umberto Puxeddu's recent cool "control
pad" for CSFE; think of this an a GTK equivalent of the Korg KAOS
pad. You get to map any mouse events (motion, button presses, etc)
into value transformations (Maurizio used python for this, not sure
what we would do). This would be a very powerful generic widget that
would allow fairly sophisticated control over a port value. I'm not
sure of the full XML spec yet.
--p
This archive was generated by hypermail 2b28 : Mon Nov 27 2000 - 19:33:59 EET