adobe-source-devel — ASL development topic discussion

[Adobe-source-devel] Re: asl-users: Request for Comments: ASL Picture Widget

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

On Feb 15, 2006, at 9:24 AM, Foster T. Brereton wrote:

> On Feb 14, 2006, at 06:43p, Sean Parent wrote:
>
>> First - what is this? If it is a visual label (like a static_text)  
>> - then the API is pretty good except there shouldn't be a "hit  
>> proc" - there should _never_ be a hit proc. This is either a label  
>> (a purely visual element like a static text) - a button, or a  
>> view. Not one picture to rule them all. If this is to be only a  
>> label, perhaps it should be combined with static_text under a new  
>> "label" widget - the binding to the image through Eve might be an  
>> href in the label (hmmm, maybe that's over kill) - and an  
>> alternate constructor on the label_t widget.
>
> This widget isn't intended to be an uber-implementation for all  
> general use cases of an image within an application. The hit test  
> proc, if anything, would simply be a void function or perhaps  
> return modifier keys. In either instance, I got the idea from  
> static_text_t, which, although it is a label, it too has a hit  
> proc. The hit proc for the static_text, when used, sets the focus  
> of the keyboard to the edit_text (or other widget) that that label  
> decorates.

static_text should not have a public hit proc. This is exposing an  
implementation detail of edit_text through static text. Ideally,  
event handling would be done by registering geometry with an event  
dispatcher, not by assuming that something will call through a  
widget. This should be removed or at least be made private to the  
platform implementation of edit_text.

> Perhaps this shouldn't be a public API, intended only for internal  
> use within the implementation: if that is the case I can file a bug  
> to have it removed. In that case, too, the public hit API for the  
> picture widget would also vanish. I was shooting for semantic  
> consistency across all things "label".

That would be good - static_text as a name has always bugged me as it  
really is just a decoration - it is neither a view or controller for  
anything (although it could be a view of external text in the future,  
but then it wouldn't be "static" - and we haven't gone there yet).  
For what you are describing I would create a new widget type, called  
"label" or "decoration" or something like that and group the current  
static text and this static picture into it.

Specifying the image through the Eve interface to this should be with  
a URL - consider that in the design for the factory.

>
>> If it is a button - mostly the same comments as above except it  
>> should be part of button_t.
>
> I never had any intention of making it behave as if it were a  
> button. It isn't intended to latch out to a command in any way.
>
>> If it is an image view (this would be the most ambitious widget) -  
>> then it should bind to an image view. The widget should support at  
>> least pan and zoom (these controls wouldn't need to be bind-able -  
>> but allow them to be bound would let you attach them to the basic  
>> sheet to preserve view state). I can envision all kinds of nice  
>> UI's for this (transparent overlay that comes up when you mouse  
>> over...) - could be slick - we can attempt to work with a UI  
>> designer to design the _last_ preview widget...
>
> This was the foundation upon which we began when coming up with the  
> design of the picture widget. I have no qualms about starting  
> simple and working our way up. The reason I began thinking about  
> the picture widget implementation is because I need icon support --  
> if we started there and worked our way forward, I would think it  
> would be a good way to do it.

No disagreement here.

>
> Blessings,
> Foster
>
>
> --
> Foster T. Brereton              <}}}><              Romans 3:21-26
> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
> "What 99 percent of programmers need to know is not how to build  
> components but how to use them." -- Alexander Stepanov
>
>

[Adobe-source-devel] Re: asl-users: Request for Comments: ASL Picture Widget

[Foster T. B. <fbr...@ad...>]

On Feb 14, 2006, at 06:43p, Sean Parent wrote:

> First - what is this? If it is a visual label (like a static_text)  
> - then the API is pretty good except there shouldn't be a "hit  
> proc" - there should _never_ be a hit proc. This is either a label  
> (a purely visual element like a static text) - a button, or a view.  
> Not one picture to rule them all. If this is to be only a label,  
> perhaps it should be combined with static_text under a new "label"  
> widget - the binding to the image through Eve might be an href in  
> the label (hmmm, maybe that's over kill) - and an alternate  
> constructor on the label_t widget.

This widget isn't intended to be an uber-implementation for all  
general use cases of an image within an application. The hit test  
proc, if anything, would simply be a void function or perhaps return  
modifier keys. In either instance, I got the idea from static_text_t,  
which, although it is a label, it too has a hit proc. The hit proc  
for the static_text, when used, sets the focus of the keyboard to the  
edit_text (or other widget) that that label decorates. Perhaps this  
shouldn't be a public API, intended only for internal use within the  
implementation: if that is the case I can file a bug to have it  
removed. In that case, too, the public hit API for the picture widget  
would also vanish. I was shooting for semantic consistency across all  
things "label".

> If it is a button - mostly the same comments as above except it  
> should be part of button_t.

I never had any intention of making it behave as if it were a button.  
It isn't intended to latch out to a command in any way.

> If it is an image view (this would be the most ambitious widget) -  
> then it should bind to an image view. The widget should support at  
> least pan and zoom (these controls wouldn't need to be bind-able -  
> but allow them to be bound would let you attach them to the basic  
> sheet to preserve view state). I can envision all kinds of nice  
> UI's for this (transparent overlay that comes up when you mouse  
> over...) - could be slick - we can attempt to work with a UI  
> designer to design the _last_ preview widget...

This was the foundation upon which we began when coming up with the  
design of the picture widget. I have no qualms about starting simple  
and working our way up. The reason I began thinking about the picture  
widget implementation is because I need icon support -- if we started  
there and worked our way forward, I would think it would be a good  
way to do it.

Blessings,
Foster


--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"What 99 percent of programmers need to know is not how to build  
components but how to use them." -- Alexander Stepanov

[Adobe-source-devel] Re: asl-users: Request for Comments: ASL Picture Widget

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

The semantic description is a bit at odds with itself and with the API -

First - what is this? If it is a visual label (like a static_text) -  
then the API is pretty good except there shouldn't be a "hit proc" -  
there should _never_ be a hit proc. This is either a label (a purely  
visual element like a static text) - a button, or a view. Not one  
picture to rule them all. If this is to be only a label, perhaps it  
should be combined with static_text under a new "label" widget - the  
binding to the image through Eve might be an href in the label (hmmm,  
maybe that's over kill) - and an alternate constructor on the label_t  
widget.

If it is a button - mostly the same comments as above except it  
should be part of button_t.

If it is an image view (this would be the most ambitious widget) -  
then it should bind to an image view. The widget should support at  
least pan and zoom (these controls wouldn't need to be bind-able -  
but allow them to be bound would let you attach them to the basic  
sheet to preserve view state). I can envision all kinds of nice UI's  
for this (transparent overlay that comes up when you mouse over...) -  
could be slick - we can attempt to work with a UI designer to design  
the _last_ preview widget...

If there is a monitor function - that would imply an image editor...  
perhaps a bit too ambitious for the first cut.

Sean

On Feb 14, 2006, at 4:06 PM, Foster T. Brereton wrote:

> All,
>
> Ralph Thomas and I have begun designing a picture widget for ASL.  
> This widget will cover icons in a generic way as well. The in- 
> development design is posted at:
>
> 	<http://opensource.adobe.com/twiki/bin/view/AdobeSource/PictureView>
>
> We would welcome any commentary, feedback, and/or refinement on the  
> design or the documentation. If anyone would like to contribute  
> please provide it either by email to the ASL mailing list or on the  
> Wiki page directly. If you do not have write access to the Wiki  
> page yet please create a Wiki account; once that is done email me  
> and I will authorize you.
>
> Thanks in advance for any time you can give to the effort.
>
> Blessings,
> Foster
>
>
> --
> Foster T. Brereton              <}}}><              Romans 3:21-26
> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
> "What 99 percent of programmers need to know is not how to build  
> components but how to use them." -- Alexander Stepanov
>
>

[Adobe-source-devel] Re: asl-users: Request for Comments: ASL Picture Widget

[Tony V. E. <to...@ad...>]

Tony Van Eerd
Adobe Waterloo
-via Thunderbird-

Foster T. Brereton wrote:
> On Feb 14, 2006, at 04:22p, Tony Van Eerd wrote:
> 
>> I have a ProportionalFit<number_type> template that might help with  
>> the proportional resizing.  I can email it to you.
> 
> 
> Ah, this is interesting. Would it make a good addition to ASL as a  
> generic algorithm? GIL might have something like this in it already,  
> too, I'm not sure (sadly I haven't looked over the API as thoroughly  as 
> I ought).
> 

I think it, or some other generic prop-fit solution, should be in ASL - 
I wrote mine because I saw prop-fit code being rewritten (with bugs) 
over and over.  I've sent it to you in another email.  Do as you please.

>> I did a image view control once that also implemented the image  
>> interface - ie acxted like an image in that you could call CopyImage 
>> (view, image) (which takes 2 image * params) to put an image into  it, 
>> etc.  Interesting idea, anyhow.
> 
> 
> Interesting. Are you familiar with Lubomir and Hailin's work on GIL?  
> How would what you are describing compare to what it has to offer?
> 

Looking more closely at GIL is on my todo list, but it is a really long 
list.  Without a closer look, I would guess that what I was doing was 
more bassed on a abstract base class model of an image, and GIL is 
template based.

The interface class I was using has interesting things like 
BeginAccess(region) ... EndAccess() for accessing the pixels.  The 
EndAccess was particularly interesting because you could then chain 
actions to the end of the write (ie update the UI in the case of an 
image widget, or use this image as the middle layer of a 3 layer 
composite in a paint program, with the composite result image chained to 
an action that updated part of the UI, etc).


>> The import/export procs will eventually need to handle options.  Do  
>> you expect the import/export procs to bring up UI, or should you  pass 
>> in a dictionary_t of params to the export funcs, or something  like that?
> 
> 
> This is a good question. I'd expect the functions to be able to run  
> without user intervention (so scripting parameters should be able to  be 
> passed), but the possibility of popping a UI to detail further  command 
> parameters is not out of the question. I'll have to think a  bit more 
> about this one. Incidentally we have recently released a  modal dialog 
> interface API that accomplishes this very task pretty  handily, so 
> leveraging that might be good.
> 

'leveraging' but not depending on, right? :-)


>> Tony Van Eerd
>> Adobe Waterloo
>> -via Thunderbird-
>>
>> Foster T. Brereton wrote:
>>
>>> All,
>>> Ralph Thomas and I have begun designing a picture widget for ASL.   
>>> This widget will cover icons in a generic way as well. The in-  
>>> development design is posted at:
>>>     <http://opensource.adobe.com/twiki/bin/view/AdobeSource/ 
>>> PictureView>
>>> We would welcome any commentary, feedback, and/or refinement on  the  
>>> design or the documentation. If anyone would like to  contribute  
>>> please provide it either by email to the ASL mailing  list or on the  
>>> Wiki page directly. If you do not have write  access to the Wiki 
>>> page  yet please create a Wiki account; once  that is done email me 
>>> and I  will authorize you.
>>> Thanks in advance for any time you can give to the effort.
>>> Blessings,
>>> Foster
>>> -- 
>>> Foster T. Brereton              <}}}><              Romans 3:21-26
>>> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
>>> "What 99 percent of programmers need to know is not how to build   
>>> components but how to use them." -- Alexander Stepanov
> 
> 
> -- 
> Foster T. Brereton              <}}}><              Romans 3:21-26
> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
> "What 99 percent of programmers need to know is not how to build  
> components but how to use them." -- Alexander Stepanov
> 
> 
> 

[Adobe-source-devel] Re: asl-users: Request for Comments: ASL Picture Widget

[Foster T. B. <fbr...@ad...>]

On Feb 14, 2006, at 04:22p, Tony Van Eerd wrote:

> I have a ProportionalFit<number_type> template that might help with  
> the proportional resizing.  I can email it to you.

Ah, this is interesting. Would it make a good addition to ASL as a  
generic algorithm? GIL might have something like this in it already,  
too, I'm not sure (sadly I haven't looked over the API as thoroughly  
as I ought).

> I did a image view control once that also implemented the image  
> interface - ie acxted like an image in that you could call CopyImage 
> (view, image) (which takes 2 image * params) to put an image into  
> it, etc.  Interesting idea, anyhow.

Interesting. Are you familiar with Lubomir and Hailin's work on GIL?  
How would what you are describing compare to what it has to offer?

> The import/export procs will eventually need to handle options.  Do  
> you expect the import/export procs to bring up UI, or should you  
> pass in a dictionary_t of params to the export funcs, or something  
> like that?

This is a good question. I'd expect the functions to be able to run  
without user intervention (so scripting parameters should be able to  
be passed), but the possibility of popping a UI to detail further  
command parameters is not out of the question. I'll have to think a  
bit more about this one. Incidentally we have recently released a  
modal dialog interface API that accomplishes this very task pretty  
handily, so leveraging that might be good.

> Tony Van Eerd
> Adobe Waterloo
> -via Thunderbird-
>
> Foster T. Brereton wrote:
>> All,
>> Ralph Thomas and I have begun designing a picture widget for ASL.   
>> This widget will cover icons in a generic way as well. The in-  
>> development design is posted at:
>>     <http://opensource.adobe.com/twiki/bin/view/AdobeSource/ 
>> PictureView>
>> We would welcome any commentary, feedback, and/or refinement on  
>> the  design or the documentation. If anyone would like to  
>> contribute  please provide it either by email to the ASL mailing  
>> list or on the  Wiki page directly. If you do not have write  
>> access to the Wiki page  yet please create a Wiki account; once  
>> that is done email me and I  will authorize you.
>> Thanks in advance for any time you can give to the effort.
>> Blessings,
>> Foster
>> -- 
>> Foster T. Brereton              <}}}><              Romans 3:21-26
>> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
>> "What 99 percent of programmers need to know is not how to build   
>> components but how to use them." -- Alexander Stepanov

--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"What 99 percent of programmers need to know is not how to build  
components but how to use them." -- Alexander Stepanov

[Adobe-source-devel] RE: asl-users: Request for Comments: ASL Picture Widget

[Lubomir B. <lbo...@ad...>]

Foster,
=20
My recommendation is that the image IO be written as a GIL extension =
module.
We already have a GIL extension to load/save images (JPEG and TIFF files =
are currently supported).
Hailin is interested in us pushing towards releasing the extension.
It is currently not in ASL for these reasons:
=20
1. The code needs to be reviewed
2. Only the common color spaces and channel depths are supported (some =
uncommon JPEG and TIFF files may fail to load)
3. There is a dependency to libjpeg and libtiff. I was reluctant to =
having .lib files as part of GIL, due to the platforms and compile =
setting combinations we need to provide and maintain.
4. I am unsure about the licensing terms of the above mentioned =
libraries.
=20
You can find the GIL I/O extension on boxer:1770 here:
//gil/extension/io/
=20
And the libs are here:
=20
//gil/lib/libjpeg/=20
//gil/lib/libtiff/
=20
Lubomir
=20

________________________________

From: own...@ad... on behalf of Foster T. Brereton
Sent: Tue 2/14/2006 4:06 PM
To: ASL External; ASL Users
Subject: asl-users: Request for Comments: ASL Picture Widget



All,

Ralph Thomas and I have begun designing a picture widget for ASL.=20
This widget will cover icons in a generic way as well. The in-
development design is posted at:

        =
<http://opensource.adobe.com/twiki/bin/view/AdobeSource/PictureView>

We would welcome any commentary, feedback, and/or refinement on the=20
design or the documentation. If anyone would like to contribute=20
please provide it either by email to the ASL mailing list or on the=20
Wiki page directly. If you do not have write access to the Wiki page=20
yet please create a Wiki account; once that is done email me and I=20
will authorize you.

Thanks in advance for any time you can give to the effort.

Blessings,
Foster


--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"What 99 percent of programmers need to know is not how to build=20
components but how to use them." -- Alexander Stepanov

[Adobe-source-devel] Re: asl-users: Request for Comments: ASL Picture Widget

[Tony V. E. <to...@ad...>]

I have a ProportionalFit<number_type> template that might help with the 
proportional resizing.  I can email it to you.

I did a image view control once that also implemented the image 
interface - ie acxted like an image in that you could call 
CopyImage(view, image) (which takes 2 image * params) to put an image 
into it, etc.  Interesting idea, anyhow.

The import/export procs will eventually need to handle options.  Do you 
expect the import/export procs to bring up UI, or should you pass in a 
dictionary_t of params to the export funcs, or something like that?

Tony Van Eerd
Adobe Waterloo
-via Thunderbird-

Foster T. Brereton wrote:
> All,
> 
> Ralph Thomas and I have begun designing a picture widget for ASL.  This 
> widget will cover icons in a generic way as well. The in- development 
> design is posted at:
> 
>     <http://opensource.adobe.com/twiki/bin/view/AdobeSource/PictureView>
> 
> We would welcome any commentary, feedback, and/or refinement on the  
> design or the documentation. If anyone would like to contribute  please 
> provide it either by email to the ASL mailing list or on the  Wiki page 
> directly. If you do not have write access to the Wiki page  yet please 
> create a Wiki account; once that is done email me and I  will authorize 
> you.
> 
> Thanks in advance for any time you can give to the effort.
> 
> Blessings,
> Foster
> 
> 
> -- 
> Foster T. Brereton              <}}}><              Romans 3:21-26
> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
> "What 99 percent of programmers need to know is not how to build  
> components but how to use them." -- Alexander Stepanov
> 
> 
> 

[Adobe-source-devel] Request for Comments: ASL Picture Widget

[Foster T. B. <fbr...@ad...>]

All,

Ralph Thomas and I have begun designing a picture widget for ASL.  
This widget will cover icons in a generic way as well. The in- 
development design is posted at:

	<http://opensource.adobe.com/twiki/bin/view/AdobeSource/PictureView>

We would welcome any commentary, feedback, and/or refinement on the  
design or the documentation. If anyone would like to contribute  
please provide it either by email to the ASL mailing list or on the  
Wiki page directly. If you do not have write access to the Wiki page  
yet please create a Wiki account; once that is done email me and I  
will authorize you.

Thanks in advance for any time you can give to the effort.

Blessings,
Foster


--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"What 99 percent of programmers need to know is not how to build  
components but how to use them." -- Alexander Stepanov

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
>>
>>

[Adobe-source-devel] adobe-source bug database revitalized

[Foster T. B. <fbr...@ad...>]

All,

We have taken some time this last week to post some fresh bugs and  
feature requests to the adobe-source SourceForge page. We would like  
to continue using SourceForge for the management of bugs and feature  
requests going forward as well. Please make use of them if you have  
bugs or requests you'd like to communicate to ASL developers.

Blessings,
Foster


--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"What 99 percent of programmers need to know is not how to build  
components but how to use them." -- Alexander Stepanov

Re: [Adobe-source-devel] xstring questions

[Foster T. B. <fbr...@ad...>]

Yes, currently we're missing an API. One of the requirements for the  
string replacement code was to take the best possible source xstring  
based on the replacement tokens provided, which implied there was  
more than one source xstring -- currently all candidate strings are  
stored in a context, but this could be avoided in the case when you  
have one xstring and just want to flesh it out. I'll add it to the  
bugbase.

Blessings,
Foster


On Feb 11, 2006, at 02:04p, Sean Parent wrote:

> 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?).

--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"What 99 percent of programmers need to know is not how to build  
components but how to use them." -- Alexander Stepanov

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

[Ralph T. <ra...@gm...>]

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" ) { ... }

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: @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: "checked"=
 ); }
        visible( predicate: @cb_value =3D=3D false ) { image( src: "uncheck=
ed" ); }
      }
      static_text( name: @cb_name );
    }
  }
}

(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).

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.

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 <xs=
tring
> > id=3D'num'/>", [{ name: "text", value: @val1 }, { name: "num", value:
> > @val2 }] );
> > };
> >
> > and have @string be "hello world, the number is 17". I can easily 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 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=12164=
2
> > _______________________________________________
> > Adobe-source-devel mailing list
> > Ado...@li...
> > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>
>

Re: [Adobe-source-devel] xstring questions

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

Foster is the xstring export so I'll let him answer - I suspect we're =20=

missing an API (I'd rather not have to go through a context for =20
replacement) - but I think you should be able to simply create a =20
local context as a workaround. I believe you also want to be using =20
the marker mechanism for the replacement (Foster?).

For the xstring_sub function call - I don't think you are getting any =20=

benefit by referring to cells by a quoted name then looking it up =20
manually - you can simply use the cell as a variable name. I'd =20
recommend making it a function taking named parameters -

xstring_replace(string: "<xstr id=3D'string'><marker id=3D'text'/> the =20=

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 =20
considering unifying the function mechanism to take a =20
pair<dictionary_t, array_t> similar to a Lua table - This would let =20
you write:

xstring_replace("<xstr id=3D'string'><marker id=3D'text'/> the number is =
=20
<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 =
<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 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 put a
> value_t straight in there?
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD =20
> SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=121642=

> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] xstring questions

[Ralph T. <ra...@gm...>]

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 <xstrin=
g
id=3D'num'/>", [{ name: "text", value: @val1 }, { name: "num", value:
@val2 }] );
};

and have @string be "hello world, the number is 17". I can easily 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 put a
value_t straight in there?

Re: [Adobe-source-devel] ASL and nibs

[David C. <unc...@un...>]

On Feb 2, 2006, at 11:31 AM, Sean Parent wrote:
> Out of curiosity - are there particular layouts that give you  
> trouble with Eve?

One layout I had trouble with - though I have since redesigned it -  
was one with four group boxes arranged in a 2x2 grid. Since Eve does  
columns and rows, but not grids, I couldn't get that to come out right.

My current issue, as I said, is that I'm designing a layout for the  
custom content in a Save As dialog, which needs to be embedded in a  
User Pane or something so I can give it to Nav Services.

The main thing, I think, is that I like to be able to tweak and fine- 
tune a layout. It may be possible with Eve, but until we have  
Espresso the process is just too tedious.

-- 
David Catmull
unc...@un...
http://www.uncommonplace.com/

Re: [Adobe-source-devel] Win32 nested group

[Ralph T. <ra...@gm...>]

It wouldn't be too hard to just catch the WM_PAINT message and do the
correct thing on that; I didn't have time last night to investigate
that (once I realized that I was dealing with a Win32 bug and not one
of our own). The other bug that we have with groups is that buttons
inside groups have a thick (uneven) outline when visual styles are
enabled. I don't know why that is happening currently.

Ralph

On 2/2/06, Sean Parent <sp...@ad...> wrote:
>
> On Feb 2, 2006, at 1:24 AM, Ralph Thomas wrote:
>
> > So what I have checked in is better than what was happening before,
> > but still not perfect. Hopefully there is a message that I can do
> > something with to ensure that the text measurement is correct (but I
> > didn't have time to look tonight).
>
> Thanks for all the hard work! If we can't figure out a way to work
> around the bug - what would it take to have a "custom" windows widget
> that mimicked a group but with correct behavior?
>
> Sean
>

Re: [Adobe-source-devel] ASL and nibs

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

Foster's been working to clean-up the Mac UI core implementation for  
today's release - take a look once it's out then you might work with  
him to see if there is a way to get what you want.

Out of curiosity - are there particular layouts that give you trouble  
with Eve? If you can, send me a screen shot of a layout from IB -  
I've got a list of changes I want to make to the Eve engine cued up  
(mostly in support of RTL languages) that I'll be rolling into .14  
or .15 - I'm hoping to improve the poi/guide implementation as part  
of this work.

Sean

On Feb 2, 2006, at 7:09 AM, David Catmull wrote:

> On Feb 1, 2006, at 10:41 PM, Sean Parent wrote:
>> Not quite sure what you mean by an "ASL dialog"? Do you want to  
>> connect a nib based layout to an Adam sheet? Do you want to  
>> connect it to an Eve layout? I'd guess you are going to try to  
>> connect it to an Adam sheet to pick up the logic.
>
> Right, I mainly want Adam, but I was hoping to use the existing  
> widget classes since they already have the event handlers.
>
> -- 
> David Catmull
> unc...@un...
> http://www.uncommonplace.com/
>
>
>
> -------------------------------------------------------
> 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=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] Win32 nested group

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

On Feb 2, 2006, at 1:24 AM, Ralph Thomas wrote:

> So what I have checked in is better than what was happening before,
> but still not perfect. Hopefully there is a message that I can do
> something with to ensure that the text measurement is correct (but I
> didn't have time to look tonight).

Thanks for all the hard work! If we can't figure out a way to work  
around the bug - what would it take to have a "custom" windows widget  
that mimicked a group but with correct behavior?

Sean

Re: [Adobe-source-devel] Win32 nested group

[Foster T. B. <fbr...@ad...>]

I have checked in this change and it'll roll out today in the 1.0.13 =20
release. Things look much better than they did before. Your continued =20=

support of the project is greatly appreciated Ralph -- thanks again!

Blessings,
Foster


On Feb 2, 2006, at 01:24a, Ralph Thomas wrote:

> I took a look at the nested group issue on Win32 this evening. The
> issue was that groups inside groups used the wrong font when visual
> styles were enabled (they calculated metrics for the correct font, but
> then went and used the "System" font to draw text). I think that this
> is actually a bug in Win32 (it seems to be exposed in some versions of
> Windows.Forms, according to newsgroups).
>
> To partially address the issue I now do not send the WM_SETFONT
> message to the group box control in set_theme, this means that the
> group box will draw with the font given to it in response to the
> WM_CTLCOLORSTATIC message it sends out. This has the distinct
> disadvantage that the nested groups no longer seem to be able to
> measure the text they have correctly, and thus draw the group line
> behind the group title text (but giving the group a font via
> WM_SETFONT means I can't work around the Win32 bug with
> WM_CTLCOLORSTATIC).
>
> So what I have checked in is better than what was happening before,
> but still not perfect. Hopefully there is a message that I can do
> something with to ensure that the text measurement is correct (but I
> didn't have time to look tonight).
>
> Ralph
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD =20
> SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=121642=

> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"The fact is that the author of STL does not know how to write min, =20
the author of C++ is not quite sure, and the standards committee is =20
at a loss." -- Alexander Stepanov

Re: [Adobe-source-devel] ASL and nibs

[David C. <unc...@un...>]

On Feb 1, 2006, at 10:41 PM, Sean Parent wrote:
> Not quite sure what you mean by an "ASL dialog"? Do you want to  
> connect a nib based layout to an Adam sheet? Do you want to connect  
> it to an Eve layout? I'd guess you are going to try to connect it  
> to an Adam sheet to pick up the logic.

Right, I mainly want Adam, but I was hoping to use the existing  
widget classes since they already have the event handlers.

-- 
David Catmull
unc...@un...
http://www.uncommonplace.com/

[Adobe-source-devel] Win32 nested group

[Ralph T. <ra...@gm...>]

I took a look at the nested group issue on Win32 this evening. The
issue was that groups inside groups used the wrong font when visual
styles were enabled (they calculated metrics for the correct font, but
then went and used the "System" font to draw text). I think that this
is actually a bug in Win32 (it seems to be exposed in some versions of
Windows.Forms, according to newsgroups).

To partially address the issue I now do not send the WM_SETFONT
message to the group box control in set_theme, this means that the
group box will draw with the font given to it in response to the
WM_CTLCOLORSTATIC message it sends out. This has the distinct
disadvantage that the nested groups no longer seem to be able to
measure the text they have correctly, and thus draw the group line
behind the group title text (but giving the group a font via
WM_SETFONT means I can't work around the Win32 bug with
WM_CTLCOLORSTATIC).

So what I have checked in is better than what was happening before,
but still not perfect. Hopefully there is a message that I can do
something with to ensure that the text measurement is correct (but I
didn't have time to look tonight).

Ralph

Re: [Adobe-source-devel] ASL and nibs

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

Not quite sure what you mean by an "ASL dialog"? Do you want to  
connect a nib based layout to an Adam sheet? Do you want to connect  
it to an Eve layout? I'd guess you are going to try to connect it to  
an Adam sheet to pick up the logic.

All of the components of ASL can be used individually - you can use  
adam_parser/evaluate/adam to construct your sheet, then read in your  
nib (I assume you just want to let the Mac just construct your  
dialog) - then traverse the HIView and bind the carbon events you  
want to cells in the sheet (if you have a string for a property and  
you want to parser it you can use the expression parser and  
virtual_machine to parse and evaluate it). To see how to bind to  
carbon events, take a look at the Mac UI core implementation. I  
wouldn't object to having a Mac only addition that let you construct  
our widgets (like a checkbox_t) from an appropriate HIView.

If you want to use an Eve layout, things get a bit more tricky as you  
need to provide Eve with the layout hierarchy - you could do that  
from a carefully constructed nib (maybe using some panels as proxies  
for row/column layout) - but inferring a layout isn't going to work.

Going with nibs you'll lose the dynamic layout that Eve enables,  
localization, and cross platform descriptions - I'm hoping someone  
will step up to write a visual editor (the infamous Expresso double- 
shot) then we can have the best of both worlds. The ASL components  
are all being designed with a visual editor in mind (this is why  
comments are built into the syntax for Adam and Eve - to support  
round-trip editing). We'll get there eventually.

Sean

On Feb 1, 2006, at 5:18 PM, David Catmull wrote:

> Is there any way to set up an ASL dialog using existing controls,  
> such as from a nib file? It seems none of the control classes have  
> constructors that will take a ControlRef.
>
> I want to use a nib because, basically, it's easier to use  
> Interface Builder to design my dialogs. I'm thinking along the  
> lines of adding the binding information using control properties.
>
> Also, my current task is creating custom content for a Navigation  
> Services "save as" dialog, so having Eve create its own window may  
> be hard to work with.
>
> -- 
> David Catmull
> unc...@un...
> http://www.uncommonplace.com/
>
>
>
> -------------------------------------------------------
> 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=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] ASL and nibs

[David C. <unc...@un...>]

Is there any way to set up an ASL dialog using existing controls,  
such as from a nib file? It seems none of the control classes have  
constructors that will take a ControlRef.

I want to use a nib because, basically, it's easier to use Interface  
Builder to design my dialogs. I'm thinking along the lines of adding  
the binding information using control properties.

Also, my current task is creating custom content for a Navigation  
Services "save as" dialog, so having Eve create its own window may be  
hard to work with.

-- 
David Catmull
unc...@un...
http://www.uncommonplace.com/

[Adobe-source-devel] Re: asl-users: Widget Parenting Issues

[Tom P. <tpi...@ad...>]

And it was also brought to my attention that you can indeed re-parent a Qt
widget that is initially created with a NULL parent - very good to know. The
only question then is whether there's any significant overhead involved if
this means each such widget is first created as a platform window and then
changed to a child view when re-parented. I'll guess I'll cross that
bridge...

Thanks,

Tom


> If it helps with implementation issues, you can easily reparent a Window
> to another parent using SetParent() (at least within the same process).
>   I suspect all controls could start with the same parent - an invisible
> window hiding somewhere, and then be reparented 'when the time is right'.
> 
> 
> Tony Van Eerd
> Adobe Waterloo
> -via Thunderbird-
> 
> Tom Pinkerton wrote:
>> Hi All,
>> 
>> While digging into my Qt implementation of the widgets library, I've noticed
>> that a widget's parent appears to be set after the underlying platform
>> widget itself is created. On MacOS this is not a problem because a control
>> can be initially created without a parent. However, the existing Windows
>> implementation uses some kind of 'invisible parent' member as an initial
>> parent when a control is created. In Qt, like on Windows, a widget needs a
>> parent at creation time, so I'm wondering if I will need a similar
>> 'invisible parent' mechanism for my Qt implementation. Does Eve somehow rely
>> upon setting the parent after a widget is initially created? Is the sole
>> purpose of the display_t object to provide a way to set the widget's parent
>> hierarchy? Will the parent hierarchy ever change for a given Eve layout
>> after the initial layout is created?
>> 
>> Thanks,
>> 
>> Tom

[Adobe-source-devel] Re: asl-users: Widget Parenting Issues

[Tom P. <tpi...@ad...>]

This makes sense. The beauty of it is to re-implement the display module
required changing only a single line of code. Very nice.

Thanks,

Tom


>>> Hi All,
>>> 
>>> While digging into my Qt implementation of the widgets library,
>>> I've noticed
>>> that a widget's parent appears to be set after the underlying
>>> platform
>>> widget itself is created. On MacOS this is not a problem because a
>>> control
>>> can be initially created without a parent. However, the existing
>>> Windows
>>> implementation uses some kind of 'invisible parent' member as an
>>> initial
>>> parent when a control is created. In Qt, like on Windows, a widget
>>> needs a
>>> parent at creation time, so I'm wondering if I will need a similar
>>> 'invisible parent' mechanism for my Qt implementation.
>> 
>> Yes, you will need to do the same for Qt.
> 
> The rational for display_t was to begin to abstract away the notion
> of a view hierarchy from the widgets that the hierarchy contains -
> we're going for an STL container model here as opposed to an
> obtrusive "every object has it's own list of children".
> 
> The principal of minimal requirements for an interface then implies
> that a widget would not have knowledge of this container, but rather
> would be associated with the view hierarchy after construction.
> 
> Because display_t actually lives within the framework (Win32, QT,
> whatever) - our implementation is a thin interface shim (much as
> checkbox_t is a thin shim on the platform checkbox interface). The
> invisible window is a hack so that checkbox_t and display_t can
> maintain a correct interface.
> 
>> 
>>> Does Eve somehow rely
>>> upon setting the parent after a widget is initially created?
>> 
>> Yes -- this is due to the fact that the widgets themselves aren't
>> supposed to manage their child-parent relationships; this is
>> modeled currently by the separation of the ui_core from the display
>> code. The display's intent is to manage parent/child relationships
>> within the visual heirarchy, completely separate from the widgets
>> themselves. A widget is first created in the ui_core, then it is
>> attached to the visual hierarchy through the display code. Thus, it
>> must exist before it can be attached, requiring the invisible
>> window for platforms where widgets must be contained by a window at
>> all times.
> 
> To correct Foster, The Eve layout engine does not make such an
> assumption - Eve doesn't even deal with the construction pass at all.
> This is handled through the eve_evaluate code (which exists to make
> it easier to connect the data coming out of the eve parser with a
> widget factory and an eve layout). The design here is purely part of
> the widget library. Eve can be wired to an existing framework without
> going through the widget library - in fact the widget library started
> life as throw away code in Begin to demonstrate how to Eve up to a
> framework (the original implementation was done with the proxy
> objects direct to Mac Carbon controls). It became apparent that have
> a thin "widget library" would make adoption of Adam and Eve simpler
> so we've been working to rework the widget library in a way which is
> intended to be framework independent.
> 
>> 
>>> Is the sole
>>> purpose of the display_t object to provide a way to set the
>>> widget's parent
>>> hierarchy?
>> 
>> Yes. Sean had other justifications for the display code, but I
>> can't remember them currently.
>> 
>>> Will the parent hierarchy ever change for a given Eve layout
>>> after the initial layout is created?
>> 
>> No -- the description of the layout specifies the hierarchy, and it
>> is parsed only when the view is first created. Ralph Thomas has
>> done some work with populating parents dynamically with children as
>> an optimization (e.g., only populating a scrollable list of image
>> thumbnails with those thumbs that are currently in the view
>> clipping rect) but it's not a part of ASL currently. Note this is a
>> different behavior from hiding and showing widgets, however (which
>> is something we do support).
> 
> The engine does support adding nodes to the graph post initial layout
> - although we don't make use if it in the current code (as Foster
> points out, Ralph is making use of it). It doesn't currently support
> removing nodes (the optional panel is handled by filtering nodes
> within the layout, not removing them). The ability to remove nodes
> may be added in the future if there is strong demand - but it is
> generally a risky prospect. If you remove a node you would invalidate
> any iterators to that node or it's children and widgets currently
> communicate with the layout by hanging onto their position. Robust
> support for remove would require something like slots/signals to
> notify connected items that they were being disconnected. I haven't
> found a use case for this yet.
> 
>> 
>> Keep the questions coming!
>> 
>> Blessings,
>> Foster
>> 
>> 
>> --
>> Foster T. Brereton              <}}}><              Romans 3:21-26
>> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
>> "The fact is that the author of STL does not know how to write min,
>> the author of C++ is not quite sure, and the standards committee is
>> at a loss." -- Alexander Stepanov
>> 
>> 
>