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