> 
> I've now put together this proposal in the wiki as RFC 2:
> https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_2-Widget_API

thanks andres!

> I'm very inclined to use a syntax for the proposed CsWidgets section
> based on the Cabbage syntax. It is more human readable than my XML
> format, but it is more extensible than the MacGUI syntax. Though I
> dislike that we add yet another syntax, I see this section as one that
> most people use through a front end.

i am fine with that.  only thing i would suggest changing though is the use of quotation marks
so that basically the same syntax for both the "source file" definition or for a "dynamic opcode"
definition.  i think my original suggestion was to use colons "attribute:value" but Rory's
"attribute(value)" is fine too.

so for example 
you would have option to do something like this way


form, caption(Minimal Example), size(280, 40)
hslider, channel(freq), pos(15, 23),  max(1500), caption(Frequency)


or this way 

instr 1
iForm widgetNew "form, caption(Minimal Example), size(280, 40)"
iSlider, kfreq widgetNew "hslider, channel(freq), pos(15, 23),  max(1500), caption(Frequency)"
endin


> 
> I think it's also important to decide who is in charge of storing the
> values. It could be the widget engine, and the values accessed via
> invalue/outvalue, or it could be that the values are stored inside
> Csound and the values are modified by the widgets in the style of
> chnget/chnset. I personally prefer the callback mechanism.

i also prefer callback.  (see more below)

> But I've had the idea that the GUI works a bit like a server that
> receives commands to create/destroy/modify widgets and acts on them at
> the appropriate time. This of course is independent of the Csound API,
> but maybe the Csound API could promote that kind of model by allowing
> this, and the creation/destruction of widgets on the fly.

i like that!   so how about having the "server" code also own the control values
and handle the parsing?  this server would live outside csoundlib (but communicate through 
the API) so that it can be instantiated and used by hosts even with no csound process
running.


> 
> Maybe if the API host doesn't support this, the widget is not created,
> and there should be a way to notify the Csound API that the creation
> has failed.

ok

-m



------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net