[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