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

[Henry Minsky]

I have a thought which will let us defer making a final decision about
a public API here ...

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

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...
>>>>>
>>>>>
>>>>>
>>>>> Change 20090103-hqm-F by hqm at badtzmaru.home on 2009-01-03 23:16:46 EST
>>>>>  in /Users/hqm/openlaszlo/trunk4/WEB-INF/lps/lfc
>>>>>  for http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc
>>>>>
>>>>> Summary: always set textfield.mouseEnabled=true in swf9 LzTextSprite
>>>>>
>>>>> New Features:
>>>>>
>>>>> Bugs Fixed: LPP-7551
>>>>>
>>>>> Technical Reviewer: andre
>>>>> QA Reviewer: (pending)
>>>>> Doc Reviewer: (pending)
>>>>>
>>>>> Documentation:
>>>>>
>>>>> Release Notes:
>>>>>
>>>>> Details:
>>>>>
>>>>>
>>>>> Tests:
>>>>>
>>>>> <canvas debug="true">
>>>>>  <class name="testcase" extends="text"
>>>>>        multiline="true" width="150"    >
>>>>>   <handler name="oninit" >
>>>>>     this.format("click %s or %s", this.makeTextLink("here", "opt1"),
>>>>> this.makeTextLink("here", "opt2"));
>>>>>   </handler>
>>>>>   <handler name="ontextlink" args="val" >
>>>>>     this.addFormat("\noption %d was clicked", val == "opt1" ? 1 : 2);
>>>>>   </handler>
>>>>>   <handler name="onclick" args="val" >
>>>>>     this.addFormat("\nclick %w ", val);
>>>>>   </handler>
>>>>>  </class>
>>>>>
>>>>>  <simplelayout spacing="6"/>
>>>>>  <testcase id="foo" clickable="false" bgcolor="#cccccc"/>
>>>>>  <testcase id="bar" clickable="true" bgcolor="#ccffcc"/>
>>>>>
>>>>> </canvas>
>>>>>
>>>>>
>>>>> Files:
>>>>> M      kernel/swf9/LzTextSprite.as
>>>>>
>>>>> Changeset:
>>>>> http://svn.openlaszlo.org/openlaszlo/patches/20090103-hqm-F.tar
>>>>>
>>>>
>>
>
>



-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com