Re: atomic toolkit, was Re: [Adobe-source-devel] xstring questions

[Sean P. <sp...@ad...>]

On Feb 12, 2006, at 1:59 PM, Ralph Thomas wrote:
> Having "ordered unnamed dictionary entries" for virtual_machine
> functions is good, and really good in the case of an xstring_subst
> function (and you're right, even just using a dictionary is far better
> than what I was proposing as it syntactically suggests that unique
> substitution keys are required [as well as being far prettier]).
>
> One distant future thing that I've been thinking about for a while is
> abstracting out some of the policy that client_assembler bakes into
> widgets, for example we currently have things like:
>
> panel( bind: @named_value, value: "show_panel" ) { ... }
>
> meaning that the panel is displayed when @named_value is "show_panel";
> but what if I wanted to show the panel whenever @named_value !=3D
> "show_panel"? I could put a rule into the sheet for this, but would
> this be better?
>
> panel( visible: @named_value !=3D "show_panel" ) { ... }

This would require an anonymous function (or we would need some =20
syntax to denote what is initialization for a view and what is =20
dynamic - something like

panel(visible: function(){ return @named_value !=3D "show_panel; }) =20
{ ... }
panel(visible: rule(){ named_value !=3D "show_panel }) { ... }

I've considered going this route but avoided it as it quickly leeds =20
to the need for a full imperative language - the basic sheet on a =20
layout in .13 may allow for rules of this type in the future =20
(currently the basic sheet only handles initialization expressions =20
and bindings.

>
> or even to remove visibility from the panel totally:
>
> visible( predicate: @named_value !=3D "show_panel" ) {
>   panel() { ... }
> }
>
> If you took this idea to it's logical extent (breaking everything down
> into atoms) could you define all/most of the widgets in terms of these
> atoms? All of the button-type things would be easy, a checkbox might
> be:
>
> define_widget( "checkbox", parameters: { name: @cb_name, bind: =20
> @cb_value } ) {
>   row() {
>     /* how to put "indeterminate" value in here for mousedown (but not
> clicked) */
>     action( activate: @cb_value =3D !@cb_value ) {
>       overlay() {
>         visible( predicate: @cb_value =3D=3D true ) { image( src: =20
> "checked" ); }
>         visible( predicate: @cb_value =3D=3D false ) { image( src: =20
> "unchecked" ); }
>       }
>       static_text( name: @cb_name );
>     }
>   }
> }

I've also been trying to avoid getting into declarative descriptions =20
for widgets - although I think it is an interesting space, I'd like =20
to keep first focus on the space at hand. This is mostly because I =20
see the biggest challenge is in using Mac and Windows native UI =20
widgets. I do realize the layout engine comes in handy for a skinning =20=

system. You might look at Skinux <http://www.skinux.com/> for some =20
ideas - Skinux (or something similar) paired with the layout engine =20
would be fun.

>
> (and then you can use "checkbox" as you currently do, but it's
> actually just parameterizing the above definition each time --
> @cb_name and @cb_value get replaced; so checkbox( name: "foo", bind:
> @my_cell ) means that @cb_name is replaced by "foo" and @cb_value is
> replaced by @my_cell).
>
> If it were possible to implement all of the widgets in ui-core in
> terms of a small set of atoms (and have a "ui-core prelude file" that
> defines all of the ui-core widgets, like checkbox above) then
> implementing new widgets (such as those proposed in the wiki) should
> mostly be a matter of combining existant atoms (and hopefully atom
> implementation is easy enough that adding a new one is still less work
> than writing a widget for N platforms).

I'm on of those hold outs who _strongly_ believes that consistency =20
with other applications on the platform is a key component of =20
usability. This is why I push for trying to make sure we use the =20
platform widgets before looking to other solutions. Even if we had a =20
good skinning solution I'd still want the platform widget support.

>
> This "atomic toolkit" idea is clearly only 1/3 baked, I might try to
> write a simple implementation of this in Mission to learn more about
> the problems involved.

I would like to see it! Besides Skinux you might also look to include =20=

GIL and/or Anti-Grain in this work.

Sean

>
> Ralph
>
> On 2/11/06, Sean Parent <sp...@ad...> wrote:
>> Foster is the xstring export so I'll let him answer - I suspect we're
>> missing an API (I'd rather not have to go through a context for
>> replacement) - but I think you should be able to simply create a
>> local context as a workaround. I believe you also want to be using
>> the marker mechanism for the replacement (Foster?).
>>
>> For the xstring_sub function call - I don't think you are getting any
>> benefit by referring to cells by a quoted name then looking it up
>> manually - you can simply use the cell as a variable name. I'd
>> recommend making it a function taking named parameters -
>>
>> xstring_replace(string: "<xstr id=3D'string'><marker id=3D'text'/> =
the
>> number is <marker id=3D'num'/></xstr>",
>>                 text: val1, num: val2)
>>
>> I spent some time looking at some Lua code this last week - I'm
>> considering unifying the function mechanism to take a
>> pair<dictionary_t, array_t> similar to a Lua table - This would let
>> you write:
>>
>> xstring_replace("<xstr id=3D'string'><marker id=3D'text'/> the number =
is
>> <marker id=3D'num'/></xstr>",
>>                 text: val1, num: val2)
>>
>> And would allow for a single API to plug-in functions. Thoughts?
>>
>> Sean
>>
>> On Feb 11, 2006, at 12:15 AM, Ralph Thomas wrote:
>>
>>> Hi ASL,
>>>
>>>   I'm trying to write a function to do xstring substitution, which
>>> should work something like this:
>>>
>>> sheet {
>>>  interface:
>>>   val1 : "hello world, " ;
>>>   val2: 17 ;
>>>  output:
>>>   string <=3D=3D xstring_sub( "<xstring id=3D'text'/> the number is =20=

>>> <xstring
>>> id=3D'num'/>", [{ name: "text", value: @val1 }, { name: "num", =
value:
>>> @val2 }] );
>>> };
>>>
>>> and have @string be "hello world, the number is 17". I can easily =20=

>>> get
>>> the values that I need from the sheet, but how can I create an
>>> xstring_context_t that contains these values? Is there a way to =20
>>> put a
>>> value_t straight in there?
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
>>> log files
>>> for problems?  Stop!  Download the new AJAX search engine that makes
>>> searching your log files as easy as surfing the  web.  DOWNLOAD
>>> SPLUNK!
>>> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=1216=
42
>>> _______________________________________________
>>> Adobe-source-devel mailing list
>>> Ado...@li...
>>> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>>
>>