Hi Maurice, Okay, I see. You are doing the right thing, sorry for my misunderstanding before.
Good luck and have fun! Sent from DarkStone's iPhone > 在 2013年11月25日，5:15，Maurice Amsellem <maurice.amsel...@systar.com> 写道： > > Hi, > >> so the ScrollableStageText itself won’t need a border skin. > > I don't get you. > This is already the case: The border is defined is the > ScrollableStageTextInputSkin. > >> We could write fxg code (like <s:Rect>) in TextInputSkin.mxml to design the >> border, which wraps the ScrollableStageText skin part around. > > Once again, this is also already the case. > ScrollableStageTextInputSkin, wich derives from StageTextSkinBase and > MobileSkin is merely a rewriting of TextInputSkin (which derives from > SparkSkin) in optimized ActionScript. > This was done mainly for performance reasons. > >> I agree most of your say, your thought is as good as mine : ) > Glad that you do ;-) > > Regards, > > Maurice > > -----Message d'origine----- > De : 周 戈 [mailto:darkst...@163.com] > Envoyé : dimanche 24 novembre 2013 21:54 > À : Apache > Objet : Re: Mobile TextInput swipe > > Hi Maurice, > > I agree most of your say, your thought is as good as mine : ) > > The only idea I want to clarify is: > > I think the key point is to use StageText to develop a RichEditableText > alternative. In other words, the ScrollableStageText should ultimately works > like a RichEditableText (of course it would be much less powerful than > RichEditableText), so the ScrollableStageText itself won’t need a border > skin. We could write fxg code (like <s:Rect>) in TextInputSkin.mxml to design > the border, which wraps the ScrollableStageText skin part around. > > Good luck! > > > DarkStone > 2013-11-25 > > > 在 2013-11-25，04:05，Maurice Amsellem <maurice.amsel...@systar.com> 写道： > >>> And why you develop ScrollingStageTextInput and ScrollingStageTextArea and >>> their skins (ScrollingStageTextInputSkin and ScrollingStageTextAreaSkin)? I >>> don’t think that’s >necessary. >> >> There is not ScrollingStageTextInput and ScrollingStageTextArea. >> >> The class involved are the following: >> - spark TextInput and TextArea =>these are the regular TextInput and >> TextArea, that you use in mxml. No other other classes are needed. >> >> - ScrollingStageTextInputSkin / ScrollingStageTextAreaSkin => these are the >> specific Flex4 skins for mobile, which derive from MobileSkin. >> => the skins are necessary for example to draw the round rect border, as >> StageText does not have one itself. But you could also design borderless >> skins if desired. >> >> - ScrollableStageText => the internal wrapper for StageText that is used by >> both skins above. >> >> And of course StageText, with is the low-level native AIR Text Input >> >> I don't see how you can use less classes than that without either breaking >> the spark architecture, breaking existing SDK classes, or duplicating code. >> >> ----------------------- >> >> Side note: >> I had to significantly modify core class to adapt them to the new mobile TI >> behavior (mainly for the focusing behavior). >> - SkinnableTextBase (which is the parent of TextInput and TextArea) >> - Adding new Interfaces ( IStylableEditableText and >> IProxiedStageTexTWrapper) so that TextInput and TextArea (which are in >> spark) can call methods of classes that exists in mobile components.swc. >> >> So you can't (and you shouldn't) implement the new behavior solely in the >> skin classes. >> >> _________________ >> >> >> Maurice >> >> -----Message d'origine----- >> De : 周 戈 [mailto:darkst...@163.com] >> Envoyé : dimanche 24 novembre 2013 18:43 À : Apache Objet : Re: Mobile >> TextInput swipe >> >> Hi all, >> >>> Maybe the whole framework in mobile-mode should ignore mouseDown and >>> determine if the gesture is a tap or not before assigning focus. >> Please don’t do that, current framework’s FocusManager is doing fine, if >> Flex team makes any serious upgrades to it, it will impact a lot of things >> already done for mobile! >> >>> You don't need to show to StageText to make a bitmap of it, it works even >>> when not visible. >> Haven’t tried that yet, thanks for the tip, I’ll give it a shot. >> >>> This is also how ScrollableStageText works. It derives from UIComponent, >>> and can be used as part in ScrollingStageTextInputSkin / >>> ScrollingStageTextAreaSkin mxml skins. >>> It's the textDisplay skin part. >> >> I highly recommend you extends SpriteVisualElement rather than UIComponent. >> UIComponent has a lot of stuff you probably will never use, and it’s a bit >> heavy for mobile text component. >> The SpriteVisualElement class helps you implemented IVisualElement interface >> in a quite lighter way than UIComponent, and it supports mxml as well. >> >> And why you develop ScrollingStageTextInput and ScrollingStageTextArea and >> their skins (ScrollingStageTextInputSkin and ScrollingStageTextAreaSkin)? I >> don’t think that’s necessary. >> >> Just extends VisualElement and implements the IEditableText, it will work >> the way like a RichEditableText (but less powerful than RichEditableText), >> you can use it in Spark TextInputSkin / TextAreaSkin as a skin part. >> >> You don’t have to develop ScrollingStageTextInput and ScrollingStageTextArea >> and their skins, just use the Spark TextInput and TextArea, they are doing >> fine. >> >> >> DarkStone >> 2013-11-25 >> >> >> >>> 在 2013-11-24，23:44，Alex Harui <aha...@adobe.com> 写道： >>> >>> All this reminded me that I don't think there were any serious >>> upgrades to FocusManager for mobile, and it is quite possible that there >>> should be. >>> Maybe the whole framework in mobile-mode should ignore mouseDown and >>> determine if the gesture is a tap or not before assigning focus. >>> >>> In FlexJS with the plug-ins, it allows for a possibility of a >>> touch-oriented FocusManager if one is needed. >>> >>> -Alex >>> >>> On 11/24/13 2:40 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> >>> wrote: >>> >>>> >>>>> BTW, I haven't tried any versions of your code, but I'm still >>>>> surprised that text selection works. I would think that trying to >>>>> swipe-select a word or placing the insertion cursor >at an exact >>>>> spot would also be problematic with the bitmap proxy in the way. >>>> >>>> You must put the focus on the text before doing any selection (that >>>> usual on mobile). So when you focus, the proxy is hidden and the >>>> StageText shown, that's why it works. >>>> >>>>> Let's step back a bit. Why is it too late to detect scrolling on >>>>> mousedown? The MX DataGrid tears down its item editors when >>>>> scrolling starts. Isn't that similar? >>>> The diifrence is that on Desktop, you scroll with the scroll bar, >>>> whereas on mobile, you scroll by "swiping" directly on the content. >>>> This causes issue for focusing text, but also for selecting an item >>>> in a list, etc... >>>> So there is a general mechanism that is implemented in >>>> TouchScrollingHelp >>>> (IIUC) that detects such behavior based on timers and movement >>>> thresholds and will trigger touchInteractionStart. >>>> >>>> As DarkStone says, touchInteractionStart is triggered after >>>> mousedown, so if the focus in bound to mouseDown, it's too late. >>>> >>>>> Does there really need to be more than one StageText instance in play? >>>>> When TI1 loses focus can TI2 use that same StageText instance? >>>> >>>> Actually, it does: ScrollingStageText uses an internal pool, that >>>> will reuse the same instance if it has the same properties >>>> (multiline, font size, etc). >>>> >>>> -----Message d'origine----- >>>> De : Alex Harui [mailto:aha...@adobe.com] Envoyé : dimanche 24 >>>> novembre 2013 06:38 À : dev@flex.apache.org Objet : Re: Mobile >>>> TextInput swipe >>>> >>>> BTW, I haven't tried any versions of your code, but I'm still >>>> surprised that text selection works. I would think that trying to >>>> swipe-select a word or placing the insertion cursor at an exact spot >>>> would also be problematic with the bitmap proxy in the way. >>>> >>>> Let's step back a bit. Why is it too late to detect scrolling on >>>> mousedown? The MX DataGrid tears down its item editors when >>>> scrolling starts. Isn't that similar? >>>> >>>> Does there really need to be more than one StageText instance in play? >>>> When TI1 loses focus can TI2 use that same StageText instance? >>>> >>>> >>>> -Alex >>>> >>>> On 11/23/13 5:22 PM, "Maurice Amsellem" >>>> <maurice.amsel...@systar.com> >>>> wrote: >>>> >>>>> Hi Team, >>>>> >>>>> I am currently working on the swipe issue with ScrollableStageText >>>>> on mobile and would like your advice / help >>>>> >>>>> The issue is the following: you cannot initiate a scroll/swipe by >>>>> touching inside a TextInput or TextArea. >>>>> >>>>> 1) current situation: >>>>> >>>>> - in ScrollableStageText, the StageText is only shown when TI is in >>>>> focus, and is replaced by a proxy when out of focus. >>>>> - when scrolling, only the proxies are scrolled, so it works well. >>>>> >>>>> - when editing TI2 after TI1: >>>>> - TI1 receives focus out => TI1 stageText is hidden, proxy shown >>>>> - TI2 receives the focus on mouse down => TI2 stage text is >>>>> focused >>>>> - stageText for TI2 is displayed (and proxy hidden) >>>>> >>>>> => the problem, is that since focus is set on mousedown, it's too >>>>> late to detect scrolling, so I had to prevent it, by calling >>>>> event.preventDefautl() in touchInteractionStarting handler. >>>>> >>>>> 2) proposed solution >>>>> To overcome that issue, I changed the focus to be set on MOUSE UP, >>>>> instead of mouse down, so that I can detection touch scroll, and >>>>> prevent editing. >>>>> >>>>> It works pretty well but has the following side effect : >>>>> When editing TI1 after TI2, the soft keyboard (which was visible), >>>>> lowers when pressing TI2, and raises back when releasing your finger. >>>>> >>>>> The reason for that is that is when pressing TI2: >>>>> - TI1 has received focus out, so its StageText it's not visible >>>>> anymore >>>>> - TI2 did not receive focus yet, so its stageText is not visible >>>>> yet => no stageText, no SoftKeyboard. >>>>> TI2 stage text is assigned focus only when finger is released. >>>>> >>>>> 3) proposed solution to the side effect: >>>>> Since the only way of having a soft keyboard visible is to have an >>>>> active StageText, and call assingFocus() on it, I added a dummy >>>>> static StageText to the stage, with no text and a viewport extent of 0,0. >>>>> This stageText is assigned focus between the time finger is >>>>> pressed, so >>>>> TI1 and TI2 stage texts are not visible, and the finger is >>>>> released, where TI2 stage text is displayed. >>>>> That way, the soft keyboard does not disappear. >>>>> ______________ >>>>> >>>>> It works well, but I consider the dummy StageText as a HORRIBLE HACK. >>>>> So if someone has a better solution that also meets the >>>>> requirements, I will be happy to take it. >>>>> >>>>> Regards, >>>>> >>>>> Maurice >>>>> >>>>> -----Message d'origine----- >>>>> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >>>>> Envoyé : vendredi 22 novembre 2013 11:37 À : dev@flex.apache.org >>>>> Objet >>>>> : RE: Mobile TextInput Implementation status >>>>> >>>>> Hi, >>>>> I fixed the two issues that were reported in the JIRA ticket by >>>>> Colins Childs. >>>>> >>>>> fixed two issues reported above: >>>>> - two focused text inputs >>>>> - stage text floating above content. >>>>> >>>>> >>>>> Committed and pushed to develop branch >>>>> https://git-wip-us.apache.org/repos/asf?p=flex-sdk.git;a=commit;h=9 >>>>> e >>>>> 4bf >>>>> 21f >>>>> >>>>> Mobile Mustella test pass: >>>>> - mobile/components/TextInput >>>>> - mobile/compoents/TextArea >>>>> - mobile/Softkeyboard >>>>> >>>>> >>>>> -----Message d'origine----- >>>>> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >>>>> Envoyé : mardi 19 novembre 2013 18:18 À : dev@flex.apache.org Objet >>>>> : RE: Mobile TextInput Implementation status >>>>> >>>>> Sure. You need mobilecomponents and mobiletheme >>>>> >>>>> -----Message d'origine----- >>>>> De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de >>>>> OmPrakash Muppirala Envoyé : mardi 19 novembre 2013 18:14 À : >>>>> dev@flex.apache.org Objet : RE: Mobile TextInput Implementation >>>>> status >>>>> >>>>> On Nov 19, 2013 9:05 AM, "Maurice Amsellem" >>>>> <maurice.amsel...@systar.com> >>>>> wrote: >>>>>> >>>>>> Since jenkins is down, do you need the updated swc ? >>>>> >>>>> Which project is it? I can just compile it and drop it in the sdk >>>>> directory. >>>>> >>>>> Thanks, >>>>> Om >>>>> >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de >>>>>> OmPrakash >>>>> Muppirala >>>>>> Envoyé : mardi 19 novembre 2013 17:55 À : dev@flex.apache.org Objet : >>>>>> RE: Mobile TextInput Implementation status >>>>>> >>>>>> On Nov 19, 2013 4:53 AM, "Maurice Amsellem" >>>>>> <maurice.amsel...@systar.com> >>>>>> wrote: >>>>>>> >>>>>>> Fixed a few other issues >>>>>>> (see https://issues.apache.org/jira/browse/FLEX-33166) >>>>>>>> FIXED : Soft keyboard partially closes/opens when moving the >>>>>>>> focus >>>>>> from one TI to another. >>>>>>>> to fix the issue above, had to trigger TI edition on mousedown >>>>>>>> instead >>>>>> of mouse click (like in StyleableStageText) >>>>>>>> fixed bug caused by the above. >>>>>>> >>>>>>> All related mustella test pass. ( mobile/TextInput, >>>>>>> mobile/TextArea, >>>>>> mobile/SoftKeyboard) >>>>>>> >>>>>>> Om, can you please make a last test run on Android, so I can >>>>>>> close the >>>>>> ticket. >>>>>> >>>>>> Will do, later in the night for me. >>>>>> >>>>>> Thanks, >>>>>> Om >>>>>> >>>>>>> Maurice >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >>>>>>> Envoyé : mardi 19 novembre 2013 00:36 À : dev@flex.apache.org >>>>>>> Objet >>>>>>> : RE: Mobile TextInput Implementation status >>>>>>> >>>>>>> Just received results of Om testing on Android (Tested on Samsung >>>>>>> Galaxy >>>>>> SIII (Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)). >>>>>>> It's working fine. >>>>>>> Thanks you Om for the quick testing, that's really good news. >>>>>>> >>>>>>> Maurice >>>>>>> -----Message d'origine----- >>>>>>> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >>>>>>> Envoyé : lundi 18 novembre 2013 16:49 À : dev@flex.apache.org >>>>>>> Objet >>>>>>> : Mobile TextInput Implementation status >>>>>>> >>>>>>> Memory profiling of the new skins: >>>>>>> >>>>>>> It's as expected: alloc memory = pixel width x pixel height x >>>>>>> 4bytes >>>>>> per pixel. >>>>>>> >>>>>>> First figure is for iPad , second is for iPad retina. >>>>>>> >>>>>>> - 25KB / 100 KB of bitmap memory allocated for a single line TI >>>>>>> with >>>>>> default size >>>>>>> - ~500KB / ~ 2 MB for a pages stuffed with text inputs / text >>>>>>> Areas >>>>>>> - 3 MB / 12 MB for a full-page TA => in this case, it's better to >>>>>>> use the >>>>>> old skins. >>>>>>> >>>>>>> The bitmap is allocated while the TI is added to the stage, and >>>>>>> disposed >>>>>> when it's removed from the stage >>>>>>> >>>>>>> Maurice >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >>>>>>> Envoyé : lundi 18 novembre 2013 02:10 À : dev@flex.apache.org >>>>>>> Objet >>>>>>> : RE: Mobile TextInput Implementation status >>>>>>> >>>>>>> >>>>>>> 1) to help debug if something goes wrong on Android, you can set >>>>>>> the >>>>>> following mx_internal flag: >>>>>>> ScrollableStageText.debugProxyImage = true; >>>>>>> >>>>>>> It will display the proxy bitmaps in magenta background. >>>>>>> >>>>>>> 2) proxy methods in ScrollableStageText has been abstracted on >>>>>>> purpose to >>>>>> DisplayObject instead of Bitmap. >>>>>>> This is so that one could override the class to use another >>>>>>> proxy >>>>>> (eg. >>>>>> StyleableTextField) which is less memory consuming than bitmaps. >>>>>>> In wich case, you will have to override: >>>>>>> createProxy >>>>>>> updateProxy >>>>>>> disposeProxy >>>>>>> >>>>>>> 3) StageTextSkinBase inner textDisplay creation method is >>>>>>> externalized so >>>>>> that it can be customized. >>>>>>> >>>>>>> Example for ScrollableStageTextInputSkin: >>>>>>> override protected function >>>>> createTextDisplay():IStyleableEditableText >>>>>>> { >>>>>>> return new ScrollableStageText(multiline); >>>>>>> } >>>>>>> >>>>>>> That way, you can derive from existing skins, instead of monkey >>>>>>> patching >>>>>> the default skin, if you only need to change the internal editable >>>>>> text >>>>> class. >>>>>>> >>>>>>> Note also that displayText is now of type IStyleableEditableText, >>>>>>> instead >>>>>> of StyleableStageText, for the same purpose. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Maurice >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >>>>>>> Envoyé : lundi 18 novembre 2013 01:49 À : dev@flex.apache.org >>>>>>> Objet >>>>>>> : RE: Mobile TextInput Implementation status >>>>>>> >>>>>>> Run mustella tests: >>>>>>> Mobile/Components/TextInput >>>>>>> Mobile/components/TextArea >>>>>>> Mobile/StageText >>>>>>> >>>>>>> All pass. >>>>>>> >>>>>>> Maurice >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >>>>>>> Envoyé : lundi 18 novembre 2013 01:11 À : dev@flex.apache.org >>>>>>> Objet >>>>>>> : RE: Mobile TextInput Implementation status >>>>>>> >>>>>>> Hi, I have committed and pushed tentative fix for >>>>>> https://issues.apache.org/jira/browse/FLEX-33166 >>>>>>> >>>>>>> Tested on iPad 2 / 3. >>>>>>> Not tested on Android. >>>>>>> I couldn't run mustella mobile tests. For some reason, they are >>>>>>> broken >>>>>> on my machine ( says: Passes: 0 / Fails: 0). >>>>>>> >>>>>>> The new skins are now the defaults for TextInput and TextArea on >>>>>> mobile: >>>>>>> >>>>>>> TextInput skinClass = >>>>>>> spark.skins.mobile.ScrollingStageTextInputSkin >>>>>>> TextArea skinClass = >>>>>>> spark.skins.mobile.ScrollingStageTextAreaSkin >>>>>>> >>>>>>> The old skins are still there, under the same name. >>>>>>> >>>>>>> Please review and tests, and this is a sensitive change... >>>>>>> >>>>>>> Your comments and feedback are welcome. >>>>>>> >>>>>>> Maurice >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >>>>>>> Envoyé : lundi 18 novembre 2013 00:08 À : dev@flex.apache.org >>>>>>> Objet >>>>>>> : RE: Mobile TextInput Implementation status >>>>>>> >>>>>>> Founds some bugs, so I won't commit until they are fixed... >>>>>>> >>>>>>> Maurice >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >>>>>>> Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org >>>>>> Objet : >>>>>> RE: Mobile TextInput Implementation status >>>>>>> >>>>>>>> I can help out with Android testing. >>>>>>> Thanks >>>>>>> >>>>>>>> Should I wait for the nightly or are these fixes on a branch? >>>>>>>> Nightly >>>>>> would be preferable so as to allow more people to test the fix. >>>>>>> I will push to the develop/ so that they be in the nightly >>>>>>> >>>>>>>> It would be better to keep the old one around with the same name. >>>>>>>> Folks >>>>>> might have subclassed it to build their own implementations. >>>>>>> >>>>>>> What about : >>>>>>> ScrollableStageText >>>>>>> ScrollableStageTextInputSkin >>>>>>> >>>>>>> For the new classes ? >>>>>>> >>>>>>> Maurice >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de >>>>>>> OmPrakash >>>>>> Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À : >>>>>> dev@flex.apache.orgObjet : Re: Mobile TextInput Implementation >>>>>> status >>>>>>> >>>>>>> On Nov 17, 2013 10:56 AM, "Maurice Amsellem" >>>>>>> <maurice.amsel...@systar.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Here is a brief status of the implementation of Mobile Text >>>>>>>> Input, along >>>>>>> with some questions: >>>>>>>> >>>>>>>> Implementation overview: >>>>>>>> The change is mainly on the class StyleableStageText, which now >>>>>>>> takes the >>>>>>> opposite approach than the previous one: >>>>>>>> - display proxy image bitmap by default >>>>>>>> - display StageText only when editing >>>>>>>> StageTextInputSkin/StageTextAreaSkin has been modified to use >>>>>>>> this class >>>>>>>> >>>>>>>> - to make it easier to change StageTextInputSkin internal >>>>>>> StyleableStageText component, the variable textDisplay is now of >>>>>>> type >>>>>> IStyleableEditText >>>>>>>> >>>>>>>> Behavior changes: >>>>>>>> - scrolling and overlapping of text is well managed , as it >>>>>>>> always uses >>>>>>> the bitmap proxy, which is a Flex component: all the text inputs >>>>>>> are >>>>>> scrolling >>>>>>>> - text occluding while editing is not managed yet, which means >>>>>>>> the >>>>>>> edited text may overlap other UIs. (TO BE DONE) >>>>>>>> >>>>>>>> Testing: >>>>>>>> - tested on iPad 2 and iPad 3: TI in scrolling forms, TI in >>>>> callouts >>>>>>>> - *NEEDS TO BE TESTED ON ANDROID* >>>>>>>> - memory consumption tests yet to be done >>>>>>>> - mustella test yet to be run >>>>>>>> >>>>>>>> >>>>>>>> Questions: >>>>>>>> - Can someone please test on Android ? >>>>>>> >>>>>>> I can help out with Android testing. Should I wait for the >>>>>>> nightly or >>>>>> are these fixes on a branch? Nightly would be preferable so as >>>>>> to allow >>>>> more people to test the fix. >>>>>>> >>>>>>> Thanks, >>>>>>> Om >>>>>>> >>>>>>>> - I have chosen to directly replace StyleableStageText. >>>>>>>> Maybe I can also leave the old StyleableStageText with a >>>>>>>> different name, >>>>>>> so that it can be used in case there is an issue with the new one ? >>>>>>> or >>>>>> the other way? >>>>>>> >>>>>>> It would be better to keep the old one around with the same name. >>>>>>> Folks >>>>>> might have subclassed it to build their own implementations. >>>>>>> >>>>>>>> Now that it is an interface, it's easy to subclass the >>>>>>> StageTextInputSkin, and override createTextDisplay() to use >>>>>>> another >>>>> class. >>>>>>>> >>>>>>>> >>>>>>>> Maurice > >
