[Laszlo-dev] For Review: Change 20090103-hqm-F Summary: always set textfield.mouseEnabled=true in swf9 LzTextSprite

[André Bargull]

On 1/5/2009 4:14 PM, Henry Minsky wrote:
> I have a thought which will let us defer making a final decision about
> a public API here ...

It is already a public API and documented in the 4.2 reference. (Because 
everything which isn't declared as "@access private" is automatically 
taken as public..)

> I can modify makeTextLink to
> actually add the link to the text field, rather than just returning a
> string. That addresses Tucker's concern
> that in some runtimes a link may not be just text data. 

Wouldn't be "addTextLink" a more adequate name in that case? And what 
about the textual representation of text-links? So should LzText#text 
contain the <a>-/<span>-tag (so the text-string will be different on all 
runtimes), or should it just contain the content of the text-link?

> I can also  modify the swf9 kernel implementation of makeTextLink to set
> mouseEnabled=true , so we don't need to have any other explicit API
> call to make the links
> start working.

But what should happen if the text was cleared, so set to the empty 
string? In that case, you don't want to have "mouseEnabled" set to 
`true` because mouse-events need to pass through the text-view. And even 
if "mouseEnabled" is set to `true`, it isn't fully compatible to swf8, 
I've added another testcase to LPP-7551 which demonstrate that issue.


> 
> I'm looking at the Flash 10 text api this week, and as an intermediate
> step I'm going to try to make the
> LzTextSprite API a little more explicit in terms of the args that get
> passed in at instantiation time.
> 
> The Flash 10 Text Layout API  uses an object called a TextFlow which
> replaces the
> TextField that we are currently using. TextFlow has a bunch of more
> sophisticated "model-view-controller"
> hooks, that allow editors and stuff to be attached to it. It also  has
> an API which lets you specify
> text layout via a richer dialect of HTML markup.
> 
>  I am trying to to figure out if we want our LzTextSprite to
> talk to the Flash TextFlow object using their fancier HTML dialect, or
> if we want to access it using
> their lower level APIs. Probably some mixture of the two...
> 
> 
> 
> 
> 
> On Sun, Jan 4, 2009 at 3:44 PM, P T Withington <ptw at pobox.com> wrote:
>> I wonder if we should do a little more designing before publishing this new
>> feature.  I'd hate to get locked in to a random API.  I'd at least like to
>> keep this API private until we are happy with it.
>>
>> Aren't what you really doing is enabling a callback from a span of text?
>>  Maybe we should be using `callback` instead of `link`?
>>
>> Also, in the test case, it seems odd to use %s to insert this callback in
>> the text.  It seems quite plausible to me that there could be some runtime
>> where you cannot just inject text to create a callback (e.g., you might have
>> to draw a target box or something).  It's probably a bug in %s if it does
>> not escape HTML (which would defeat the example).
>>
>> I'm thinking there should be a more abstract interface, perhaps using
>> `format` that would allow you to specify a callback.  Something like:
>>
>>> <class name="testcase" extends="text"
>>>        multiline="true" width="150"    >
>>>   <handler name="oninit" >
>>>     this.format("click %!s or %!s", 'callback', 'here', 'callback',
>>> 'there');
>>>   </handler>
>>>   <method name="callback" args="val" >
>>>     this.addFormat("\n%s was clicked", val);
>>>   </method>
>>>  </class>
>>
>> That is, add a new flag '!' (mnemonic executable magic number, or emacs m-!
>> (execute shell command), etc.) which takes the next argument as a method to
>> call, and indicates that the formatted version of the subsequent argument
>> should be clickable (and call the method with that object as an argument).
>>  (Similar in spirit to the `=` flag that lets you associate an object with a
>> presentation for the debugger to inspect.)
>>
>> That's my 2p. at least.
>>
>>
>> On 2009-01-04, at 11:50EST, André Bargull wrote:
>>
>>> Yes, I think that's the way to go. Maybe the name shouldn't contain
>>> "hyperlink" but instead "textlink" because the method is also called
>>> "makeTextLink(..)". And how about to use just "textlinks", because IMO
>>> writing "enabletextlinks" is a bit too cumbersome.
>>>
>>> <text enabletextlinks="true" />
>>> <text textlinks="true" />
>>>
>>>
>>>
>>> On 1/4/2009 4:48 PM, Henry Minsky wrote:
>>>> Yeah, I guess we had better not set mouseEnabled=true by default. But
>>>> it looks like we do need to set it in order
>>>> to make text links clickable. So maybe we have to add a new flag
>>>> "enablehyperlinks" or something, to let
>>>> the user specify that they want mouse clicks to be accepted, but don't
>>>> necessarily want the other
>>>> behaviors of 'selectable' or 'clickable'?
>>>> On Sun, Jan 4, 2009 at 8:51 AM, André Bargull <andre.bargull at udo.edu>
>>>> wrote:
>>>>> If you set "mouseEnabled" to `true` unconditionally, you'll reintroduce
>>>>> LPP-6086, won't you?
>>>>>
>>>>>
>>>>> On 1/4/2009 5:25 AM, Henry Minsky wrote:
>>>>>> This  change just keeps textfield.mouseEnabled = true all the time in
>>>>>> the
>>>>>> LzTextSprite. This at least makes the same behavior in swf8 and swf9,
>>>>>> for
>>>>>> non-clickable text with links.
>>>>>>
>>>>>> The current behavior in swf8, when  clickable=true on a <text> view,
>>>>>> clicking on a hyperlink causes the view to only generate onclick
>>>>>> events,
>>>>>> and doesn't send the ontextlink event.
>>>>>>
>>>>>> I'm not sure how to get the hand cursor to appear in dhtml over
>>>>>> hyperlinks, maybe Max knows...
>>
> 
> 
>