You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Alex Harui <ah...@adobe.com.INVALID> on 2018/09/13 15:54:18 UTC
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Is setTimeout guaranteed to run after the CLICK event?
On 9/13/18, 6:14 AM, "harbs@apache.org" <ha...@apache.org> wrote:
This is an automated email from the ASF dual-hosted git repository.
harbs pushed a commit to branch develop
in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C1ae20fcfaca24ad2792f08d6197acee6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724412586134726&sdata=gasHWKJBGUaGc6k7gqt2fJcI3iQ2qp4Xjjst7SA7a%2FE%3D&reserved=0
The following commit(s) were added to refs/heads/develop by this push:
new e1ec25e I think this fixes Menu
e1ec25e is described below
commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
Author: Harbs <ha...@in-tools.com>
AuthorDate: Thu Sep 13 16:14:03 2018 +0300
I think this fixes Menu
---
.../projects/Basic/src/main/resources/defaults.css | 1 +
.../controllers/ItemRendererMouseController.as | 1 -
.../controllers/MenuSelectionMouseController.as | 33 ++++++++++++++--------
3 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css b/frameworks/projects/Basic/src/main/resources/defaults.css
index f88da20..15cb4e6 100644
--- a/frameworks/projects/Basic/src/main/resources/defaults.css
+++ b/frameworks/projects/Basic/src/main/resources/defaults.css
@@ -545,6 +545,7 @@ Panel
IBeadModel: ClassReference("org.apache.royale.html.beads.models.PanelModel");
IBeadView: ClassReference("org.apache.royale.html.beads.PanelView");
IPanelLayout: ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
+ IPanelContentArea: ClassReference("org.apache.royale.html.Container");
background-color: #FFFFFF;
border: 1px solid #333333
diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
index f408a71..6073264 100644
--- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
+++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
@@ -92,7 +92,6 @@ COMPILE::JS {
goog.events.listen(element, goog.events.EventType.MOUSEOUT, this.handleMouseOut);
goog.events.listen(element, goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
goog.events.listen(element, goog.events.EventType.CLICK, this.handleMouseUp);
- goog.events.listen(element, goog.events.EventType.MOUSEUP, this.handleMouseUp);
}
}
diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
index 5f986bb..6a09a52 100644
--- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
+++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
@@ -127,6 +127,8 @@ package org.apache.royale.html.beads.controllers
* @playerversion Flash 10.2
* @playerversion AIR 2.6
* @productversion Royale 0.9
+ * @royaleignorecoercion org.apache.royale.core.UIBase
+ * @royaleignorecoercion org.apache.royale.core.IUIBase
*/
protected function hideOpenMenus():void
{
@@ -137,8 +139,9 @@ package org.apache.royale.html.beads.controllers
if (menu.parent != null) {
var controller:MenuSelectionMouseController = menu.getBeadByType(MenuSelectionMouseController) as MenuSelectionMouseController;
controller.removeClickOutHandler(menu);
- var host:IPopUpHost = UIUtils.findPopUpHost(_strand as IUIBase);
- host.popUpParent.removeElement(menu);
+ var host:IPopUpHost = UIUtils.findPopUpHost(menu as IUIBase);
+ if(host)
+ host.popUpParent.removeElement(menu);
}
}
MenuModel.clearMenuList();
@@ -163,6 +166,8 @@ package org.apache.royale.html.beads.controllers
* @playerversion Flash 10.2
* @playerversion AIR 2.6
* @productversion Royale 0.9
+ * @royaleignorecoercion org.apache.royale.core.IUIBase
+ * @royaleignorecoercion org.apache.royale.events.IEventDispatcher
*/
public function removeClickOutHandler(menu:Object):void
{
@@ -191,23 +196,29 @@ package org.apache.royale.html.beads.controllers
/**
* @royaleignorecoercion HTMLElement
+ * @royaleignorecoercion org.apache.royale.core.IUIBase
* @private
*/
COMPILE::JS
protected function hideMenu_internal(event:BrowserEvent):void
{
var menu:IMenu = _strand as IMenu;
+ var menuElem:HTMLElement = (_strand as IUIBase).element as HTMLElement;
+ var menuBarElement:HTMLElement;
if (menu.parentMenuBar)
{
- var menuBarElement:HTMLElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
- var target:HTMLElement = event.target as HTMLElement;
- while (target != null)
- {
- if (target == menuBarElement) return;
- target = target.parentNode as HTMLElement;
- }
- }
- hideOpenMenus();
+ menuBarElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
+ }
+ var target:HTMLElement = event.target as HTMLElement;
+ while (target != null)
+ {
+ var comp:IUIBase = target["royale_wrapper"];
+ if(comp && (comp is IMenu || comp == menu.parentMenuBar) ) return;
+ // if (target == menuElem || (menuBarElement && target == menuBarElement) ) return;
+ target = target.parentNode as HTMLElement;
+ }
+
+ setTimeout(hideOpenMenus);
}
}
}
\ No newline at end of file
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hmm. What "interaction" does it refer to? I think "click" is fine because it is saying that a mouse click happened and wasn't consumed for some intra-renderer thing like an expand/collapse triangle. It is up to the List's controller to watch for all "item*" events and determine what they mean regarding selection. In some Lists, hitting the "space" bar selects the renderer as well. The renderer's controller shouldn't map a space key to an itemClick event, it should just handle the key event and decide how to update the selection.
It did occur to me to replace "item" with "renderer" in the event name such as "rendererClick", but itemClick was what was used in Flex.
My 2 cents,
-Alex
On 9/13/18, 11:41 PM, "Harbs" <ha...@gmail.com> wrote:
I feel like ItemClickedEvent should be renamed to ItemInteractionEvent…
> On Sep 14, 2018, at 9:35 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> For sure, a more sophisticated controller is needed to support "drag selection" in Menu, but the current version may be ok for simple "must click" menus. IOW, IMO, drag selection should be PAYG.
>
> IMO, finger dragging is a different event than mouseOver and thus would be separate events/controllers.
>
> My 2 cents,
> -Alex
>
> On 9/13/18, 11:06 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> Actually after thinking about this some more, MenuItemRenderer should have its own controller. The standard ItemRendererMouseController only needs to dispatch a single click event. MenuItemRendererMouseController could dispatch all these other events. This seems more PAYG...
>
> Regarding “over” events on mobile, I think finger dragging would trigger “over” events there.
>
>> On Sep 14, 2018, at 8:44 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Sure, there can/should be "item*" events as higher-level semantic events for each mouse event and touch gesture. Bonus if you can make that PAYG since mobile devices will rarely leverage "over" events. The semantic meaning is that the mouse event was not used for any other interaction in the renderer and thus can be used by a selection controller in the List.
>>
>> My 2 cents,
>> -Alex
>>
>> On 9/13/18, 2:22 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> What about itemMouseOver? I think we’d need that too. It seems like mousing down on a menu and moving over a sub-menu should pop open the submenu.
>>
>>> On Sep 14, 2018, at 12:15 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> Yes please. It sounds like you are already set up with some test cases.
>>>
>>> Thanks,
>>> -Alex
>>>
>>> On 9/13/18, 2:12 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> OK. It sounds like you have a good plan.
>>>
>>> I’m fine with dispatching itemMouseDown, itemMouseUp and itemClick. That makes sense and should solve the problem.
>>>
>>> Do you want me to work on implementing that?
>>>
>>>> On Sep 14, 2018, at 12:09 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>>
>>>> Different controllers will have different behaviors. Menu behavior is in fact one of the reasons I wanted to do beads and have replacable component logic. In your standard List, you "must" mouseDown and mouseUp on the same renderer to generate a Click that changes selection. However, in many menus, you can mouseDown on the MenuBar and without releasing the mouse button, drag down the menu to an item and release (MouseUp) and that item will be selected from the menu. Outlook's menubar on my Mac seems to work this way. So, some people will want mouseUp to change selection, others will want click to change selection. Royale should offer choices.
>>>>
>>>> But changing selection is a higher-level event. The lowest level events are mouseDown/mouseUp/click. In between is the "ITEM_CLICK" event and in theor, ITEM_MOUSEDOWN and ITEM_MOUSEUP. It is up to the controllers to interpret a lower-level event and then dispatch a higher-level event. It seems "illogical" to me that an ITEM_CLICK would be dispatched from a mouseUp handler. ITEM_CLICK (and ITEM_MOUSEUP if there is such a things) is meant to indicate that an event happened on the renderer that should be interpreted by the controller. Some parts of a renderer may not dispatch ITEM_CLICK (for example, in some Trees, clcking on expand/collapse icons don't change selection.
>>>>
>>>> Then the MenuController and ListSelectionController should be interpreting ITEM_CLICK and ITEM_MOUSEUP and deciding what to do. So maybe the answer is that the renderer's mouseUp controller dispatches ITEM_MOUSEUP, and Menu changes selection on ITEM_CLICK or ITEM_MOUSEUP.
>>>>
>>>> Separately, whether setTimeout or requestAnimationFrame, the more deferred work and asynchronicity we put in the framework, the more trouble we will give our users IMO. Starting such a trend has the danger of making application code use more and more callLater/setTimeout/requestAnimationFrame calls as well. We should not defer work unless we have to, and I don't think we have to in this case. Making things rely on timing creates the potential for timing issues.
>>>>
>>>> My 2 cents,
>>>> -Alex
>>>>
>>>> On 9/13/18, 1:50 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>>>
>>>> That article was not what I was referring to. Like I said I couldn’t find it. I’m working from memory.
>>>>
>>>>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>>>
>>>> I don’t understand you. Are you saying that mousing down on one renderer and mousing up on another should fire an itemClick? That seems wrong to me. An itemClick should be both mouse down and mouse up on the same item. Click does that very nicely.
>>>>
>>>>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers.
>>>>
>>>> I would generally agree with you. But in this case, we’re handling the dismissal of a menu. I don’t see the harm here. If you have another proposal, I’m open to hear…
>>>>
>>>> We can also use requestAnimationFrame() to delay the execution until after click. That will be guaranteed to be before the next draw of the screen, so it might be better than setTimeout() which will probably be later.
>>>>
>>>> Thanks,
>>>> Harbs
>>>>
>>>>> On Sep 13, 2018, at 11:20 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> wrote:
>>>>>
>>>>> I didn't see anywhere in the article where it guaranteed that both up and click are sequential in the queue. Sharing the heap isn't the issue here.
>>>>>
>>>>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>>>>
>>>>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers. With many browsers having immediate screen updates (as opposed to Flash's deferred rendering), postponing work with setTimeout can result in unexpected behavior, and can result in callLater "wars" where more and more code has to keep deferring work with setTimeout because some lower layer also used setTimeout. Deferring work should be the option of the application developer as much as possible.
>>>>>
>>>>> My 2 cents,
>>>>> -Alex
>>>>>
>>>>> On 9/13/18, 11:36 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>> I once read that the way setTimeout works is that it’s added to the next event loop. That would mean that both mouseup and click would be executed in the current event loop and the setTimout would be delayed to the next one (i..e between 4ms and 10ms later).
>>>>>
>>>>> I can’t find the article at the moment, but my understanding is that this is a safe way to guarantee later execution in all browsers.
>>>>>
>>>>> The MDN doc has a decent explanation.[1] Both mouseup and click would be on the same heap.
>>>>>
>>>>> Harbs
>>>>>
>>>>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080693700&sdata=RZ%2BhLCybXC%2FHGB80Ueqy0Wj0TUgcPrAuBWhA5CAcWyQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080693700&sdata=RZ%2BhLCybXC%2FHGB80Ueqy0Wj0TUgcPrAuBWhA5CAcWyQ%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080693700&sdata=RZ%2BhLCybXC%2FHGB80Ueqy0Wj0TUgcPrAuBWhA5CAcWyQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080693700&sdata=RZ%2BhLCybXC%2FHGB80Ueqy0Wj0TUgcPrAuBWhA5CAcWyQ%3D&reserved=0>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080693700&sdata=RZ%2BhLCybXC%2FHGB80Ueqy0Wj0TUgcPrAuBWhA5CAcWyQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080693700&sdata=RZ%2BhLCybXC%2FHGB80Ueqy0Wj0TUgcPrAuBWhA5CAcWyQ%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080693700&sdata=RZ%2BhLCybXC%2FHGB80Ueqy0Wj0TUgcPrAuBWhA5CAcWyQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080693700&sdata=RZ%2BhLCybXC%2FHGB80Ueqy0Wj0TUgcPrAuBWhA5CAcWyQ%3D&reserved=0>>>
>>>>>> On Sep 13, 2018, at 6:54 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID><mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>>> wrote:
>>>>>>
>>>>>> Is setTimeout guaranteed to run after the CLICK event?
>>>>>>
>>>>>> On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>> <mailto:harbs@apache.org <ma...@apache.org><mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>>>" <harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>><mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org><mailto:harbs@apache.org <ma...@apache.org>>>>> wrote:
>>>>>>
>>>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>>>
>>>>>> harbs pushed a commit to branch develop
>>>>>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080703714&sdata=vMJKqxMitc8kV9B8IeykPFI51SPf36AqCqjFQ1e6VOU%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080703714&sdata=vMJKqxMitc8kV9B8IeykPFI51SPf36AqCqjFQ1e6VOU%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080703714&sdata=vMJKqxMitc8kV9B8IeykPFI51SPf36AqCqjFQ1e6VOU%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080703714&sdata=vMJKqxMitc8kV9B8IeykPFI51SPf36AqCqjFQ1e6VOU%3D&reserved=0>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080703714&sdata=vMJKqxMitc8kV9B8IeykPFI51SPf36AqCqjFQ1e6VOU%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080703714&sdata=vMJKqxMitc8kV9B8IeykPFI51SPf36AqCqjFQ1e6VOU%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080703714&sdata=vMJKqxMitc8kV9B8IeykPFI51SPf36AqCqjFQ1e6VOU%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080703714&sdata=vMJKqxMitc8kV9B8IeykPFI51SPf36AqCqjFQ1e6VOU%3D&reserved=0>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080703714&sdata=vMJKqxMitc8kV9B8IeykPFI51SPf36AqCqjFQ1e6VOU%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080713719&sdata=IiyLY2wQ3cBLLulkKOZu2lAV0tjKSWNGSnH5Qnfwn4A%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080713719&sdata=IiyLY2wQ3cBLLulkKOZu2lAV0tjKSWNGSnH5Qnfwn4A%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080713719&sdata=IiyLY2wQ3cBLLulkKOZu2lAV0tjKSWNGSnH5Qnfwn4A%3D&reserved=0>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080713719&sdata=IiyLY2wQ3cBLLulkKOZu2lAV0tjKSWNGSnH5Qnfwn4A%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080713719&sdata=IiyLY2wQ3cBLLulkKOZu2lAV0tjKSWNGSnH5Qnfwn4A%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080713719&sdata=IiyLY2wQ3cBLLulkKOZu2lAV0tjKSWNGSnH5Qnfwn4A%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc86701bc44d34321dc6e08d61a0d23e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725041080713719&sdata=IiyLY2wQ3cBLLulkKOZu2lAV0tjKSWNGSnH5Qnfwn4A%3D&reserved=0>>>>
>>>>>>
>>>>>>
>>>>>> The following commit(s) were added to refs/heads/develop by this push:
>>>>>> new e1ec25e I think this fixes Menu
>>>>>> e1ec25e is described below
>>>>>>
>>>>>> commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
>>>>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>> <mailto:harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>>> <mailto:harbs@in-tools.com <ma...@in-tools.com><mailto:harbs@in-tools.com <ma...@in-tools.com>> <mailto:harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>>>>>
>>>>>> AuthorDate: Thu Sep 13 16:14:03 2018 +0300
>>>>>>
>>>>>> I think this fixes Menu
>>>>>> ---
>>>>>> .../projects/Basic/src/main/resources/defaults.css | 1 +
>>>>>> .../controllers/ItemRendererMouseController.as | 1 -
>>>>>> .../controllers/MenuSelectionMouseController.as | 33 ++++++++++++++--------
>>>>>> 3 files changed, 23 insertions(+), 12 deletions(-)
>>>>>>
>>>>>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>>>> index f88da20..15cb4e6 100644
>>>>>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>>>>>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>>>> @@ -545,6 +545,7 @@ Panel
>>>>>> IBeadModel: ClassReference("org.apache.royale.html.beads.models.PanelModel");
>>>>>> IBeadView: ClassReference("org.apache.royale.html.beads.PanelView");
>>>>>> IPanelLayout: ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
>>>>>> + IPanelContentArea: ClassReference("org.apache.royale.html.Container");
>>>>>>
>>>>>> background-color: #FFFFFF;
>>>>>> border: 1px solid #333333
>>>>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>>>> index f408a71..6073264 100644
>>>>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>>>> @@ -92,7 +92,6 @@ COMPILE::JS {
>>>>>> goog.events.listen(element, goog.events.EventType.MOUSEOUT, this.handleMouseOut);
>>>>>> goog.events.listen(element, goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
>>>>>> goog.events.listen(element, goog.events.EventType.CLICK, this.handleMouseUp);
>>>>>> - goog.events.listen(element, goog.events.EventType.MOUSEUP, this.handleMouseUp);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>>>> index 5f986bb..6a09a52 100644
>>>>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>>>> @@ -127,6 +127,8 @@ package org.apache.royale.html.beads.controllers
>>>>>> * @playerversion Flash 10.2
>>>>>> * @playerversion AIR 2.6
>>>>>> * @productversion Royale 0.9
>>>>>> + * @royaleignorecoercion org.apache.royale.core.UIBase
>>>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>>>> */
>>>>>> protected function hideOpenMenus():void
>>>>>> {
>>>>>> @@ -137,8 +139,9 @@ package org.apache.royale.html.beads.controllers
>>>>>> if (menu.parent != null) {
>>>>>> var controller:MenuSelectionMouseController = menu.getBeadByType(MenuSelectionMouseController) as MenuSelectionMouseController;
>>>>>> controller.removeClickOutHandler(menu);
>>>>>> - var host:IPopUpHost = UIUtils.findPopUpHost(_strand as IUIBase);
>>>>>> - host.popUpParent.removeElement(menu);
>>>>>> + var host:IPopUpHost = UIUtils.findPopUpHost(menu as IUIBase);
>>>>>> + if(host)
>>>>>> + host.popUpParent.removeElement(menu);
>>>>>> }
>>>>>> }
>>>>>> MenuModel.clearMenuList();
>>>>>> @@ -163,6 +166,8 @@ package org.apache.royale.html.beads.controllers
>>>>>> * @playerversion Flash 10.2
>>>>>> * @playerversion AIR 2.6
>>>>>> * @productversion Royale 0.9
>>>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>>>> + * @royaleignorecoercion org.apache.royale.events.IEventDispatcher
>>>>>> */
>>>>>> public function removeClickOutHandler(menu:Object):void
>>>>>> {
>>>>>> @@ -191,23 +196,29 @@ package org.apache.royale.html.beads.controllers
>>>>>>
>>>>>> /**
>>>>>> * @royaleignorecoercion HTMLElement
>>>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>>>> * @private
>>>>>> */
>>>>>> COMPILE::JS
>>>>>> protected function hideMenu_internal(event:BrowserEvent):void
>>>>>> {
>>>>>> var menu:IMenu = _strand as IMenu;
>>>>>> + var menuElem:HTMLElement = (_strand as IUIBase).element as HTMLElement;
>>>>>> + var menuBarElement:HTMLElement;
>>>>>> if (menu.parentMenuBar)
>>>>>> {
>>>>>> - var menuBarElement:HTMLElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>>>>> - var target:HTMLElement = event.target as HTMLElement;
>>>>>> - while (target != null)
>>>>>> - {
>>>>>> - if (target == menuBarElement) return;
>>>>>> - target = target.parentNode as HTMLElement;
>>>>>> - }
>>>>>> - }
>>>>>> - hideOpenMenus();
>>>>>> + menuBarElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>>>>> + }
>>>>>> + var target:HTMLElement = event.target as HTMLElement;
>>>>>> + while (target != null)
>>>>>> + {
>>>>>> + var comp:IUIBase = target["royale_wrapper"];
>>>>>> + if(comp && (comp is IMenu || comp == menu.parentMenuBar) ) return;
>>>>>> + // if (target == menuElem || (menuBarElement && target == menuBarElement) ) return;
>>>>>> + target = target.parentNode as HTMLElement;
>>>>>> + }
>>>>>> +
>>>>>> + setTimeout(hideOpenMenus);
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>> \ No newline at end of file
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Harbs <ha...@gmail.com>.
I feel like ItemClickedEvent should be renamed to ItemInteractionEvent…
> On Sep 14, 2018, at 9:35 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> For sure, a more sophisticated controller is needed to support "drag selection" in Menu, but the current version may be ok for simple "must click" menus. IOW, IMO, drag selection should be PAYG.
>
> IMO, finger dragging is a different event than mouseOver and thus would be separate events/controllers.
>
> My 2 cents,
> -Alex
>
> On 9/13/18, 11:06 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> Actually after thinking about this some more, MenuItemRenderer should have its own controller. The standard ItemRendererMouseController only needs to dispatch a single click event. MenuItemRendererMouseController could dispatch all these other events. This seems more PAYG...
>
> Regarding “over” events on mobile, I think finger dragging would trigger “over” events there.
>
>> On Sep 14, 2018, at 8:44 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Sure, there can/should be "item*" events as higher-level semantic events for each mouse event and touch gesture. Bonus if you can make that PAYG since mobile devices will rarely leverage "over" events. The semantic meaning is that the mouse event was not used for any other interaction in the renderer and thus can be used by a selection controller in the List.
>>
>> My 2 cents,
>> -Alex
>>
>> On 9/13/18, 2:22 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> What about itemMouseOver? I think we’d need that too. It seems like mousing down on a menu and moving over a sub-menu should pop open the submenu.
>>
>>> On Sep 14, 2018, at 12:15 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> Yes please. It sounds like you are already set up with some test cases.
>>>
>>> Thanks,
>>> -Alex
>>>
>>> On 9/13/18, 2:12 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> OK. It sounds like you have a good plan.
>>>
>>> I’m fine with dispatching itemMouseDown, itemMouseUp and itemClick. That makes sense and should solve the problem.
>>>
>>> Do you want me to work on implementing that?
>>>
>>>> On Sep 14, 2018, at 12:09 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>>
>>>> Different controllers will have different behaviors. Menu behavior is in fact one of the reasons I wanted to do beads and have replacable component logic. In your standard List, you "must" mouseDown and mouseUp on the same renderer to generate a Click that changes selection. However, in many menus, you can mouseDown on the MenuBar and without releasing the mouse button, drag down the menu to an item and release (MouseUp) and that item will be selected from the menu. Outlook's menubar on my Mac seems to work this way. So, some people will want mouseUp to change selection, others will want click to change selection. Royale should offer choices.
>>>>
>>>> But changing selection is a higher-level event. The lowest level events are mouseDown/mouseUp/click. In between is the "ITEM_CLICK" event and in theor, ITEM_MOUSEDOWN and ITEM_MOUSEUP. It is up to the controllers to interpret a lower-level event and then dispatch a higher-level event. It seems "illogical" to me that an ITEM_CLICK would be dispatched from a mouseUp handler. ITEM_CLICK (and ITEM_MOUSEUP if there is such a things) is meant to indicate that an event happened on the renderer that should be interpreted by the controller. Some parts of a renderer may not dispatch ITEM_CLICK (for example, in some Trees, clcking on expand/collapse icons don't change selection.
>>>>
>>>> Then the MenuController and ListSelectionController should be interpreting ITEM_CLICK and ITEM_MOUSEUP and deciding what to do. So maybe the answer is that the renderer's mouseUp controller dispatches ITEM_MOUSEUP, and Menu changes selection on ITEM_CLICK or ITEM_MOUSEUP.
>>>>
>>>> Separately, whether setTimeout or requestAnimationFrame, the more deferred work and asynchronicity we put in the framework, the more trouble we will give our users IMO. Starting such a trend has the danger of making application code use more and more callLater/setTimeout/requestAnimationFrame calls as well. We should not defer work unless we have to, and I don't think we have to in this case. Making things rely on timing creates the potential for timing issues.
>>>>
>>>> My 2 cents,
>>>> -Alex
>>>>
>>>> On 9/13/18, 1:50 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>>>
>>>> That article was not what I was referring to. Like I said I couldn’t find it. I’m working from memory.
>>>>
>>>>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>>>
>>>> I don’t understand you. Are you saying that mousing down on one renderer and mousing up on another should fire an itemClick? That seems wrong to me. An itemClick should be both mouse down and mouse up on the same item. Click does that very nicely.
>>>>
>>>>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers.
>>>>
>>>> I would generally agree with you. But in this case, we’re handling the dismissal of a menu. I don’t see the harm here. If you have another proposal, I’m open to hear…
>>>>
>>>> We can also use requestAnimationFrame() to delay the execution until after click. That will be guaranteed to be before the next draw of the screen, so it might be better than setTimeout() which will probably be later.
>>>>
>>>> Thanks,
>>>> Harbs
>>>>
>>>>> On Sep 13, 2018, at 11:20 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> wrote:
>>>>>
>>>>> I didn't see anywhere in the article where it guaranteed that both up and click are sequential in the queue. Sharing the heap isn't the issue here.
>>>>>
>>>>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>>>>
>>>>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers. With many browsers having immediate screen updates (as opposed to Flash's deferred rendering), postponing work with setTimeout can result in unexpected behavior, and can result in callLater "wars" where more and more code has to keep deferring work with setTimeout because some lower layer also used setTimeout. Deferring work should be the option of the application developer as much as possible.
>>>>>
>>>>> My 2 cents,
>>>>> -Alex
>>>>>
>>>>> On 9/13/18, 11:36 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>> I once read that the way setTimeout works is that it’s added to the next event loop. That would mean that both mouseup and click would be executed in the current event loop and the setTimout would be delayed to the next one (i..e between 4ms and 10ms later).
>>>>>
>>>>> I can’t find the article at the moment, but my understanding is that this is a safe way to guarantee later execution in all browsers.
>>>>>
>>>>> The MDN doc has a decent explanation.[1] Both mouseup and click would be on the same heap.
>>>>>
>>>>> Harbs
>>>>>
>>>>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=AjLWb1Gp5zYwrlPu7XcMM72iZTkgWM5CUPAsboOMgWo%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=AjLWb1Gp5zYwrlPu7XcMM72iZTkgWM5CUPAsboOMgWo%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=AjLWb1Gp5zYwrlPu7XcMM72iZTkgWM5CUPAsboOMgWo%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=AjLWb1Gp5zYwrlPu7XcMM72iZTkgWM5CUPAsboOMgWo%3D&reserved=0>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=AjLWb1Gp5zYwrlPu7XcMM72iZTkgWM5CUPAsboOMgWo%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=AjLWb1Gp5zYwrlPu7XcMM72iZTkgWM5CUPAsboOMgWo%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=AjLWb1Gp5zYwrlPu7XcMM72iZTkgWM5CUPAsboOMgWo%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=AjLWb1Gp5zYwrlPu7XcMM72iZTkgWM5CUPAsboOMgWo%3D&reserved=0>>>
>>>>>> On Sep 13, 2018, at 6:54 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID><mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>>> wrote:
>>>>>>
>>>>>> Is setTimeout guaranteed to run after the CLICK event?
>>>>>>
>>>>>> On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>> <mailto:harbs@apache.org <ma...@apache.org><mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>>>" <harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>><mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org><mailto:harbs@apache.org <ma...@apache.org>>>>> wrote:
>>>>>>
>>>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>>>
>>>>>> harbs pushed a commit to branch develop
>>>>>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=Q1EeCf7tdEoUGsVcSeIFkjWhlMH2iDvTHO%2BqKa5Abcg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=Q1EeCf7tdEoUGsVcSeIFkjWhlMH2iDvTHO%2BqKa5Abcg%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=Q1EeCf7tdEoUGsVcSeIFkjWhlMH2iDvTHO%2BqKa5Abcg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=Q1EeCf7tdEoUGsVcSeIFkjWhlMH2iDvTHO%2BqKa5Abcg%3D&reserved=0>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=Q1EeCf7tdEoUGsVcSeIFkjWhlMH2iDvTHO%2BqKa5Abcg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=Q1EeCf7tdEoUGsVcSeIFkjWhlMH2iDvTHO%2BqKa5Abcg%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=Q1EeCf7tdEoUGsVcSeIFkjWhlMH2iDvTHO%2BqKa5Abcg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=Q1EeCf7tdEoUGsVcSeIFkjWhlMH2iDvTHO%2BqKa5Abcg%3D&reserved=0>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897171832&sdata=EV1GfOTQdaZdRg7gDKgsdIX6GqpFsg3O9FIZQGeTVWg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897171832&sdata=EV1GfOTQdaZdRg7gDKgsdIX6GqpFsg3O9FIZQGeTVWg%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897171832&sdata=EV1GfOTQdaZdRg7gDKgsdIX6GqpFsg3O9FIZQGeTVWg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897171832&sdata=EV1GfOTQdaZdRg7gDKgsdIX6GqpFsg3O9FIZQGeTVWg%3D&reserved=0>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897171832&sdata=EV1GfOTQdaZdRg7gDKgsdIX6GqpFsg3O9FIZQGeTVWg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897171832&sdata=EV1GfOTQdaZdRg7gDKgsdIX6GqpFsg3O9FIZQGeTVWg%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897171832&sdata=EV1GfOTQdaZdRg7gDKgsdIX6GqpFsg3O9FIZQGeTVWg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897171832&sdata=EV1GfOTQdaZdRg7gDKgsdIX6GqpFsg3O9FIZQGeTVWg%3D&reserved=0>>>>
>>>>>>
>>>>>>
>>>>>> The following commit(s) were added to refs/heads/develop by this push:
>>>>>> new e1ec25e I think this fixes Menu
>>>>>> e1ec25e is described below
>>>>>>
>>>>>> commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
>>>>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>> <mailto:harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>>> <mailto:harbs@in-tools.com <ma...@in-tools.com><mailto:harbs@in-tools.com <ma...@in-tools.com>> <mailto:harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>>>>>
>>>>>> AuthorDate: Thu Sep 13 16:14:03 2018 +0300
>>>>>>
>>>>>> I think this fixes Menu
>>>>>> ---
>>>>>> .../projects/Basic/src/main/resources/defaults.css | 1 +
>>>>>> .../controllers/ItemRendererMouseController.as | 1 -
>>>>>> .../controllers/MenuSelectionMouseController.as | 33 ++++++++++++++--------
>>>>>> 3 files changed, 23 insertions(+), 12 deletions(-)
>>>>>>
>>>>>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>>>> index f88da20..15cb4e6 100644
>>>>>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>>>>>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>>>> @@ -545,6 +545,7 @@ Panel
>>>>>> IBeadModel: ClassReference("org.apache.royale.html.beads.models.PanelModel");
>>>>>> IBeadView: ClassReference("org.apache.royale.html.beads.PanelView");
>>>>>> IPanelLayout: ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
>>>>>> + IPanelContentArea: ClassReference("org.apache.royale.html.Container");
>>>>>>
>>>>>> background-color: #FFFFFF;
>>>>>> border: 1px solid #333333
>>>>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>>>> index f408a71..6073264 100644
>>>>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>>>> @@ -92,7 +92,6 @@ COMPILE::JS {
>>>>>> goog.events.listen(element, goog.events.EventType.MOUSEOUT, this.handleMouseOut);
>>>>>> goog.events.listen(element, goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
>>>>>> goog.events.listen(element, goog.events.EventType.CLICK, this.handleMouseUp);
>>>>>> - goog.events.listen(element, goog.events.EventType.MOUSEUP, this.handleMouseUp);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>>>> index 5f986bb..6a09a52 100644
>>>>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>>>> @@ -127,6 +127,8 @@ package org.apache.royale.html.beads.controllers
>>>>>> * @playerversion Flash 10.2
>>>>>> * @playerversion AIR 2.6
>>>>>> * @productversion Royale 0.9
>>>>>> + * @royaleignorecoercion org.apache.royale.core.UIBase
>>>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>>>> */
>>>>>> protected function hideOpenMenus():void
>>>>>> {
>>>>>> @@ -137,8 +139,9 @@ package org.apache.royale.html.beads.controllers
>>>>>> if (menu.parent != null) {
>>>>>> var controller:MenuSelectionMouseController = menu.getBeadByType(MenuSelectionMouseController) as MenuSelectionMouseController;
>>>>>> controller.removeClickOutHandler(menu);
>>>>>> - var host:IPopUpHost = UIUtils.findPopUpHost(_strand as IUIBase);
>>>>>> - host.popUpParent.removeElement(menu);
>>>>>> + var host:IPopUpHost = UIUtils.findPopUpHost(menu as IUIBase);
>>>>>> + if(host)
>>>>>> + host.popUpParent.removeElement(menu);
>>>>>> }
>>>>>> }
>>>>>> MenuModel.clearMenuList();
>>>>>> @@ -163,6 +166,8 @@ package org.apache.royale.html.beads.controllers
>>>>>> * @playerversion Flash 10.2
>>>>>> * @playerversion AIR 2.6
>>>>>> * @productversion Royale 0.9
>>>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>>>> + * @royaleignorecoercion org.apache.royale.events.IEventDispatcher
>>>>>> */
>>>>>> public function removeClickOutHandler(menu:Object):void
>>>>>> {
>>>>>> @@ -191,23 +196,29 @@ package org.apache.royale.html.beads.controllers
>>>>>>
>>>>>> /**
>>>>>> * @royaleignorecoercion HTMLElement
>>>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>>>> * @private
>>>>>> */
>>>>>> COMPILE::JS
>>>>>> protected function hideMenu_internal(event:BrowserEvent):void
>>>>>> {
>>>>>> var menu:IMenu = _strand as IMenu;
>>>>>> + var menuElem:HTMLElement = (_strand as IUIBase).element as HTMLElement;
>>>>>> + var menuBarElement:HTMLElement;
>>>>>> if (menu.parentMenuBar)
>>>>>> {
>>>>>> - var menuBarElement:HTMLElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>>>>> - var target:HTMLElement = event.target as HTMLElement;
>>>>>> - while (target != null)
>>>>>> - {
>>>>>> - if (target == menuBarElement) return;
>>>>>> - target = target.parentNode as HTMLElement;
>>>>>> - }
>>>>>> - }
>>>>>> - hideOpenMenus();
>>>>>> + menuBarElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>>>>> + }
>>>>>> + var target:HTMLElement = event.target as HTMLElement;
>>>>>> + while (target != null)
>>>>>> + {
>>>>>> + var comp:IUIBase = target["royale_wrapper"];
>>>>>> + if(comp && (comp is IMenu || comp == menu.parentMenuBar) ) return;
>>>>>> + // if (target == menuElem || (menuBarElement && target == menuBarElement) ) return;
>>>>>> + target = target.parentNode as HTMLElement;
>>>>>> + }
>>>>>> +
>>>>>> + setTimeout(hideOpenMenus);
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>> \ No newline at end of file
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Alex Harui <ah...@adobe.com.INVALID>.
For sure, a more sophisticated controller is needed to support "drag selection" in Menu, but the current version may be ok for simple "must click" menus. IOW, IMO, drag selection should be PAYG.
IMO, finger dragging is a different event than mouseOver and thus would be separate events/controllers.
My 2 cents,
-Alex
On 9/13/18, 11:06 PM, "Harbs" <ha...@gmail.com> wrote:
Actually after thinking about this some more, MenuItemRenderer should have its own controller. The standard ItemRendererMouseController only needs to dispatch a single click event. MenuItemRendererMouseController could dispatch all these other events. This seems more PAYG...
Regarding “over” events on mobile, I think finger dragging would trigger “over” events there.
> On Sep 14, 2018, at 8:44 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Sure, there can/should be "item*" events as higher-level semantic events for each mouse event and touch gesture. Bonus if you can make that PAYG since mobile devices will rarely leverage "over" events. The semantic meaning is that the mouse event was not used for any other interaction in the renderer and thus can be used by a selection controller in the List.
>
> My 2 cents,
> -Alex
>
> On 9/13/18, 2:22 PM, "Harbs" <ha...@gmail.com> wrote:
>
> What about itemMouseOver? I think we’d need that too. It seems like mousing down on a menu and moving over a sub-menu should pop open the submenu.
>
>> On Sep 14, 2018, at 12:15 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Yes please. It sounds like you are already set up with some test cases.
>>
>> Thanks,
>> -Alex
>>
>> On 9/13/18, 2:12 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>
>> OK. It sounds like you have a good plan.
>>
>> I’m fine with dispatching itemMouseDown, itemMouseUp and itemClick. That makes sense and should solve the problem.
>>
>> Do you want me to work on implementing that?
>>
>>> On Sep 14, 2018, at 12:09 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> Different controllers will have different behaviors. Menu behavior is in fact one of the reasons I wanted to do beads and have replacable component logic. In your standard List, you "must" mouseDown and mouseUp on the same renderer to generate a Click that changes selection. However, in many menus, you can mouseDown on the MenuBar and without releasing the mouse button, drag down the menu to an item and release (MouseUp) and that item will be selected from the menu. Outlook's menubar on my Mac seems to work this way. So, some people will want mouseUp to change selection, others will want click to change selection. Royale should offer choices.
>>>
>>> But changing selection is a higher-level event. The lowest level events are mouseDown/mouseUp/click. In between is the "ITEM_CLICK" event and in theor, ITEM_MOUSEDOWN and ITEM_MOUSEUP. It is up to the controllers to interpret a lower-level event and then dispatch a higher-level event. It seems "illogical" to me that an ITEM_CLICK would be dispatched from a mouseUp handler. ITEM_CLICK (and ITEM_MOUSEUP if there is such a things) is meant to indicate that an event happened on the renderer that should be interpreted by the controller. Some parts of a renderer may not dispatch ITEM_CLICK (for example, in some Trees, clcking on expand/collapse icons don't change selection.
>>>
>>> Then the MenuController and ListSelectionController should be interpreting ITEM_CLICK and ITEM_MOUSEUP and deciding what to do. So maybe the answer is that the renderer's mouseUp controller dispatches ITEM_MOUSEUP, and Menu changes selection on ITEM_CLICK or ITEM_MOUSEUP.
>>>
>>> Separately, whether setTimeout or requestAnimationFrame, the more deferred work and asynchronicity we put in the framework, the more trouble we will give our users IMO. Starting such a trend has the danger of making application code use more and more callLater/setTimeout/requestAnimationFrame calls as well. We should not defer work unless we have to, and I don't think we have to in this case. Making things rely on timing creates the potential for timing issues.
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 9/13/18, 1:50 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>>
>>> That article was not what I was referring to. Like I said I couldn’t find it. I’m working from memory.
>>>
>>>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>>
>>> I don’t understand you. Are you saying that mousing down on one renderer and mousing up on another should fire an itemClick? That seems wrong to me. An itemClick should be both mouse down and mouse up on the same item. Click does that very nicely.
>>>
>>>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers.
>>>
>>> I would generally agree with you. But in this case, we’re handling the dismissal of a menu. I don’t see the harm here. If you have another proposal, I’m open to hear…
>>>
>>> We can also use requestAnimationFrame() to delay the execution until after click. That will be guaranteed to be before the next draw of the screen, so it might be better than setTimeout() which will probably be later.
>>>
>>> Thanks,
>>> Harbs
>>>
>>>> On Sep 13, 2018, at 11:20 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> wrote:
>>>>
>>>> I didn't see anywhere in the article where it guaranteed that both up and click are sequential in the queue. Sharing the heap isn't the issue here.
>>>>
>>>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>>>
>>>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers. With many browsers having immediate screen updates (as opposed to Flash's deferred rendering), postponing work with setTimeout can result in unexpected behavior, and can result in callLater "wars" where more and more code has to keep deferring work with setTimeout because some lower layer also used setTimeout. Deferring work should be the option of the application developer as much as possible.
>>>>
>>>> My 2 cents,
>>>> -Alex
>>>>
>>>> On 9/13/18, 11:36 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> I once read that the way setTimeout works is that it’s added to the next event loop. That would mean that both mouseup and click would be executed in the current event loop and the setTimout would be delayed to the next one (i..e between 4ms and 10ms later).
>>>>
>>>> I can’t find the article at the moment, but my understanding is that this is a safe way to guarantee later execution in all browsers.
>>>>
>>>> The MDN doc has a decent explanation.[1] Both mouseup and click would be on the same heap.
>>>>
>>>> Harbs
>>>>
>>>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=AjLWb1Gp5zYwrlPu7XcMM72iZTkgWM5CUPAsboOMgWo%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=AjLWb1Gp5zYwrlPu7XcMM72iZTkgWM5CUPAsboOMgWo%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=AjLWb1Gp5zYwrlPu7XcMM72iZTkgWM5CUPAsboOMgWo%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=AjLWb1Gp5zYwrlPu7XcMM72iZTkgWM5CUPAsboOMgWo%3D&reserved=0>>
>>>>> On Sep 13, 2018, at 6:54 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>> wrote:
>>>>>
>>>>> Is setTimeout guaranteed to run after the CLICK event?
>>>>>
>>>>> On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>>" <harbs@apache.org <ma...@apache.org><mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>>> wrote:
>>>>>
>>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>>
>>>>> harbs pushed a commit to branch develop
>>>>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=Q1EeCf7tdEoUGsVcSeIFkjWhlMH2iDvTHO%2BqKa5Abcg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=Q1EeCf7tdEoUGsVcSeIFkjWhlMH2iDvTHO%2BqKa5Abcg%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=Q1EeCf7tdEoUGsVcSeIFkjWhlMH2iDvTHO%2BqKa5Abcg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897161828&sdata=Q1EeCf7tdEoUGsVcSeIFkjWhlMH2iDvTHO%2BqKa5Abcg%3D&reserved=0>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897171832&sdata=EV1GfOTQdaZdRg7gDKgsdIX6GqpFsg3O9FIZQGeTVWg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897171832&sdata=EV1GfOTQdaZdRg7gDKgsdIX6GqpFsg3O9FIZQGeTVWg%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897171832&sdata=EV1GfOTQdaZdRg7gDKgsdIX6GqpFsg3O9FIZQGeTVWg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C5e2a131758ea44e9c04c08d61a08341f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725019897171832&sdata=EV1GfOTQdaZdRg7gDKgsdIX6GqpFsg3O9FIZQGeTVWg%3D&reserved=0>>>
>>>>>
>>>>>
>>>>> The following commit(s) were added to refs/heads/develop by this push:
>>>>> new e1ec25e I think this fixes Menu
>>>>> e1ec25e is described below
>>>>>
>>>>> commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
>>>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>> <mailto:harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>>>>
>>>>> AuthorDate: Thu Sep 13 16:14:03 2018 +0300
>>>>>
>>>>> I think this fixes Menu
>>>>> ---
>>>>> .../projects/Basic/src/main/resources/defaults.css | 1 +
>>>>> .../controllers/ItemRendererMouseController.as | 1 -
>>>>> .../controllers/MenuSelectionMouseController.as | 33 ++++++++++++++--------
>>>>> 3 files changed, 23 insertions(+), 12 deletions(-)
>>>>>
>>>>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>>> index f88da20..15cb4e6 100644
>>>>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>>>>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>>> @@ -545,6 +545,7 @@ Panel
>>>>> IBeadModel: ClassReference("org.apache.royale.html.beads.models.PanelModel");
>>>>> IBeadView: ClassReference("org.apache.royale.html.beads.PanelView");
>>>>> IPanelLayout: ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
>>>>> + IPanelContentArea: ClassReference("org.apache.royale.html.Container");
>>>>>
>>>>> background-color: #FFFFFF;
>>>>> border: 1px solid #333333
>>>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>>> index f408a71..6073264 100644
>>>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>>> @@ -92,7 +92,6 @@ COMPILE::JS {
>>>>> goog.events.listen(element, goog.events.EventType.MOUSEOUT, this.handleMouseOut);
>>>>> goog.events.listen(element, goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
>>>>> goog.events.listen(element, goog.events.EventType.CLICK, this.handleMouseUp);
>>>>> - goog.events.listen(element, goog.events.EventType.MOUSEUP, this.handleMouseUp);
>>>>> }
>>>>> }
>>>>>
>>>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>>> index 5f986bb..6a09a52 100644
>>>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>>> @@ -127,6 +127,8 @@ package org.apache.royale.html.beads.controllers
>>>>> * @playerversion Flash 10.2
>>>>> * @playerversion AIR 2.6
>>>>> * @productversion Royale 0.9
>>>>> + * @royaleignorecoercion org.apache.royale.core.UIBase
>>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>>> */
>>>>> protected function hideOpenMenus():void
>>>>> {
>>>>> @@ -137,8 +139,9 @@ package org.apache.royale.html.beads.controllers
>>>>> if (menu.parent != null) {
>>>>> var controller:MenuSelectionMouseController = menu.getBeadByType(MenuSelectionMouseController) as MenuSelectionMouseController;
>>>>> controller.removeClickOutHandler(menu);
>>>>> - var host:IPopUpHost = UIUtils.findPopUpHost(_strand as IUIBase);
>>>>> - host.popUpParent.removeElement(menu);
>>>>> + var host:IPopUpHost = UIUtils.findPopUpHost(menu as IUIBase);
>>>>> + if(host)
>>>>> + host.popUpParent.removeElement(menu);
>>>>> }
>>>>> }
>>>>> MenuModel.clearMenuList();
>>>>> @@ -163,6 +166,8 @@ package org.apache.royale.html.beads.controllers
>>>>> * @playerversion Flash 10.2
>>>>> * @playerversion AIR 2.6
>>>>> * @productversion Royale 0.9
>>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>>> + * @royaleignorecoercion org.apache.royale.events.IEventDispatcher
>>>>> */
>>>>> public function removeClickOutHandler(menu:Object):void
>>>>> {
>>>>> @@ -191,23 +196,29 @@ package org.apache.royale.html.beads.controllers
>>>>>
>>>>> /**
>>>>> * @royaleignorecoercion HTMLElement
>>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>>> * @private
>>>>> */
>>>>> COMPILE::JS
>>>>> protected function hideMenu_internal(event:BrowserEvent):void
>>>>> {
>>>>> var menu:IMenu = _strand as IMenu;
>>>>> + var menuElem:HTMLElement = (_strand as IUIBase).element as HTMLElement;
>>>>> + var menuBarElement:HTMLElement;
>>>>> if (menu.parentMenuBar)
>>>>> {
>>>>> - var menuBarElement:HTMLElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>>>> - var target:HTMLElement = event.target as HTMLElement;
>>>>> - while (target != null)
>>>>> - {
>>>>> - if (target == menuBarElement) return;
>>>>> - target = target.parentNode as HTMLElement;
>>>>> - }
>>>>> - }
>>>>> - hideOpenMenus();
>>>>> + menuBarElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>>>> + }
>>>>> + var target:HTMLElement = event.target as HTMLElement;
>>>>> + while (target != null)
>>>>> + {
>>>>> + var comp:IUIBase = target["royale_wrapper"];
>>>>> + if(comp && (comp is IMenu || comp == menu.parentMenuBar) ) return;
>>>>> + // if (target == menuElem || (menuBarElement && target == menuBarElement) ) return;
>>>>> + target = target.parentNode as HTMLElement;
>>>>> + }
>>>>> +
>>>>> + setTimeout(hideOpenMenus);
>>>>> }
>>>>> }
>>>>> }
>>>>> \ No newline at end of file
>
>
>
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Harbs <ha...@gmail.com>.
Actually after thinking about this some more, MenuItemRenderer should have its own controller. The standard ItemRendererMouseController only needs to dispatch a single click event. MenuItemRendererMouseController could dispatch all these other events. This seems more PAYG...
Regarding “over” events on mobile, I think finger dragging would trigger “over” events there.
> On Sep 14, 2018, at 8:44 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Sure, there can/should be "item*" events as higher-level semantic events for each mouse event and touch gesture. Bonus if you can make that PAYG since mobile devices will rarely leverage "over" events. The semantic meaning is that the mouse event was not used for any other interaction in the renderer and thus can be used by a selection controller in the List.
>
> My 2 cents,
> -Alex
>
> On 9/13/18, 2:22 PM, "Harbs" <ha...@gmail.com> wrote:
>
> What about itemMouseOver? I think we’d need that too. It seems like mousing down on a menu and moving over a sub-menu should pop open the submenu.
>
>> On Sep 14, 2018, at 12:15 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Yes please. It sounds like you are already set up with some test cases.
>>
>> Thanks,
>> -Alex
>>
>> On 9/13/18, 2:12 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>
>> OK. It sounds like you have a good plan.
>>
>> I’m fine with dispatching itemMouseDown, itemMouseUp and itemClick. That makes sense and should solve the problem.
>>
>> Do you want me to work on implementing that?
>>
>>> On Sep 14, 2018, at 12:09 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> Different controllers will have different behaviors. Menu behavior is in fact one of the reasons I wanted to do beads and have replacable component logic. In your standard List, you "must" mouseDown and mouseUp on the same renderer to generate a Click that changes selection. However, in many menus, you can mouseDown on the MenuBar and without releasing the mouse button, drag down the menu to an item and release (MouseUp) and that item will be selected from the menu. Outlook's menubar on my Mac seems to work this way. So, some people will want mouseUp to change selection, others will want click to change selection. Royale should offer choices.
>>>
>>> But changing selection is a higher-level event. The lowest level events are mouseDown/mouseUp/click. In between is the "ITEM_CLICK" event and in theor, ITEM_MOUSEDOWN and ITEM_MOUSEUP. It is up to the controllers to interpret a lower-level event and then dispatch a higher-level event. It seems "illogical" to me that an ITEM_CLICK would be dispatched from a mouseUp handler. ITEM_CLICK (and ITEM_MOUSEUP if there is such a things) is meant to indicate that an event happened on the renderer that should be interpreted by the controller. Some parts of a renderer may not dispatch ITEM_CLICK (for example, in some Trees, clcking on expand/collapse icons don't change selection.
>>>
>>> Then the MenuController and ListSelectionController should be interpreting ITEM_CLICK and ITEM_MOUSEUP and deciding what to do. So maybe the answer is that the renderer's mouseUp controller dispatches ITEM_MOUSEUP, and Menu changes selection on ITEM_CLICK or ITEM_MOUSEUP.
>>>
>>> Separately, whether setTimeout or requestAnimationFrame, the more deferred work and asynchronicity we put in the framework, the more trouble we will give our users IMO. Starting such a trend has the danger of making application code use more and more callLater/setTimeout/requestAnimationFrame calls as well. We should not defer work unless we have to, and I don't think we have to in this case. Making things rely on timing creates the potential for timing issues.
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 9/13/18, 1:50 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>>
>>> That article was not what I was referring to. Like I said I couldn’t find it. I’m working from memory.
>>>
>>>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>>
>>> I don’t understand you. Are you saying that mousing down on one renderer and mousing up on another should fire an itemClick? That seems wrong to me. An itemClick should be both mouse down and mouse up on the same item. Click does that very nicely.
>>>
>>>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers.
>>>
>>> I would generally agree with you. But in this case, we’re handling the dismissal of a menu. I don’t see the harm here. If you have another proposal, I’m open to hear…
>>>
>>> We can also use requestAnimationFrame() to delay the execution until after click. That will be guaranteed to be before the next draw of the screen, so it might be better than setTimeout() which will probably be later.
>>>
>>> Thanks,
>>> Harbs
>>>
>>>> On Sep 13, 2018, at 11:20 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> wrote:
>>>>
>>>> I didn't see anywhere in the article where it guaranteed that both up and click are sequential in the queue. Sharing the heap isn't the issue here.
>>>>
>>>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>>>
>>>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers. With many browsers having immediate screen updates (as opposed to Flash's deferred rendering), postponing work with setTimeout can result in unexpected behavior, and can result in callLater "wars" where more and more code has to keep deferring work with setTimeout because some lower layer also used setTimeout. Deferring work should be the option of the application developer as much as possible.
>>>>
>>>> My 2 cents,
>>>> -Alex
>>>>
>>>> On 9/13/18, 11:36 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> I once read that the way setTimeout works is that it’s added to the next event loop. That would mean that both mouseup and click would be executed in the current event loop and the setTimout would be delayed to the next one (i..e between 4ms and 10ms later).
>>>>
>>>> I can’t find the article at the moment, but my understanding is that this is a safe way to guarantee later execution in all browsers.
>>>>
>>>> The MDN doc has a decent explanation.[1] Both mouseup and click would be on the same heap.
>>>>
>>>> Harbs
>>>>
>>>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=WlXgm2G0O5%2FneGMCkXVql3nKNLXtlD1ZMxeXVms3a%2Fk%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=WlXgm2G0O5%2FneGMCkXVql3nKNLXtlD1ZMxeXVms3a%2Fk%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=WlXgm2G0O5%2FneGMCkXVql3nKNLXtlD1ZMxeXVms3a%2Fk%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=WlXgm2G0O5%2FneGMCkXVql3nKNLXtlD1ZMxeXVms3a%2Fk%3D&reserved=0>>
>>>>> On Sep 13, 2018, at 6:54 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>> wrote:
>>>>>
>>>>> Is setTimeout guaranteed to run after the CLICK event?
>>>>>
>>>>> On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>>" <harbs@apache.org <ma...@apache.org><mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>>> wrote:
>>>>>
>>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>>
>>>>> harbs pushed a commit to branch develop
>>>>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0>>>
>>>>>
>>>>>
>>>>> The following commit(s) were added to refs/heads/develop by this push:
>>>>> new e1ec25e I think this fixes Menu
>>>>> e1ec25e is described below
>>>>>
>>>>> commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
>>>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>> <mailto:harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>>>>
>>>>> AuthorDate: Thu Sep 13 16:14:03 2018 +0300
>>>>>
>>>>> I think this fixes Menu
>>>>> ---
>>>>> .../projects/Basic/src/main/resources/defaults.css | 1 +
>>>>> .../controllers/ItemRendererMouseController.as | 1 -
>>>>> .../controllers/MenuSelectionMouseController.as | 33 ++++++++++++++--------
>>>>> 3 files changed, 23 insertions(+), 12 deletions(-)
>>>>>
>>>>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>>> index f88da20..15cb4e6 100644
>>>>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>>>>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>>> @@ -545,6 +545,7 @@ Panel
>>>>> IBeadModel: ClassReference("org.apache.royale.html.beads.models.PanelModel");
>>>>> IBeadView: ClassReference("org.apache.royale.html.beads.PanelView");
>>>>> IPanelLayout: ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
>>>>> + IPanelContentArea: ClassReference("org.apache.royale.html.Container");
>>>>>
>>>>> background-color: #FFFFFF;
>>>>> border: 1px solid #333333
>>>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>>> index f408a71..6073264 100644
>>>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>>> @@ -92,7 +92,6 @@ COMPILE::JS {
>>>>> goog.events.listen(element, goog.events.EventType.MOUSEOUT, this.handleMouseOut);
>>>>> goog.events.listen(element, goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
>>>>> goog.events.listen(element, goog.events.EventType.CLICK, this.handleMouseUp);
>>>>> - goog.events.listen(element, goog.events.EventType.MOUSEUP, this.handleMouseUp);
>>>>> }
>>>>> }
>>>>>
>>>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>>> index 5f986bb..6a09a52 100644
>>>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>>> @@ -127,6 +127,8 @@ package org.apache.royale.html.beads.controllers
>>>>> * @playerversion Flash 10.2
>>>>> * @playerversion AIR 2.6
>>>>> * @productversion Royale 0.9
>>>>> + * @royaleignorecoercion org.apache.royale.core.UIBase
>>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>>> */
>>>>> protected function hideOpenMenus():void
>>>>> {
>>>>> @@ -137,8 +139,9 @@ package org.apache.royale.html.beads.controllers
>>>>> if (menu.parent != null) {
>>>>> var controller:MenuSelectionMouseController = menu.getBeadByType(MenuSelectionMouseController) as MenuSelectionMouseController;
>>>>> controller.removeClickOutHandler(menu);
>>>>> - var host:IPopUpHost = UIUtils.findPopUpHost(_strand as IUIBase);
>>>>> - host.popUpParent.removeElement(menu);
>>>>> + var host:IPopUpHost = UIUtils.findPopUpHost(menu as IUIBase);
>>>>> + if(host)
>>>>> + host.popUpParent.removeElement(menu);
>>>>> }
>>>>> }
>>>>> MenuModel.clearMenuList();
>>>>> @@ -163,6 +166,8 @@ package org.apache.royale.html.beads.controllers
>>>>> * @playerversion Flash 10.2
>>>>> * @playerversion AIR 2.6
>>>>> * @productversion Royale 0.9
>>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>>> + * @royaleignorecoercion org.apache.royale.events.IEventDispatcher
>>>>> */
>>>>> public function removeClickOutHandler(menu:Object):void
>>>>> {
>>>>> @@ -191,23 +196,29 @@ package org.apache.royale.html.beads.controllers
>>>>>
>>>>> /**
>>>>> * @royaleignorecoercion HTMLElement
>>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>>> * @private
>>>>> */
>>>>> COMPILE::JS
>>>>> protected function hideMenu_internal(event:BrowserEvent):void
>>>>> {
>>>>> var menu:IMenu = _strand as IMenu;
>>>>> + var menuElem:HTMLElement = (_strand as IUIBase).element as HTMLElement;
>>>>> + var menuBarElement:HTMLElement;
>>>>> if (menu.parentMenuBar)
>>>>> {
>>>>> - var menuBarElement:HTMLElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>>>> - var target:HTMLElement = event.target as HTMLElement;
>>>>> - while (target != null)
>>>>> - {
>>>>> - if (target == menuBarElement) return;
>>>>> - target = target.parentNode as HTMLElement;
>>>>> - }
>>>>> - }
>>>>> - hideOpenMenus();
>>>>> + menuBarElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>>>> + }
>>>>> + var target:HTMLElement = event.target as HTMLElement;
>>>>> + while (target != null)
>>>>> + {
>>>>> + var comp:IUIBase = target["royale_wrapper"];
>>>>> + if(comp && (comp is IMenu || comp == menu.parentMenuBar) ) return;
>>>>> + // if (target == menuElem || (menuBarElement && target == menuBarElement) ) return;
>>>>> + target = target.parentNode as HTMLElement;
>>>>> + }
>>>>> +
>>>>> + setTimeout(hideOpenMenus);
>>>>> }
>>>>> }
>>>>> }
>>>>> \ No newline at end of file
>
>
>
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Sure, there can/should be "item*" events as higher-level semantic events for each mouse event and touch gesture. Bonus if you can make that PAYG since mobile devices will rarely leverage "over" events. The semantic meaning is that the mouse event was not used for any other interaction in the renderer and thus can be used by a selection controller in the List.
My 2 cents,
-Alex
On 9/13/18, 2:22 PM, "Harbs" <ha...@gmail.com> wrote:
What about itemMouseOver? I think we’d need that too. It seems like mousing down on a menu and moving over a sub-menu should pop open the submenu.
> On Sep 14, 2018, at 12:15 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Yes please. It sounds like you are already set up with some test cases.
>
> Thanks,
> -Alex
>
> On 9/13/18, 2:12 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> OK. It sounds like you have a good plan.
>
> I’m fine with dispatching itemMouseDown, itemMouseUp and itemClick. That makes sense and should solve the problem.
>
> Do you want me to work on implementing that?
>
>> On Sep 14, 2018, at 12:09 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Different controllers will have different behaviors. Menu behavior is in fact one of the reasons I wanted to do beads and have replacable component logic. In your standard List, you "must" mouseDown and mouseUp on the same renderer to generate a Click that changes selection. However, in many menus, you can mouseDown on the MenuBar and without releasing the mouse button, drag down the menu to an item and release (MouseUp) and that item will be selected from the menu. Outlook's menubar on my Mac seems to work this way. So, some people will want mouseUp to change selection, others will want click to change selection. Royale should offer choices.
>>
>> But changing selection is a higher-level event. The lowest level events are mouseDown/mouseUp/click. In between is the "ITEM_CLICK" event and in theor, ITEM_MOUSEDOWN and ITEM_MOUSEUP. It is up to the controllers to interpret a lower-level event and then dispatch a higher-level event. It seems "illogical" to me that an ITEM_CLICK would be dispatched from a mouseUp handler. ITEM_CLICK (and ITEM_MOUSEUP if there is such a things) is meant to indicate that an event happened on the renderer that should be interpreted by the controller. Some parts of a renderer may not dispatch ITEM_CLICK (for example, in some Trees, clcking on expand/collapse icons don't change selection.
>>
>> Then the MenuController and ListSelectionController should be interpreting ITEM_CLICK and ITEM_MOUSEUP and deciding what to do. So maybe the answer is that the renderer's mouseUp controller dispatches ITEM_MOUSEUP, and Menu changes selection on ITEM_CLICK or ITEM_MOUSEUP.
>>
>> Separately, whether setTimeout or requestAnimationFrame, the more deferred work and asynchronicity we put in the framework, the more trouble we will give our users IMO. Starting such a trend has the danger of making application code use more and more callLater/setTimeout/requestAnimationFrame calls as well. We should not defer work unless we have to, and I don't think we have to in this case. Making things rely on timing creates the potential for timing issues.
>>
>> My 2 cents,
>> -Alex
>>
>> On 9/13/18, 1:50 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>
>> That article was not what I was referring to. Like I said I couldn’t find it. I’m working from memory.
>>
>>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>
>> I don’t understand you. Are you saying that mousing down on one renderer and mousing up on another should fire an itemClick? That seems wrong to me. An itemClick should be both mouse down and mouse up on the same item. Click does that very nicely.
>>
>>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers.
>>
>> I would generally agree with you. But in this case, we’re handling the dismissal of a menu. I don’t see the harm here. If you have another proposal, I’m open to hear…
>>
>> We can also use requestAnimationFrame() to delay the execution until after click. That will be guaranteed to be before the next draw of the screen, so it might be better than setTimeout() which will probably be later.
>>
>> Thanks,
>> Harbs
>>
>>> On Sep 13, 2018, at 11:20 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> wrote:
>>>
>>> I didn't see anywhere in the article where it guaranteed that both up and click are sequential in the queue. Sharing the heap isn't the issue here.
>>>
>>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>>
>>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers. With many browsers having immediate screen updates (as opposed to Flash's deferred rendering), postponing work with setTimeout can result in unexpected behavior, and can result in callLater "wars" where more and more code has to keep deferring work with setTimeout because some lower layer also used setTimeout. Deferring work should be the option of the application developer as much as possible.
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 9/13/18, 11:36 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> I once read that the way setTimeout works is that it’s added to the next event loop. That would mean that both mouseup and click would be executed in the current event loop and the setTimout would be delayed to the next one (i..e between 4ms and 10ms later).
>>>
>>> I can’t find the article at the moment, but my understanding is that this is a safe way to guarantee later execution in all browsers.
>>>
>>> The MDN doc has a decent explanation.[1] Both mouseup and click would be on the same heap.
>>>
>>> Harbs
>>>
>>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=WlXgm2G0O5%2FneGMCkXVql3nKNLXtlD1ZMxeXVms3a%2Fk%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=WlXgm2G0O5%2FneGMCkXVql3nKNLXtlD1ZMxeXVms3a%2Fk%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=WlXgm2G0O5%2FneGMCkXVql3nKNLXtlD1ZMxeXVms3a%2Fk%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=WlXgm2G0O5%2FneGMCkXVql3nKNLXtlD1ZMxeXVms3a%2Fk%3D&reserved=0>>
>>>> On Sep 13, 2018, at 6:54 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>> wrote:
>>>>
>>>> Is setTimeout guaranteed to run after the CLICK event?
>>>>
>>>> On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>>" <harbs@apache.org <ma...@apache.org><mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>>> wrote:
>>>>
>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>
>>>> harbs pushed a commit to branch develop
>>>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cfb60650ae1ab445e42a208d619bf04c0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724705541473946&sdata=jjONJRkIS9RJImEu8p92y3HpBkrQeRqOZChFg6jJw%2FQ%3D&reserved=0>>>
>>>>
>>>>
>>>> The following commit(s) were added to refs/heads/develop by this push:
>>>> new e1ec25e I think this fixes Menu
>>>> e1ec25e is described below
>>>>
>>>> commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
>>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>> <mailto:harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>>>>
>>>> AuthorDate: Thu Sep 13 16:14:03 2018 +0300
>>>>
>>>> I think this fixes Menu
>>>> ---
>>>> .../projects/Basic/src/main/resources/defaults.css | 1 +
>>>> .../controllers/ItemRendererMouseController.as | 1 -
>>>> .../controllers/MenuSelectionMouseController.as | 33 ++++++++++++++--------
>>>> 3 files changed, 23 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>> index f88da20..15cb4e6 100644
>>>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>>>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>> @@ -545,6 +545,7 @@ Panel
>>>> IBeadModel: ClassReference("org.apache.royale.html.beads.models.PanelModel");
>>>> IBeadView: ClassReference("org.apache.royale.html.beads.PanelView");
>>>> IPanelLayout: ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
>>>> + IPanelContentArea: ClassReference("org.apache.royale.html.Container");
>>>>
>>>> background-color: #FFFFFF;
>>>> border: 1px solid #333333
>>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>> index f408a71..6073264 100644
>>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>> @@ -92,7 +92,6 @@ COMPILE::JS {
>>>> goog.events.listen(element, goog.events.EventType.MOUSEOUT, this.handleMouseOut);
>>>> goog.events.listen(element, goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
>>>> goog.events.listen(element, goog.events.EventType.CLICK, this.handleMouseUp);
>>>> - goog.events.listen(element, goog.events.EventType.MOUSEUP, this.handleMouseUp);
>>>> }
>>>> }
>>>>
>>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>> index 5f986bb..6a09a52 100644
>>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>> @@ -127,6 +127,8 @@ package org.apache.royale.html.beads.controllers
>>>> * @playerversion Flash 10.2
>>>> * @playerversion AIR 2.6
>>>> * @productversion Royale 0.9
>>>> + * @royaleignorecoercion org.apache.royale.core.UIBase
>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>> */
>>>> protected function hideOpenMenus():void
>>>> {
>>>> @@ -137,8 +139,9 @@ package org.apache.royale.html.beads.controllers
>>>> if (menu.parent != null) {
>>>> var controller:MenuSelectionMouseController = menu.getBeadByType(MenuSelectionMouseController) as MenuSelectionMouseController;
>>>> controller.removeClickOutHandler(menu);
>>>> - var host:IPopUpHost = UIUtils.findPopUpHost(_strand as IUIBase);
>>>> - host.popUpParent.removeElement(menu);
>>>> + var host:IPopUpHost = UIUtils.findPopUpHost(menu as IUIBase);
>>>> + if(host)
>>>> + host.popUpParent.removeElement(menu);
>>>> }
>>>> }
>>>> MenuModel.clearMenuList();
>>>> @@ -163,6 +166,8 @@ package org.apache.royale.html.beads.controllers
>>>> * @playerversion Flash 10.2
>>>> * @playerversion AIR 2.6
>>>> * @productversion Royale 0.9
>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>> + * @royaleignorecoercion org.apache.royale.events.IEventDispatcher
>>>> */
>>>> public function removeClickOutHandler(menu:Object):void
>>>> {
>>>> @@ -191,23 +196,29 @@ package org.apache.royale.html.beads.controllers
>>>>
>>>> /**
>>>> * @royaleignorecoercion HTMLElement
>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>> * @private
>>>> */
>>>> COMPILE::JS
>>>> protected function hideMenu_internal(event:BrowserEvent):void
>>>> {
>>>> var menu:IMenu = _strand as IMenu;
>>>> + var menuElem:HTMLElement = (_strand as IUIBase).element as HTMLElement;
>>>> + var menuBarElement:HTMLElement;
>>>> if (menu.parentMenuBar)
>>>> {
>>>> - var menuBarElement:HTMLElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>>> - var target:HTMLElement = event.target as HTMLElement;
>>>> - while (target != null)
>>>> - {
>>>> - if (target == menuBarElement) return;
>>>> - target = target.parentNode as HTMLElement;
>>>> - }
>>>> - }
>>>> - hideOpenMenus();
>>>> + menuBarElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>>> + }
>>>> + var target:HTMLElement = event.target as HTMLElement;
>>>> + while (target != null)
>>>> + {
>>>> + var comp:IUIBase = target["royale_wrapper"];
>>>> + if(comp && (comp is IMenu || comp == menu.parentMenuBar) ) return;
>>>> + // if (target == menuElem || (menuBarElement && target == menuBarElement) ) return;
>>>> + target = target.parentNode as HTMLElement;
>>>> + }
>>>> +
>>>> + setTimeout(hideOpenMenus);
>>>> }
>>>> }
>>>> }
>>>> \ No newline at end of file
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Harbs <ha...@gmail.com>.
What about itemMouseOver? I think we’d need that too. It seems like mousing down on a menu and moving over a sub-menu should pop open the submenu.
> On Sep 14, 2018, at 12:15 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Yes please. It sounds like you are already set up with some test cases.
>
> Thanks,
> -Alex
>
> On 9/13/18, 2:12 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> OK. It sounds like you have a good plan.
>
> I’m fine with dispatching itemMouseDown, itemMouseUp and itemClick. That makes sense and should solve the problem.
>
> Do you want me to work on implementing that?
>
>> On Sep 14, 2018, at 12:09 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Different controllers will have different behaviors. Menu behavior is in fact one of the reasons I wanted to do beads and have replacable component logic. In your standard List, you "must" mouseDown and mouseUp on the same renderer to generate a Click that changes selection. However, in many menus, you can mouseDown on the MenuBar and without releasing the mouse button, drag down the menu to an item and release (MouseUp) and that item will be selected from the menu. Outlook's menubar on my Mac seems to work this way. So, some people will want mouseUp to change selection, others will want click to change selection. Royale should offer choices.
>>
>> But changing selection is a higher-level event. The lowest level events are mouseDown/mouseUp/click. In between is the "ITEM_CLICK" event and in theor, ITEM_MOUSEDOWN and ITEM_MOUSEUP. It is up to the controllers to interpret a lower-level event and then dispatch a higher-level event. It seems "illogical" to me that an ITEM_CLICK would be dispatched from a mouseUp handler. ITEM_CLICK (and ITEM_MOUSEUP if there is such a things) is meant to indicate that an event happened on the renderer that should be interpreted by the controller. Some parts of a renderer may not dispatch ITEM_CLICK (for example, in some Trees, clcking on expand/collapse icons don't change selection.
>>
>> Then the MenuController and ListSelectionController should be interpreting ITEM_CLICK and ITEM_MOUSEUP and deciding what to do. So maybe the answer is that the renderer's mouseUp controller dispatches ITEM_MOUSEUP, and Menu changes selection on ITEM_CLICK or ITEM_MOUSEUP.
>>
>> Separately, whether setTimeout or requestAnimationFrame, the more deferred work and asynchronicity we put in the framework, the more trouble we will give our users IMO. Starting such a trend has the danger of making application code use more and more callLater/setTimeout/requestAnimationFrame calls as well. We should not defer work unless we have to, and I don't think we have to in this case. Making things rely on timing creates the potential for timing issues.
>>
>> My 2 cents,
>> -Alex
>>
>> On 9/13/18, 1:50 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>
>> That article was not what I was referring to. Like I said I couldn’t find it. I’m working from memory.
>>
>>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>
>> I don’t understand you. Are you saying that mousing down on one renderer and mousing up on another should fire an itemClick? That seems wrong to me. An itemClick should be both mouse down and mouse up on the same item. Click does that very nicely.
>>
>>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers.
>>
>> I would generally agree with you. But in this case, we’re handling the dismissal of a menu. I don’t see the harm here. If you have another proposal, I’m open to hear…
>>
>> We can also use requestAnimationFrame() to delay the execution until after click. That will be guaranteed to be before the next draw of the screen, so it might be better than setTimeout() which will probably be later.
>>
>> Thanks,
>> Harbs
>>
>>> On Sep 13, 2018, at 11:20 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> wrote:
>>>
>>> I didn't see anywhere in the article where it guaranteed that both up and click are sequential in the queue. Sharing the heap isn't the issue here.
>>>
>>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>>
>>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers. With many browsers having immediate screen updates (as opposed to Flash's deferred rendering), postponing work with setTimeout can result in unexpected behavior, and can result in callLater "wars" where more and more code has to keep deferring work with setTimeout because some lower layer also used setTimeout. Deferring work should be the option of the application developer as much as possible.
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 9/13/18, 11:36 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> I once read that the way setTimeout works is that it’s added to the next event loop. That would mean that both mouseup and click would be executed in the current event loop and the setTimout would be delayed to the next one (i..e between 4ms and 10ms later).
>>>
>>> I can’t find the article at the moment, but my understanding is that this is a safe way to guarantee later execution in all browsers.
>>>
>>> The MDN doc has a decent explanation.[1] Both mouseup and click would be on the same heap.
>>>
>>> Harbs
>>>
>>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=sbp%2FEYrqHaPIKhbtaDnUm%2FnbL3qFGOBJ10saQ6Km3cA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=sbp%2FEYrqHaPIKhbtaDnUm%2FnbL3qFGOBJ10saQ6Km3cA%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=sbp%2FEYrqHaPIKhbtaDnUm%2FnbL3qFGOBJ10saQ6Km3cA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=sbp%2FEYrqHaPIKhbtaDnUm%2FnbL3qFGOBJ10saQ6Km3cA%3D&reserved=0>>
>>>> On Sep 13, 2018, at 6:54 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>> wrote:
>>>>
>>>> Is setTimeout guaranteed to run after the CLICK event?
>>>>
>>>> On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>>" <harbs@apache.org <ma...@apache.org><mailto:harbs@apache.org <ma...@apache.org>> <mailto:harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>>> wrote:
>>>>
>>>> This is an automated email from the ASF dual-hosted git repository.
>>>>
>>>> harbs pushed a commit to branch develop
>>>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=GXGY1kdljfNOtmF9t1nCUx2EN8oZ0BOuH4Qwiv%2FYxzM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=GXGY1kdljfNOtmF9t1nCUx2EN8oZ0BOuH4Qwiv%2FYxzM%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=GXGY1kdljfNOtmF9t1nCUx2EN8oZ0BOuH4Qwiv%2FYxzM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=GXGY1kdljfNOtmF9t1nCUx2EN8oZ0BOuH4Qwiv%2FYxzM%3D&reserved=0>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=GXGY1kdljfNOtmF9t1nCUx2EN8oZ0BOuH4Qwiv%2FYxzM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=GXGY1kdljfNOtmF9t1nCUx2EN8oZ0BOuH4Qwiv%2FYxzM%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=GXGY1kdljfNOtmF9t1nCUx2EN8oZ0BOuH4Qwiv%2FYxzM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=GXGY1kdljfNOtmF9t1nCUx2EN8oZ0BOuH4Qwiv%2FYxzM%3D&reserved=0>>>
>>>>
>>>>
>>>> The following commit(s) were added to refs/heads/develop by this push:
>>>> new e1ec25e I think this fixes Menu
>>>> e1ec25e is described below
>>>>
>>>> commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
>>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>> <mailto:harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>>>>
>>>> AuthorDate: Thu Sep 13 16:14:03 2018 +0300
>>>>
>>>> I think this fixes Menu
>>>> ---
>>>> .../projects/Basic/src/main/resources/defaults.css | 1 +
>>>> .../controllers/ItemRendererMouseController.as | 1 -
>>>> .../controllers/MenuSelectionMouseController.as | 33 ++++++++++++++--------
>>>> 3 files changed, 23 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>> index f88da20..15cb4e6 100644
>>>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>>>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>> @@ -545,6 +545,7 @@ Panel
>>>> IBeadModel: ClassReference("org.apache.royale.html.beads.models.PanelModel");
>>>> IBeadView: ClassReference("org.apache.royale.html.beads.PanelView");
>>>> IPanelLayout: ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
>>>> + IPanelContentArea: ClassReference("org.apache.royale.html.Container");
>>>>
>>>> background-color: #FFFFFF;
>>>> border: 1px solid #333333
>>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>> index f408a71..6073264 100644
>>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>>> @@ -92,7 +92,6 @@ COMPILE::JS {
>>>> goog.events.listen(element, goog.events.EventType.MOUSEOUT, this.handleMouseOut);
>>>> goog.events.listen(element, goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
>>>> goog.events.listen(element, goog.events.EventType.CLICK, this.handleMouseUp);
>>>> - goog.events.listen(element, goog.events.EventType.MOUSEUP, this.handleMouseUp);
>>>> }
>>>> }
>>>>
>>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>> index 5f986bb..6a09a52 100644
>>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>>> @@ -127,6 +127,8 @@ package org.apache.royale.html.beads.controllers
>>>> * @playerversion Flash 10.2
>>>> * @playerversion AIR 2.6
>>>> * @productversion Royale 0.9
>>>> + * @royaleignorecoercion org.apache.royale.core.UIBase
>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>> */
>>>> protected function hideOpenMenus():void
>>>> {
>>>> @@ -137,8 +139,9 @@ package org.apache.royale.html.beads.controllers
>>>> if (menu.parent != null) {
>>>> var controller:MenuSelectionMouseController = menu.getBeadByType(MenuSelectionMouseController) as MenuSelectionMouseController;
>>>> controller.removeClickOutHandler(menu);
>>>> - var host:IPopUpHost = UIUtils.findPopUpHost(_strand as IUIBase);
>>>> - host.popUpParent.removeElement(menu);
>>>> + var host:IPopUpHost = UIUtils.findPopUpHost(menu as IUIBase);
>>>> + if(host)
>>>> + host.popUpParent.removeElement(menu);
>>>> }
>>>> }
>>>> MenuModel.clearMenuList();
>>>> @@ -163,6 +166,8 @@ package org.apache.royale.html.beads.controllers
>>>> * @playerversion Flash 10.2
>>>> * @playerversion AIR 2.6
>>>> * @productversion Royale 0.9
>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>> + * @royaleignorecoercion org.apache.royale.events.IEventDispatcher
>>>> */
>>>> public function removeClickOutHandler(menu:Object):void
>>>> {
>>>> @@ -191,23 +196,29 @@ package org.apache.royale.html.beads.controllers
>>>>
>>>> /**
>>>> * @royaleignorecoercion HTMLElement
>>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>>> * @private
>>>> */
>>>> COMPILE::JS
>>>> protected function hideMenu_internal(event:BrowserEvent):void
>>>> {
>>>> var menu:IMenu = _strand as IMenu;
>>>> + var menuElem:HTMLElement = (_strand as IUIBase).element as HTMLElement;
>>>> + var menuBarElement:HTMLElement;
>>>> if (menu.parentMenuBar)
>>>> {
>>>> - var menuBarElement:HTMLElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>>> - var target:HTMLElement = event.target as HTMLElement;
>>>> - while (target != null)
>>>> - {
>>>> - if (target == menuBarElement) return;
>>>> - target = target.parentNode as HTMLElement;
>>>> - }
>>>> - }
>>>> - hideOpenMenus();
>>>> + menuBarElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>>> + }
>>>> + var target:HTMLElement = event.target as HTMLElement;
>>>> + while (target != null)
>>>> + {
>>>> + var comp:IUIBase = target["royale_wrapper"];
>>>> + if(comp && (comp is IMenu || comp == menu.parentMenuBar) ) return;
>>>> + // if (target == menuElem || (menuBarElement && target == menuBarElement) ) return;
>>>> + target = target.parentNode as HTMLElement;
>>>> + }
>>>> +
>>>> + setTimeout(hideOpenMenus);
>>>> }
>>>> }
>>>> }
>>>> \ No newline at end of file
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Yes please. It sounds like you are already set up with some test cases.
Thanks,
-Alex
On 9/13/18, 2:12 PM, "Harbs" <ha...@gmail.com> wrote:
OK. It sounds like you have a good plan.
I’m fine with dispatching itemMouseDown, itemMouseUp and itemClick. That makes sense and should solve the problem.
Do you want me to work on implementing that?
> On Sep 14, 2018, at 12:09 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Different controllers will have different behaviors. Menu behavior is in fact one of the reasons I wanted to do beads and have replacable component logic. In your standard List, you "must" mouseDown and mouseUp on the same renderer to generate a Click that changes selection. However, in many menus, you can mouseDown on the MenuBar and without releasing the mouse button, drag down the menu to an item and release (MouseUp) and that item will be selected from the menu. Outlook's menubar on my Mac seems to work this way. So, some people will want mouseUp to change selection, others will want click to change selection. Royale should offer choices.
>
> But changing selection is a higher-level event. The lowest level events are mouseDown/mouseUp/click. In between is the "ITEM_CLICK" event and in theor, ITEM_MOUSEDOWN and ITEM_MOUSEUP. It is up to the controllers to interpret a lower-level event and then dispatch a higher-level event. It seems "illogical" to me that an ITEM_CLICK would be dispatched from a mouseUp handler. ITEM_CLICK (and ITEM_MOUSEUP if there is such a things) is meant to indicate that an event happened on the renderer that should be interpreted by the controller. Some parts of a renderer may not dispatch ITEM_CLICK (for example, in some Trees, clcking on expand/collapse icons don't change selection.
>
> Then the MenuController and ListSelectionController should be interpreting ITEM_CLICK and ITEM_MOUSEUP and deciding what to do. So maybe the answer is that the renderer's mouseUp controller dispatches ITEM_MOUSEUP, and Menu changes selection on ITEM_CLICK or ITEM_MOUSEUP.
>
> Separately, whether setTimeout or requestAnimationFrame, the more deferred work and asynchronicity we put in the framework, the more trouble we will give our users IMO. Starting such a trend has the danger of making application code use more and more callLater/setTimeout/requestAnimationFrame calls as well. We should not defer work unless we have to, and I don't think we have to in this case. Making things rely on timing creates the potential for timing issues.
>
> My 2 cents,
> -Alex
>
> On 9/13/18, 1:50 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> That article was not what I was referring to. Like I said I couldn’t find it. I’m working from memory.
>
>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>
> I don’t understand you. Are you saying that mousing down on one renderer and mousing up on another should fire an itemClick? That seems wrong to me. An itemClick should be both mouse down and mouse up on the same item. Click does that very nicely.
>
>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers.
>
> I would generally agree with you. But in this case, we’re handling the dismissal of a menu. I don’t see the harm here. If you have another proposal, I’m open to hear…
>
> We can also use requestAnimationFrame() to delay the execution until after click. That will be guaranteed to be before the next draw of the screen, so it might be better than setTimeout() which will probably be later.
>
> Thanks,
> Harbs
>
>> On Sep 13, 2018, at 11:20 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> I didn't see anywhere in the article where it guaranteed that both up and click are sequential in the queue. Sharing the heap isn't the issue here.
>>
>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>
>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers. With many browsers having immediate screen updates (as opposed to Flash's deferred rendering), postponing work with setTimeout can result in unexpected behavior, and can result in callLater "wars" where more and more code has to keep deferring work with setTimeout because some lower layer also used setTimeout. Deferring work should be the option of the application developer as much as possible.
>>
>> My 2 cents,
>> -Alex
>>
>> On 9/13/18, 11:36 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> I once read that the way setTimeout works is that it’s added to the next event loop. That would mean that both mouseup and click would be executed in the current event loop and the setTimout would be delayed to the next one (i..e between 4ms and 10ms later).
>>
>> I can’t find the article at the moment, but my understanding is that this is a safe way to guarantee later execution in all browsers.
>>
>> The MDN doc has a decent explanation.[1] Both mouseup and click would be on the same heap.
>>
>> Harbs
>>
>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=sbp%2FEYrqHaPIKhbtaDnUm%2FnbL3qFGOBJ10saQ6Km3cA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=sbp%2FEYrqHaPIKhbtaDnUm%2FnbL3qFGOBJ10saQ6Km3cA%3D&reserved=0>
>>> On Sep 13, 2018, at 6:54 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> wrote:
>>>
>>> Is setTimeout guaranteed to run after the CLICK event?
>>>
>>> On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>" <harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>> wrote:
>>>
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> harbs pushed a commit to branch develop
>>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=GXGY1kdljfNOtmF9t1nCUx2EN8oZ0BOuH4Qwiv%2FYxzM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=GXGY1kdljfNOtmF9t1nCUx2EN8oZ0BOuH4Qwiv%2FYxzM%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=GXGY1kdljfNOtmF9t1nCUx2EN8oZ0BOuH4Qwiv%2FYxzM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Cc33cd3814b3a48f26c4808d619bda54b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724699651430925&sdata=GXGY1kdljfNOtmF9t1nCUx2EN8oZ0BOuH4Qwiv%2FYxzM%3D&reserved=0>>
>>>
>>>
>>> The following commit(s) were added to refs/heads/develop by this push:
>>> new e1ec25e I think this fixes Menu
>>> e1ec25e is described below
>>>
>>> commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>>>
>>> AuthorDate: Thu Sep 13 16:14:03 2018 +0300
>>>
>>> I think this fixes Menu
>>> ---
>>> .../projects/Basic/src/main/resources/defaults.css | 1 +
>>> .../controllers/ItemRendererMouseController.as | 1 -
>>> .../controllers/MenuSelectionMouseController.as | 33 ++++++++++++++--------
>>> 3 files changed, 23 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css b/frameworks/projects/Basic/src/main/resources/defaults.css
>>> index f88da20..15cb4e6 100644
>>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>>> @@ -545,6 +545,7 @@ Panel
>>> IBeadModel: ClassReference("org.apache.royale.html.beads.models.PanelModel");
>>> IBeadView: ClassReference("org.apache.royale.html.beads.PanelView");
>>> IPanelLayout: ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
>>> + IPanelContentArea: ClassReference("org.apache.royale.html.Container");
>>>
>>> background-color: #FFFFFF;
>>> border: 1px solid #333333
>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>> index f408a71..6073264 100644
>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>> @@ -92,7 +92,6 @@ COMPILE::JS {
>>> goog.events.listen(element, goog.events.EventType.MOUSEOUT, this.handleMouseOut);
>>> goog.events.listen(element, goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
>>> goog.events.listen(element, goog.events.EventType.CLICK, this.handleMouseUp);
>>> - goog.events.listen(element, goog.events.EventType.MOUSEUP, this.handleMouseUp);
>>> }
>>> }
>>>
>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>> index 5f986bb..6a09a52 100644
>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>> @@ -127,6 +127,8 @@ package org.apache.royale.html.beads.controllers
>>> * @playerversion Flash 10.2
>>> * @playerversion AIR 2.6
>>> * @productversion Royale 0.9
>>> + * @royaleignorecoercion org.apache.royale.core.UIBase
>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>> */
>>> protected function hideOpenMenus():void
>>> {
>>> @@ -137,8 +139,9 @@ package org.apache.royale.html.beads.controllers
>>> if (menu.parent != null) {
>>> var controller:MenuSelectionMouseController = menu.getBeadByType(MenuSelectionMouseController) as MenuSelectionMouseController;
>>> controller.removeClickOutHandler(menu);
>>> - var host:IPopUpHost = UIUtils.findPopUpHost(_strand as IUIBase);
>>> - host.popUpParent.removeElement(menu);
>>> + var host:IPopUpHost = UIUtils.findPopUpHost(menu as IUIBase);
>>> + if(host)
>>> + host.popUpParent.removeElement(menu);
>>> }
>>> }
>>> MenuModel.clearMenuList();
>>> @@ -163,6 +166,8 @@ package org.apache.royale.html.beads.controllers
>>> * @playerversion Flash 10.2
>>> * @playerversion AIR 2.6
>>> * @productversion Royale 0.9
>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>> + * @royaleignorecoercion org.apache.royale.events.IEventDispatcher
>>> */
>>> public function removeClickOutHandler(menu:Object):void
>>> {
>>> @@ -191,23 +196,29 @@ package org.apache.royale.html.beads.controllers
>>>
>>> /**
>>> * @royaleignorecoercion HTMLElement
>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>> * @private
>>> */
>>> COMPILE::JS
>>> protected function hideMenu_internal(event:BrowserEvent):void
>>> {
>>> var menu:IMenu = _strand as IMenu;
>>> + var menuElem:HTMLElement = (_strand as IUIBase).element as HTMLElement;
>>> + var menuBarElement:HTMLElement;
>>> if (menu.parentMenuBar)
>>> {
>>> - var menuBarElement:HTMLElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>> - var target:HTMLElement = event.target as HTMLElement;
>>> - while (target != null)
>>> - {
>>> - if (target == menuBarElement) return;
>>> - target = target.parentNode as HTMLElement;
>>> - }
>>> - }
>>> - hideOpenMenus();
>>> + menuBarElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>> + }
>>> + var target:HTMLElement = event.target as HTMLElement;
>>> + while (target != null)
>>> + {
>>> + var comp:IUIBase = target["royale_wrapper"];
>>> + if(comp && (comp is IMenu || comp == menu.parentMenuBar) ) return;
>>> + // if (target == menuElem || (menuBarElement && target == menuBarElement) ) return;
>>> + target = target.parentNode as HTMLElement;
>>> + }
>>> +
>>> + setTimeout(hideOpenMenus);
>>> }
>>> }
>>> }
>>> \ No newline at end of file
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Harbs <ha...@gmail.com>.
OK. It sounds like you have a good plan.
I’m fine with dispatching itemMouseDown, itemMouseUp and itemClick. That makes sense and should solve the problem.
Do you want me to work on implementing that?
> On Sep 14, 2018, at 12:09 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Different controllers will have different behaviors. Menu behavior is in fact one of the reasons I wanted to do beads and have replacable component logic. In your standard List, you "must" mouseDown and mouseUp on the same renderer to generate a Click that changes selection. However, in many menus, you can mouseDown on the MenuBar and without releasing the mouse button, drag down the menu to an item and release (MouseUp) and that item will be selected from the menu. Outlook's menubar on my Mac seems to work this way. So, some people will want mouseUp to change selection, others will want click to change selection. Royale should offer choices.
>
> But changing selection is a higher-level event. The lowest level events are mouseDown/mouseUp/click. In between is the "ITEM_CLICK" event and in theor, ITEM_MOUSEDOWN and ITEM_MOUSEUP. It is up to the controllers to interpret a lower-level event and then dispatch a higher-level event. It seems "illogical" to me that an ITEM_CLICK would be dispatched from a mouseUp handler. ITEM_CLICK (and ITEM_MOUSEUP if there is such a things) is meant to indicate that an event happened on the renderer that should be interpreted by the controller. Some parts of a renderer may not dispatch ITEM_CLICK (for example, in some Trees, clcking on expand/collapse icons don't change selection.
>
> Then the MenuController and ListSelectionController should be interpreting ITEM_CLICK and ITEM_MOUSEUP and deciding what to do. So maybe the answer is that the renderer's mouseUp controller dispatches ITEM_MOUSEUP, and Menu changes selection on ITEM_CLICK or ITEM_MOUSEUP.
>
> Separately, whether setTimeout or requestAnimationFrame, the more deferred work and asynchronicity we put in the framework, the more trouble we will give our users IMO. Starting such a trend has the danger of making application code use more and more callLater/setTimeout/requestAnimationFrame calls as well. We should not defer work unless we have to, and I don't think we have to in this case. Making things rely on timing creates the potential for timing issues.
>
> My 2 cents,
> -Alex
>
> On 9/13/18, 1:50 PM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
> That article was not what I was referring to. Like I said I couldn’t find it. I’m working from memory.
>
>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>
> I don’t understand you. Are you saying that mousing down on one renderer and mousing up on another should fire an itemClick? That seems wrong to me. An itemClick should be both mouse down and mouse up on the same item. Click does that very nicely.
>
>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers.
>
> I would generally agree with you. But in this case, we’re handling the dismissal of a menu. I don’t see the harm here. If you have another proposal, I’m open to hear…
>
> We can also use requestAnimationFrame() to delay the execution until after click. That will be guaranteed to be before the next draw of the screen, so it might be better than setTimeout() which will probably be later.
>
> Thanks,
> Harbs
>
>> On Sep 13, 2018, at 11:20 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> I didn't see anywhere in the article where it guaranteed that both up and click are sequential in the queue. Sharing the heap isn't the issue here.
>>
>> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>>
>> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers. With many browsers having immediate screen updates (as opposed to Flash's deferred rendering), postponing work with setTimeout can result in unexpected behavior, and can result in callLater "wars" where more and more code has to keep deferring work with setTimeout because some lower layer also used setTimeout. Deferring work should be the option of the application developer as much as possible.
>>
>> My 2 cents,
>> -Alex
>>
>> On 9/13/18, 11:36 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> I once read that the way setTimeout works is that it’s added to the next event loop. That would mean that both mouseup and click would be executed in the current event loop and the setTimout would be delayed to the next one (i..e between 4ms and 10ms later).
>>
>> I can’t find the article at the moment, but my understanding is that this is a safe way to guarantee later execution in all browsers.
>>
>> The MDN doc has a decent explanation.[1] Both mouseup and click would be on the same heap.
>>
>> Harbs
>>
>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C9ee09de039e5447493e208d619ba7b44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724686077133255&sdata=P0peR5eRbvHOFN1DgfG7q2Lho4cSbH47z3l4m77Vx6s%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C9ee09de039e5447493e208d619ba7b44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724686077133255&sdata=P0peR5eRbvHOFN1DgfG7q2Lho4cSbH47z3l4m77Vx6s%3D&reserved=0>
>>> On Sep 13, 2018, at 6:54 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> wrote:
>>>
>>> Is setTimeout guaranteed to run after the CLICK event?
>>>
>>> On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>" <harbs@apache.org <ma...@apache.org> <mailto:harbs@apache.org <ma...@apache.org>>> wrote:
>>>
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> harbs pushed a commit to branch develop
>>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C9ee09de039e5447493e208d619ba7b44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724686077133255&sdata=lOu9EWZnwy%2Fz6ENAoLgQp21XdIlyHrY3JEIwLg48J2w%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C9ee09de039e5447493e208d619ba7b44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724686077133255&sdata=lOu9EWZnwy%2Fz6ENAoLgQp21XdIlyHrY3JEIwLg48J2w%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C9ee09de039e5447493e208d619ba7b44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724686077133255&sdata=lOu9EWZnwy%2Fz6ENAoLgQp21XdIlyHrY3JEIwLg48J2w%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C9ee09de039e5447493e208d619ba7b44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724686077133255&sdata=lOu9EWZnwy%2Fz6ENAoLgQp21XdIlyHrY3JEIwLg48J2w%3D&reserved=0>>
>>>
>>>
>>> The following commit(s) were added to refs/heads/develop by this push:
>>> new e1ec25e I think this fixes Menu
>>> e1ec25e is described below
>>>
>>> commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
>>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com> <mailto:harbs@in-tools.com <ma...@in-tools.com>>>
>>> AuthorDate: Thu Sep 13 16:14:03 2018 +0300
>>>
>>> I think this fixes Menu
>>> ---
>>> .../projects/Basic/src/main/resources/defaults.css | 1 +
>>> .../controllers/ItemRendererMouseController.as | 1 -
>>> .../controllers/MenuSelectionMouseController.as | 33 ++++++++++++++--------
>>> 3 files changed, 23 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css b/frameworks/projects/Basic/src/main/resources/defaults.css
>>> index f88da20..15cb4e6 100644
>>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>>> @@ -545,6 +545,7 @@ Panel
>>> IBeadModel: ClassReference("org.apache.royale.html.beads.models.PanelModel");
>>> IBeadView: ClassReference("org.apache.royale.html.beads.PanelView");
>>> IPanelLayout: ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
>>> + IPanelContentArea: ClassReference("org.apache.royale.html.Container");
>>>
>>> background-color: #FFFFFF;
>>> border: 1px solid #333333
>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>> index f408a71..6073264 100644
>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>>> @@ -92,7 +92,6 @@ COMPILE::JS {
>>> goog.events.listen(element, goog.events.EventType.MOUSEOUT, this.handleMouseOut);
>>> goog.events.listen(element, goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
>>> goog.events.listen(element, goog.events.EventType.CLICK, this.handleMouseUp);
>>> - goog.events.listen(element, goog.events.EventType.MOUSEUP, this.handleMouseUp);
>>> }
>>> }
>>>
>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>> index 5f986bb..6a09a52 100644
>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>>> @@ -127,6 +127,8 @@ package org.apache.royale.html.beads.controllers
>>> * @playerversion Flash 10.2
>>> * @playerversion AIR 2.6
>>> * @productversion Royale 0.9
>>> + * @royaleignorecoercion org.apache.royale.core.UIBase
>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>> */
>>> protected function hideOpenMenus():void
>>> {
>>> @@ -137,8 +139,9 @@ package org.apache.royale.html.beads.controllers
>>> if (menu.parent != null) {
>>> var controller:MenuSelectionMouseController = menu.getBeadByType(MenuSelectionMouseController) as MenuSelectionMouseController;
>>> controller.removeClickOutHandler(menu);
>>> - var host:IPopUpHost = UIUtils.findPopUpHost(_strand as IUIBase);
>>> - host.popUpParent.removeElement(menu);
>>> + var host:IPopUpHost = UIUtils.findPopUpHost(menu as IUIBase);
>>> + if(host)
>>> + host.popUpParent.removeElement(menu);
>>> }
>>> }
>>> MenuModel.clearMenuList();
>>> @@ -163,6 +166,8 @@ package org.apache.royale.html.beads.controllers
>>> * @playerversion Flash 10.2
>>> * @playerversion AIR 2.6
>>> * @productversion Royale 0.9
>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>> + * @royaleignorecoercion org.apache.royale.events.IEventDispatcher
>>> */
>>> public function removeClickOutHandler(menu:Object):void
>>> {
>>> @@ -191,23 +196,29 @@ package org.apache.royale.html.beads.controllers
>>>
>>> /**
>>> * @royaleignorecoercion HTMLElement
>>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>>> * @private
>>> */
>>> COMPILE::JS
>>> protected function hideMenu_internal(event:BrowserEvent):void
>>> {
>>> var menu:IMenu = _strand as IMenu;
>>> + var menuElem:HTMLElement = (_strand as IUIBase).element as HTMLElement;
>>> + var menuBarElement:HTMLElement;
>>> if (menu.parentMenuBar)
>>> {
>>> - var menuBarElement:HTMLElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>> - var target:HTMLElement = event.target as HTMLElement;
>>> - while (target != null)
>>> - {
>>> - if (target == menuBarElement) return;
>>> - target = target.parentNode as HTMLElement;
>>> - }
>>> - }
>>> - hideOpenMenus();
>>> + menuBarElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>>> + }
>>> + var target:HTMLElement = event.target as HTMLElement;
>>> + while (target != null)
>>> + {
>>> + var comp:IUIBase = target["royale_wrapper"];
>>> + if(comp && (comp is IMenu || comp == menu.parentMenuBar) ) return;
>>> + // if (target == menuElem || (menuBarElement && target == menuBarElement) ) return;
>>> + target = target.parentNode as HTMLElement;
>>> + }
>>> +
>>> + setTimeout(hideOpenMenus);
>>> }
>>> }
>>> }
>>> \ No newline at end of file
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Different controllers will have different behaviors. Menu behavior is in fact one of the reasons I wanted to do beads and have replacable component logic. In your standard List, you "must" mouseDown and mouseUp on the same renderer to generate a Click that changes selection. However, in many menus, you can mouseDown on the MenuBar and without releasing the mouse button, drag down the menu to an item and release (MouseUp) and that item will be selected from the menu. Outlook's menubar on my Mac seems to work this way. So, some people will want mouseUp to change selection, others will want click to change selection. Royale should offer choices.
But changing selection is a higher-level event. The lowest level events are mouseDown/mouseUp/click. In between is the "ITEM_CLICK" event and in theor, ITEM_MOUSEDOWN and ITEM_MOUSEUP. It is up to the controllers to interpret a lower-level event and then dispatch a higher-level event. It seems "illogical" to me that an ITEM_CLICK would be dispatched from a mouseUp handler. ITEM_CLICK (and ITEM_MOUSEUP if there is such a things) is meant to indicate that an event happened on the renderer that should be interpreted by the controller. Some parts of a renderer may not dispatch ITEM_CLICK (for example, in some Trees, clcking on expand/collapse icons don't change selection.
Then the MenuController and ListSelectionController should be interpreting ITEM_CLICK and ITEM_MOUSEUP and deciding what to do. So maybe the answer is that the renderer's mouseUp controller dispatches ITEM_MOUSEUP, and Menu changes selection on ITEM_CLICK or ITEM_MOUSEUP.
Separately, whether setTimeout or requestAnimationFrame, the more deferred work and asynchronicity we put in the framework, the more trouble we will give our users IMO. Starting such a trend has the danger of making application code use more and more callLater/setTimeout/requestAnimationFrame calls as well. We should not defer work unless we have to, and I don't think we have to in this case. Making things rely on timing creates the potential for timing issues.
My 2 cents,
-Alex
On 9/13/18, 1:50 PM, "Harbs" <ha...@gmail.com> wrote:
That article was not what I was referring to. Like I said I couldn’t find it. I’m working from memory.
> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
I don’t understand you. Are you saying that mousing down on one renderer and mousing up on another should fire an itemClick? That seems wrong to me. An itemClick should be both mouse down and mouse up on the same item. Click does that very nicely.
> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers.
I would generally agree with you. But in this case, we’re handling the dismissal of a menu. I don’t see the harm here. If you have another proposal, I’m open to hear…
We can also use requestAnimationFrame() to delay the execution until after click. That will be guaranteed to be before the next draw of the screen, so it might be better than setTimeout() which will probably be later.
Thanks,
Harbs
> On Sep 13, 2018, at 11:20 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I didn't see anywhere in the article where it guaranteed that both up and click are sequential in the queue. Sharing the heap isn't the issue here.
>
> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>
> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers. With many browsers having immediate screen updates (as opposed to Flash's deferred rendering), postponing work with setTimeout can result in unexpected behavior, and can result in callLater "wars" where more and more code has to keep deferring work with setTimeout because some lower layer also used setTimeout. Deferring work should be the option of the application developer as much as possible.
>
> My 2 cents,
> -Alex
>
> On 9/13/18, 11:36 AM, "Harbs" <ha...@gmail.com> wrote:
>
> I once read that the way setTimeout works is that it’s added to the next event loop. That would mean that both mouseup and click would be executed in the current event loop and the setTimout would be delayed to the next one (i..e between 4ms and 10ms later).
>
> I can’t find the article at the moment, but my understanding is that this is a safe way to guarantee later execution in all browsers.
>
> The MDN doc has a decent explanation.[1] Both mouseup and click would be on the same heap.
>
> Harbs
>
> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C9ee09de039e5447493e208d619ba7b44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724686077133255&sdata=P0peR5eRbvHOFN1DgfG7q2Lho4cSbH47z3l4m77Vx6s%3D&reserved=0
>> On Sep 13, 2018, at 6:54 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Is setTimeout guaranteed to run after the CLICK event?
>>
>> On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org>" <harbs@apache.org <ma...@apache.org>> wrote:
>>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> harbs pushed a commit to branch develop
>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C9ee09de039e5447493e208d619ba7b44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724686077133255&sdata=lOu9EWZnwy%2Fz6ENAoLgQp21XdIlyHrY3JEIwLg48J2w%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C9ee09de039e5447493e208d619ba7b44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724686077133255&sdata=lOu9EWZnwy%2Fz6ENAoLgQp21XdIlyHrY3JEIwLg48J2w%3D&reserved=0>
>>
>>
>> The following commit(s) were added to refs/heads/develop by this push:
>> new e1ec25e I think this fixes Menu
>> e1ec25e is described below
>>
>> commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
>> AuthorDate: Thu Sep 13 16:14:03 2018 +0300
>>
>> I think this fixes Menu
>> ---
>> .../projects/Basic/src/main/resources/defaults.css | 1 +
>> .../controllers/ItemRendererMouseController.as | 1 -
>> .../controllers/MenuSelectionMouseController.as | 33 ++++++++++++++--------
>> 3 files changed, 23 insertions(+), 12 deletions(-)
>>
>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css b/frameworks/projects/Basic/src/main/resources/defaults.css
>> index f88da20..15cb4e6 100644
>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>> @@ -545,6 +545,7 @@ Panel
>> IBeadModel: ClassReference("org.apache.royale.html.beads.models.PanelModel");
>> IBeadView: ClassReference("org.apache.royale.html.beads.PanelView");
>> IPanelLayout: ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
>> + IPanelContentArea: ClassReference("org.apache.royale.html.Container");
>>
>> background-color: #FFFFFF;
>> border: 1px solid #333333
>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>> index f408a71..6073264 100644
>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>> @@ -92,7 +92,6 @@ COMPILE::JS {
>> goog.events.listen(element, goog.events.EventType.MOUSEOUT, this.handleMouseOut);
>> goog.events.listen(element, goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
>> goog.events.listen(element, goog.events.EventType.CLICK, this.handleMouseUp);
>> - goog.events.listen(element, goog.events.EventType.MOUSEUP, this.handleMouseUp);
>> }
>> }
>>
>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>> index 5f986bb..6a09a52 100644
>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>> @@ -127,6 +127,8 @@ package org.apache.royale.html.beads.controllers
>> * @playerversion Flash 10.2
>> * @playerversion AIR 2.6
>> * @productversion Royale 0.9
>> + * @royaleignorecoercion org.apache.royale.core.UIBase
>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>> */
>> protected function hideOpenMenus():void
>> {
>> @@ -137,8 +139,9 @@ package org.apache.royale.html.beads.controllers
>> if (menu.parent != null) {
>> var controller:MenuSelectionMouseController = menu.getBeadByType(MenuSelectionMouseController) as MenuSelectionMouseController;
>> controller.removeClickOutHandler(menu);
>> - var host:IPopUpHost = UIUtils.findPopUpHost(_strand as IUIBase);
>> - host.popUpParent.removeElement(menu);
>> + var host:IPopUpHost = UIUtils.findPopUpHost(menu as IUIBase);
>> + if(host)
>> + host.popUpParent.removeElement(menu);
>> }
>> }
>> MenuModel.clearMenuList();
>> @@ -163,6 +166,8 @@ package org.apache.royale.html.beads.controllers
>> * @playerversion Flash 10.2
>> * @playerversion AIR 2.6
>> * @productversion Royale 0.9
>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>> + * @royaleignorecoercion org.apache.royale.events.IEventDispatcher
>> */
>> public function removeClickOutHandler(menu:Object):void
>> {
>> @@ -191,23 +196,29 @@ package org.apache.royale.html.beads.controllers
>>
>> /**
>> * @royaleignorecoercion HTMLElement
>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>> * @private
>> */
>> COMPILE::JS
>> protected function hideMenu_internal(event:BrowserEvent):void
>> {
>> var menu:IMenu = _strand as IMenu;
>> + var menuElem:HTMLElement = (_strand as IUIBase).element as HTMLElement;
>> + var menuBarElement:HTMLElement;
>> if (menu.parentMenuBar)
>> {
>> - var menuBarElement:HTMLElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>> - var target:HTMLElement = event.target as HTMLElement;
>> - while (target != null)
>> - {
>> - if (target == menuBarElement) return;
>> - target = target.parentNode as HTMLElement;
>> - }
>> - }
>> - hideOpenMenus();
>> + menuBarElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>> + }
>> + var target:HTMLElement = event.target as HTMLElement;
>> + while (target != null)
>> + {
>> + var comp:IUIBase = target["royale_wrapper"];
>> + if(comp && (comp is IMenu || comp == menu.parentMenuBar) ) return;
>> + // if (target == menuElem || (menuBarElement && target == menuBarElement) ) return;
>> + target = target.parentNode as HTMLElement;
>> + }
>> +
>> + setTimeout(hideOpenMenus);
>> }
>> }
>> }
>> \ No newline at end of file
>
>
>
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Harbs <ha...@gmail.com>.
And another interesting discussion on Stack Overflow:
https://stackoverflow.com/questions/25915634/difference-between-microtask-and-macrotask-within-an-event-loop-context <https://stackoverflow.com/questions/25915634/difference-between-microtask-and-macrotask-within-an-event-loop-context>
> On Sep 14, 2018, at 12:03 AM, Harbs <ha...@gmail.com> wrote:
>
> HEre’s some docs on how event loops work:
> https://html.spec.whatwg.org/multipage/webappapis.html#event-loop <https://html.spec.whatwg.org/multipage/webappapis.html#event-loop>
>
> https://stackoverflow.com/questions/19743354/does-javascript-event-queue-have-priority <https://stackoverflow.com/questions/19743354/does-javascript-event-queue-have-priority>
>
> Here’s an interesting article with some interesting tests:
> https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/ <https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/>
>
>> On Sep 13, 2018, at 11:49 PM, Harbs <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>
>> That article was not what I was referring to. Like I said I couldn’t find it. I’m working from memory.
>
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Harbs <ha...@gmail.com>.
HEre’s some docs on how event loops work:
https://html.spec.whatwg.org/multipage/webappapis.html#event-loop <https://html.spec.whatwg.org/multipage/webappapis.html#event-loop>
https://stackoverflow.com/questions/19743354/does-javascript-event-queue-have-priority <https://stackoverflow.com/questions/19743354/does-javascript-event-queue-have-priority>
Here’s an interesting article with some interesting tests:
https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/ <https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/>
> On Sep 13, 2018, at 11:49 PM, Harbs <ha...@gmail.com> wrote:
>
> That article was not what I was referring to. Like I said I couldn’t find it. I’m working from memory.
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Harbs <ha...@gmail.com>.
That article was not what I was referring to. Like I said I couldn’t find it. I’m working from memory.
> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
I don’t understand you. Are you saying that mousing down on one renderer and mousing up on another should fire an itemClick? That seems wrong to me. An itemClick should be both mouse down and mouse up on the same item. Click does that very nicely.
> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers.
I would generally agree with you. But in this case, we’re handling the dismissal of a menu. I don’t see the harm here. If you have another proposal, I’m open to hear…
We can also use requestAnimationFrame() to delay the execution until after click. That will be guaranteed to be before the next draw of the screen, so it might be better than setTimeout() which will probably be later.
Thanks,
Harbs
> On Sep 13, 2018, at 11:20 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I didn't see anywhere in the article where it guaranteed that both up and click are sequential in the queue. Sharing the heap isn't the issue here.
>
> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
>
> Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers. With many browsers having immediate screen updates (as opposed to Flash's deferred rendering), postponing work with setTimeout can result in unexpected behavior, and can result in callLater "wars" where more and more code has to keep deferring work with setTimeout because some lower layer also used setTimeout. Deferring work should be the option of the application developer as much as possible.
>
> My 2 cents,
> -Alex
>
> On 9/13/18, 11:36 AM, "Harbs" <ha...@gmail.com> wrote:
>
> I once read that the way setTimeout works is that it’s added to the next event loop. That would mean that both mouseup and click would be executed in the current event loop and the setTimout would be delayed to the next one (i..e between 4ms and 10ms later).
>
> I can’t find the article at the moment, but my understanding is that this is a safe way to guarantee later execution in all browsers.
>
> The MDN doc has a decent explanation.[1] Both mouseup and click would be on the same heap.
>
> Harbs
>
> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C576c9eb8f72f4456b8de08d619a7e21e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724606177243994&sdata=k2OOBE6%2BB6q53vlxPSHkm6ZUfqKhGlEmhS54Xj%2FWNDU%3D&reserved=0
>> On Sep 13, 2018, at 6:54 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Is setTimeout guaranteed to run after the CLICK event?
>>
>> On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org>" <harbs@apache.org <ma...@apache.org>> wrote:
>>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> harbs pushed a commit to branch develop
>> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C576c9eb8f72f4456b8de08d619a7e21e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724606177243994&sdata=tl2ADaUxtE4RW1eYucJAULvVhoibVGWfCqzfXidCF6E%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C576c9eb8f72f4456b8de08d619a7e21e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724606177243994&sdata=tl2ADaUxtE4RW1eYucJAULvVhoibVGWfCqzfXidCF6E%3D&reserved=0>
>>
>>
>> The following commit(s) were added to refs/heads/develop by this push:
>> new e1ec25e I think this fixes Menu
>> e1ec25e is described below
>>
>> commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
>> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
>> AuthorDate: Thu Sep 13 16:14:03 2018 +0300
>>
>> I think this fixes Menu
>> ---
>> .../projects/Basic/src/main/resources/defaults.css | 1 +
>> .../controllers/ItemRendererMouseController.as | 1 -
>> .../controllers/MenuSelectionMouseController.as | 33 ++++++++++++++--------
>> 3 files changed, 23 insertions(+), 12 deletions(-)
>>
>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css b/frameworks/projects/Basic/src/main/resources/defaults.css
>> index f88da20..15cb4e6 100644
>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>> @@ -545,6 +545,7 @@ Panel
>> IBeadModel: ClassReference("org.apache.royale.html.beads.models.PanelModel");
>> IBeadView: ClassReference("org.apache.royale.html.beads.PanelView");
>> IPanelLayout: ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
>> + IPanelContentArea: ClassReference("org.apache.royale.html.Container");
>>
>> background-color: #FFFFFF;
>> border: 1px solid #333333
>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>> index f408a71..6073264 100644
>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
>> @@ -92,7 +92,6 @@ COMPILE::JS {
>> goog.events.listen(element, goog.events.EventType.MOUSEOUT, this.handleMouseOut);
>> goog.events.listen(element, goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
>> goog.events.listen(element, goog.events.EventType.CLICK, this.handleMouseUp);
>> - goog.events.listen(element, goog.events.EventType.MOUSEUP, this.handleMouseUp);
>> }
>> }
>>
>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>> index 5f986bb..6a09a52 100644
>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
>> @@ -127,6 +127,8 @@ package org.apache.royale.html.beads.controllers
>> * @playerversion Flash 10.2
>> * @playerversion AIR 2.6
>> * @productversion Royale 0.9
>> + * @royaleignorecoercion org.apache.royale.core.UIBase
>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>> */
>> protected function hideOpenMenus():void
>> {
>> @@ -137,8 +139,9 @@ package org.apache.royale.html.beads.controllers
>> if (menu.parent != null) {
>> var controller:MenuSelectionMouseController = menu.getBeadByType(MenuSelectionMouseController) as MenuSelectionMouseController;
>> controller.removeClickOutHandler(menu);
>> - var host:IPopUpHost = UIUtils.findPopUpHost(_strand as IUIBase);
>> - host.popUpParent.removeElement(menu);
>> + var host:IPopUpHost = UIUtils.findPopUpHost(menu as IUIBase);
>> + if(host)
>> + host.popUpParent.removeElement(menu);
>> }
>> }
>> MenuModel.clearMenuList();
>> @@ -163,6 +166,8 @@ package org.apache.royale.html.beads.controllers
>> * @playerversion Flash 10.2
>> * @playerversion AIR 2.6
>> * @productversion Royale 0.9
>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>> + * @royaleignorecoercion org.apache.royale.events.IEventDispatcher
>> */
>> public function removeClickOutHandler(menu:Object):void
>> {
>> @@ -191,23 +196,29 @@ package org.apache.royale.html.beads.controllers
>>
>> /**
>> * @royaleignorecoercion HTMLElement
>> + * @royaleignorecoercion org.apache.royale.core.IUIBase
>> * @private
>> */
>> COMPILE::JS
>> protected function hideMenu_internal(event:BrowserEvent):void
>> {
>> var menu:IMenu = _strand as IMenu;
>> + var menuElem:HTMLElement = (_strand as IUIBase).element as HTMLElement;
>> + var menuBarElement:HTMLElement;
>> if (menu.parentMenuBar)
>> {
>> - var menuBarElement:HTMLElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>> - var target:HTMLElement = event.target as HTMLElement;
>> - while (target != null)
>> - {
>> - if (target == menuBarElement) return;
>> - target = target.parentNode as HTMLElement;
>> - }
>> - }
>> - hideOpenMenus();
>> + menuBarElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
>> + }
>> + var target:HTMLElement = event.target as HTMLElement;
>> + while (target != null)
>> + {
>> + var comp:IUIBase = target["royale_wrapper"];
>> + if(comp && (comp is IMenu || comp == menu.parentMenuBar) ) return;
>> + // if (target == menuElem || (menuBarElement && target == menuBarElement) ) return;
>> + target = target.parentNode as HTMLElement;
>> + }
>> +
>> + setTimeout(hideOpenMenus);
>> }
>> }
>> }
>> \ No newline at end of file
>
>
>
Re: Royale Transitions, Effects, States infrastructure [was: Re:
[royale-asjs] branch develop updated: I think this fixes Menu]
Posted by Kenny Lerma <ke...@kennylerma.com>.
I totally agree and I can wrap up a SWC of Tweener for sure as I'm using it
already, but will need to ensure it's compatibility with Royale.
On Fri, Sep 14, 2018 at 11:38 AM Alex Harui <ah...@adobe.com.invalid>
wrote:
> IMO, we want people to be able to choose Greensock, Tweener, or anything
> they want.
>
> Really, Royale is in the business of making it easier/more efficient/more
> productive to integrate pieces of Javascript into an application. We are
> writing our own framework so we know that the baseline is in terms of size
> and performance. But people are way more likely to use heavier but richer
> libraries if they don't need to save bytes or cpu cycles.
>
> So, if you know folks involved with Tweener and can convince them to wrap
> up their code in a Royale SWC, or want to do it yourself, that's great.
> The more choices, the better Royale is.
>
> My 2 cents,
> -Alex
>
> On 9/14/18, 9:30 AM, "Kenny Lerma" <ke...@kennylerma.com> wrote:
>
> Have you considered using Tweener? I'm incorporating this into
> SpriteFlexjs
> and It's what I've always used at other companies for years since it's
> free
> and open-source.
>
> I realize greensock has a javascript version already and is a great
> library. However, unless they have changed their license, you need to
> buy
> a license to you use it for commercial projects.
>
> It's for that reason that companies in the past switched to Tweener.
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhosted.zeh.com.br%2Ftweener%2Fdocs%2Fen-us%2F&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=%2F3S3iqsK4gBNgWoJx9cxpu0w95iDTY1JR7T%2FAREQOAA%3D&reserved=0
>
>
>
>
> On Fri, Sep 14, 2018 at 11:23 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Greensock was quite popular among Flex developers. Does anyone on
> this
> > list have contacts at Greensock? We might want to see if they will
> create
> > a Royale SWC for their code.
> >
> > Regarding class selectors and states, I guess I don't understand the
> > issue. The code behind Royale (and Flex) states should be capturing
> values
> > of properties changed by the state before they get changed, then
> restoring
> > those properties. IOW, if you were to have
> >
> > <js:states>
> > <js:state name="normal" />
> > <js:state name="important" />
> > <js:states>
> > <j:Button id="myButton" emphasis.normal="primary"
> > emphasis.important="emphasized" />
> >
> > Then the myButton.emphasis="primary" at startup and when the state
> > changes to "important" the States impl should read myButton.emphasis
> and
> > store that value away before setting
> myButton.emphasis="emphasized". Then,
> > when the state changes back to "normal", the States impl should set
> > myButton.emphasis="primary" again.
> >
> > In the implementation for the emphasis property, if it involves
> changing
> > classLists, the implementation must do so in a way that handles
> having the
> > emphasis property changes at runtime. The States impl isn't really
> doing
> > anything application developer code might do, so the implementation
> must
> > support properties being set and re-set.
> >
> > My 2 cents,
> > -Alex
> >
> > On 9/14/18, 4:07 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > Hi Harbs,
> >
> > for me is ok, but I'm more worried about how to accommodate this
> and
> > the
> > underlying architecture. The events systems that Alex propose,
> > About implementation, I'm sure can do something on the lines of
> GASP,
> > but
> > as you say, we should be able to plug other options as we do with
> > layouts
> > currently.
> >
> > But first of all, for me, we should solve the problem with
> > addition/removal
> > of class selectors in the core of UIBase. I at least don't know
> other
> > way
> > to deal with it without the need of adding lots of unnecessary
> code
> > like I
> > had to do in Jewel for something that is so "core" to us.
> >
> > Thanks
> >
> >
> >
> > El vie., 14 sept. 2018 a las 11:34, Harbs (<
> harbs.lists@gmail.com>)
> > escribió:
> >
> > > Well, my point of view on animation would be that GSAP is the
> > industry
> > > standard.[1]
> > >
> > > Making GSAP a dependency is a no-go because the license is not
> > compatible,
> > > but I’d say that the approach should be similar (although I
> don’t
> > expect
> > > we’d get nearly to the level of complete-ness / robustness
> that GSAP
> > has).
> > > Extra points would be to allow GSAP to be easily substituted
> for the
> > > default implementation.
> > >
> > > I’m not sure about states.
> > >
> > > My $0.02,
> > > Harbs
> > >
> > > [1]
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreensock.com%2Fgsap&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=QTIFnkaLVawza7nlHXmShHctuRW6f5Kif9NmEdq55YE%3D&reserved=0
> > <
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreensock.com%2Fgsap&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=QTIFnkaLVawza7nlHXmShHctuRW6f5Kif9NmEdq55YE%3D&reserved=0
> > >
> > >
> > > > On Sep 14, 2018, at 10:36 AM, Carlos Rovira <
> > carlosrovira@apache.org>
> > > wrote:
> > > >
> > > > Hi Alex,
> > > >
> > > > renaming this to other thread since I think this deserves its
> > space to
> > > > planning.
> > > >
> > > > Right now, in Jewel, we try to get most of "eye candy" things
> > through CSS
> > > > class selectors. This means that we defer this to the CSS
> > "engine". The
> > > > same happens with Jewel layouts, that are based on add the
> proper
> > class
> > > > selectors.
> > > >
> > > > This for now is working, but I think is not the Royale way,
> since
> > I see
> > > > some drawbacks:
> > > >
> > > > - you don't have control in Royale of the things deferred to
> CSS.
> > > > - targets like SWF, or future targets, could be left since
> this
> > strategy
> > > is
> > > > platform dependent
> > > >
> > > > And some issues:
> > > >
> > > > - States subsystems is not playing nicely with class
> selectors. It
> > can't
> > > > recreate the class selectors the component has before the
> state
> > change
> > > > - As I stated in other thread recently, although we
> introduced a
> > way to
> > > > deal with classList, since is not part of UIBase, we can see
> it's
> > not
> > > > playing nicely with the rest of Royale and it's causing to
> > introduce more
> > > > code in lost of classes (checking for ClassSelectorList in
> Jewel
> > and
> > > Basic
> > > > Code will discover all places where I had to inject the same
> code,
> > what
> > > > seems not optimal.
> > > >
> > > > So, I think we should refactor now (post release) how we
> deal with
> > class
> > > > names (before the ball gets bigger), and think a way to play
> with
> > > > transitions and effects in a more Royale way. I think first
> is very
> > > needed,
> > > > and second can wait a bit more...
> > > >
> > > > For example for HTML, I envision using
> StatesWithTransitionImpl to
> > deal
> > > > with class selectors that will play, in HTML, transitions, so
> > > effectStart,
> > > > transitionStart, or effectEnd, or transitionEnd, could make
> an
> > > "addClass",
> > > > "removeClass" or "toggleClass" and the those class selectors
> will
> > define
> > > > the platform (in this case CSS) way to deal with the effect,
> and
> > avoid
> > > hard
> > > > coding that in AS3 code.
> > > >
> > > > Another side problem here is that we need to include
> @keyframe in
> > > compiler
> > > > since Royale, as today, don't know how to deal with this.
> > > >
> > > > Thoughts?
> > > >
> > > >
> > > >
> > > > El vie., 14 sept. 2018 a las 8:45, Alex Harui
> > (<aharui@adobe.com.invalid
> > > >)
> > > > escribió:
> > > >
> > > >> Hi Carlos,
> > > >>
> > > >> We have not devoted much time and energy to an effects
> subsystem,
> > so
> > > maybe
> > > >> you will be the pioneer in this area.
> > > >>
> > > >> In my mind, there will be at least two kinds of effects
> subsystem:
> > > >> planned and unplanned.
> > > >>
> > > >> In a planned effects subsystem, the assumption is that most
> users
> > will
> > > >> want to implement an effect/transition. The
> > StatesWithTransitionsImpl
> > > is
> > > >> an early example of that. Such a subsystem should have a
> > "lifecycle".
> > > A
> > > >> known set of events should be dispatched that provide useful
> > > opportunities
> > > >> to change the effects start and end conditions. For state
> > changes, the
> > > >> events should be something like transitionStart,
> transitionEnd,
> > > >> stateChanged. For your cases, the events might be
> something like
> > > >> effectStart, effectEnd, open/close. If you get the right
> set of
> > events,
> > > >> then the work you want to defer should happen on an
> lifecycle
> > event
> > > instead
> > > >> of a timer event.
> > > >>
> > > >> In an unplanned effects subsystem, the event system is more
> > > >> sophisticated. The assumption is that it will be rare to
> have an
> > > effect in
> > > >> response to some change in the component. So hide/show
> effects,
> > > selection
> > > >> and focus effects and things like that would be
> "unplanned". I
> > hope we
> > > >> can find a way to do this in a PAYG way with
> different/heavier
> > beads,
> > > but
> > > >> that is a bit tricky for hide/show since it is built into
> > UIBase. In an
> > > >> unplanned system, there will either be cancelable "ing"
> events or
> > the
> > > >> target classes have to be able to reverse a property change
> > without
> > > >> flicker.
> > > >>
> > > >> For example, right now if you set the UIBase visible
> property to
> > false,
> > > >> the component becomes invisible immediately. And similarly
> if
> > you set
> > > >> visible=true, the component becomes visible immediately.
> Adding
> > > unplanned
> > > >> effect support to visible would require dispatching a
> cancelable
> > > >> visibleChanging event before actually setting the browser's
> CSS
> > display
> > > >> property that an effect instance would listen for and
> cancel,
> > then wait
> > > for
> > > >> the effectEnd event and then finally actually set the
> visible
> > > property. Or
> > > >> we'd have to be confident that you can set the CSS display
> > property and
> > > set
> > > >> it back without flicker.
> > > >>
> > > >> In summary, having the right events should eliminate the
> need for
> > timing
> > > >> events.
> > > >>
> > > >> My 2 cents,
> > > >> -Alex
> > > >>
> > > >>
> > > >> On 9/13/18, 2:34 PM, "Carlos Rovira" <
> carlosrovira@apache.org>
> > wrote:
> > > >>
> > > >> Hi Alex,
> > > >> I'm with you. Don't like setTimeOut. But I needed in
> Jewel in
> > at
> > > least
> > > >> 3
> > > >> scenearios. I'd love to change it sometime in the
> future, but
> > for now
> > > >> don't
> > > >> know how.
> > > >> I think the actual ways to defer something are:
> > > >> -setTimeOut
> > > >> -setInterval
> > > >> -requestAnimationFrame
> > > >>
> > > >> the first one is in SWF, so the solution is cross SWF/JS,
> > although if
> > > >> we
> > > >> add other targets, maybe will require changes.
> > > >> the second seems to be the worse.
> > > >> the latest seems the actual way to do things in JS, but I
> > tried and
> > > >> didn't
> > > >> work for me, and I suppose we'll need to abstract it to
> > something
> > > >> usable in
> > > >> SWF and future targets.
> > > >>
> > > >> My concrete case in the three ocassions is when I
> instantiate a
> > > >> component
> > > >> and add a class name to make the component animate
> > (transition)
> > > >> through
> > > >> CSS. For example Alert, DateField and ComboBox popups
> > components and
> > > >> then
> > > >> add a class ".open" in CSS, so we need at least
> 300-400ms so
> > the
> > > >> transition
> > > >> can play.
> > > >>
> > > >> Any other way to do it would be good to know in order to
> > upgrade this
> > > >> implementations.
> > > >>
> > > >> Thanks
> > > >>
> > > >> Carlos
> > > >>
> > > >> --
> > > >> Carlos Rovira
> > > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=CKs33Ct8MEVeGy6s6Ce3Gywbylnsj1qdRn4jS%2F7G8cA%3D&reserved=0
> > > >>
> > > >>
> > > >>
> > > >>
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=CKs33Ct8MEVeGy6s6Ce3Gywbylnsj1qdRn4jS%2F7G8cA%3D&reserved=0
> >
> >
> >
>
>
>
Re: Royale Transitions, Effects, States infrastructure [was: Re:
[royale-asjs] branch develop updated: I think this fixes Menu]
Posted by Alex Harui <ah...@adobe.com.INVALID>.
IMO, we want people to be able to choose Greensock, Tweener, or anything they want.
Really, Royale is in the business of making it easier/more efficient/more productive to integrate pieces of Javascript into an application. We are writing our own framework so we know that the baseline is in terms of size and performance. But people are way more likely to use heavier but richer libraries if they don't need to save bytes or cpu cycles.
So, if you know folks involved with Tweener and can convince them to wrap up their code in a Royale SWC, or want to do it yourself, that's great. The more choices, the better Royale is.
My 2 cents,
-Alex
On 9/14/18, 9:30 AM, "Kenny Lerma" <ke...@kennylerma.com> wrote:
Have you considered using Tweener? I'm incorporating this into SpriteFlexjs
and It's what I've always used at other companies for years since it's free
and open-source.
I realize greensock has a javascript version already and is a great
library. However, unless they have changed their license, you need to buy
a license to you use it for commercial projects.
It's for that reason that companies in the past switched to Tweener.
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhosted.zeh.com.br%2Ftweener%2Fdocs%2Fen-us%2F&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=%2F3S3iqsK4gBNgWoJx9cxpu0w95iDTY1JR7T%2FAREQOAA%3D&reserved=0
On Fri, Sep 14, 2018 at 11:23 AM Alex Harui <ah...@adobe.com.invalid>
wrote:
> Greensock was quite popular among Flex developers. Does anyone on this
> list have contacts at Greensock? We might want to see if they will create
> a Royale SWC for their code.
>
> Regarding class selectors and states, I guess I don't understand the
> issue. The code behind Royale (and Flex) states should be capturing values
> of properties changed by the state before they get changed, then restoring
> those properties. IOW, if you were to have
>
> <js:states>
> <js:state name="normal" />
> <js:state name="important" />
> <js:states>
> <j:Button id="myButton" emphasis.normal="primary"
> emphasis.important="emphasized" />
>
> Then the myButton.emphasis="primary" at startup and when the state
> changes to "important" the States impl should read myButton.emphasis and
> store that value away before setting myButton.emphasis="emphasized". Then,
> when the state changes back to "normal", the States impl should set
> myButton.emphasis="primary" again.
>
> In the implementation for the emphasis property, if it involves changing
> classLists, the implementation must do so in a way that handles having the
> emphasis property changes at runtime. The States impl isn't really doing
> anything application developer code might do, so the implementation must
> support properties being set and re-set.
>
> My 2 cents,
> -Alex
>
> On 9/14/18, 4:07 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Harbs,
>
> for me is ok, but I'm more worried about how to accommodate this and
> the
> underlying architecture. The events systems that Alex propose,
> About implementation, I'm sure can do something on the lines of GASP,
> but
> as you say, we should be able to plug other options as we do with
> layouts
> currently.
>
> But first of all, for me, we should solve the problem with
> addition/removal
> of class selectors in the core of UIBase. I at least don't know other
> way
> to deal with it without the need of adding lots of unnecessary code
> like I
> had to do in Jewel for something that is so "core" to us.
>
> Thanks
>
>
>
> El vie., 14 sept. 2018 a las 11:34, Harbs (<ha...@gmail.com>)
> escribió:
>
> > Well, my point of view on animation would be that GSAP is the
> industry
> > standard.[1]
> >
> > Making GSAP a dependency is a no-go because the license is not
> compatible,
> > but I’d say that the approach should be similar (although I don’t
> expect
> > we’d get nearly to the level of complete-ness / robustness that GSAP
> has).
> > Extra points would be to allow GSAP to be easily substituted for the
> > default implementation.
> >
> > I’m not sure about states.
> >
> > My $0.02,
> > Harbs
> >
> > [1]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreensock.com%2Fgsap&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=QTIFnkaLVawza7nlHXmShHctuRW6f5Kif9NmEdq55YE%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreensock.com%2Fgsap&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=QTIFnkaLVawza7nlHXmShHctuRW6f5Kif9NmEdq55YE%3D&reserved=0
> >
> >
> > > On Sep 14, 2018, at 10:36 AM, Carlos Rovira <
> carlosrovira@apache.org>
> > wrote:
> > >
> > > Hi Alex,
> > >
> > > renaming this to other thread since I think this deserves its
> space to
> > > planning.
> > >
> > > Right now, in Jewel, we try to get most of "eye candy" things
> through CSS
> > > class selectors. This means that we defer this to the CSS
> "engine". The
> > > same happens with Jewel layouts, that are based on add the proper
> class
> > > selectors.
> > >
> > > This for now is working, but I think is not the Royale way, since
> I see
> > > some drawbacks:
> > >
> > > - you don't have control in Royale of the things deferred to CSS.
> > > - targets like SWF, or future targets, could be left since this
> strategy
> > is
> > > platform dependent
> > >
> > > And some issues:
> > >
> > > - States subsystems is not playing nicely with class selectors. It
> can't
> > > recreate the class selectors the component has before the state
> change
> > > - As I stated in other thread recently, although we introduced a
> way to
> > > deal with classList, since is not part of UIBase, we can see it's
> not
> > > playing nicely with the rest of Royale and it's causing to
> introduce more
> > > code in lost of classes (checking for ClassSelectorList in Jewel
> and
> > Basic
> > > Code will discover all places where I had to inject the same code,
> what
> > > seems not optimal.
> > >
> > > So, I think we should refactor now (post release) how we deal with
> class
> > > names (before the ball gets bigger), and think a way to play with
> > > transitions and effects in a more Royale way. I think first is very
> > needed,
> > > and second can wait a bit more...
> > >
> > > For example for HTML, I envision using StatesWithTransitionImpl to
> deal
> > > with class selectors that will play, in HTML, transitions, so
> > effectStart,
> > > transitionStart, or effectEnd, or transitionEnd, could make an
> > "addClass",
> > > "removeClass" or "toggleClass" and the those class selectors will
> define
> > > the platform (in this case CSS) way to deal with the effect, and
> avoid
> > hard
> > > coding that in AS3 code.
> > >
> > > Another side problem here is that we need to include @keyframe in
> > compiler
> > > since Royale, as today, don't know how to deal with this.
> > >
> > > Thoughts?
> > >
> > >
> > >
> > > El vie., 14 sept. 2018 a las 8:45, Alex Harui
> (<aharui@adobe.com.invalid
> > >)
> > > escribió:
> > >
> > >> Hi Carlos,
> > >>
> > >> We have not devoted much time and energy to an effects subsystem,
> so
> > maybe
> > >> you will be the pioneer in this area.
> > >>
> > >> In my mind, there will be at least two kinds of effects subsystem:
> > >> planned and unplanned.
> > >>
> > >> In a planned effects subsystem, the assumption is that most users
> will
> > >> want to implement an effect/transition. The
> StatesWithTransitionsImpl
> > is
> > >> an early example of that. Such a subsystem should have a
> "lifecycle".
> > A
> > >> known set of events should be dispatched that provide useful
> > opportunities
> > >> to change the effects start and end conditions. For state
> changes, the
> > >> events should be something like transitionStart, transitionEnd,
> > >> stateChanged. For your cases, the events might be something like
> > >> effectStart, effectEnd, open/close. If you get the right set of
> events,
> > >> then the work you want to defer should happen on an lifecycle
> event
> > instead
> > >> of a timer event.
> > >>
> > >> In an unplanned effects subsystem, the event system is more
> > >> sophisticated. The assumption is that it will be rare to have an
> > effect in
> > >> response to some change in the component. So hide/show effects,
> > selection
> > >> and focus effects and things like that would be "unplanned". I
> hope we
> > >> can find a way to do this in a PAYG way with different/heavier
> beads,
> > but
> > >> that is a bit tricky for hide/show since it is built into
> UIBase. In an
> > >> unplanned system, there will either be cancelable "ing" events or
> the
> > >> target classes have to be able to reverse a property change
> without
> > >> flicker.
> > >>
> > >> For example, right now if you set the UIBase visible property to
> false,
> > >> the component becomes invisible immediately. And similarly if
> you set
> > >> visible=true, the component becomes visible immediately. Adding
> > unplanned
> > >> effect support to visible would require dispatching a cancelable
> > >> visibleChanging event before actually setting the browser's CSS
> display
> > >> property that an effect instance would listen for and cancel,
> then wait
> > for
> > >> the effectEnd event and then finally actually set the visible
> > property. Or
> > >> we'd have to be confident that you can set the CSS display
> property and
> > set
> > >> it back without flicker.
> > >>
> > >> In summary, having the right events should eliminate the need for
> timing
> > >> events.
> > >>
> > >> My 2 cents,
> > >> -Alex
> > >>
> > >>
> > >> On 9/13/18, 2:34 PM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> > >>
> > >> Hi Alex,
> > >> I'm with you. Don't like setTimeOut. But I needed in Jewel in
> at
> > least
> > >> 3
> > >> scenearios. I'd love to change it sometime in the future, but
> for now
> > >> don't
> > >> know how.
> > >> I think the actual ways to defer something are:
> > >> -setTimeOut
> > >> -setInterval
> > >> -requestAnimationFrame
> > >>
> > >> the first one is in SWF, so the solution is cross SWF/JS,
> although if
> > >> we
> > >> add other targets, maybe will require changes.
> > >> the second seems to be the worse.
> > >> the latest seems the actual way to do things in JS, but I
> tried and
> > >> didn't
> > >> work for me, and I suppose we'll need to abstract it to
> something
> > >> usable in
> > >> SWF and future targets.
> > >>
> > >> My concrete case in the three ocassions is when I instantiate a
> > >> component
> > >> and add a class name to make the component animate
> (transition)
> > >> through
> > >> CSS. For example Alert, DateField and ComboBox popups
> components and
> > >> then
> > >> add a class ".open" in CSS, so we need at least 300-400ms so
> the
> > >> transition
> > >> can play.
> > >>
> > >> Any other way to do it would be good to know in order to
> upgrade this
> > >> implementations.
> > >>
> > >> Thanks
> > >>
> > >> Carlos
> > >>
> > >> --
> > >> Carlos Rovira
> > >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=CKs33Ct8MEVeGy6s6Ce3Gywbylnsj1qdRn4jS%2F7G8cA%3D&reserved=0
> > >>
> > >>
> > >>
> > >>
> >
> >
>
> --
> Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C51f1adf3ae5949f79d9d08d61a5f6f8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725394529887502&sdata=CKs33Ct8MEVeGy6s6Ce3Gywbylnsj1qdRn4jS%2F7G8cA%3D&reserved=0
>
>
>
Re: Royale Transitions, Effects, States infrastructure [was: Re:
[royale-asjs] branch develop updated: I think this fixes Menu]
Posted by Kenny Lerma <ke...@kennylerma.com>.
Have you considered using Tweener? I'm incorporating this into SpriteFlexjs
and It's what I've always used at other companies for years since it's free
and open-source.
I realize greensock has a javascript version already and is a great
library. However, unless they have changed their license, you need to buy
a license to you use it for commercial projects.
It's for that reason that companies in the past switched to Tweener.
http://hosted.zeh.com.br/tweener/docs/en-us/
On Fri, Sep 14, 2018 at 11:23 AM Alex Harui <ah...@adobe.com.invalid>
wrote:
> Greensock was quite popular among Flex developers. Does anyone on this
> list have contacts at Greensock? We might want to see if they will create
> a Royale SWC for their code.
>
> Regarding class selectors and states, I guess I don't understand the
> issue. The code behind Royale (and Flex) states should be capturing values
> of properties changed by the state before they get changed, then restoring
> those properties. IOW, if you were to have
>
> <js:states>
> <js:state name="normal" />
> <js:state name="important" />
> <js:states>
> <j:Button id="myButton" emphasis.normal="primary"
> emphasis.important="emphasized" />
>
> Then the myButton.emphasis="primary" at startup and when the state
> changes to "important" the States impl should read myButton.emphasis and
> store that value away before setting myButton.emphasis="emphasized". Then,
> when the state changes back to "normal", the States impl should set
> myButton.emphasis="primary" again.
>
> In the implementation for the emphasis property, if it involves changing
> classLists, the implementation must do so in a way that handles having the
> emphasis property changes at runtime. The States impl isn't really doing
> anything application developer code might do, so the implementation must
> support properties being set and re-set.
>
> My 2 cents,
> -Alex
>
> On 9/14/18, 4:07 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Harbs,
>
> for me is ok, but I'm more worried about how to accommodate this and
> the
> underlying architecture. The events systems that Alex propose,
> About implementation, I'm sure can do something on the lines of GASP,
> but
> as you say, we should be able to plug other options as we do with
> layouts
> currently.
>
> But first of all, for me, we should solve the problem with
> addition/removal
> of class selectors in the core of UIBase. I at least don't know other
> way
> to deal with it without the need of adding lots of unnecessary code
> like I
> had to do in Jewel for something that is so "core" to us.
>
> Thanks
>
>
>
> El vie., 14 sept. 2018 a las 11:34, Harbs (<ha...@gmail.com>)
> escribió:
>
> > Well, my point of view on animation would be that GSAP is the
> industry
> > standard.[1]
> >
> > Making GSAP a dependency is a no-go because the license is not
> compatible,
> > but I’d say that the approach should be similar (although I don’t
> expect
> > we’d get nearly to the level of complete-ness / robustness that GSAP
> has).
> > Extra points would be to allow GSAP to be easily substituted for the
> > default implementation.
> >
> > I’m not sure about states.
> >
> > My $0.02,
> > Harbs
> >
> > [1]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreensock.com%2Fgsap&data=02%7C01%7Caharui%40adobe.com%7C79138145b5db4f85575d08d61a325020%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725200735947429&sdata=mCQxXT6%2FzwI35gAhDoBbfPWkEUSwUGBUvFyZwME3i94%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreensock.com%2Fgsap&data=02%7C01%7Caharui%40adobe.com%7C79138145b5db4f85575d08d61a325020%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725200735957438&sdata=7kGIZpj4g6bFkWXKyz%2BDwDG0x4VGhFQbEeDgeQnPWPI%3D&reserved=0
> >
> >
> > > On Sep 14, 2018, at 10:36 AM, Carlos Rovira <
> carlosrovira@apache.org>
> > wrote:
> > >
> > > Hi Alex,
> > >
> > > renaming this to other thread since I think this deserves its
> space to
> > > planning.
> > >
> > > Right now, in Jewel, we try to get most of "eye candy" things
> through CSS
> > > class selectors. This means that we defer this to the CSS
> "engine". The
> > > same happens with Jewel layouts, that are based on add the proper
> class
> > > selectors.
> > >
> > > This for now is working, but I think is not the Royale way, since
> I see
> > > some drawbacks:
> > >
> > > - you don't have control in Royale of the things deferred to CSS.
> > > - targets like SWF, or future targets, could be left since this
> strategy
> > is
> > > platform dependent
> > >
> > > And some issues:
> > >
> > > - States subsystems is not playing nicely with class selectors. It
> can't
> > > recreate the class selectors the component has before the state
> change
> > > - As I stated in other thread recently, although we introduced a
> way to
> > > deal with classList, since is not part of UIBase, we can see it's
> not
> > > playing nicely with the rest of Royale and it's causing to
> introduce more
> > > code in lost of classes (checking for ClassSelectorList in Jewel
> and
> > Basic
> > > Code will discover all places where I had to inject the same code,
> what
> > > seems not optimal.
> > >
> > > So, I think we should refactor now (post release) how we deal with
> class
> > > names (before the ball gets bigger), and think a way to play with
> > > transitions and effects in a more Royale way. I think first is very
> > needed,
> > > and second can wait a bit more...
> > >
> > > For example for HTML, I envision using StatesWithTransitionImpl to
> deal
> > > with class selectors that will play, in HTML, transitions, so
> > effectStart,
> > > transitionStart, or effectEnd, or transitionEnd, could make an
> > "addClass",
> > > "removeClass" or "toggleClass" and the those class selectors will
> define
> > > the platform (in this case CSS) way to deal with the effect, and
> avoid
> > hard
> > > coding that in AS3 code.
> > >
> > > Another side problem here is that we need to include @keyframe in
> > compiler
> > > since Royale, as today, don't know how to deal with this.
> > >
> > > Thoughts?
> > >
> > >
> > >
> > > El vie., 14 sept. 2018 a las 8:45, Alex Harui
> (<aharui@adobe.com.invalid
> > >)
> > > escribió:
> > >
> > >> Hi Carlos,
> > >>
> > >> We have not devoted much time and energy to an effects subsystem,
> so
> > maybe
> > >> you will be the pioneer in this area.
> > >>
> > >> In my mind, there will be at least two kinds of effects subsystem:
> > >> planned and unplanned.
> > >>
> > >> In a planned effects subsystem, the assumption is that most users
> will
> > >> want to implement an effect/transition. The
> StatesWithTransitionsImpl
> > is
> > >> an early example of that. Such a subsystem should have a
> "lifecycle".
> > A
> > >> known set of events should be dispatched that provide useful
> > opportunities
> > >> to change the effects start and end conditions. For state
> changes, the
> > >> events should be something like transitionStart, transitionEnd,
> > >> stateChanged. For your cases, the events might be something like
> > >> effectStart, effectEnd, open/close. If you get the right set of
> events,
> > >> then the work you want to defer should happen on an lifecycle
> event
> > instead
> > >> of a timer event.
> > >>
> > >> In an unplanned effects subsystem, the event system is more
> > >> sophisticated. The assumption is that it will be rare to have an
> > effect in
> > >> response to some change in the component. So hide/show effects,
> > selection
> > >> and focus effects and things like that would be "unplanned". I
> hope we
> > >> can find a way to do this in a PAYG way with different/heavier
> beads,
> > but
> > >> that is a bit tricky for hide/show since it is built into
> UIBase. In an
> > >> unplanned system, there will either be cancelable "ing" events or
> the
> > >> target classes have to be able to reverse a property change
> without
> > >> flicker.
> > >>
> > >> For example, right now if you set the UIBase visible property to
> false,
> > >> the component becomes invisible immediately. And similarly if
> you set
> > >> visible=true, the component becomes visible immediately. Adding
> > unplanned
> > >> effect support to visible would require dispatching a cancelable
> > >> visibleChanging event before actually setting the browser's CSS
> display
> > >> property that an effect instance would listen for and cancel,
> then wait
> > for
> > >> the effectEnd event and then finally actually set the visible
> > property. Or
> > >> we'd have to be confident that you can set the CSS display
> property and
> > set
> > >> it back without flicker.
> > >>
> > >> In summary, having the right events should eliminate the need for
> timing
> > >> events.
> > >>
> > >> My 2 cents,
> > >> -Alex
> > >>
> > >>
> > >> On 9/13/18, 2:34 PM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> > >>
> > >> Hi Alex,
> > >> I'm with you. Don't like setTimeOut. But I needed in Jewel in
> at
> > least
> > >> 3
> > >> scenearios. I'd love to change it sometime in the future, but
> for now
> > >> don't
> > >> know how.
> > >> I think the actual ways to defer something are:
> > >> -setTimeOut
> > >> -setInterval
> > >> -requestAnimationFrame
> > >>
> > >> the first one is in SWF, so the solution is cross SWF/JS,
> although if
> > >> we
> > >> add other targets, maybe will require changes.
> > >> the second seems to be the worse.
> > >> the latest seems the actual way to do things in JS, but I
> tried and
> > >> didn't
> > >> work for me, and I suppose we'll need to abstract it to
> something
> > >> usable in
> > >> SWF and future targets.
> > >>
> > >> My concrete case in the three ocassions is when I instantiate a
> > >> component
> > >> and add a class name to make the component animate
> (transition)
> > >> through
> > >> CSS. For example Alert, DateField and ComboBox popups
> components and
> > >> then
> > >> add a class ".open" in CSS, so we need at least 300-400ms so
> the
> > >> transition
> > >> can play.
> > >>
> > >> Any other way to do it would be good to know in order to
> upgrade this
> > >> implementations.
> > >>
> > >> Thanks
> > >>
> > >> Carlos
> > >>
> > >> --
> > >> Carlos Rovira
> > >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C79138145b5db4f85575d08d61a325020%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725200735957438&sdata=GaQKQ9ia22sYICn5XY26T8DYbgbtnBstHc%2FshO%2F%2F4Rw%3D&reserved=0
> > >>
> > >>
> > >>
> > >>
> >
> >
>
> --
> Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C79138145b5db4f85575d08d61a325020%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725200735957438&sdata=GaQKQ9ia22sYICn5XY26T8DYbgbtnBstHc%2FshO%2F%2F4Rw%3D&reserved=0
>
>
>
Re: States problem [was: Re: Royale Transitions, Effects, States infrastructure]
Posted by Carlos Rovira <ca...@apache.org>.
Hi Andrew, don't think so. I think "currentState" is a missing capability
from Flex States, don't know what Alex think about it, but seems something
to add to States.
This is more a bug at some point, in states? in ClassSelectorList? is a
lack of implementation in Jewel components? maybe Alex that knows more
about States could bring some light on this.
thanks
El sáb., 15 sept. 2018 a las 0:45, Andrew Wetmore (<co...@gmail.com>)
escribió:
> Could one deal with this issue for now by creating a global "currentState"
> property and referencing it on state change?
>
> On Fri, Sep 14, 2018 at 7:29 PM Carlos Rovira <ca...@apache.org>
> wrote:
>
> > Hi Alex,
> >
> > the issue comes from beads modifying strand className. This can be seen
> > mixing states with jewel layouts. Jewel Layouts add or removes class
> names
> > in the strand at runtime.
> > Since, as you describe in the example, those changes are not part of some
> > state (i.e: className.normal or className.someState, for example), the
> > current class name is not stored anywhere, so when you change the state
> and
> > comes back, Royale is not capable of recreate the right strand className
> >
> > You can see the issue in action if you compile the blog example about
> > states [1]
> >
> >
> >
> https://github.com/apache/royale-asjs/tree/develop/examples/blog/BE0008_Using_View_States_to_show_or_hide_content
> >
> > Compile the example and run (online version works ok due to it was
> > published when the work was in unfinished stated)
> >
> > Then push the button to change state from login form to result screen and
> > push the button back to go to the other state. You'll see the layout is
> not
> > equal. If check the html in the broswer, you'll find class names are lost
> > between state changes.
> >
> > What do you think would be a good solution to this problem?
> >
> > thanks
> >
> > Carlos
> >
> >
> >
> >
> >
> > El vie., 14 sept. 2018 a las 18:23, Alex Harui (<aharui@adobe.com.invalid
> > >)
> > escribió:
> >
> > > Regarding class selectors and states, I guess I don't understand the
> > > issue. The code behind Royale (and Flex) states should be capturing
> > values
> > > of properties changed by the state before they get changed, then
> > restoring
> > > those properties. IOW, if you were to have
> > >
> > > <js:states>
> > > <js:state name="normal" />
> > > <js:state name="important" />
> > > <js:states>
> > > <j:Button id="myButton" emphasis.normal="primary"
> > > emphasis.important="emphasized" />
> > >
> > > Then the myButton.emphasis="primary" at startup and when the state
> > > changes to "important" the States impl should read myButton.emphasis
> and
> > > store that value away before setting myButton.emphasis="emphasized".
> > Then,
> > > when the state changes back to "normal", the States impl should set
> > > myButton.emphasis="primary" again.
> > >
> > > In the implementation for the emphasis property, if it involves
> changing
> > > classLists, the implementation must do so in a way that handles having
> > the
> > > emphasis property changes at runtime. The States impl isn't really
> doing
> > > anything application developer code might do, so the implementation
> must
> > > support properties being set and re-set.
> > >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
> --
> Andrew Wetmore
>
> http://cottage14.blogspot.com/
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: States problem [was: Re: Royale Transitions, Effects, States infrastructure]
Posted by Andrew Wetmore <co...@gmail.com>.
Could one deal with this issue for now by creating a global "currentState"
property and referencing it on state change?
On Fri, Sep 14, 2018 at 7:29 PM Carlos Rovira <ca...@apache.org>
wrote:
> Hi Alex,
>
> the issue comes from beads modifying strand className. This can be seen
> mixing states with jewel layouts. Jewel Layouts add or removes class names
> in the strand at runtime.
> Since, as you describe in the example, those changes are not part of some
> state (i.e: className.normal or className.someState, for example), the
> current class name is not stored anywhere, so when you change the state and
> comes back, Royale is not capable of recreate the right strand className
>
> You can see the issue in action if you compile the blog example about
> states [1]
>
>
> https://github.com/apache/royale-asjs/tree/develop/examples/blog/BE0008_Using_View_States_to_show_or_hide_content
>
> Compile the example and run (online version works ok due to it was
> published when the work was in unfinished stated)
>
> Then push the button to change state from login form to result screen and
> push the button back to go to the other state. You'll see the layout is not
> equal. If check the html in the broswer, you'll find class names are lost
> between state changes.
>
> What do you think would be a good solution to this problem?
>
> thanks
>
> Carlos
>
>
>
>
>
> El vie., 14 sept. 2018 a las 18:23, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> > Regarding class selectors and states, I guess I don't understand the
> > issue. The code behind Royale (and Flex) states should be capturing
> values
> > of properties changed by the state before they get changed, then
> restoring
> > those properties. IOW, if you were to have
> >
> > <js:states>
> > <js:state name="normal" />
> > <js:state name="important" />
> > <js:states>
> > <j:Button id="myButton" emphasis.normal="primary"
> > emphasis.important="emphasized" />
> >
> > Then the myButton.emphasis="primary" at startup and when the state
> > changes to "important" the States impl should read myButton.emphasis and
> > store that value away before setting myButton.emphasis="emphasized".
> Then,
> > when the state changes back to "normal", the States impl should set
> > myButton.emphasis="primary" again.
> >
> > In the implementation for the emphasis property, if it involves changing
> > classLists, the implementation must do so in a way that handles having
> the
> > emphasis property changes at runtime. The States impl isn't really doing
> > anything application developer code might do, so the implementation must
> > support properties being set and re-set.
> >
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
--
Andrew Wetmore
http://cottage14.blogspot.com/
Re: States problem [was: Re: Royale Transitions, Effects, States infrastructure]
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
ok, I'll try to get again over it as I get some time and report here my
findings.
thanks!
Carlos
El lun., 17 sept. 2018 a las 20:19, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Hi Carlos,
>
> It simply will not scale for me to have to debug every hard problem. We
> need others to increase their skills in debugging the framework. I tried
> to help as much as I can. I pointed you to files like ContainerBase which
> dispatches a childrenAdded event and to LayoutBase which listens for it.
> It looks like your example calls addElement. Step into it, and see why it
> doesn't dispatch the event, or if the event is dispatched and not picked up
> by LayoutBase. Even if it would only take me 30 minutes to figure it out,
> and take you longer, it doesn't matter. If we end up with more users and I
> have to spend 30 minutes on all of their bugs, there is no way I will be
> able to keep up.
>
> Thanks,
> -Alex
>
> On 9/17/18, 11:10 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> I'm very interested in now the essence of each part of Royale, and
> trying
> to use it all the things behind at maximum level. It's intrinsic to me
> :)
> Since most of the things were invented by you, Peter or others, I'm
> trying
> to get the knowledge browsing code and trying things, since most of
> this
> things can only be learn by experience and continuos work with the
> framework.
>
> Begin said that, I said in other email that I trace all methods in
> LayoutBase and in the layouts used in the example ( in this case
> VerticalLayout). I found that removing and adding doesn't trigger any
> more
> calls to this methods (either by a event dispatched or by calling
> expressly
> a method).
>
> So maybe the resolution way is not ok, but to get the proper, I'll
> need you
> take the code I posted to test and see what's happening. I think I can
> get
> far from here without you revising the example and looking where the
> premise you propose is failing and why.
>
> I think this should doesn't get you much time since the code of test is
> very simple and maybe you could find something that is not set as you
> suppose and by this reason I'm not getting the proper results.
>
> Let me know if you can take a look, If you find it, then I can
> propagate
> the changes you instruct over the rest of layouts.
>
> Thanks!
>
> Carlos
>
>
>
>
> El lun., 17 sept. 2018 a las 18:34, Alex Harui
> (<ah...@adobe.com.invalid>)
> escribió:
>
> > Hi Carlos,
> >
> > I looked at your changes. I cannot understand why that would fix
> your
> > problem. beadsAdded gets run pretty early in the lifecycle and
> shouldn't
> > be a factor. I think you may be relying on a bug where beadsAdded
> gets
> > called every time you are added to a parent. Someday that
> beadsAdded will
> > check that beads have already been added and not get fired again.
> >
> > It is important (maybe just to me) that we try to really understand
> the
> > fundamentals of a framework, especially Royale, were PAYG is
> important. If
> > you are still unclear how containers and assignable layouts work,
> then let
> > us know and we'll try to explain it in more detail. The Basic
> Containers
> > and Layouts rely on notification events being dispatched by the
> Container
> > as children are added to the Container. Adding a beadsAdded handler
> should
> > not normally get called if the Container itself did not get added to
> a
> > parent. So I don't know how these changes worked unless the test
> scenario
> > also added and removed the Container.
> >
> > Fundamentally, when you call addElement, the Container's addElement
> should
> > be dispatching a childrenAdded from ContainerBase. I see in
> LayoutBase
> > that it has set up a listener for it. If that listener is not
> getting
> > called, figuring out why it isn't should be the first step in
> proposing a
> > solution. So I would recommend starting there.
> >
> > HTH,
> > -Alex
> >
> > On 9/17/18, 3:01 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > I put traces on LayoutBase and in VerticalLayout to see what
> happens:
> >
> > The layout runs for a component only when it's created (all the
> implied
> > methods, called to strand, handle chidren added, handle init
> complete
> > and
> > perform layout...
> > then if I remove and add again no method in the layout runs
> again...
> >
> > I get to fix it by adding a handler to "beadsAdded" in
> StyledLayoutBase
> > (hope others could see if this problem affects layouts that
> doesn't
> > modify
> > strand class names).
> > In this way when the component is added to parent it runs the
> code to
> > add
> > class selectors.
> >
> > Let me know if you consider the resolution way right, or if it's
> > better to
> > deal with it in other way.
> >
> > Thanks
> >
> >
> > El lun., 17 sept. 2018 a las 9:50, Alex Harui
> > (<ah...@adobe.com.invalid>)
> > escribió:
> >
> > > In Basic ContainerBase events are dispatched as children are
> added.
> > The
> > > Basic Layouts listen for those events (in theory).
> > >
> > > HTH,
> > > -Alex
> > >
> > > On 9/16/18, 4:10 PM, "Carlos Rovira" <ca...@apache.org>
> > wrote:
> > >
> > > Hi Alex,
> > >
> > > you said: "It sounds like an event like childrenAdded is
> not
> > being
> > > dispatched by the component or not being picked up by the
> > layout. It
> > > might
> > > be easier to debug with a non-States example first"
> > >
> > > But I don't really know what I'm looking for, can you
> develop
> > more
> > > about
> > > this?, I see in View and Container we have this comment
> > >
> > > // - why was this added here? childrenAdded(); //?? Is this
> > necessary
> > > since
> > > MXMLDataInterpreter will already have called it
> > >
> > > I tried to add childrenAdded but nothing changes, what it
> > indicated
> > > that
> > > I'm going a bit blind with this.
> > >
> > > So I need to understand first if I'm looking for something
> > related to
> > > "childrenAdded" (or was only named as an example in the
> phrase),
> > and
> > > if so
> > > explain the connection between the container - the event -
> the
> > layout.
> > > What
> > > scares me is that the first time is added, all goes ok,
> but the
> > second
> > > time, is added, it's not. The difference is the instance is
> > already
> > > created, so it seems a problem about process again all
> beads
> > right?
> > >
> > > I'm done for today.
> > >
> > > thanks
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > El lun., 17 sept. 2018 a las 0:02, Carlos Rovira (<
> > > carlosrovira@apache.org>)
> > > escribió:
> > >
> > > > Hi Alex,
> > > >
> > > > seems a bug in Layouts or UIBase/Container. I'll try to
> find
> > it.
> > > >
> > > > this is the test case that make it fail. Add/remove/add
> the
> > Card,
> > > makes
> > > > the second time the card doesn't get the proper class
> Names as
> > with
> > > states.
> > > > I'll try to
> > > >
> > > > <j:Application xmlns:fx="
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316726792&sdata=khDl6qSrCv9X45hccsm8lbbp5NCyz73UI4q2BPej6nk%3D&reserved=0
> > > "
> > > > xmlns:j="library://ns.apache.org/royale/jewel"
> > > > xmlns:js="library://ns.apache.org/royale/basic"
> > > > xmlns:html="library://ns.apache.org/royale/html">
> > > > <fx:Script>
> > > > <![CDATA[
> > > > import org.apache.royale.jewel.Card;
> > > >
> > > > public var card:Card = new Card();
> > > >
> > > > private function addCard():void
> > > > {
> > > > addElement(card);
> > > > }
> > > >
> > > > private function removeCard():void
> > > > {
> > > > removeElement(card);
> > > > }
> > > > ]]>
> > > > </fx:Script>
> > > >
> > > > <j:initialView>
> > > > <j:View id="view" >
> > > > <j:beads>
> > > > <j:VerticalLayout/>
> > > > </j:beads>
> > > > <j:Button text="add card" click="addCard()" />
> > > > <j:Button text="remove card" click="removeCard()"/>
> > > > </j:View>
> > > > </j:initialView>
> > > >
> > > > </j:Application>
> > > >
> > > > El dom., 16 sept. 2018 a las 4:22, Alex Harui
> > > (<ah...@adobe.com.invalid>)
> > > > escribió:
> > > >
> > > >> Hi Carlos,
> > > >>
> > > >> That sounds like a bug in the layouts or
> UIBase/Containers.
> > > >>
> > > >> The non-States equivalent of this scenario should be,
> instead
> > of
> > > setting
> > > >> currentState on a button, to instead call
> > addElement/removeElement
> > > on
> > > >> loginForm and loggedInForm.
> > > >>
> > > >> It sounds like an event like childrenAdded is not being
> > dispatched
> > > by the
> > > >> component or not being picked up by the layout. It
> might be
> > easier
> > > to
> > > >> debug with a non-States example first. And if
> non-States
> > works but
> > > it
> > > >> doesn't with States then we know we have to debug the
> > specific state
> > > >> apply-ing logic.
> > > >>
> > > >> HTH,
> > > >> -Alex
> > > >>
> > > >> On 9/15/18, 8:49 AM, "Carlos Rovira" <
> carlosrovira@apache.org
> > >
> > > wrote:
> > > >>
> > > >> Hi Alex,
> > > >>
> > > >> checking the States example, I can confirm that
> changing
> > the
> > > demo to
> > > >> use
> > > >> dot notation works perfect. I mean this code:
> > > >>
> > > >> <j:Card id="loginForm" *visible="true"
> > > >> visible.loggedIn="false"*>
> > > >> ...
> > > >> </j:Card>
> > > >>
> > > >> <j:Card id="loggedInForm"*
> visible="false"
> > > >> visible.loggedIn="true"*>
> > > >> ....
> > > >> </j:Card>
> > > >>
> > > >> *But* using the other format:
> > > >>
> > > >> <j:Card id="loginForm"*
> includeIn="login"*>
> > > >> ...
> > > >> </j:Card>
> > > >>
> > > >> <j:Card id="loggedInForm"*
> > includeIn="loggedIn"*>
> > > >> ...
> > > >> </j:Card>
> > > >>
> > > >> make the first time the html generate is:
> > > >>
> > > >> <div id="loginForm"* class="jewel card layout
> > vertical
> > > >> gap-3x3px"*>
> > > >>
> > > >> but coming back from loggedIn we get:
> > > >>
> > > >> <div id="loginForm" *class="jewel card"*>
> > > >>
> > > >> This *layout vertical gap-3x3px* is set in the
> strand by
> > > >> VerticalLayout
> > > >> bead.
> > > >>
> > > >> What means for me that beads are not processed
> again in
> > the
> > > process of
> > > >> states recreation.
> > > >>
> > > >> But, bonus is that something similar happens
> recreating
> > PopUps
> > > (as I
> > > >> said
> > > >> with the case of the basic combobox popup)
> > > >>
> > > >> Make this sense?
> > > >>
> > > >> Thanks
> > > >>
> > > >> Carlos
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> El sáb., 15 sept. 2018 a las 17:24, Carlos Rovira (<
> > > >> carlosrovira@apache.org>)
> > > >> escribió:
> > > >>
> > > >> > Hi Alex,
> > > >> >
> > > >> > El sáb., 15 sept. 2018 a las 1:00, Alex Harui
> > > >> (<ah...@adobe.com.invalid>)
> > > >> > escribió:
> > > >> >
> > > >> >> Hi Carlos,
> > > >> >>
> > > >> >> I didn't look at your example yet, but I point
> out
> > that this
> > > may
> > > >> not be
> > > >> >> an issue with States.
> > > >> >
> > > >> >
> > > >> > it's possible.
> > > >> >
> > > >> >
> > > >> >> Currently the States support can only add and
> remove
> > > components
> > > >> and set
> > > >> >> properties on components. So my point is that
> any
> > > application
> > > >> developer
> > > >> >> can do the same thing in their business logic.
> If a
> > Jewel
> > > >> component cannot
> > > >> >> be exactly restored from a set of properties,
> that is a
> > > problem to
> > > >> solve
> > > >> >> regardless of States.
> > > >> >>
> > > >> >
> > > >> > ok.
> > > >> >
> > > >> >
> > > >> >>
> > > >> >> The set of classNames should be directly mapped
> to one
> > or
> > > more
> > > >> >> properties. I thought that was why you wanted
> the
> > classList
> > > API,
> > > >> so that
> > > >> >> various Jewel properties could add/remove class
> > selectors
> > > from the
> > > >> >> classList.
> > > >> >>
> > > >> >
> > > >> > The objective of a class list api is to be able
> to add
> > > >> > and/remove/toggle/check a class selector easily
> in a
> > > component.
> > > >> Don't
> > > >> > understand the sentence "The set of classNames
> should be
> > > directly
> > > >> mapped to
> > > >> > one or more properties".
> > > >> >
> > > >> >
> > > >> >> Maybe we should discuss a simple scenario without
> > states.
> > > If I
> > > >> take a
> > > >> >> Jewel component or container and write some AS to
> > change
> > > >> properties or
> > > >> >> add/remove children and then restore it back to
> the
> > original
> > > and
> > > >> it doesn't
> > > >> >> look the same, what part of the Royale framework
> is
> > > preventing
> > > >> that from
> > > >> >> happening?
> > > >> >>
> > > >> >
> > > >> > ok, change properties is easy, but what do you
> mean with
> > > restore?,
> > > >> how do
> > > >> > you do that?
> > > >> >
> > > >> > Discussing this I remember that I found the same
> effect
> > > adding and
> > > >> > removing a PopUp, in concrete the combobox popup.
> > > >> > In Basic, the list popup in the ComboBox is
> created and
> > then
> > > >> changed from
> > > >> > visible to invisible. In Jewel I had to change it
> to
> > create
> > > and
> > > >> remove the
> > > >> > list each time, since only the first time the
> list was
> > > created with
> > > >> the
> > > >> > right class selectors. and then when made
> invisible, and
> > > visible
> > > >> again, the
> > > >> > list change the layout from vertical to
> horizontal, what
> > > means that
> > > >> class
> > > >> > selectors was changed.
> > > >> >
> > > >> > In the States problem, we had two versions of the
> demo,
> > one
> > > based on
> > > >> > "indludeIn" and other based on dot state notation
> > > (visible.state1).
> > > >> I think
> > > >> > first fail and second was doing things right.
> > > >> >
> > > >> > I'll take a look to see if I find the problem.
> > > >> >
> > > >> >
> > > >> >> Thoughts?
> > > >> >> -Alex
> > > >> >>
> > > >> >> On 9/14/18, 3:29 PM, "Carlos Rovira" <
> > > carlosrovira@apache.org>
> > > >> wrote:
> > > >> >>
> > > >> >> Hi Alex,
> > > >> >>
> > > >> >> the issue comes from beads modifying strand
> > className.
> > > This
> > > >> can be
> > > >> >> seen
> > > >> >> mixing states with jewel layouts. Jewel
> Layouts
> > add or
> > > removes
> > > >> class
> > > >> >> names
> > > >> >> in the strand at runtime.
> > > >> >> Since, as you describe in the example, those
> > changes are
> > > not
> > > >> part of
> > > >> >> some
> > > >> >> state (i.e: className.normal or
> > className.someState, for
> > > >> example), the
> > > >> >> current class name is not stored anywhere,
> so when
> > you
> > > change
> > > >> the
> > > >> >> state and
> > > >> >> comes back, Royale is not capable of
> recreate the
> > right
> > > strand
> > > >> >> className
> > > >> >>
> > > >> >> You can see the issue in action if you
> compile the
> > blog
> > > >> example about
> > > >> >> states [1]
> > > >> >>
> > > >> >>
> > > >> >>
> > > >>
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fblog%2FBE0008_Using_View_States_to_show_or_hide_content&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=iKrJ4hGQkP8fy8ionHbRr0Dw8wZNLDJWxwBLJylQQgY%3D&reserved=0
> > > >> >>
> > > >> >> Compile the example and run (online version
> works
> > ok due
> > > to it
> > > >> was
> > > >> >> published when the work was in unfinished
> stated)
> > > >> >>
> > > >> >> Then push the button to change state from
> login
> > form to
> > > result
> > > >> screen
> > > >> >> and
> > > >> >> push the button back to go to the other
> state.
> > You'll
> > > see the
> > > >> layout
> > > >> >> is not
> > > >> >> equal. If check the html in the broswer,
> you'll
> > find
> > > class
> > > >> names are
> > > >> >> lost
> > > >> >> between state changes.
> > > >> >>
> > > >> >> What do you think would be a good solution
> to this
> > > problem?
> > > >> >>
> > > >> >> thanks
> > > >> >>
> > > >> >> Carlos
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> El vie., 14 sept. 2018 a las 18:23, Alex
> Harui
> > > >> >> (<ah...@adobe.com.invalid>)
> > > >> >> escribió:
> > > >> >>
> > > >> >> > Regarding class selectors and states, I
> guess I
> > don't
> > > >> understand the
> > > >> >> > issue. The code behind Royale (and Flex)
> states
> > > should be
> > > >> >> capturing values
> > > >> >> > of properties changed by the state before
> they
> > get
> > > changed,
> > > >> then
> > > >> >> restoring
> > > >> >> > those properties. IOW, if you were to have
> > > >> >> >
> > > >> >> > <js:states>
> > > >> >> > <js:state name="normal" />
> > > >> >> > <js:state name="important" />
> > > >> >> > <js:states>
> > > >> >> > <j:Button id="myButton"
> emphasis.normal="primary"
> > > >> >> > emphasis.important="emphasized" />
> > > >> >> >
> > > >> >> > Then the myButton.emphasis="primary" at
> startup
> > and
> > > when
> > > >> the state
> > > >> >> > changes to "important" the States impl
> should
> > read
> > > >> >> myButton.emphasis and
> > > >> >> > store that value away before setting
> > > >> >> myButton.emphasis="emphasized". Then,
> > > >> >> > when the state changes back to "normal",
> the
> > States
> > > impl
> > > >> should set
> > > >> >> > myButton.emphasis="primary" again.
> > > >> >> >
> > > >> >> > In the implementation for the emphasis
> property,
> > if it
> > > >> involves
> > > >> >> changing
> > > >> >> > classLists, the implementation must do so
> in a
> > way that
> > > >> handles
> > > >> >> having the
> > > >> >> > emphasis property changes at runtime. The
> > States impl
> > > isn't
> > > >> really
> > > >> >> doing
> > > >> >> > anything application developer code might
> do, so
> > the
> > > >> implementation
> > > >> >> must
> > > >> >> > support properties being set and re-set.
> > > >> >> >
> > > >> >> --
> > > >> >> Carlos Rovira
> > > >> >>
> > > >> >>
> > > >>
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >
> > > >> > --
> > > >> > Carlos Rovira
> > > >> >
> > > >>
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
> > > >> >
> > > >> >
> > > >>
> > > >> --
> > > >> Carlos Rovira
> > > >>
> > > >>
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
> > > >>
> > > >>
> > > >>
> > > >
> > > > --
> > > > Carlos Rovira
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
> > > >
> > > >
> > >
> > > --
> > > Carlos Rovira
> > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
> > >
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: States problem [was: Re: Royale Transitions, Effects, States
infrastructure]
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
It simply will not scale for me to have to debug every hard problem. We need others to increase their skills in debugging the framework. I tried to help as much as I can. I pointed you to files like ContainerBase which dispatches a childrenAdded event and to LayoutBase which listens for it. It looks like your example calls addElement. Step into it, and see why it doesn't dispatch the event, or if the event is dispatched and not picked up by LayoutBase. Even if it would only take me 30 minutes to figure it out, and take you longer, it doesn't matter. If we end up with more users and I have to spend 30 minutes on all of their bugs, there is no way I will be able to keep up.
Thanks,
-Alex
On 9/17/18, 11:10 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
I'm very interested in now the essence of each part of Royale, and trying
to use it all the things behind at maximum level. It's intrinsic to me :)
Since most of the things were invented by you, Peter or others, I'm trying
to get the knowledge browsing code and trying things, since most of this
things can only be learn by experience and continuos work with the
framework.
Begin said that, I said in other email that I trace all methods in
LayoutBase and in the layouts used in the example ( in this case
VerticalLayout). I found that removing and adding doesn't trigger any more
calls to this methods (either by a event dispatched or by calling expressly
a method).
So maybe the resolution way is not ok, but to get the proper, I'll need you
take the code I posted to test and see what's happening. I think I can get
far from here without you revising the example and looking where the
premise you propose is failing and why.
I think this should doesn't get you much time since the code of test is
very simple and maybe you could find something that is not set as you
suppose and by this reason I'm not getting the proper results.
Let me know if you can take a look, If you find it, then I can propagate
the changes you instruct over the rest of layouts.
Thanks!
Carlos
El lun., 17 sept. 2018 a las 18:34, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Hi Carlos,
>
> I looked at your changes. I cannot understand why that would fix your
> problem. beadsAdded gets run pretty early in the lifecycle and shouldn't
> be a factor. I think you may be relying on a bug where beadsAdded gets
> called every time you are added to a parent. Someday that beadsAdded will
> check that beads have already been added and not get fired again.
>
> It is important (maybe just to me) that we try to really understand the
> fundamentals of a framework, especially Royale, were PAYG is important. If
> you are still unclear how containers and assignable layouts work, then let
> us know and we'll try to explain it in more detail. The Basic Containers
> and Layouts rely on notification events being dispatched by the Container
> as children are added to the Container. Adding a beadsAdded handler should
> not normally get called if the Container itself did not get added to a
> parent. So I don't know how these changes worked unless the test scenario
> also added and removed the Container.
>
> Fundamentally, when you call addElement, the Container's addElement should
> be dispatching a childrenAdded from ContainerBase. I see in LayoutBase
> that it has set up a listener for it. If that listener is not getting
> called, figuring out why it isn't should be the first step in proposing a
> solution. So I would recommend starting there.
>
> HTH,
> -Alex
>
> On 9/17/18, 3:01 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> I put traces on LayoutBase and in VerticalLayout to see what happens:
>
> The layout runs for a component only when it's created (all the implied
> methods, called to strand, handle chidren added, handle init complete
> and
> perform layout...
> then if I remove and add again no method in the layout runs again...
>
> I get to fix it by adding a handler to "beadsAdded" in StyledLayoutBase
> (hope others could see if this problem affects layouts that doesn't
> modify
> strand class names).
> In this way when the component is added to parent it runs the code to
> add
> class selectors.
>
> Let me know if you consider the resolution way right, or if it's
> better to
> deal with it in other way.
>
> Thanks
>
>
> El lun., 17 sept. 2018 a las 9:50, Alex Harui
> (<ah...@adobe.com.invalid>)
> escribió:
>
> > In Basic ContainerBase events are dispatched as children are added.
> The
> > Basic Layouts listen for those events (in theory).
> >
> > HTH,
> > -Alex
> >
> > On 9/16/18, 4:10 PM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > Hi Alex,
> >
> > you said: "It sounds like an event like childrenAdded is not
> being
> > dispatched by the component or not being picked up by the
> layout. It
> > might
> > be easier to debug with a non-States example first"
> >
> > But I don't really know what I'm looking for, can you develop
> more
> > about
> > this?, I see in View and Container we have this comment
> >
> > // - why was this added here? childrenAdded(); //?? Is this
> necessary
> > since
> > MXMLDataInterpreter will already have called it
> >
> > I tried to add childrenAdded but nothing changes, what it
> indicated
> > that
> > I'm going a bit blind with this.
> >
> > So I need to understand first if I'm looking for something
> related to
> > "childrenAdded" (or was only named as an example in the phrase),
> and
> > if so
> > explain the connection between the container - the event - the
> layout.
> > What
> > scares me is that the first time is added, all goes ok, but the
> second
> > time, is added, it's not. The difference is the instance is
> already
> > created, so it seems a problem about process again all beads
> right?
> >
> > I'm done for today.
> >
> > thanks
> >
> >
> >
> >
> >
> >
> >
> > El lun., 17 sept. 2018 a las 0:02, Carlos Rovira (<
> > carlosrovira@apache.org>)
> > escribió:
> >
> > > Hi Alex,
> > >
> > > seems a bug in Layouts or UIBase/Container. I'll try to find
> it.
> > >
> > > this is the test case that make it fail. Add/remove/add the
> Card,
> > makes
> > > the second time the card doesn't get the proper class Names as
> with
> > states.
> > > I'll try to
> > >
> > > <j:Application xmlns:fx="
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316726792&sdata=khDl6qSrCv9X45hccsm8lbbp5NCyz73UI4q2BPej6nk%3D&reserved=0
> > "
> > > xmlns:j="library://ns.apache.org/royale/jewel"
> > > xmlns:js="library://ns.apache.org/royale/basic"
> > > xmlns:html="library://ns.apache.org/royale/html">
> > > <fx:Script>
> > > <![CDATA[
> > > import org.apache.royale.jewel.Card;
> > >
> > > public var card:Card = new Card();
> > >
> > > private function addCard():void
> > > {
> > > addElement(card);
> > > }
> > >
> > > private function removeCard():void
> > > {
> > > removeElement(card);
> > > }
> > > ]]>
> > > </fx:Script>
> > >
> > > <j:initialView>
> > > <j:View id="view" >
> > > <j:beads>
> > > <j:VerticalLayout/>
> > > </j:beads>
> > > <j:Button text="add card" click="addCard()" />
> > > <j:Button text="remove card" click="removeCard()"/>
> > > </j:View>
> > > </j:initialView>
> > >
> > > </j:Application>
> > >
> > > El dom., 16 sept. 2018 a las 4:22, Alex Harui
> > (<ah...@adobe.com.invalid>)
> > > escribió:
> > >
> > >> Hi Carlos,
> > >>
> > >> That sounds like a bug in the layouts or UIBase/Containers.
> > >>
> > >> The non-States equivalent of this scenario should be, instead
> of
> > setting
> > >> currentState on a button, to instead call
> addElement/removeElement
> > on
> > >> loginForm and loggedInForm.
> > >>
> > >> It sounds like an event like childrenAdded is not being
> dispatched
> > by the
> > >> component or not being picked up by the layout. It might be
> easier
> > to
> > >> debug with a non-States example first. And if non-States
> works but
> > it
> > >> doesn't with States then we know we have to debug the
> specific state
> > >> apply-ing logic.
> > >>
> > >> HTH,
> > >> -Alex
> > >>
> > >> On 9/15/18, 8:49 AM, "Carlos Rovira" <carlosrovira@apache.org
> >
> > wrote:
> > >>
> > >> Hi Alex,
> > >>
> > >> checking the States example, I can confirm that changing
> the
> > demo to
> > >> use
> > >> dot notation works perfect. I mean this code:
> > >>
> > >> <j:Card id="loginForm" *visible="true"
> > >> visible.loggedIn="false"*>
> > >> ...
> > >> </j:Card>
> > >>
> > >> <j:Card id="loggedInForm"* visible="false"
> > >> visible.loggedIn="true"*>
> > >> ....
> > >> </j:Card>
> > >>
> > >> *But* using the other format:
> > >>
> > >> <j:Card id="loginForm"* includeIn="login"*>
> > >> ...
> > >> </j:Card>
> > >>
> > >> <j:Card id="loggedInForm"*
> includeIn="loggedIn"*>
> > >> ...
> > >> </j:Card>
> > >>
> > >> make the first time the html generate is:
> > >>
> > >> <div id="loginForm"* class="jewel card layout
> vertical
> > >> gap-3x3px"*>
> > >>
> > >> but coming back from loggedIn we get:
> > >>
> > >> <div id="loginForm" *class="jewel card"*>
> > >>
> > >> This *layout vertical gap-3x3px* is set in the strand by
> > >> VerticalLayout
> > >> bead.
> > >>
> > >> What means for me that beads are not processed again in
> the
> > process of
> > >> states recreation.
> > >>
> > >> But, bonus is that something similar happens recreating
> PopUps
> > (as I
> > >> said
> > >> with the case of the basic combobox popup)
> > >>
> > >> Make this sense?
> > >>
> > >> Thanks
> > >>
> > >> Carlos
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> El sáb., 15 sept. 2018 a las 17:24, Carlos Rovira (<
> > >> carlosrovira@apache.org>)
> > >> escribió:
> > >>
> > >> > Hi Alex,
> > >> >
> > >> > El sáb., 15 sept. 2018 a las 1:00, Alex Harui
> > >> (<ah...@adobe.com.invalid>)
> > >> > escribió:
> > >> >
> > >> >> Hi Carlos,
> > >> >>
> > >> >> I didn't look at your example yet, but I point out
> that this
> > may
> > >> not be
> > >> >> an issue with States.
> > >> >
> > >> >
> > >> > it's possible.
> > >> >
> > >> >
> > >> >> Currently the States support can only add and remove
> > components
> > >> and set
> > >> >> properties on components. So my point is that any
> > application
> > >> developer
> > >> >> can do the same thing in their business logic. If a
> Jewel
> > >> component cannot
> > >> >> be exactly restored from a set of properties, that is a
> > problem to
> > >> solve
> > >> >> regardless of States.
> > >> >>
> > >> >
> > >> > ok.
> > >> >
> > >> >
> > >> >>
> > >> >> The set of classNames should be directly mapped to one
> or
> > more
> > >> >> properties. I thought that was why you wanted the
> classList
> > API,
> > >> so that
> > >> >> various Jewel properties could add/remove class
> selectors
> > from the
> > >> >> classList.
> > >> >>
> > >> >
> > >> > The objective of a class list api is to be able to add
> > >> > and/remove/toggle/check a class selector easily in a
> > component.
> > >> Don't
> > >> > understand the sentence "The set of classNames should be
> > directly
> > >> mapped to
> > >> > one or more properties".
> > >> >
> > >> >
> > >> >> Maybe we should discuss a simple scenario without
> states.
> > If I
> > >> take a
> > >> >> Jewel component or container and write some AS to
> change
> > >> properties or
> > >> >> add/remove children and then restore it back to the
> original
> > and
> > >> it doesn't
> > >> >> look the same, what part of the Royale framework is
> > preventing
> > >> that from
> > >> >> happening?
> > >> >>
> > >> >
> > >> > ok, change properties is easy, but what do you mean with
> > restore?,
> > >> how do
> > >> > you do that?
> > >> >
> > >> > Discussing this I remember that I found the same effect
> > adding and
> > >> > removing a PopUp, in concrete the combobox popup.
> > >> > In Basic, the list popup in the ComboBox is created and
> then
> > >> changed from
> > >> > visible to invisible. In Jewel I had to change it to
> create
> > and
> > >> remove the
> > >> > list each time, since only the first time the list was
> > created with
> > >> the
> > >> > right class selectors. and then when made invisible, and
> > visible
> > >> again, the
> > >> > list change the layout from vertical to horizontal, what
> > means that
> > >> class
> > >> > selectors was changed.
> > >> >
> > >> > In the States problem, we had two versions of the demo,
> one
> > based on
> > >> > "indludeIn" and other based on dot state notation
> > (visible.state1).
> > >> I think
> > >> > first fail and second was doing things right.
> > >> >
> > >> > I'll take a look to see if I find the problem.
> > >> >
> > >> >
> > >> >> Thoughts?
> > >> >> -Alex
> > >> >>
> > >> >> On 9/14/18, 3:29 PM, "Carlos Rovira" <
> > carlosrovira@apache.org>
> > >> wrote:
> > >> >>
> > >> >> Hi Alex,
> > >> >>
> > >> >> the issue comes from beads modifying strand
> className.
> > This
> > >> can be
> > >> >> seen
> > >> >> mixing states with jewel layouts. Jewel Layouts
> add or
> > removes
> > >> class
> > >> >> names
> > >> >> in the strand at runtime.
> > >> >> Since, as you describe in the example, those
> changes are
> > not
> > >> part of
> > >> >> some
> > >> >> state (i.e: className.normal or
> className.someState, for
> > >> example), the
> > >> >> current class name is not stored anywhere, so when
> you
> > change
> > >> the
> > >> >> state and
> > >> >> comes back, Royale is not capable of recreate the
> right
> > strand
> > >> >> className
> > >> >>
> > >> >> You can see the issue in action if you compile the
> blog
> > >> example about
> > >> >> states [1]
> > >> >>
> > >> >>
> > >> >>
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fblog%2FBE0008_Using_View_States_to_show_or_hide_content&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=iKrJ4hGQkP8fy8ionHbRr0Dw8wZNLDJWxwBLJylQQgY%3D&reserved=0
> > >> >>
> > >> >> Compile the example and run (online version works
> ok due
> > to it
> > >> was
> > >> >> published when the work was in unfinished stated)
> > >> >>
> > >> >> Then push the button to change state from login
> form to
> > result
> > >> screen
> > >> >> and
> > >> >> push the button back to go to the other state.
> You'll
> > see the
> > >> layout
> > >> >> is not
> > >> >> equal. If check the html in the broswer, you'll
> find
> > class
> > >> names are
> > >> >> lost
> > >> >> between state changes.
> > >> >>
> > >> >> What do you think would be a good solution to this
> > problem?
> > >> >>
> > >> >> thanks
> > >> >>
> > >> >> Carlos
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> El vie., 14 sept. 2018 a las 18:23, Alex Harui
> > >> >> (<ah...@adobe.com.invalid>)
> > >> >> escribió:
> > >> >>
> > >> >> > Regarding class selectors and states, I guess I
> don't
> > >> understand the
> > >> >> > issue. The code behind Royale (and Flex) states
> > should be
> > >> >> capturing values
> > >> >> > of properties changed by the state before they
> get
> > changed,
> > >> then
> > >> >> restoring
> > >> >> > those properties. IOW, if you were to have
> > >> >> >
> > >> >> > <js:states>
> > >> >> > <js:state name="normal" />
> > >> >> > <js:state name="important" />
> > >> >> > <js:states>
> > >> >> > <j:Button id="myButton" emphasis.normal="primary"
> > >> >> > emphasis.important="emphasized" />
> > >> >> >
> > >> >> > Then the myButton.emphasis="primary" at startup
> and
> > when
> > >> the state
> > >> >> > changes to "important" the States impl should
> read
> > >> >> myButton.emphasis and
> > >> >> > store that value away before setting
> > >> >> myButton.emphasis="emphasized". Then,
> > >> >> > when the state changes back to "normal", the
> States
> > impl
> > >> should set
> > >> >> > myButton.emphasis="primary" again.
> > >> >> >
> > >> >> > In the implementation for the emphasis property,
> if it
> > >> involves
> > >> >> changing
> > >> >> > classLists, the implementation must do so in a
> way that
> > >> handles
> > >> >> having the
> > >> >> > emphasis property changes at runtime. The
> States impl
> > isn't
> > >> really
> > >> >> doing
> > >> >> > anything application developer code might do, so
> the
> > >> implementation
> > >> >> must
> > >> >> > support properties being set and re-set.
> > >> >> >
> > >> >> --
> > >> >> Carlos Rovira
> > >> >>
> > >> >>
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >> > --
> > >> > Carlos Rovira
> > >> >
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
> > >> >
> > >> >
> > >>
> > >> --
> > >> Carlos Rovira
> > >>
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
> > >>
> > >>
> > >>
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
>
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0
Re: States problem [was: Re: Royale Transitions, Effects, States infrastructure]
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
I'm very interested in now the essence of each part of Royale, and trying
to use it all the things behind at maximum level. It's intrinsic to me :)
Since most of the things were invented by you, Peter or others, I'm trying
to get the knowledge browsing code and trying things, since most of this
things can only be learn by experience and continuos work with the
framework.
Begin said that, I said in other email that I trace all methods in
LayoutBase and in the layouts used in the example ( in this case
VerticalLayout). I found that removing and adding doesn't trigger any more
calls to this methods (either by a event dispatched or by calling expressly
a method).
So maybe the resolution way is not ok, but to get the proper, I'll need you
take the code I posted to test and see what's happening. I think I can get
far from here without you revising the example and looking where the
premise you propose is failing and why.
I think this should doesn't get you much time since the code of test is
very simple and maybe you could find something that is not set as you
suppose and by this reason I'm not getting the proper results.
Let me know if you can take a look, If you find it, then I can propagate
the changes you instruct over the rest of layouts.
Thanks!
Carlos
El lun., 17 sept. 2018 a las 18:34, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Hi Carlos,
>
> I looked at your changes. I cannot understand why that would fix your
> problem. beadsAdded gets run pretty early in the lifecycle and shouldn't
> be a factor. I think you may be relying on a bug where beadsAdded gets
> called every time you are added to a parent. Someday that beadsAdded will
> check that beads have already been added and not get fired again.
>
> It is important (maybe just to me) that we try to really understand the
> fundamentals of a framework, especially Royale, were PAYG is important. If
> you are still unclear how containers and assignable layouts work, then let
> us know and we'll try to explain it in more detail. The Basic Containers
> and Layouts rely on notification events being dispatched by the Container
> as children are added to the Container. Adding a beadsAdded handler should
> not normally get called if the Container itself did not get added to a
> parent. So I don't know how these changes worked unless the test scenario
> also added and removed the Container.
>
> Fundamentally, when you call addElement, the Container's addElement should
> be dispatching a childrenAdded from ContainerBase. I see in LayoutBase
> that it has set up a listener for it. If that listener is not getting
> called, figuring out why it isn't should be the first step in proposing a
> solution. So I would recommend starting there.
>
> HTH,
> -Alex
>
> On 9/17/18, 3:01 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> I put traces on LayoutBase and in VerticalLayout to see what happens:
>
> The layout runs for a component only when it's created (all the implied
> methods, called to strand, handle chidren added, handle init complete
> and
> perform layout...
> then if I remove and add again no method in the layout runs again...
>
> I get to fix it by adding a handler to "beadsAdded" in StyledLayoutBase
> (hope others could see if this problem affects layouts that doesn't
> modify
> strand class names).
> In this way when the component is added to parent it runs the code to
> add
> class selectors.
>
> Let me know if you consider the resolution way right, or if it's
> better to
> deal with it in other way.
>
> Thanks
>
>
> El lun., 17 sept. 2018 a las 9:50, Alex Harui
> (<ah...@adobe.com.invalid>)
> escribió:
>
> > In Basic ContainerBase events are dispatched as children are added.
> The
> > Basic Layouts listen for those events (in theory).
> >
> > HTH,
> > -Alex
> >
> > On 9/16/18, 4:10 PM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > Hi Alex,
> >
> > you said: "It sounds like an event like childrenAdded is not
> being
> > dispatched by the component or not being picked up by the
> layout. It
> > might
> > be easier to debug with a non-States example first"
> >
> > But I don't really know what I'm looking for, can you develop
> more
> > about
> > this?, I see in View and Container we have this comment
> >
> > // - why was this added here? childrenAdded(); //?? Is this
> necessary
> > since
> > MXMLDataInterpreter will already have called it
> >
> > I tried to add childrenAdded but nothing changes, what it
> indicated
> > that
> > I'm going a bit blind with this.
> >
> > So I need to understand first if I'm looking for something
> related to
> > "childrenAdded" (or was only named as an example in the phrase),
> and
> > if so
> > explain the connection between the container - the event - the
> layout.
> > What
> > scares me is that the first time is added, all goes ok, but the
> second
> > time, is added, it's not. The difference is the instance is
> already
> > created, so it seems a problem about process again all beads
> right?
> >
> > I'm done for today.
> >
> > thanks
> >
> >
> >
> >
> >
> >
> >
> > El lun., 17 sept. 2018 a las 0:02, Carlos Rovira (<
> > carlosrovira@apache.org>)
> > escribió:
> >
> > > Hi Alex,
> > >
> > > seems a bug in Layouts or UIBase/Container. I'll try to find
> it.
> > >
> > > this is the test case that make it fail. Add/remove/add the
> Card,
> > makes
> > > the second time the card doesn't get the proper class Names as
> with
> > states.
> > > I'll try to
> > >
> > > <j:Application xmlns:fx="
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=PvO7zAzeiFSXmOksUs4T%2FmcX9B920%2BNSsqkYzFbrsoY%3D&reserved=0
> > "
> > > xmlns:j="library://ns.apache.org/royale/jewel"
> > > xmlns:js="library://ns.apache.org/royale/basic"
> > > xmlns:html="library://ns.apache.org/royale/html">
> > > <fx:Script>
> > > <![CDATA[
> > > import org.apache.royale.jewel.Card;
> > >
> > > public var card:Card = new Card();
> > >
> > > private function addCard():void
> > > {
> > > addElement(card);
> > > }
> > >
> > > private function removeCard():void
> > > {
> > > removeElement(card);
> > > }
> > > ]]>
> > > </fx:Script>
> > >
> > > <j:initialView>
> > > <j:View id="view" >
> > > <j:beads>
> > > <j:VerticalLayout/>
> > > </j:beads>
> > > <j:Button text="add card" click="addCard()" />
> > > <j:Button text="remove card" click="removeCard()"/>
> > > </j:View>
> > > </j:initialView>
> > >
> > > </j:Application>
> > >
> > > El dom., 16 sept. 2018 a las 4:22, Alex Harui
> > (<ah...@adobe.com.invalid>)
> > > escribió:
> > >
> > >> Hi Carlos,
> > >>
> > >> That sounds like a bug in the layouts or UIBase/Containers.
> > >>
> > >> The non-States equivalent of this scenario should be, instead
> of
> > setting
> > >> currentState on a button, to instead call
> addElement/removeElement
> > on
> > >> loginForm and loggedInForm.
> > >>
> > >> It sounds like an event like childrenAdded is not being
> dispatched
> > by the
> > >> component or not being picked up by the layout. It might be
> easier
> > to
> > >> debug with a non-States example first. And if non-States
> works but
> > it
> > >> doesn't with States then we know we have to debug the
> specific state
> > >> apply-ing logic.
> > >>
> > >> HTH,
> > >> -Alex
> > >>
> > >> On 9/15/18, 8:49 AM, "Carlos Rovira" <carlosrovira@apache.org
> >
> > wrote:
> > >>
> > >> Hi Alex,
> > >>
> > >> checking the States example, I can confirm that changing
> the
> > demo to
> > >> use
> > >> dot notation works perfect. I mean this code:
> > >>
> > >> <j:Card id="loginForm" *visible="true"
> > >> visible.loggedIn="false"*>
> > >> ...
> > >> </j:Card>
> > >>
> > >> <j:Card id="loggedInForm"* visible="false"
> > >> visible.loggedIn="true"*>
> > >> ....
> > >> </j:Card>
> > >>
> > >> *But* using the other format:
> > >>
> > >> <j:Card id="loginForm"* includeIn="login"*>
> > >> ...
> > >> </j:Card>
> > >>
> > >> <j:Card id="loggedInForm"*
> includeIn="loggedIn"*>
> > >> ...
> > >> </j:Card>
> > >>
> > >> make the first time the html generate is:
> > >>
> > >> <div id="loginForm"* class="jewel card layout
> vertical
> > >> gap-3x3px"*>
> > >>
> > >> but coming back from loggedIn we get:
> > >>
> > >> <div id="loginForm" *class="jewel card"*>
> > >>
> > >> This *layout vertical gap-3x3px* is set in the strand by
> > >> VerticalLayout
> > >> bead.
> > >>
> > >> What means for me that beads are not processed again in
> the
> > process of
> > >> states recreation.
> > >>
> > >> But, bonus is that something similar happens recreating
> PopUps
> > (as I
> > >> said
> > >> with the case of the basic combobox popup)
> > >>
> > >> Make this sense?
> > >>
> > >> Thanks
> > >>
> > >> Carlos
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> El sáb., 15 sept. 2018 a las 17:24, Carlos Rovira (<
> > >> carlosrovira@apache.org>)
> > >> escribió:
> > >>
> > >> > Hi Alex,
> > >> >
> > >> > El sáb., 15 sept. 2018 a las 1:00, Alex Harui
> > >> (<ah...@adobe.com.invalid>)
> > >> > escribió:
> > >> >
> > >> >> Hi Carlos,
> > >> >>
> > >> >> I didn't look at your example yet, but I point out
> that this
> > may
> > >> not be
> > >> >> an issue with States.
> > >> >
> > >> >
> > >> > it's possible.
> > >> >
> > >> >
> > >> >> Currently the States support can only add and remove
> > components
> > >> and set
> > >> >> properties on components. So my point is that any
> > application
> > >> developer
> > >> >> can do the same thing in their business logic. If a
> Jewel
> > >> component cannot
> > >> >> be exactly restored from a set of properties, that is a
> > problem to
> > >> solve
> > >> >> regardless of States.
> > >> >>
> > >> >
> > >> > ok.
> > >> >
> > >> >
> > >> >>
> > >> >> The set of classNames should be directly mapped to one
> or
> > more
> > >> >> properties. I thought that was why you wanted the
> classList
> > API,
> > >> so that
> > >> >> various Jewel properties could add/remove class
> selectors
> > from the
> > >> >> classList.
> > >> >>
> > >> >
> > >> > The objective of a class list api is to be able to add
> > >> > and/remove/toggle/check a class selector easily in a
> > component.
> > >> Don't
> > >> > understand the sentence "The set of classNames should be
> > directly
> > >> mapped to
> > >> > one or more properties".
> > >> >
> > >> >
> > >> >> Maybe we should discuss a simple scenario without
> states.
> > If I
> > >> take a
> > >> >> Jewel component or container and write some AS to
> change
> > >> properties or
> > >> >> add/remove children and then restore it back to the
> original
> > and
> > >> it doesn't
> > >> >> look the same, what part of the Royale framework is
> > preventing
> > >> that from
> > >> >> happening?
> > >> >>
> > >> >
> > >> > ok, change properties is easy, but what do you mean with
> > restore?,
> > >> how do
> > >> > you do that?
> > >> >
> > >> > Discussing this I remember that I found the same effect
> > adding and
> > >> > removing a PopUp, in concrete the combobox popup.
> > >> > In Basic, the list popup in the ComboBox is created and
> then
> > >> changed from
> > >> > visible to invisible. In Jewel I had to change it to
> create
> > and
> > >> remove the
> > >> > list each time, since only the first time the list was
> > created with
> > >> the
> > >> > right class selectors. and then when made invisible, and
> > visible
> > >> again, the
> > >> > list change the layout from vertical to horizontal, what
> > means that
> > >> class
> > >> > selectors was changed.
> > >> >
> > >> > In the States problem, we had two versions of the demo,
> one
> > based on
> > >> > "indludeIn" and other based on dot state notation
> > (visible.state1).
> > >> I think
> > >> > first fail and second was doing things right.
> > >> >
> > >> > I'll take a look to see if I find the problem.
> > >> >
> > >> >
> > >> >> Thoughts?
> > >> >> -Alex
> > >> >>
> > >> >> On 9/14/18, 3:29 PM, "Carlos Rovira" <
> > carlosrovira@apache.org>
> > >> wrote:
> > >> >>
> > >> >> Hi Alex,
> > >> >>
> > >> >> the issue comes from beads modifying strand
> className.
> > This
> > >> can be
> > >> >> seen
> > >> >> mixing states with jewel layouts. Jewel Layouts
> add or
> > removes
> > >> class
> > >> >> names
> > >> >> in the strand at runtime.
> > >> >> Since, as you describe in the example, those
> changes are
> > not
> > >> part of
> > >> >> some
> > >> >> state (i.e: className.normal or
> className.someState, for
> > >> example), the
> > >> >> current class name is not stored anywhere, so when
> you
> > change
> > >> the
> > >> >> state and
> > >> >> comes back, Royale is not capable of recreate the
> right
> > strand
> > >> >> className
> > >> >>
> > >> >> You can see the issue in action if you compile the
> blog
> > >> example about
> > >> >> states [1]
> > >> >>
> > >> >>
> > >> >>
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fblog%2FBE0008_Using_View_States_to_show_or_hide_content&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=HdMYRGixb5jJpqGztOqu%2FiaQqK29L%2B1H8mPq2AkFYXk%3D&reserved=0
> > >> >>
> > >> >> Compile the example and run (online version works
> ok due
> > to it
> > >> was
> > >> >> published when the work was in unfinished stated)
> > >> >>
> > >> >> Then push the button to change state from login
> form to
> > result
> > >> screen
> > >> >> and
> > >> >> push the button back to go to the other state.
> You'll
> > see the
> > >> layout
> > >> >> is not
> > >> >> equal. If check the html in the broswer, you'll
> find
> > class
> > >> names are
> > >> >> lost
> > >> >> between state changes.
> > >> >>
> > >> >> What do you think would be a good solution to this
> > problem?
> > >> >>
> > >> >> thanks
> > >> >>
> > >> >> Carlos
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> El vie., 14 sept. 2018 a las 18:23, Alex Harui
> > >> >> (<ah...@adobe.com.invalid>)
> > >> >> escribió:
> > >> >>
> > >> >> > Regarding class selectors and states, I guess I
> don't
> > >> understand the
> > >> >> > issue. The code behind Royale (and Flex) states
> > should be
> > >> >> capturing values
> > >> >> > of properties changed by the state before they
> get
> > changed,
> > >> then
> > >> >> restoring
> > >> >> > those properties. IOW, if you were to have
> > >> >> >
> > >> >> > <js:states>
> > >> >> > <js:state name="normal" />
> > >> >> > <js:state name="important" />
> > >> >> > <js:states>
> > >> >> > <j:Button id="myButton" emphasis.normal="primary"
> > >> >> > emphasis.important="emphasized" />
> > >> >> >
> > >> >> > Then the myButton.emphasis="primary" at startup
> and
> > when
> > >> the state
> > >> >> > changes to "important" the States impl should
> read
> > >> >> myButton.emphasis and
> > >> >> > store that value away before setting
> > >> >> myButton.emphasis="emphasized". Then,
> > >> >> > when the state changes back to "normal", the
> States
> > impl
> > >> should set
> > >> >> > myButton.emphasis="primary" again.
> > >> >> >
> > >> >> > In the implementation for the emphasis property,
> if it
> > >> involves
> > >> >> changing
> > >> >> > classLists, the implementation must do so in a
> way that
> > >> handles
> > >> >> having the
> > >> >> > emphasis property changes at runtime. The
> States impl
> > isn't
> > >> really
> > >> >> doing
> > >> >> > anything application developer code might do, so
> the
> > >> implementation
> > >> >> must
> > >> >> > support properties being set and re-set.
> > >> >> >
> > >> >> --
> > >> >> Carlos Rovira
> > >> >>
> > >> >>
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&reserved=0
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >> > --
> > >> > Carlos Rovira
> > >> >
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&reserved=0
> > >> >
> > >> >
> > >>
> > >> --
> > >> Carlos Rovira
> > >>
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&reserved=0
> > >>
> > >>
> > >>
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&reserved=0
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: States problem [was: Re: Royale Transitions, Effects, States
infrastructure]
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
I looked at your changes. I cannot understand why that would fix your problem. beadsAdded gets run pretty early in the lifecycle and shouldn't be a factor. I think you may be relying on a bug where beadsAdded gets called every time you are added to a parent. Someday that beadsAdded will check that beads have already been added and not get fired again.
It is important (maybe just to me) that we try to really understand the fundamentals of a framework, especially Royale, were PAYG is important. If you are still unclear how containers and assignable layouts work, then let us know and we'll try to explain it in more detail. The Basic Containers and Layouts rely on notification events being dispatched by the Container as children are added to the Container. Adding a beadsAdded handler should not normally get called if the Container itself did not get added to a parent. So I don't know how these changes worked unless the test scenario also added and removed the Container.
Fundamentally, when you call addElement, the Container's addElement should be dispatching a childrenAdded from ContainerBase. I see in LayoutBase that it has set up a listener for it. If that listener is not getting called, figuring out why it isn't should be the first step in proposing a solution. So I would recommend starting there.
HTH,
-Alex
On 9/17/18, 3:01 AM, "Carlos Rovira" <ca...@apache.org> wrote:
I put traces on LayoutBase and in VerticalLayout to see what happens:
The layout runs for a component only when it's created (all the implied
methods, called to strand, handle chidren added, handle init complete and
perform layout...
then if I remove and add again no method in the layout runs again...
I get to fix it by adding a handler to "beadsAdded" in StyledLayoutBase
(hope others could see if this problem affects layouts that doesn't modify
strand class names).
In this way when the component is added to parent it runs the code to add
class selectors.
Let me know if you consider the resolution way right, or if it's better to
deal with it in other way.
Thanks
El lun., 17 sept. 2018 a las 9:50, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> In Basic ContainerBase events are dispatched as children are added. The
> Basic Layouts listen for those events (in theory).
>
> HTH,
> -Alex
>
> On 9/16/18, 4:10 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> you said: "It sounds like an event like childrenAdded is not being
> dispatched by the component or not being picked up by the layout. It
> might
> be easier to debug with a non-States example first"
>
> But I don't really know what I'm looking for, can you develop more
> about
> this?, I see in View and Container we have this comment
>
> // - why was this added here? childrenAdded(); //?? Is this necessary
> since
> MXMLDataInterpreter will already have called it
>
> I tried to add childrenAdded but nothing changes, what it indicated
> that
> I'm going a bit blind with this.
>
> So I need to understand first if I'm looking for something related to
> "childrenAdded" (or was only named as an example in the phrase), and
> if so
> explain the connection between the container - the event - the layout.
> What
> scares me is that the first time is added, all goes ok, but the second
> time, is added, it's not. The difference is the instance is already
> created, so it seems a problem about process again all beads right?
>
> I'm done for today.
>
> thanks
>
>
>
>
>
>
>
> El lun., 17 sept. 2018 a las 0:02, Carlos Rovira (<
> carlosrovira@apache.org>)
> escribió:
>
> > Hi Alex,
> >
> > seems a bug in Layouts or UIBase/Container. I'll try to find it.
> >
> > this is the test case that make it fail. Add/remove/add the Card,
> makes
> > the second time the card doesn't get the proper class Names as with
> states.
> > I'll try to
> >
> > <j:Application xmlns:fx="
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=PvO7zAzeiFSXmOksUs4T%2FmcX9B920%2BNSsqkYzFbrsoY%3D&reserved=0
> "
> > xmlns:j="library://ns.apache.org/royale/jewel"
> > xmlns:js="library://ns.apache.org/royale/basic"
> > xmlns:html="library://ns.apache.org/royale/html">
> > <fx:Script>
> > <![CDATA[
> > import org.apache.royale.jewel.Card;
> >
> > public var card:Card = new Card();
> >
> > private function addCard():void
> > {
> > addElement(card);
> > }
> >
> > private function removeCard():void
> > {
> > removeElement(card);
> > }
> > ]]>
> > </fx:Script>
> >
> > <j:initialView>
> > <j:View id="view" >
> > <j:beads>
> > <j:VerticalLayout/>
> > </j:beads>
> > <j:Button text="add card" click="addCard()" />
> > <j:Button text="remove card" click="removeCard()"/>
> > </j:View>
> > </j:initialView>
> >
> > </j:Application>
> >
> > El dom., 16 sept. 2018 a las 4:22, Alex Harui
> (<ah...@adobe.com.invalid>)
> > escribió:
> >
> >> Hi Carlos,
> >>
> >> That sounds like a bug in the layouts or UIBase/Containers.
> >>
> >> The non-States equivalent of this scenario should be, instead of
> setting
> >> currentState on a button, to instead call addElement/removeElement
> on
> >> loginForm and loggedInForm.
> >>
> >> It sounds like an event like childrenAdded is not being dispatched
> by the
> >> component or not being picked up by the layout. It might be easier
> to
> >> debug with a non-States example first. And if non-States works but
> it
> >> doesn't with States then we know we have to debug the specific state
> >> apply-ing logic.
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 9/15/18, 8:49 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >>
> >> Hi Alex,
> >>
> >> checking the States example, I can confirm that changing the
> demo to
> >> use
> >> dot notation works perfect. I mean this code:
> >>
> >> <j:Card id="loginForm" *visible="true"
> >> visible.loggedIn="false"*>
> >> ...
> >> </j:Card>
> >>
> >> <j:Card id="loggedInForm"* visible="false"
> >> visible.loggedIn="true"*>
> >> ....
> >> </j:Card>
> >>
> >> *But* using the other format:
> >>
> >> <j:Card id="loginForm"* includeIn="login"*>
> >> ...
> >> </j:Card>
> >>
> >> <j:Card id="loggedInForm"* includeIn="loggedIn"*>
> >> ...
> >> </j:Card>
> >>
> >> make the first time the html generate is:
> >>
> >> <div id="loginForm"* class="jewel card layout vertical
> >> gap-3x3px"*>
> >>
> >> but coming back from loggedIn we get:
> >>
> >> <div id="loginForm" *class="jewel card"*>
> >>
> >> This *layout vertical gap-3x3px* is set in the strand by
> >> VerticalLayout
> >> bead.
> >>
> >> What means for me that beads are not processed again in the
> process of
> >> states recreation.
> >>
> >> But, bonus is that something similar happens recreating PopUps
> (as I
> >> said
> >> with the case of the basic combobox popup)
> >>
> >> Make this sense?
> >>
> >> Thanks
> >>
> >> Carlos
> >>
> >>
> >>
> >>
> >>
> >> El sáb., 15 sept. 2018 a las 17:24, Carlos Rovira (<
> >> carlosrovira@apache.org>)
> >> escribió:
> >>
> >> > Hi Alex,
> >> >
> >> > El sáb., 15 sept. 2018 a las 1:00, Alex Harui
> >> (<ah...@adobe.com.invalid>)
> >> > escribió:
> >> >
> >> >> Hi Carlos,
> >> >>
> >> >> I didn't look at your example yet, but I point out that this
> may
> >> not be
> >> >> an issue with States.
> >> >
> >> >
> >> > it's possible.
> >> >
> >> >
> >> >> Currently the States support can only add and remove
> components
> >> and set
> >> >> properties on components. So my point is that any
> application
> >> developer
> >> >> can do the same thing in their business logic. If a Jewel
> >> component cannot
> >> >> be exactly restored from a set of properties, that is a
> problem to
> >> solve
> >> >> regardless of States.
> >> >>
> >> >
> >> > ok.
> >> >
> >> >
> >> >>
> >> >> The set of classNames should be directly mapped to one or
> more
> >> >> properties. I thought that was why you wanted the classList
> API,
> >> so that
> >> >> various Jewel properties could add/remove class selectors
> from the
> >> >> classList.
> >> >>
> >> >
> >> > The objective of a class list api is to be able to add
> >> > and/remove/toggle/check a class selector easily in a
> component.
> >> Don't
> >> > understand the sentence "The set of classNames should be
> directly
> >> mapped to
> >> > one or more properties".
> >> >
> >> >
> >> >> Maybe we should discuss a simple scenario without states.
> If I
> >> take a
> >> >> Jewel component or container and write some AS to change
> >> properties or
> >> >> add/remove children and then restore it back to the original
> and
> >> it doesn't
> >> >> look the same, what part of the Royale framework is
> preventing
> >> that from
> >> >> happening?
> >> >>
> >> >
> >> > ok, change properties is easy, but what do you mean with
> restore?,
> >> how do
> >> > you do that?
> >> >
> >> > Discussing this I remember that I found the same effect
> adding and
> >> > removing a PopUp, in concrete the combobox popup.
> >> > In Basic, the list popup in the ComboBox is created and then
> >> changed from
> >> > visible to invisible. In Jewel I had to change it to create
> and
> >> remove the
> >> > list each time, since only the first time the list was
> created with
> >> the
> >> > right class selectors. and then when made invisible, and
> visible
> >> again, the
> >> > list change the layout from vertical to horizontal, what
> means that
> >> class
> >> > selectors was changed.
> >> >
> >> > In the States problem, we had two versions of the demo, one
> based on
> >> > "indludeIn" and other based on dot state notation
> (visible.state1).
> >> I think
> >> > first fail and second was doing things right.
> >> >
> >> > I'll take a look to see if I find the problem.
> >> >
> >> >
> >> >> Thoughts?
> >> >> -Alex
> >> >>
> >> >> On 9/14/18, 3:29 PM, "Carlos Rovira" <
> carlosrovira@apache.org>
> >> wrote:
> >> >>
> >> >> Hi Alex,
> >> >>
> >> >> the issue comes from beads modifying strand className.
> This
> >> can be
> >> >> seen
> >> >> mixing states with jewel layouts. Jewel Layouts add or
> removes
> >> class
> >> >> names
> >> >> in the strand at runtime.
> >> >> Since, as you describe in the example, those changes are
> not
> >> part of
> >> >> some
> >> >> state (i.e: className.normal or className.someState, for
> >> example), the
> >> >> current class name is not stored anywhere, so when you
> change
> >> the
> >> >> state and
> >> >> comes back, Royale is not capable of recreate the right
> strand
> >> >> className
> >> >>
> >> >> You can see the issue in action if you compile the blog
> >> example about
> >> >> states [1]
> >> >>
> >> >>
> >> >>
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fblog%2FBE0008_Using_View_States_to_show_or_hide_content&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=HdMYRGixb5jJpqGztOqu%2FiaQqK29L%2B1H8mPq2AkFYXk%3D&reserved=0
> >> >>
> >> >> Compile the example and run (online version works ok due
> to it
> >> was
> >> >> published when the work was in unfinished stated)
> >> >>
> >> >> Then push the button to change state from login form to
> result
> >> screen
> >> >> and
> >> >> push the button back to go to the other state. You'll
> see the
> >> layout
> >> >> is not
> >> >> equal. If check the html in the broswer, you'll find
> class
> >> names are
> >> >> lost
> >> >> between state changes.
> >> >>
> >> >> What do you think would be a good solution to this
> problem?
> >> >>
> >> >> thanks
> >> >>
> >> >> Carlos
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> El vie., 14 sept. 2018 a las 18:23, Alex Harui
> >> >> (<ah...@adobe.com.invalid>)
> >> >> escribió:
> >> >>
> >> >> > Regarding class selectors and states, I guess I don't
> >> understand the
> >> >> > issue. The code behind Royale (and Flex) states
> should be
> >> >> capturing values
> >> >> > of properties changed by the state before they get
> changed,
> >> then
> >> >> restoring
> >> >> > those properties. IOW, if you were to have
> >> >> >
> >> >> > <js:states>
> >> >> > <js:state name="normal" />
> >> >> > <js:state name="important" />
> >> >> > <js:states>
> >> >> > <j:Button id="myButton" emphasis.normal="primary"
> >> >> > emphasis.important="emphasized" />
> >> >> >
> >> >> > Then the myButton.emphasis="primary" at startup and
> when
> >> the state
> >> >> > changes to "important" the States impl should read
> >> >> myButton.emphasis and
> >> >> > store that value away before setting
> >> >> myButton.emphasis="emphasized". Then,
> >> >> > when the state changes back to "normal", the States
> impl
> >> should set
> >> >> > myButton.emphasis="primary" again.
> >> >> >
> >> >> > In the implementation for the emphasis property, if it
> >> involves
> >> >> changing
> >> >> > classLists, the implementation must do so in a way that
> >> handles
> >> >> having the
> >> >> > emphasis property changes at runtime. The States impl
> isn't
> >> really
> >> >> doing
> >> >> > anything application developer code might do, so the
> >> implementation
> >> >> must
> >> >> > support properties being set and re-set.
> >> >> >
> >> >> --
> >> >> Carlos Rovira
> >> >>
> >> >>
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&reserved=0
> >> >>
> >> >>
> >> >>
> >> >
> >> > --
> >> > Carlos Rovira
> >> >
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&reserved=0
> >> >
> >> >
> >>
> >> --
> >> Carlos Rovira
> >>
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&reserved=0
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&reserved=0
> >
> >
>
> --
> Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&reserved=0
>
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&reserved=0
Re: States problem [was: Re: Royale Transitions, Effects, States infrastructure]
Posted by Carlos Rovira <ca...@apache.org>.
I put traces on LayoutBase and in VerticalLayout to see what happens:
The layout runs for a component only when it's created (all the implied
methods, called to strand, handle chidren added, handle init complete and
perform layout...
then if I remove and add again no method in the layout runs again...
I get to fix it by adding a handler to "beadsAdded" in StyledLayoutBase
(hope others could see if this problem affects layouts that doesn't modify
strand class names).
In this way when the component is added to parent it runs the code to add
class selectors.
Let me know if you consider the resolution way right, or if it's better to
deal with it in other way.
Thanks
El lun., 17 sept. 2018 a las 9:50, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> In Basic ContainerBase events are dispatched as children are added. The
> Basic Layouts listen for those events (in theory).
>
> HTH,
> -Alex
>
> On 9/16/18, 4:10 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> you said: "It sounds like an event like childrenAdded is not being
> dispatched by the component or not being picked up by the layout. It
> might
> be easier to debug with a non-States example first"
>
> But I don't really know what I'm looking for, can you develop more
> about
> this?, I see in View and Container we have this comment
>
> // - why was this added here? childrenAdded(); //?? Is this necessary
> since
> MXMLDataInterpreter will already have called it
>
> I tried to add childrenAdded but nothing changes, what it indicated
> that
> I'm going a bit blind with this.
>
> So I need to understand first if I'm looking for something related to
> "childrenAdded" (or was only named as an example in the phrase), and
> if so
> explain the connection between the container - the event - the layout.
> What
> scares me is that the first time is added, all goes ok, but the second
> time, is added, it's not. The difference is the instance is already
> created, so it seems a problem about process again all beads right?
>
> I'm done for today.
>
> thanks
>
>
>
>
>
>
>
> El lun., 17 sept. 2018 a las 0:02, Carlos Rovira (<
> carlosrovira@apache.org>)
> escribió:
>
> > Hi Alex,
> >
> > seems a bug in Layouts or UIBase/Container. I'll try to find it.
> >
> > this is the test case that make it fail. Add/remove/add the Card,
> makes
> > the second time the card doesn't get the proper class Names as with
> states.
> > I'll try to
> >
> > <j:Application xmlns:fx="
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=M0p%2FTNB3Wpjq7CT%2FQ%2Fp0OqNcQg2evuGzFhTFbqiGI2E%3D&reserved=0
> "
> > xmlns:j="library://ns.apache.org/royale/jewel"
> > xmlns:js="library://ns.apache.org/royale/basic"
> > xmlns:html="library://ns.apache.org/royale/html">
> > <fx:Script>
> > <![CDATA[
> > import org.apache.royale.jewel.Card;
> >
> > public var card:Card = new Card();
> >
> > private function addCard():void
> > {
> > addElement(card);
> > }
> >
> > private function removeCard():void
> > {
> > removeElement(card);
> > }
> > ]]>
> > </fx:Script>
> >
> > <j:initialView>
> > <j:View id="view" >
> > <j:beads>
> > <j:VerticalLayout/>
> > </j:beads>
> > <j:Button text="add card" click="addCard()" />
> > <j:Button text="remove card" click="removeCard()"/>
> > </j:View>
> > </j:initialView>
> >
> > </j:Application>
> >
> > El dom., 16 sept. 2018 a las 4:22, Alex Harui
> (<ah...@adobe.com.invalid>)
> > escribió:
> >
> >> Hi Carlos,
> >>
> >> That sounds like a bug in the layouts or UIBase/Containers.
> >>
> >> The non-States equivalent of this scenario should be, instead of
> setting
> >> currentState on a button, to instead call addElement/removeElement
> on
> >> loginForm and loggedInForm.
> >>
> >> It sounds like an event like childrenAdded is not being dispatched
> by the
> >> component or not being picked up by the layout. It might be easier
> to
> >> debug with a non-States example first. And if non-States works but
> it
> >> doesn't with States then we know we have to debug the specific state
> >> apply-ing logic.
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 9/15/18, 8:49 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >>
> >> Hi Alex,
> >>
> >> checking the States example, I can confirm that changing the
> demo to
> >> use
> >> dot notation works perfect. I mean this code:
> >>
> >> <j:Card id="loginForm" *visible="true"
> >> visible.loggedIn="false"*>
> >> ...
> >> </j:Card>
> >>
> >> <j:Card id="loggedInForm"* visible="false"
> >> visible.loggedIn="true"*>
> >> ....
> >> </j:Card>
> >>
> >> *But* using the other format:
> >>
> >> <j:Card id="loginForm"* includeIn="login"*>
> >> ...
> >> </j:Card>
> >>
> >> <j:Card id="loggedInForm"* includeIn="loggedIn"*>
> >> ...
> >> </j:Card>
> >>
> >> make the first time the html generate is:
> >>
> >> <div id="loginForm"* class="jewel card layout vertical
> >> gap-3x3px"*>
> >>
> >> but coming back from loggedIn we get:
> >>
> >> <div id="loginForm" *class="jewel card"*>
> >>
> >> This *layout vertical gap-3x3px* is set in the strand by
> >> VerticalLayout
> >> bead.
> >>
> >> What means for me that beads are not processed again in the
> process of
> >> states recreation.
> >>
> >> But, bonus is that something similar happens recreating PopUps
> (as I
> >> said
> >> with the case of the basic combobox popup)
> >>
> >> Make this sense?
> >>
> >> Thanks
> >>
> >> Carlos
> >>
> >>
> >>
> >>
> >>
> >> El sáb., 15 sept. 2018 a las 17:24, Carlos Rovira (<
> >> carlosrovira@apache.org>)
> >> escribió:
> >>
> >> > Hi Alex,
> >> >
> >> > El sáb., 15 sept. 2018 a las 1:00, Alex Harui
> >> (<ah...@adobe.com.invalid>)
> >> > escribió:
> >> >
> >> >> Hi Carlos,
> >> >>
> >> >> I didn't look at your example yet, but I point out that this
> may
> >> not be
> >> >> an issue with States.
> >> >
> >> >
> >> > it's possible.
> >> >
> >> >
> >> >> Currently the States support can only add and remove
> components
> >> and set
> >> >> properties on components. So my point is that any
> application
> >> developer
> >> >> can do the same thing in their business logic. If a Jewel
> >> component cannot
> >> >> be exactly restored from a set of properties, that is a
> problem to
> >> solve
> >> >> regardless of States.
> >> >>
> >> >
> >> > ok.
> >> >
> >> >
> >> >>
> >> >> The set of classNames should be directly mapped to one or
> more
> >> >> properties. I thought that was why you wanted the classList
> API,
> >> so that
> >> >> various Jewel properties could add/remove class selectors
> from the
> >> >> classList.
> >> >>
> >> >
> >> > The objective of a class list api is to be able to add
> >> > and/remove/toggle/check a class selector easily in a
> component.
> >> Don't
> >> > understand the sentence "The set of classNames should be
> directly
> >> mapped to
> >> > one or more properties".
> >> >
> >> >
> >> >> Maybe we should discuss a simple scenario without states.
> If I
> >> take a
> >> >> Jewel component or container and write some AS to change
> >> properties or
> >> >> add/remove children and then restore it back to the original
> and
> >> it doesn't
> >> >> look the same, what part of the Royale framework is
> preventing
> >> that from
> >> >> happening?
> >> >>
> >> >
> >> > ok, change properties is easy, but what do you mean with
> restore?,
> >> how do
> >> > you do that?
> >> >
> >> > Discussing this I remember that I found the same effect
> adding and
> >> > removing a PopUp, in concrete the combobox popup.
> >> > In Basic, the list popup in the ComboBox is created and then
> >> changed from
> >> > visible to invisible. In Jewel I had to change it to create
> and
> >> remove the
> >> > list each time, since only the first time the list was
> created with
> >> the
> >> > right class selectors. and then when made invisible, and
> visible
> >> again, the
> >> > list change the layout from vertical to horizontal, what
> means that
> >> class
> >> > selectors was changed.
> >> >
> >> > In the States problem, we had two versions of the demo, one
> based on
> >> > "indludeIn" and other based on dot state notation
> (visible.state1).
> >> I think
> >> > first fail and second was doing things right.
> >> >
> >> > I'll take a look to see if I find the problem.
> >> >
> >> >
> >> >> Thoughts?
> >> >> -Alex
> >> >>
> >> >> On 9/14/18, 3:29 PM, "Carlos Rovira" <
> carlosrovira@apache.org>
> >> wrote:
> >> >>
> >> >> Hi Alex,
> >> >>
> >> >> the issue comes from beads modifying strand className.
> This
> >> can be
> >> >> seen
> >> >> mixing states with jewel layouts. Jewel Layouts add or
> removes
> >> class
> >> >> names
> >> >> in the strand at runtime.
> >> >> Since, as you describe in the example, those changes are
> not
> >> part of
> >> >> some
> >> >> state (i.e: className.normal or className.someState, for
> >> example), the
> >> >> current class name is not stored anywhere, so when you
> change
> >> the
> >> >> state and
> >> >> comes back, Royale is not capable of recreate the right
> strand
> >> >> className
> >> >>
> >> >> You can see the issue in action if you compile the blog
> >> example about
> >> >> states [1]
> >> >>
> >> >>
> >> >>
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fblog%2FBE0008_Using_View_States_to_show_or_hide_content&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=INXSBxWAPgbRaIoe1SH6cUjGedyKDkMhmtqVEO%2FTr5k%3D&reserved=0
> >> >>
> >> >> Compile the example and run (online version works ok due
> to it
> >> was
> >> >> published when the work was in unfinished stated)
> >> >>
> >> >> Then push the button to change state from login form to
> result
> >> screen
> >> >> and
> >> >> push the button back to go to the other state. You'll
> see the
> >> layout
> >> >> is not
> >> >> equal. If check the html in the broswer, you'll find
> class
> >> names are
> >> >> lost
> >> >> between state changes.
> >> >>
> >> >> What do you think would be a good solution to this
> problem?
> >> >>
> >> >> thanks
> >> >>
> >> >> Carlos
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> El vie., 14 sept. 2018 a las 18:23, Alex Harui
> >> >> (<ah...@adobe.com.invalid>)
> >> >> escribió:
> >> >>
> >> >> > Regarding class selectors and states, I guess I don't
> >> understand the
> >> >> > issue. The code behind Royale (and Flex) states
> should be
> >> >> capturing values
> >> >> > of properties changed by the state before they get
> changed,
> >> then
> >> >> restoring
> >> >> > those properties. IOW, if you were to have
> >> >> >
> >> >> > <js:states>
> >> >> > <js:state name="normal" />
> >> >> > <js:state name="important" />
> >> >> > <js:states>
> >> >> > <j:Button id="myButton" emphasis.normal="primary"
> >> >> > emphasis.important="emphasized" />
> >> >> >
> >> >> > Then the myButton.emphasis="primary" at startup and
> when
> >> the state
> >> >> > changes to "important" the States impl should read
> >> >> myButton.emphasis and
> >> >> > store that value away before setting
> >> >> myButton.emphasis="emphasized". Then,
> >> >> > when the state changes back to "normal", the States
> impl
> >> should set
> >> >> > myButton.emphasis="primary" again.
> >> >> >
> >> >> > In the implementation for the emphasis property, if it
> >> involves
> >> >> changing
> >> >> > classLists, the implementation must do so in a way that
> >> handles
> >> >> having the
> >> >> > emphasis property changes at runtime. The States impl
> isn't
> >> really
> >> >> doing
> >> >> > anything application developer code might do, so the
> >> implementation
> >> >> must
> >> >> > support properties being set and re-set.
> >> >> >
> >> >> --
> >> >> Carlos Rovira
> >> >>
> >> >>
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=8gWdCS3xEEoApBwx%2FkqFn2pcF0JVHeeQ0VZ7Ffhmbfg%3D&reserved=0
> >> >>
> >> >>
> >> >>
> >> >
> >> > --
> >> > Carlos Rovira
> >> >
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=8gWdCS3xEEoApBwx%2FkqFn2pcF0JVHeeQ0VZ7Ffhmbfg%3D&reserved=0
> >> >
> >> >
> >>
> >> --
> >> Carlos Rovira
> >>
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=8gWdCS3xEEoApBwx%2FkqFn2pcF0JVHeeQ0VZ7Ffhmbfg%3D&reserved=0
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=8gWdCS3xEEoApBwx%2FkqFn2pcF0JVHeeQ0VZ7Ffhmbfg%3D&reserved=0
> >
> >
>
> --
> Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480510945&sdata=ASYDwQMSRBw3MqwIek8An7u0%2F8GNUSpS0B%2B7Y2Xd%2FHk%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: States problem [was: Re: Royale Transitions, Effects, States
infrastructure]
Posted by Alex Harui <ah...@adobe.com.INVALID>.
In Basic ContainerBase events are dispatched as children are added. The Basic Layouts listen for those events (in theory).
HTH,
-Alex
On 9/16/18, 4:10 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
you said: "It sounds like an event like childrenAdded is not being
dispatched by the component or not being picked up by the layout. It might
be easier to debug with a non-States example first"
But I don't really know what I'm looking for, can you develop more about
this?, I see in View and Container we have this comment
// - why was this added here? childrenAdded(); //?? Is this necessary since
MXMLDataInterpreter will already have called it
I tried to add childrenAdded but nothing changes, what it indicated that
I'm going a bit blind with this.
So I need to understand first if I'm looking for something related to
"childrenAdded" (or was only named as an example in the phrase), and if so
explain the connection between the container - the event - the layout. What
scares me is that the first time is added, all goes ok, but the second
time, is added, it's not. The difference is the instance is already
created, so it seems a problem about process again all beads right?
I'm done for today.
thanks
El lun., 17 sept. 2018 a las 0:02, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
>
> seems a bug in Layouts or UIBase/Container. I'll try to find it.
>
> this is the test case that make it fail. Add/remove/add the Card, makes
> the second time the card doesn't get the proper class Names as with states.
> I'll try to
>
> <j:Application xmlns:fx="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=M0p%2FTNB3Wpjq7CT%2FQ%2Fp0OqNcQg2evuGzFhTFbqiGI2E%3D&reserved=0"
> xmlns:j="library://ns.apache.org/royale/jewel"
> xmlns:js="library://ns.apache.org/royale/basic"
> xmlns:html="library://ns.apache.org/royale/html">
> <fx:Script>
> <![CDATA[
> import org.apache.royale.jewel.Card;
>
> public var card:Card = new Card();
>
> private function addCard():void
> {
> addElement(card);
> }
>
> private function removeCard():void
> {
> removeElement(card);
> }
> ]]>
> </fx:Script>
>
> <j:initialView>
> <j:View id="view" >
> <j:beads>
> <j:VerticalLayout/>
> </j:beads>
> <j:Button text="add card" click="addCard()" />
> <j:Button text="remove card" click="removeCard()"/>
> </j:View>
> </j:initialView>
>
> </j:Application>
>
> El dom., 16 sept. 2018 a las 4:22, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> Hi Carlos,
>>
>> That sounds like a bug in the layouts or UIBase/Containers.
>>
>> The non-States equivalent of this scenario should be, instead of setting
>> currentState on a button, to instead call addElement/removeElement on
>> loginForm and loggedInForm.
>>
>> It sounds like an event like childrenAdded is not being dispatched by the
>> component or not being picked up by the layout. It might be easier to
>> debug with a non-States example first. And if non-States works but it
>> doesn't with States then we know we have to debug the specific state
>> apply-ing logic.
>>
>> HTH,
>> -Alex
>>
>> On 9/15/18, 8:49 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> Hi Alex,
>>
>> checking the States example, I can confirm that changing the demo to
>> use
>> dot notation works perfect. I mean this code:
>>
>> <j:Card id="loginForm" *visible="true"
>> visible.loggedIn="false"*>
>> ...
>> </j:Card>
>>
>> <j:Card id="loggedInForm"* visible="false"
>> visible.loggedIn="true"*>
>> ....
>> </j:Card>
>>
>> *But* using the other format:
>>
>> <j:Card id="loginForm"* includeIn="login"*>
>> ...
>> </j:Card>
>>
>> <j:Card id="loggedInForm"* includeIn="loggedIn"*>
>> ...
>> </j:Card>
>>
>> make the first time the html generate is:
>>
>> <div id="loginForm"* class="jewel card layout vertical
>> gap-3x3px"*>
>>
>> but coming back from loggedIn we get:
>>
>> <div id="loginForm" *class="jewel card"*>
>>
>> This *layout vertical gap-3x3px* is set in the strand by
>> VerticalLayout
>> bead.
>>
>> What means for me that beads are not processed again in the process of
>> states recreation.
>>
>> But, bonus is that something similar happens recreating PopUps (as I
>> said
>> with the case of the basic combobox popup)
>>
>> Make this sense?
>>
>> Thanks
>>
>> Carlos
>>
>>
>>
>>
>>
>> El sáb., 15 sept. 2018 a las 17:24, Carlos Rovira (<
>> carlosrovira@apache.org>)
>> escribió:
>>
>> > Hi Alex,
>> >
>> > El sáb., 15 sept. 2018 a las 1:00, Alex Harui
>> (<ah...@adobe.com.invalid>)
>> > escribió:
>> >
>> >> Hi Carlos,
>> >>
>> >> I didn't look at your example yet, but I point out that this may
>> not be
>> >> an issue with States.
>> >
>> >
>> > it's possible.
>> >
>> >
>> >> Currently the States support can only add and remove components
>> and set
>> >> properties on components. So my point is that any application
>> developer
>> >> can do the same thing in their business logic. If a Jewel
>> component cannot
>> >> be exactly restored from a set of properties, that is a problem to
>> solve
>> >> regardless of States.
>> >>
>> >
>> > ok.
>> >
>> >
>> >>
>> >> The set of classNames should be directly mapped to one or more
>> >> properties. I thought that was why you wanted the classList API,
>> so that
>> >> various Jewel properties could add/remove class selectors from the
>> >> classList.
>> >>
>> >
>> > The objective of a class list api is to be able to add
>> > and/remove/toggle/check a class selector easily in a component.
>> Don't
>> > understand the sentence "The set of classNames should be directly
>> mapped to
>> > one or more properties".
>> >
>> >
>> >> Maybe we should discuss a simple scenario without states. If I
>> take a
>> >> Jewel component or container and write some AS to change
>> properties or
>> >> add/remove children and then restore it back to the original and
>> it doesn't
>> >> look the same, what part of the Royale framework is preventing
>> that from
>> >> happening?
>> >>
>> >
>> > ok, change properties is easy, but what do you mean with restore?,
>> how do
>> > you do that?
>> >
>> > Discussing this I remember that I found the same effect adding and
>> > removing a PopUp, in concrete the combobox popup.
>> > In Basic, the list popup in the ComboBox is created and then
>> changed from
>> > visible to invisible. In Jewel I had to change it to create and
>> remove the
>> > list each time, since only the first time the list was created with
>> the
>> > right class selectors. and then when made invisible, and visible
>> again, the
>> > list change the layout from vertical to horizontal, what means that
>> class
>> > selectors was changed.
>> >
>> > In the States problem, we had two versions of the demo, one based on
>> > "indludeIn" and other based on dot state notation (visible.state1).
>> I think
>> > first fail and second was doing things right.
>> >
>> > I'll take a look to see if I find the problem.
>> >
>> >
>> >> Thoughts?
>> >> -Alex
>> >>
>> >> On 9/14/18, 3:29 PM, "Carlos Rovira" <ca...@apache.org>
>> wrote:
>> >>
>> >> Hi Alex,
>> >>
>> >> the issue comes from beads modifying strand className. This
>> can be
>> >> seen
>> >> mixing states with jewel layouts. Jewel Layouts add or removes
>> class
>> >> names
>> >> in the strand at runtime.
>> >> Since, as you describe in the example, those changes are not
>> part of
>> >> some
>> >> state (i.e: className.normal or className.someState, for
>> example), the
>> >> current class name is not stored anywhere, so when you change
>> the
>> >> state and
>> >> comes back, Royale is not capable of recreate the right strand
>> >> className
>> >>
>> >> You can see the issue in action if you compile the blog
>> example about
>> >> states [1]
>> >>
>> >>
>> >>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fblog%2FBE0008_Using_View_States_to_show_or_hide_content&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=INXSBxWAPgbRaIoe1SH6cUjGedyKDkMhmtqVEO%2FTr5k%3D&reserved=0
>> >>
>> >> Compile the example and run (online version works ok due to it
>> was
>> >> published when the work was in unfinished stated)
>> >>
>> >> Then push the button to change state from login form to result
>> screen
>> >> and
>> >> push the button back to go to the other state. You'll see the
>> layout
>> >> is not
>> >> equal. If check the html in the broswer, you'll find class
>> names are
>> >> lost
>> >> between state changes.
>> >>
>> >> What do you think would be a good solution to this problem?
>> >>
>> >> thanks
>> >>
>> >> Carlos
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> El vie., 14 sept. 2018 a las 18:23, Alex Harui
>> >> (<ah...@adobe.com.invalid>)
>> >> escribió:
>> >>
>> >> > Regarding class selectors and states, I guess I don't
>> understand the
>> >> > issue. The code behind Royale (and Flex) states should be
>> >> capturing values
>> >> > of properties changed by the state before they get changed,
>> then
>> >> restoring
>> >> > those properties. IOW, if you were to have
>> >> >
>> >> > <js:states>
>> >> > <js:state name="normal" />
>> >> > <js:state name="important" />
>> >> > <js:states>
>> >> > <j:Button id="myButton" emphasis.normal="primary"
>> >> > emphasis.important="emphasized" />
>> >> >
>> >> > Then the myButton.emphasis="primary" at startup and when
>> the state
>> >> > changes to "important" the States impl should read
>> >> myButton.emphasis and
>> >> > store that value away before setting
>> >> myButton.emphasis="emphasized". Then,
>> >> > when the state changes back to "normal", the States impl
>> should set
>> >> > myButton.emphasis="primary" again.
>> >> >
>> >> > In the implementation for the emphasis property, if it
>> involves
>> >> changing
>> >> > classLists, the implementation must do so in a way that
>> handles
>> >> having the
>> >> > emphasis property changes at runtime. The States impl isn't
>> really
>> >> doing
>> >> > anything application developer code might do, so the
>> implementation
>> >> must
>> >> > support properties being set and re-set.
>> >> >
>> >> --
>> >> Carlos Rovira
>> >>
>> >>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=8gWdCS3xEEoApBwx%2FkqFn2pcF0JVHeeQ0VZ7Ffhmbfg%3D&reserved=0
>> >>
>> >>
>> >>
>> >
>> > --
>> > Carlos Rovira
>> >
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=8gWdCS3xEEoApBwx%2FkqFn2pcF0JVHeeQ0VZ7Ffhmbfg%3D&reserved=0
>> >
>> >
>>
>> --
>> Carlos Rovira
>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=8gWdCS3xEEoApBwx%2FkqFn2pcF0JVHeeQ0VZ7Ffhmbfg%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=8gWdCS3xEEoApBwx%2FkqFn2pcF0JVHeeQ0VZ7Ffhmbfg%3D&reserved=0
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480510945&sdata=ASYDwQMSRBw3MqwIek8An7u0%2F8GNUSpS0B%2B7Y2Xd%2FHk%3D&reserved=0
Re: States problem [was: Re: Royale Transitions, Effects, States infrastructure]
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
you said: "It sounds like an event like childrenAdded is not being
dispatched by the component or not being picked up by the layout. It might
be easier to debug with a non-States example first"
But I don't really know what I'm looking for, can you develop more about
this?, I see in View and Container we have this comment
// - why was this added here? childrenAdded(); //?? Is this necessary since
MXMLDataInterpreter will already have called it
I tried to add childrenAdded but nothing changes, what it indicated that
I'm going a bit blind with this.
So I need to understand first if I'm looking for something related to
"childrenAdded" (or was only named as an example in the phrase), and if so
explain the connection between the container - the event - the layout. What
scares me is that the first time is added, all goes ok, but the second
time, is added, it's not. The difference is the instance is already
created, so it seems a problem about process again all beads right?
I'm done for today.
thanks
El lun., 17 sept. 2018 a las 0:02, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
>
> seems a bug in Layouts or UIBase/Container. I'll try to find it.
>
> this is the test case that make it fail. Add/remove/add the Card, makes
> the second time the card doesn't get the proper class Names as with states.
> I'll try to
>
> <j:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
> xmlns:j="library://ns.apache.org/royale/jewel"
> xmlns:js="library://ns.apache.org/royale/basic"
> xmlns:html="library://ns.apache.org/royale/html">
> <fx:Script>
> <![CDATA[
> import org.apache.royale.jewel.Card;
>
> public var card:Card = new Card();
>
> private function addCard():void
> {
> addElement(card);
> }
>
> private function removeCard():void
> {
> removeElement(card);
> }
> ]]>
> </fx:Script>
>
> <j:initialView>
> <j:View id="view" >
> <j:beads>
> <j:VerticalLayout/>
> </j:beads>
> <j:Button text="add card" click="addCard()" />
> <j:Button text="remove card" click="removeCard()"/>
> </j:View>
> </j:initialView>
>
> </j:Application>
>
> El dom., 16 sept. 2018 a las 4:22, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> Hi Carlos,
>>
>> That sounds like a bug in the layouts or UIBase/Containers.
>>
>> The non-States equivalent of this scenario should be, instead of setting
>> currentState on a button, to instead call addElement/removeElement on
>> loginForm and loggedInForm.
>>
>> It sounds like an event like childrenAdded is not being dispatched by the
>> component or not being picked up by the layout. It might be easier to
>> debug with a non-States example first. And if non-States works but it
>> doesn't with States then we know we have to debug the specific state
>> apply-ing logic.
>>
>> HTH,
>> -Alex
>>
>> On 9/15/18, 8:49 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> Hi Alex,
>>
>> checking the States example, I can confirm that changing the demo to
>> use
>> dot notation works perfect. I mean this code:
>>
>> <j:Card id="loginForm" *visible="true"
>> visible.loggedIn="false"*>
>> ...
>> </j:Card>
>>
>> <j:Card id="loggedInForm"* visible="false"
>> visible.loggedIn="true"*>
>> ....
>> </j:Card>
>>
>> *But* using the other format:
>>
>> <j:Card id="loginForm"* includeIn="login"*>
>> ...
>> </j:Card>
>>
>> <j:Card id="loggedInForm"* includeIn="loggedIn"*>
>> ...
>> </j:Card>
>>
>> make the first time the html generate is:
>>
>> <div id="loginForm"* class="jewel card layout vertical
>> gap-3x3px"*>
>>
>> but coming back from loggedIn we get:
>>
>> <div id="loginForm" *class="jewel card"*>
>>
>> This *layout vertical gap-3x3px* is set in the strand by
>> VerticalLayout
>> bead.
>>
>> What means for me that beads are not processed again in the process of
>> states recreation.
>>
>> But, bonus is that something similar happens recreating PopUps (as I
>> said
>> with the case of the basic combobox popup)
>>
>> Make this sense?
>>
>> Thanks
>>
>> Carlos
>>
>>
>>
>>
>>
>> El sáb., 15 sept. 2018 a las 17:24, Carlos Rovira (<
>> carlosrovira@apache.org>)
>> escribió:
>>
>> > Hi Alex,
>> >
>> > El sáb., 15 sept. 2018 a las 1:00, Alex Harui
>> (<ah...@adobe.com.invalid>)
>> > escribió:
>> >
>> >> Hi Carlos,
>> >>
>> >> I didn't look at your example yet, but I point out that this may
>> not be
>> >> an issue with States.
>> >
>> >
>> > it's possible.
>> >
>> >
>> >> Currently the States support can only add and remove components
>> and set
>> >> properties on components. So my point is that any application
>> developer
>> >> can do the same thing in their business logic. If a Jewel
>> component cannot
>> >> be exactly restored from a set of properties, that is a problem to
>> solve
>> >> regardless of States.
>> >>
>> >
>> > ok.
>> >
>> >
>> >>
>> >> The set of classNames should be directly mapped to one or more
>> >> properties. I thought that was why you wanted the classList API,
>> so that
>> >> various Jewel properties could add/remove class selectors from the
>> >> classList.
>> >>
>> >
>> > The objective of a class list api is to be able to add
>> > and/remove/toggle/check a class selector easily in a component.
>> Don't
>> > understand the sentence "The set of classNames should be directly
>> mapped to
>> > one or more properties".
>> >
>> >
>> >> Maybe we should discuss a simple scenario without states. If I
>> take a
>> >> Jewel component or container and write some AS to change
>> properties or
>> >> add/remove children and then restore it back to the original and
>> it doesn't
>> >> look the same, what part of the Royale framework is preventing
>> that from
>> >> happening?
>> >>
>> >
>> > ok, change properties is easy, but what do you mean with restore?,
>> how do
>> > you do that?
>> >
>> > Discussing this I remember that I found the same effect adding and
>> > removing a PopUp, in concrete the combobox popup.
>> > In Basic, the list popup in the ComboBox is created and then
>> changed from
>> > visible to invisible. In Jewel I had to change it to create and
>> remove the
>> > list each time, since only the first time the list was created with
>> the
>> > right class selectors. and then when made invisible, and visible
>> again, the
>> > list change the layout from vertical to horizontal, what means that
>> class
>> > selectors was changed.
>> >
>> > In the States problem, we had two versions of the demo, one based on
>> > "indludeIn" and other based on dot state notation (visible.state1).
>> I think
>> > first fail and second was doing things right.
>> >
>> > I'll take a look to see if I find the problem.
>> >
>> >
>> >> Thoughts?
>> >> -Alex
>> >>
>> >> On 9/14/18, 3:29 PM, "Carlos Rovira" <ca...@apache.org>
>> wrote:
>> >>
>> >> Hi Alex,
>> >>
>> >> the issue comes from beads modifying strand className. This
>> can be
>> >> seen
>> >> mixing states with jewel layouts. Jewel Layouts add or removes
>> class
>> >> names
>> >> in the strand at runtime.
>> >> Since, as you describe in the example, those changes are not
>> part of
>> >> some
>> >> state (i.e: className.normal or className.someState, for
>> example), the
>> >> current class name is not stored anywhere, so when you change
>> the
>> >> state and
>> >> comes back, Royale is not capable of recreate the right strand
>> >> className
>> >>
>> >> You can see the issue in action if you compile the blog
>> example about
>> >> states [1]
>> >>
>> >>
>> >>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fblog%2FBE0008_Using_View_States_to_show_or_hide_content&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992266487&sdata=T5KqlcfJnzeLhMottox6U0l3%2FyvtcywEhX6IHdxQplg%3D&reserved=0
>> >>
>> >> Compile the example and run (online version works ok due to it
>> was
>> >> published when the work was in unfinished stated)
>> >>
>> >> Then push the button to change state from login form to result
>> screen
>> >> and
>> >> push the button back to go to the other state. You'll see the
>> layout
>> >> is not
>> >> equal. If check the html in the broswer, you'll find class
>> names are
>> >> lost
>> >> between state changes.
>> >>
>> >> What do you think would be a good solution to this problem?
>> >>
>> >> thanks
>> >>
>> >> Carlos
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> El vie., 14 sept. 2018 a las 18:23, Alex Harui
>> >> (<ah...@adobe.com.invalid>)
>> >> escribió:
>> >>
>> >> > Regarding class selectors and states, I guess I don't
>> understand the
>> >> > issue. The code behind Royale (and Flex) states should be
>> >> capturing values
>> >> > of properties changed by the state before they get changed,
>> then
>> >> restoring
>> >> > those properties. IOW, if you were to have
>> >> >
>> >> > <js:states>
>> >> > <js:state name="normal" />
>> >> > <js:state name="important" />
>> >> > <js:states>
>> >> > <j:Button id="myButton" emphasis.normal="primary"
>> >> > emphasis.important="emphasized" />
>> >> >
>> >> > Then the myButton.emphasis="primary" at startup and when
>> the state
>> >> > changes to "important" the States impl should read
>> >> myButton.emphasis and
>> >> > store that value away before setting
>> >> myButton.emphasis="emphasized". Then,
>> >> > when the state changes back to "normal", the States impl
>> should set
>> >> > myButton.emphasis="primary" again.
>> >> >
>> >> > In the implementation for the emphasis property, if it
>> involves
>> >> changing
>> >> > classLists, the implementation must do so in a way that
>> handles
>> >> having the
>> >> > emphasis property changes at runtime. The States impl isn't
>> really
>> >> doing
>> >> > anything application developer code might do, so the
>> implementation
>> >> must
>> >> > support properties being set and re-set.
>> >> >
>> >> --
>> >> Carlos Rovira
>> >>
>> >>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992276496&sdata=PjL2j0Fy8BAb4Av9Nq0u2Ju1xcLGg%2B38dD1E3fQkVXY%3D&reserved=0
>> >>
>> >>
>> >>
>> >
>> > --
>> > Carlos Rovira
>> >
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992276496&sdata=PjL2j0Fy8BAb4Av9Nq0u2Ju1xcLGg%2B38dD1E3fQkVXY%3D&reserved=0
>> >
>> >
>>
>> --
>> Carlos Rovira
>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992276496&sdata=PjL2j0Fy8BAb4Av9Nq0u2Ju1xcLGg%2B38dD1E3fQkVXY%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: States problem [was: Re: Royale Transitions, Effects, States infrastructure]
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
seems a bug in Layouts or UIBase/Container. I'll try to find it.
this is the test case that make it fail. Add/remove/add the Card, makes the
second time the card doesn't get the proper class Names as with states.
I'll try to
<j:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:j="library://ns.apache.org/royale/jewel"
xmlns:js="library://ns.apache.org/royale/basic"
xmlns:html="library://ns.apache.org/royale/html">
<fx:Script>
<![CDATA[
import org.apache.royale.jewel.Card;
public var card:Card = new Card();
private function addCard():void
{
addElement(card);
}
private function removeCard():void
{
removeElement(card);
}
]]>
</fx:Script>
<j:initialView>
<j:View id="view" >
<j:beads>
<j:VerticalLayout/>
</j:beads>
<j:Button text="add card" click="addCard()" />
<j:Button text="remove card" click="removeCard()"/>
</j:View>
</j:initialView>
</j:Application>
El dom., 16 sept. 2018 a las 4:22, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Hi Carlos,
>
> That sounds like a bug in the layouts or UIBase/Containers.
>
> The non-States equivalent of this scenario should be, instead of setting
> currentState on a button, to instead call addElement/removeElement on
> loginForm and loggedInForm.
>
> It sounds like an event like childrenAdded is not being dispatched by the
> component or not being picked up by the layout. It might be easier to
> debug with a non-States example first. And if non-States works but it
> doesn't with States then we know we have to debug the specific state
> apply-ing logic.
>
> HTH,
> -Alex
>
> On 9/15/18, 8:49 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> checking the States example, I can confirm that changing the demo to
> use
> dot notation works perfect. I mean this code:
>
> <j:Card id="loginForm" *visible="true"
> visible.loggedIn="false"*>
> ...
> </j:Card>
>
> <j:Card id="loggedInForm"* visible="false"
> visible.loggedIn="true"*>
> ....
> </j:Card>
>
> *But* using the other format:
>
> <j:Card id="loginForm"* includeIn="login"*>
> ...
> </j:Card>
>
> <j:Card id="loggedInForm"* includeIn="loggedIn"*>
> ...
> </j:Card>
>
> make the first time the html generate is:
>
> <div id="loginForm"* class="jewel card layout vertical
> gap-3x3px"*>
>
> but coming back from loggedIn we get:
>
> <div id="loginForm" *class="jewel card"*>
>
> This *layout vertical gap-3x3px* is set in the strand by VerticalLayout
> bead.
>
> What means for me that beads are not processed again in the process of
> states recreation.
>
> But, bonus is that something similar happens recreating PopUps (as I
> said
> with the case of the basic combobox popup)
>
> Make this sense?
>
> Thanks
>
> Carlos
>
>
>
>
>
> El sáb., 15 sept. 2018 a las 17:24, Carlos Rovira (<
> carlosrovira@apache.org>)
> escribió:
>
> > Hi Alex,
> >
> > El sáb., 15 sept. 2018 a las 1:00, Alex Harui
> (<ah...@adobe.com.invalid>)
> > escribió:
> >
> >> Hi Carlos,
> >>
> >> I didn't look at your example yet, but I point out that this may
> not be
> >> an issue with States.
> >
> >
> > it's possible.
> >
> >
> >> Currently the States support can only add and remove components
> and set
> >> properties on components. So my point is that any application
> developer
> >> can do the same thing in their business logic. If a Jewel
> component cannot
> >> be exactly restored from a set of properties, that is a problem to
> solve
> >> regardless of States.
> >>
> >
> > ok.
> >
> >
> >>
> >> The set of classNames should be directly mapped to one or more
> >> properties. I thought that was why you wanted the classList API,
> so that
> >> various Jewel properties could add/remove class selectors from the
> >> classList.
> >>
> >
> > The objective of a class list api is to be able to add
> > and/remove/toggle/check a class selector easily in a component. Don't
> > understand the sentence "The set of classNames should be directly
> mapped to
> > one or more properties".
> >
> >
> >> Maybe we should discuss a simple scenario without states. If I
> take a
> >> Jewel component or container and write some AS to change properties
> or
> >> add/remove children and then restore it back to the original and it
> doesn't
> >> look the same, what part of the Royale framework is preventing that
> from
> >> happening?
> >>
> >
> > ok, change properties is easy, but what do you mean with restore?,
> how do
> > you do that?
> >
> > Discussing this I remember that I found the same effect adding and
> > removing a PopUp, in concrete the combobox popup.
> > In Basic, the list popup in the ComboBox is created and then changed
> from
> > visible to invisible. In Jewel I had to change it to create and
> remove the
> > list each time, since only the first time the list was created with
> the
> > right class selectors. and then when made invisible, and visible
> again, the
> > list change the layout from vertical to horizontal, what means that
> class
> > selectors was changed.
> >
> > In the States problem, we had two versions of the demo, one based on
> > "indludeIn" and other based on dot state notation (visible.state1).
> I think
> > first fail and second was doing things right.
> >
> > I'll take a look to see if I find the problem.
> >
> >
> >> Thoughts?
> >> -Alex
> >>
> >> On 9/14/18, 3:29 PM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >>
> >> Hi Alex,
> >>
> >> the issue comes from beads modifying strand className. This can
> be
> >> seen
> >> mixing states with jewel layouts. Jewel Layouts add or removes
> class
> >> names
> >> in the strand at runtime.
> >> Since, as you describe in the example, those changes are not
> part of
> >> some
> >> state (i.e: className.normal or className.someState, for
> example), the
> >> current class name is not stored anywhere, so when you change
> the
> >> state and
> >> comes back, Royale is not capable of recreate the right strand
> >> className
> >>
> >> You can see the issue in action if you compile the blog example
> about
> >> states [1]
> >>
> >>
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fblog%2FBE0008_Using_View_States_to_show_or_hide_content&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992266487&sdata=T5KqlcfJnzeLhMottox6U0l3%2FyvtcywEhX6IHdxQplg%3D&reserved=0
> >>
> >> Compile the example and run (online version works ok due to it
> was
> >> published when the work was in unfinished stated)
> >>
> >> Then push the button to change state from login form to result
> screen
> >> and
> >> push the button back to go to the other state. You'll see the
> layout
> >> is not
> >> equal. If check the html in the broswer, you'll find class
> names are
> >> lost
> >> between state changes.
> >>
> >> What do you think would be a good solution to this problem?
> >>
> >> thanks
> >>
> >> Carlos
> >>
> >>
> >>
> >>
> >>
> >> El vie., 14 sept. 2018 a las 18:23, Alex Harui
> >> (<ah...@adobe.com.invalid>)
> >> escribió:
> >>
> >> > Regarding class selectors and states, I guess I don't
> understand the
> >> > issue. The code behind Royale (and Flex) states should be
> >> capturing values
> >> > of properties changed by the state before they get changed,
> then
> >> restoring
> >> > those properties. IOW, if you were to have
> >> >
> >> > <js:states>
> >> > <js:state name="normal" />
> >> > <js:state name="important" />
> >> > <js:states>
> >> > <j:Button id="myButton" emphasis.normal="primary"
> >> > emphasis.important="emphasized" />
> >> >
> >> > Then the myButton.emphasis="primary" at startup and when the
> state
> >> > changes to "important" the States impl should read
> >> myButton.emphasis and
> >> > store that value away before setting
> >> myButton.emphasis="emphasized". Then,
> >> > when the state changes back to "normal", the States impl
> should set
> >> > myButton.emphasis="primary" again.
> >> >
> >> > In the implementation for the emphasis property, if it
> involves
> >> changing
> >> > classLists, the implementation must do so in a way that
> handles
> >> having the
> >> > emphasis property changes at runtime. The States impl isn't
> really
> >> doing
> >> > anything application developer code might do, so the
> implementation
> >> must
> >> > support properties being set and re-set.
> >> >
> >> --
> >> Carlos Rovira
> >>
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992276496&sdata=PjL2j0Fy8BAb4Av9Nq0u2Ju1xcLGg%2B38dD1E3fQkVXY%3D&reserved=0
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992276496&sdata=PjL2j0Fy8BAb4Av9Nq0u2Ju1xcLGg%2B38dD1E3fQkVXY%3D&reserved=0
> >
> >
>
> --
> Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992276496&sdata=PjL2j0Fy8BAb4Av9Nq0u2Ju1xcLGg%2B38dD1E3fQkVXY%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: States problem [was: Re: Royale Transitions, Effects, States
infrastructure]
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
That sounds like a bug in the layouts or UIBase/Containers.
The non-States equivalent of this scenario should be, instead of setting currentState on a button, to instead call addElement/removeElement on loginForm and loggedInForm.
It sounds like an event like childrenAdded is not being dispatched by the component or not being picked up by the layout. It might be easier to debug with a non-States example first. And if non-States works but it doesn't with States then we know we have to debug the specific state apply-ing logic.
HTH,
-Alex
On 9/15/18, 8:49 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
checking the States example, I can confirm that changing the demo to use
dot notation works perfect. I mean this code:
<j:Card id="loginForm" *visible="true" visible.loggedIn="false"*>
...
</j:Card>
<j:Card id="loggedInForm"* visible="false"
visible.loggedIn="true"*>
....
</j:Card>
*But* using the other format:
<j:Card id="loginForm"* includeIn="login"*>
...
</j:Card>
<j:Card id="loggedInForm"* includeIn="loggedIn"*>
...
</j:Card>
make the first time the html generate is:
<div id="loginForm"* class="jewel card layout vertical gap-3x3px"*>
but coming back from loggedIn we get:
<div id="loginForm" *class="jewel card"*>
This *layout vertical gap-3x3px* is set in the strand by VerticalLayout
bead.
What means for me that beads are not processed again in the process of
states recreation.
But, bonus is that something similar happens recreating PopUps (as I said
with the case of the basic combobox popup)
Make this sense?
Thanks
Carlos
El sáb., 15 sept. 2018 a las 17:24, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
>
> El sáb., 15 sept. 2018 a las 1:00, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> Hi Carlos,
>>
>> I didn't look at your example yet, but I point out that this may not be
>> an issue with States.
>
>
> it's possible.
>
>
>> Currently the States support can only add and remove components and set
>> properties on components. So my point is that any application developer
>> can do the same thing in their business logic. If a Jewel component cannot
>> be exactly restored from a set of properties, that is a problem to solve
>> regardless of States.
>>
>
> ok.
>
>
>>
>> The set of classNames should be directly mapped to one or more
>> properties. I thought that was why you wanted the classList API, so that
>> various Jewel properties could add/remove class selectors from the
>> classList.
>>
>
> The objective of a class list api is to be able to add
> and/remove/toggle/check a class selector easily in a component. Don't
> understand the sentence "The set of classNames should be directly mapped to
> one or more properties".
>
>
>> Maybe we should discuss a simple scenario without states. If I take a
>> Jewel component or container and write some AS to change properties or
>> add/remove children and then restore it back to the original and it doesn't
>> look the same, what part of the Royale framework is preventing that from
>> happening?
>>
>
> ok, change properties is easy, but what do you mean with restore?, how do
> you do that?
>
> Discussing this I remember that I found the same effect adding and
> removing a PopUp, in concrete the combobox popup.
> In Basic, the list popup in the ComboBox is created and then changed from
> visible to invisible. In Jewel I had to change it to create and remove the
> list each time, since only the first time the list was created with the
> right class selectors. and then when made invisible, and visible again, the
> list change the layout from vertical to horizontal, what means that class
> selectors was changed.
>
> In the States problem, we had two versions of the demo, one based on
> "indludeIn" and other based on dot state notation (visible.state1). I think
> first fail and second was doing things right.
>
> I'll take a look to see if I find the problem.
>
>
>> Thoughts?
>> -Alex
>>
>> On 9/14/18, 3:29 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> Hi Alex,
>>
>> the issue comes from beads modifying strand className. This can be
>> seen
>> mixing states with jewel layouts. Jewel Layouts add or removes class
>> names
>> in the strand at runtime.
>> Since, as you describe in the example, those changes are not part of
>> some
>> state (i.e: className.normal or className.someState, for example), the
>> current class name is not stored anywhere, so when you change the
>> state and
>> comes back, Royale is not capable of recreate the right strand
>> className
>>
>> You can see the issue in action if you compile the blog example about
>> states [1]
>>
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fblog%2FBE0008_Using_View_States_to_show_or_hide_content&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992266487&sdata=T5KqlcfJnzeLhMottox6U0l3%2FyvtcywEhX6IHdxQplg%3D&reserved=0
>>
>> Compile the example and run (online version works ok due to it was
>> published when the work was in unfinished stated)
>>
>> Then push the button to change state from login form to result screen
>> and
>> push the button back to go to the other state. You'll see the layout
>> is not
>> equal. If check the html in the broswer, you'll find class names are
>> lost
>> between state changes.
>>
>> What do you think would be a good solution to this problem?
>>
>> thanks
>>
>> Carlos
>>
>>
>>
>>
>>
>> El vie., 14 sept. 2018 a las 18:23, Alex Harui
>> (<ah...@adobe.com.invalid>)
>> escribió:
>>
>> > Regarding class selectors and states, I guess I don't understand the
>> > issue. The code behind Royale (and Flex) states should be
>> capturing values
>> > of properties changed by the state before they get changed, then
>> restoring
>> > those properties. IOW, if you were to have
>> >
>> > <js:states>
>> > <js:state name="normal" />
>> > <js:state name="important" />
>> > <js:states>
>> > <j:Button id="myButton" emphasis.normal="primary"
>> > emphasis.important="emphasized" />
>> >
>> > Then the myButton.emphasis="primary" at startup and when the state
>> > changes to "important" the States impl should read
>> myButton.emphasis and
>> > store that value away before setting
>> myButton.emphasis="emphasized". Then,
>> > when the state changes back to "normal", the States impl should set
>> > myButton.emphasis="primary" again.
>> >
>> > In the implementation for the emphasis property, if it involves
>> changing
>> > classLists, the implementation must do so in a way that handles
>> having the
>> > emphasis property changes at runtime. The States impl isn't really
>> doing
>> > anything application developer code might do, so the implementation
>> must
>> > support properties being set and re-set.
>> >
>> --
>> Carlos Rovira
>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992276496&sdata=PjL2j0Fy8BAb4Av9Nq0u2Ju1xcLGg%2B38dD1E3fQkVXY%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992276496&sdata=PjL2j0Fy8BAb4Av9Nq0u2Ju1xcLGg%2B38dD1E3fQkVXY%3D&reserved=0
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992276496&sdata=PjL2j0Fy8BAb4Av9Nq0u2Ju1xcLGg%2B38dD1E3fQkVXY%3D&reserved=0
Re: States problem [was: Re: Royale Transitions, Effects, States infrastructure]
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
checking the States example, I can confirm that changing the demo to use
dot notation works perfect. I mean this code:
<j:Card id="loginForm" *visible="true" visible.loggedIn="false"*>
...
</j:Card>
<j:Card id="loggedInForm"* visible="false"
visible.loggedIn="true"*>
....
</j:Card>
*But* using the other format:
<j:Card id="loginForm"* includeIn="login"*>
...
</j:Card>
<j:Card id="loggedInForm"* includeIn="loggedIn"*>
...
</j:Card>
make the first time the html generate is:
<div id="loginForm"* class="jewel card layout vertical gap-3x3px"*>
but coming back from loggedIn we get:
<div id="loginForm" *class="jewel card"*>
This *layout vertical gap-3x3px* is set in the strand by VerticalLayout
bead.
What means for me that beads are not processed again in the process of
states recreation.
But, bonus is that something similar happens recreating PopUps (as I said
with the case of the basic combobox popup)
Make this sense?
Thanks
Carlos
El sáb., 15 sept. 2018 a las 17:24, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
>
> El sáb., 15 sept. 2018 a las 1:00, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> Hi Carlos,
>>
>> I didn't look at your example yet, but I point out that this may not be
>> an issue with States.
>
>
> it's possible.
>
>
>> Currently the States support can only add and remove components and set
>> properties on components. So my point is that any application developer
>> can do the same thing in their business logic. If a Jewel component cannot
>> be exactly restored from a set of properties, that is a problem to solve
>> regardless of States.
>>
>
> ok.
>
>
>>
>> The set of classNames should be directly mapped to one or more
>> properties. I thought that was why you wanted the classList API, so that
>> various Jewel properties could add/remove class selectors from the
>> classList.
>>
>
> The objective of a class list api is to be able to add
> and/remove/toggle/check a class selector easily in a component. Don't
> understand the sentence "The set of classNames should be directly mapped to
> one or more properties".
>
>
>> Maybe we should discuss a simple scenario without states. If I take a
>> Jewel component or container and write some AS to change properties or
>> add/remove children and then restore it back to the original and it doesn't
>> look the same, what part of the Royale framework is preventing that from
>> happening?
>>
>
> ok, change properties is easy, but what do you mean with restore?, how do
> you do that?
>
> Discussing this I remember that I found the same effect adding and
> removing a PopUp, in concrete the combobox popup.
> In Basic, the list popup in the ComboBox is created and then changed from
> visible to invisible. In Jewel I had to change it to create and remove the
> list each time, since only the first time the list was created with the
> right class selectors. and then when made invisible, and visible again, the
> list change the layout from vertical to horizontal, what means that class
> selectors was changed.
>
> In the States problem, we had two versions of the demo, one based on
> "indludeIn" and other based on dot state notation (visible.state1). I think
> first fail and second was doing things right.
>
> I'll take a look to see if I find the problem.
>
>
>> Thoughts?
>> -Alex
>>
>> On 9/14/18, 3:29 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> Hi Alex,
>>
>> the issue comes from beads modifying strand className. This can be
>> seen
>> mixing states with jewel layouts. Jewel Layouts add or removes class
>> names
>> in the strand at runtime.
>> Since, as you describe in the example, those changes are not part of
>> some
>> state (i.e: className.normal or className.someState, for example), the
>> current class name is not stored anywhere, so when you change the
>> state and
>> comes back, Royale is not capable of recreate the right strand
>> className
>>
>> You can see the issue in action if you compile the blog example about
>> states [1]
>>
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fblog%2FBE0008_Using_View_States_to_show_or_hide_content&data=02%7C01%7Caharui%40adobe.com%7C2592599a6d224d94342b08d61a917fea%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725609577539201&sdata=NaIJmC4%2Bbhr3Ysba%2BOxsjFnmliemEWq6nHGIDkzoxwc%3D&reserved=0
>>
>> Compile the example and run (online version works ok due to it was
>> published when the work was in unfinished stated)
>>
>> Then push the button to change state from login form to result screen
>> and
>> push the button back to go to the other state. You'll see the layout
>> is not
>> equal. If check the html in the broswer, you'll find class names are
>> lost
>> between state changes.
>>
>> What do you think would be a good solution to this problem?
>>
>> thanks
>>
>> Carlos
>>
>>
>>
>>
>>
>> El vie., 14 sept. 2018 a las 18:23, Alex Harui
>> (<ah...@adobe.com.invalid>)
>> escribió:
>>
>> > Regarding class selectors and states, I guess I don't understand the
>> > issue. The code behind Royale (and Flex) states should be
>> capturing values
>> > of properties changed by the state before they get changed, then
>> restoring
>> > those properties. IOW, if you were to have
>> >
>> > <js:states>
>> > <js:state name="normal" />
>> > <js:state name="important" />
>> > <js:states>
>> > <j:Button id="myButton" emphasis.normal="primary"
>> > emphasis.important="emphasized" />
>> >
>> > Then the myButton.emphasis="primary" at startup and when the state
>> > changes to "important" the States impl should read
>> myButton.emphasis and
>> > store that value away before setting
>> myButton.emphasis="emphasized". Then,
>> > when the state changes back to "normal", the States impl should set
>> > myButton.emphasis="primary" again.
>> >
>> > In the implementation for the emphasis property, if it involves
>> changing
>> > classLists, the implementation must do so in a way that handles
>> having the
>> > emphasis property changes at runtime. The States impl isn't really
>> doing
>> > anything application developer code might do, so the implementation
>> must
>> > support properties being set and re-set.
>> >
>> --
>> Carlos Rovira
>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2592599a6d224d94342b08d61a917fea%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725609577539201&sdata=bHjSWhNbYwkhNfQbX2Q%2BQDUQWTtVXNozSTe6eHyX61Y%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: States problem [was: Re: Royale Transitions, Effects, States infrastructure]
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
El sáb., 15 sept. 2018 a las 1:00, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Hi Carlos,
>
> I didn't look at your example yet, but I point out that this may not be an
> issue with States.
it's possible.
> Currently the States support can only add and remove components and set
> properties on components. So my point is that any application developer
> can do the same thing in their business logic. If a Jewel component cannot
> be exactly restored from a set of properties, that is a problem to solve
> regardless of States.
>
ok.
>
> The set of classNames should be directly mapped to one or more
> properties. I thought that was why you wanted the classList API, so that
> various Jewel properties could add/remove class selectors from the
> classList.
>
The objective of a class list api is to be able to add
and/remove/toggle/check a class selector easily in a component. Don't
understand the sentence "The set of classNames should be directly mapped to
one or more properties".
> Maybe we should discuss a simple scenario without states. If I take a
> Jewel component or container and write some AS to change properties or
> add/remove children and then restore it back to the original and it doesn't
> look the same, what part of the Royale framework is preventing that from
> happening?
>
ok, change properties is easy, but what do you mean with restore?, how do
you do that?
Discussing this I remember that I found the same effect adding and removing
a PopUp, in concrete the combobox popup.
In Basic, the list popup in the ComboBox is created and then changed from
visible to invisible. In Jewel I had to change it to create and remove the
list each time, since only the first time the list was created with the
right class selectors. and then when made invisible, and visible again, the
list change the layout from vertical to horizontal, what means that class
selectors was changed.
In the States problem, we had two versions of the demo, one based on
"indludeIn" and other based on dot state notation (visible.state1). I think
first fail and second was doing things right.
I'll take a look to see if I find the problem.
> Thoughts?
> -Alex
>
> On 9/14/18, 3:29 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> the issue comes from beads modifying strand className. This can be seen
> mixing states with jewel layouts. Jewel Layouts add or removes class
> names
> in the strand at runtime.
> Since, as you describe in the example, those changes are not part of
> some
> state (i.e: className.normal or className.someState, for example), the
> current class name is not stored anywhere, so when you change the
> state and
> comes back, Royale is not capable of recreate the right strand
> className
>
> You can see the issue in action if you compile the blog example about
> states [1]
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fblog%2FBE0008_Using_View_States_to_show_or_hide_content&data=02%7C01%7Caharui%40adobe.com%7C2592599a6d224d94342b08d61a917fea%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725609577539201&sdata=NaIJmC4%2Bbhr3Ysba%2BOxsjFnmliemEWq6nHGIDkzoxwc%3D&reserved=0
>
> Compile the example and run (online version works ok due to it was
> published when the work was in unfinished stated)
>
> Then push the button to change state from login form to result screen
> and
> push the button back to go to the other state. You'll see the layout
> is not
> equal. If check the html in the broswer, you'll find class names are
> lost
> between state changes.
>
> What do you think would be a good solution to this problem?
>
> thanks
>
> Carlos
>
>
>
>
>
> El vie., 14 sept. 2018 a las 18:23, Alex Harui
> (<ah...@adobe.com.invalid>)
> escribió:
>
> > Regarding class selectors and states, I guess I don't understand the
> > issue. The code behind Royale (and Flex) states should be capturing
> values
> > of properties changed by the state before they get changed, then
> restoring
> > those properties. IOW, if you were to have
> >
> > <js:states>
> > <js:state name="normal" />
> > <js:state name="important" />
> > <js:states>
> > <j:Button id="myButton" emphasis.normal="primary"
> > emphasis.important="emphasized" />
> >
> > Then the myButton.emphasis="primary" at startup and when the state
> > changes to "important" the States impl should read myButton.emphasis
> and
> > store that value away before setting
> myButton.emphasis="emphasized". Then,
> > when the state changes back to "normal", the States impl should set
> > myButton.emphasis="primary" again.
> >
> > In the implementation for the emphasis property, if it involves
> changing
> > classLists, the implementation must do so in a way that handles
> having the
> > emphasis property changes at runtime. The States impl isn't really
> doing
> > anything application developer code might do, so the implementation
> must
> > support properties being set and re-set.
> >
> --
> Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2592599a6d224d94342b08d61a917fea%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725609577539201&sdata=bHjSWhNbYwkhNfQbX2Q%2BQDUQWTtVXNozSTe6eHyX61Y%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: States problem [was: Re: Royale Transitions, Effects, States
infrastructure]
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
I didn't look at your example yet, but I point out that this may not be an issue with States. Currently the States support can only add and remove components and set properties on components. So my point is that any application developer can do the same thing in their business logic. If a Jewel component cannot be exactly restored from a set of properties, that is a problem to solve regardless of States.
The set of classNames should be directly mapped to one or more properties. I thought that was why you wanted the classList API, so that various Jewel properties could add/remove class selectors from the classList.
Maybe we should discuss a simple scenario without states. If I take a Jewel component or container and write some AS to change properties or add/remove children and then restore it back to the original and it doesn't look the same, what part of the Royale framework is preventing that from happening?
Thoughts?
-Alex
On 9/14/18, 3:29 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
the issue comes from beads modifying strand className. This can be seen
mixing states with jewel layouts. Jewel Layouts add or removes class names
in the strand at runtime.
Since, as you describe in the example, those changes are not part of some
state (i.e: className.normal or className.someState, for example), the
current class name is not stored anywhere, so when you change the state and
comes back, Royale is not capable of recreate the right strand className
You can see the issue in action if you compile the blog example about
states [1]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fblog%2FBE0008_Using_View_States_to_show_or_hide_content&data=02%7C01%7Caharui%40adobe.com%7C2592599a6d224d94342b08d61a917fea%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725609577539201&sdata=NaIJmC4%2Bbhr3Ysba%2BOxsjFnmliemEWq6nHGIDkzoxwc%3D&reserved=0
Compile the example and run (online version works ok due to it was
published when the work was in unfinished stated)
Then push the button to change state from login form to result screen and
push the button back to go to the other state. You'll see the layout is not
equal. If check the html in the broswer, you'll find class names are lost
between state changes.
What do you think would be a good solution to this problem?
thanks
Carlos
El vie., 14 sept. 2018 a las 18:23, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Regarding class selectors and states, I guess I don't understand the
> issue. The code behind Royale (and Flex) states should be capturing values
> of properties changed by the state before they get changed, then restoring
> those properties. IOW, if you were to have
>
> <js:states>
> <js:state name="normal" />
> <js:state name="important" />
> <js:states>
> <j:Button id="myButton" emphasis.normal="primary"
> emphasis.important="emphasized" />
>
> Then the myButton.emphasis="primary" at startup and when the state
> changes to "important" the States impl should read myButton.emphasis and
> store that value away before setting myButton.emphasis="emphasized". Then,
> when the state changes back to "normal", the States impl should set
> myButton.emphasis="primary" again.
>
> In the implementation for the emphasis property, if it involves changing
> classLists, the implementation must do so in a way that handles having the
> emphasis property changes at runtime. The States impl isn't really doing
> anything application developer code might do, so the implementation must
> support properties being set and re-set.
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2592599a6d224d94342b08d61a917fea%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725609577539201&sdata=bHjSWhNbYwkhNfQbX2Q%2BQDUQWTtVXNozSTe6eHyX61Y%3D&reserved=0
States problem [was: Re: Royale Transitions, Effects, States infrastructure]
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
the issue comes from beads modifying strand className. This can be seen
mixing states with jewel layouts. Jewel Layouts add or removes class names
in the strand at runtime.
Since, as you describe in the example, those changes are not part of some
state (i.e: className.normal or className.someState, for example), the
current class name is not stored anywhere, so when you change the state and
comes back, Royale is not capable of recreate the right strand className
You can see the issue in action if you compile the blog example about
states [1]
https://github.com/apache/royale-asjs/tree/develop/examples/blog/BE0008_Using_View_States_to_show_or_hide_content
Compile the example and run (online version works ok due to it was
published when the work was in unfinished stated)
Then push the button to change state from login form to result screen and
push the button back to go to the other state. You'll see the layout is not
equal. If check the html in the broswer, you'll find class names are lost
between state changes.
What do you think would be a good solution to this problem?
thanks
Carlos
El vie., 14 sept. 2018 a las 18:23, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Regarding class selectors and states, I guess I don't understand the
> issue. The code behind Royale (and Flex) states should be capturing values
> of properties changed by the state before they get changed, then restoring
> those properties. IOW, if you were to have
>
> <js:states>
> <js:state name="normal" />
> <js:state name="important" />
> <js:states>
> <j:Button id="myButton" emphasis.normal="primary"
> emphasis.important="emphasized" />
>
> Then the myButton.emphasis="primary" at startup and when the state
> changes to "important" the States impl should read myButton.emphasis and
> store that value away before setting myButton.emphasis="emphasized". Then,
> when the state changes back to "normal", the States impl should set
> myButton.emphasis="primary" again.
>
> In the implementation for the emphasis property, if it involves changing
> classLists, the implementation must do so in a way that handles having the
> emphasis property changes at runtime. The States impl isn't really doing
> anything application developer code might do, so the implementation must
> support properties being set and re-set.
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Transitions, Effects, States infrastructure [was: Re:
[royale-asjs] branch develop updated: I think this fixes Menu]
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Greensock was quite popular among Flex developers. Does anyone on this list have contacts at Greensock? We might want to see if they will create a Royale SWC for their code.
Regarding class selectors and states, I guess I don't understand the issue. The code behind Royale (and Flex) states should be capturing values of properties changed by the state before they get changed, then restoring those properties. IOW, if you were to have
<js:states>
<js:state name="normal" />
<js:state name="important" />
<js:states>
<j:Button id="myButton" emphasis.normal="primary" emphasis.important="emphasized" />
Then the myButton.emphasis="primary" at startup and when the state changes to "important" the States impl should read myButton.emphasis and store that value away before setting myButton.emphasis="emphasized". Then, when the state changes back to "normal", the States impl should set myButton.emphasis="primary" again.
In the implementation for the emphasis property, if it involves changing classLists, the implementation must do so in a way that handles having the emphasis property changes at runtime. The States impl isn't really doing anything application developer code might do, so the implementation must support properties being set and re-set.
My 2 cents,
-Alex
On 9/14/18, 4:07 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Harbs,
for me is ok, but I'm more worried about how to accommodate this and the
underlying architecture. The events systems that Alex propose,
About implementation, I'm sure can do something on the lines of GASP, but
as you say, we should be able to plug other options as we do with layouts
currently.
But first of all, for me, we should solve the problem with addition/removal
of class selectors in the core of UIBase. I at least don't know other way
to deal with it without the need of adding lots of unnecessary code like I
had to do in Jewel for something that is so "core" to us.
Thanks
El vie., 14 sept. 2018 a las 11:34, Harbs (<ha...@gmail.com>)
escribió:
> Well, my point of view on animation would be that GSAP is the industry
> standard.[1]
>
> Making GSAP a dependency is a no-go because the license is not compatible,
> but I’d say that the approach should be similar (although I don’t expect
> we’d get nearly to the level of complete-ness / robustness that GSAP has).
> Extra points would be to allow GSAP to be easily substituted for the
> default implementation.
>
> I’m not sure about states.
>
> My $0.02,
> Harbs
>
> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreensock.com%2Fgsap&data=02%7C01%7Caharui%40adobe.com%7C79138145b5db4f85575d08d61a325020%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725200735947429&sdata=mCQxXT6%2FzwI35gAhDoBbfPWkEUSwUGBUvFyZwME3i94%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgreensock.com%2Fgsap&data=02%7C01%7Caharui%40adobe.com%7C79138145b5db4f85575d08d61a325020%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725200735957438&sdata=7kGIZpj4g6bFkWXKyz%2BDwDG0x4VGhFQbEeDgeQnPWPI%3D&reserved=0>
>
> > On Sep 14, 2018, at 10:36 AM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Hi Alex,
> >
> > renaming this to other thread since I think this deserves its space to
> > planning.
> >
> > Right now, in Jewel, we try to get most of "eye candy" things through CSS
> > class selectors. This means that we defer this to the CSS "engine". The
> > same happens with Jewel layouts, that are based on add the proper class
> > selectors.
> >
> > This for now is working, but I think is not the Royale way, since I see
> > some drawbacks:
> >
> > - you don't have control in Royale of the things deferred to CSS.
> > - targets like SWF, or future targets, could be left since this strategy
> is
> > platform dependent
> >
> > And some issues:
> >
> > - States subsystems is not playing nicely with class selectors. It can't
> > recreate the class selectors the component has before the state change
> > - As I stated in other thread recently, although we introduced a way to
> > deal with classList, since is not part of UIBase, we can see it's not
> > playing nicely with the rest of Royale and it's causing to introduce more
> > code in lost of classes (checking for ClassSelectorList in Jewel and
> Basic
> > Code will discover all places where I had to inject the same code, what
> > seems not optimal.
> >
> > So, I think we should refactor now (post release) how we deal with class
> > names (before the ball gets bigger), and think a way to play with
> > transitions and effects in a more Royale way. I think first is very
> needed,
> > and second can wait a bit more...
> >
> > For example for HTML, I envision using StatesWithTransitionImpl to deal
> > with class selectors that will play, in HTML, transitions, so
> effectStart,
> > transitionStart, or effectEnd, or transitionEnd, could make an
> "addClass",
> > "removeClass" or "toggleClass" and the those class selectors will define
> > the platform (in this case CSS) way to deal with the effect, and avoid
> hard
> > coding that in AS3 code.
> >
> > Another side problem here is that we need to include @keyframe in
> compiler
> > since Royale, as today, don't know how to deal with this.
> >
> > Thoughts?
> >
> >
> >
> > El vie., 14 sept. 2018 a las 8:45, Alex Harui (<aharui@adobe.com.invalid
> >)
> > escribió:
> >
> >> Hi Carlos,
> >>
> >> We have not devoted much time and energy to an effects subsystem, so
> maybe
> >> you will be the pioneer in this area.
> >>
> >> In my mind, there will be at least two kinds of effects subsystem:
> >> planned and unplanned.
> >>
> >> In a planned effects subsystem, the assumption is that most users will
> >> want to implement an effect/transition. The StatesWithTransitionsImpl
> is
> >> an early example of that. Such a subsystem should have a "lifecycle".
> A
> >> known set of events should be dispatched that provide useful
> opportunities
> >> to change the effects start and end conditions. For state changes, the
> >> events should be something like transitionStart, transitionEnd,
> >> stateChanged. For your cases, the events might be something like
> >> effectStart, effectEnd, open/close. If you get the right set of events,
> >> then the work you want to defer should happen on an lifecycle event
> instead
> >> of a timer event.
> >>
> >> In an unplanned effects subsystem, the event system is more
> >> sophisticated. The assumption is that it will be rare to have an
> effect in
> >> response to some change in the component. So hide/show effects,
> selection
> >> and focus effects and things like that would be "unplanned". I hope we
> >> can find a way to do this in a PAYG way with different/heavier beads,
> but
> >> that is a bit tricky for hide/show since it is built into UIBase. In an
> >> unplanned system, there will either be cancelable "ing" events or the
> >> target classes have to be able to reverse a property change without
> >> flicker.
> >>
> >> For example, right now if you set the UIBase visible property to false,
> >> the component becomes invisible immediately. And similarly if you set
> >> visible=true, the component becomes visible immediately. Adding
> unplanned
> >> effect support to visible would require dispatching a cancelable
> >> visibleChanging event before actually setting the browser's CSS display
> >> property that an effect instance would listen for and cancel, then wait
> for
> >> the effectEnd event and then finally actually set the visible
> property. Or
> >> we'd have to be confident that you can set the CSS display property and
> set
> >> it back without flicker.
> >>
> >> In summary, having the right events should eliminate the need for timing
> >> events.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >>
> >> On 9/13/18, 2:34 PM, "Carlos Rovira" <ca...@apache.org> wrote:
> >>
> >> Hi Alex,
> >> I'm with you. Don't like setTimeOut. But I needed in Jewel in at
> least
> >> 3
> >> scenearios. I'd love to change it sometime in the future, but for now
> >> don't
> >> know how.
> >> I think the actual ways to defer something are:
> >> -setTimeOut
> >> -setInterval
> >> -requestAnimationFrame
> >>
> >> the first one is in SWF, so the solution is cross SWF/JS, although if
> >> we
> >> add other targets, maybe will require changes.
> >> the second seems to be the worse.
> >> the latest seems the actual way to do things in JS, but I tried and
> >> didn't
> >> work for me, and I suppose we'll need to abstract it to something
> >> usable in
> >> SWF and future targets.
> >>
> >> My concrete case in the three ocassions is when I instantiate a
> >> component
> >> and add a class name to make the component animate (transition)
> >> through
> >> CSS. For example Alert, DateField and ComboBox popups components and
> >> then
> >> add a class ".open" in CSS, so we need at least 300-400ms so the
> >> transition
> >> can play.
> >>
> >> Any other way to do it would be good to know in order to upgrade this
> >> implementations.
> >>
> >> Thanks
> >>
> >> Carlos
> >>
> >> --
> >> Carlos Rovira
> >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C79138145b5db4f85575d08d61a325020%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725200735957438&sdata=GaQKQ9ia22sYICn5XY26T8DYbgbtnBstHc%2FshO%2F%2F4Rw%3D&reserved=0
> >>
> >>
> >>
> >>
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C79138145b5db4f85575d08d61a325020%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725200735957438&sdata=GaQKQ9ia22sYICn5XY26T8DYbgbtnBstHc%2FshO%2F%2F4Rw%3D&reserved=0
Re: Royale Transitions, Effects, States infrastructure [was: Re:
[royale-asjs] branch develop updated: I think this fixes Menu]
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
for me is ok, but I'm more worried about how to accommodate this and the
underlying architecture. The events systems that Alex propose,
About implementation, I'm sure can do something on the lines of GASP, but
as you say, we should be able to plug other options as we do with layouts
currently.
But first of all, for me, we should solve the problem with addition/removal
of class selectors in the core of UIBase. I at least don't know other way
to deal with it without the need of adding lots of unnecessary code like I
had to do in Jewel for something that is so "core" to us.
Thanks
El vie., 14 sept. 2018 a las 11:34, Harbs (<ha...@gmail.com>)
escribió:
> Well, my point of view on animation would be that GSAP is the industry
> standard.[1]
>
> Making GSAP a dependency is a no-go because the license is not compatible,
> but I’d say that the approach should be similar (although I don’t expect
> we’d get nearly to the level of complete-ness / robustness that GSAP has).
> Extra points would be to allow GSAP to be easily substituted for the
> default implementation.
>
> I’m not sure about states.
>
> My $0.02,
> Harbs
>
> [1]https://greensock.com/gsap <https://greensock.com/gsap>
>
> > On Sep 14, 2018, at 10:36 AM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Hi Alex,
> >
> > renaming this to other thread since I think this deserves its space to
> > planning.
> >
> > Right now, in Jewel, we try to get most of "eye candy" things through CSS
> > class selectors. This means that we defer this to the CSS "engine". The
> > same happens with Jewel layouts, that are based on add the proper class
> > selectors.
> >
> > This for now is working, but I think is not the Royale way, since I see
> > some drawbacks:
> >
> > - you don't have control in Royale of the things deferred to CSS.
> > - targets like SWF, or future targets, could be left since this strategy
> is
> > platform dependent
> >
> > And some issues:
> >
> > - States subsystems is not playing nicely with class selectors. It can't
> > recreate the class selectors the component has before the state change
> > - As I stated in other thread recently, although we introduced a way to
> > deal with classList, since is not part of UIBase, we can see it's not
> > playing nicely with the rest of Royale and it's causing to introduce more
> > code in lost of classes (checking for ClassSelectorList in Jewel and
> Basic
> > Code will discover all places where I had to inject the same code, what
> > seems not optimal.
> >
> > So, I think we should refactor now (post release) how we deal with class
> > names (before the ball gets bigger), and think a way to play with
> > transitions and effects in a more Royale way. I think first is very
> needed,
> > and second can wait a bit more...
> >
> > For example for HTML, I envision using StatesWithTransitionImpl to deal
> > with class selectors that will play, in HTML, transitions, so
> effectStart,
> > transitionStart, or effectEnd, or transitionEnd, could make an
> "addClass",
> > "removeClass" or "toggleClass" and the those class selectors will define
> > the platform (in this case CSS) way to deal with the effect, and avoid
> hard
> > coding that in AS3 code.
> >
> > Another side problem here is that we need to include @keyframe in
> compiler
> > since Royale, as today, don't know how to deal with this.
> >
> > Thoughts?
> >
> >
> >
> > El vie., 14 sept. 2018 a las 8:45, Alex Harui (<aharui@adobe.com.invalid
> >)
> > escribió:
> >
> >> Hi Carlos,
> >>
> >> We have not devoted much time and energy to an effects subsystem, so
> maybe
> >> you will be the pioneer in this area.
> >>
> >> In my mind, there will be at least two kinds of effects subsystem:
> >> planned and unplanned.
> >>
> >> In a planned effects subsystem, the assumption is that most users will
> >> want to implement an effect/transition. The StatesWithTransitionsImpl
> is
> >> an early example of that. Such a subsystem should have a "lifecycle".
> A
> >> known set of events should be dispatched that provide useful
> opportunities
> >> to change the effects start and end conditions. For state changes, the
> >> events should be something like transitionStart, transitionEnd,
> >> stateChanged. For your cases, the events might be something like
> >> effectStart, effectEnd, open/close. If you get the right set of events,
> >> then the work you want to defer should happen on an lifecycle event
> instead
> >> of a timer event.
> >>
> >> In an unplanned effects subsystem, the event system is more
> >> sophisticated. The assumption is that it will be rare to have an
> effect in
> >> response to some change in the component. So hide/show effects,
> selection
> >> and focus effects and things like that would be "unplanned". I hope we
> >> can find a way to do this in a PAYG way with different/heavier beads,
> but
> >> that is a bit tricky for hide/show since it is built into UIBase. In an
> >> unplanned system, there will either be cancelable "ing" events or the
> >> target classes have to be able to reverse a property change without
> >> flicker.
> >>
> >> For example, right now if you set the UIBase visible property to false,
> >> the component becomes invisible immediately. And similarly if you set
> >> visible=true, the component becomes visible immediately. Adding
> unplanned
> >> effect support to visible would require dispatching a cancelable
> >> visibleChanging event before actually setting the browser's CSS display
> >> property that an effect instance would listen for and cancel, then wait
> for
> >> the effectEnd event and then finally actually set the visible
> property. Or
> >> we'd have to be confident that you can set the CSS display property and
> set
> >> it back without flicker.
> >>
> >> In summary, having the right events should eliminate the need for timing
> >> events.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >>
> >> On 9/13/18, 2:34 PM, "Carlos Rovira" <ca...@apache.org> wrote:
> >>
> >> Hi Alex,
> >> I'm with you. Don't like setTimeOut. But I needed in Jewel in at
> least
> >> 3
> >> scenearios. I'd love to change it sometime in the future, but for now
> >> don't
> >> know how.
> >> I think the actual ways to defer something are:
> >> -setTimeOut
> >> -setInterval
> >> -requestAnimationFrame
> >>
> >> the first one is in SWF, so the solution is cross SWF/JS, although if
> >> we
> >> add other targets, maybe will require changes.
> >> the second seems to be the worse.
> >> the latest seems the actual way to do things in JS, but I tried and
> >> didn't
> >> work for me, and I suppose we'll need to abstract it to something
> >> usable in
> >> SWF and future targets.
> >>
> >> My concrete case in the three ocassions is when I instantiate a
> >> component
> >> and add a class name to make the component animate (transition)
> >> through
> >> CSS. For example Alert, DateField and ComboBox popups components and
> >> then
> >> add a class ".open" in CSS, so we need at least 300-400ms so the
> >> transition
> >> can play.
> >>
> >> Any other way to do it would be good to know in order to upgrade this
> >> implementations.
> >>
> >> Thanks
> >>
> >> Carlos
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >>
> >>
> >>
> >>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale Transitions, Effects, States infrastructure [was: Re:
[royale-asjs] branch develop updated: I think this fixes Menu]
Posted by Harbs <ha...@gmail.com>.
Well, my point of view on animation would be that GSAP is the industry standard.[1]
Making GSAP a dependency is a no-go because the license is not compatible, but I’d say that the approach should be similar (although I don’t expect we’d get nearly to the level of complete-ness / robustness that GSAP has). Extra points would be to allow GSAP to be easily substituted for the default implementation.
I’m not sure about states.
My $0.02,
Harbs
[1]https://greensock.com/gsap <https://greensock.com/gsap>
> On Sep 14, 2018, at 10:36 AM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Alex,
>
> renaming this to other thread since I think this deserves its space to
> planning.
>
> Right now, in Jewel, we try to get most of "eye candy" things through CSS
> class selectors. This means that we defer this to the CSS "engine". The
> same happens with Jewel layouts, that are based on add the proper class
> selectors.
>
> This for now is working, but I think is not the Royale way, since I see
> some drawbacks:
>
> - you don't have control in Royale of the things deferred to CSS.
> - targets like SWF, or future targets, could be left since this strategy is
> platform dependent
>
> And some issues:
>
> - States subsystems is not playing nicely with class selectors. It can't
> recreate the class selectors the component has before the state change
> - As I stated in other thread recently, although we introduced a way to
> deal with classList, since is not part of UIBase, we can see it's not
> playing nicely with the rest of Royale and it's causing to introduce more
> code in lost of classes (checking for ClassSelectorList in Jewel and Basic
> Code will discover all places where I had to inject the same code, what
> seems not optimal.
>
> So, I think we should refactor now (post release) how we deal with class
> names (before the ball gets bigger), and think a way to play with
> transitions and effects in a more Royale way. I think first is very needed,
> and second can wait a bit more...
>
> For example for HTML, I envision using StatesWithTransitionImpl to deal
> with class selectors that will play, in HTML, transitions, so effectStart,
> transitionStart, or effectEnd, or transitionEnd, could make an "addClass",
> "removeClass" or "toggleClass" and the those class selectors will define
> the platform (in this case CSS) way to deal with the effect, and avoid hard
> coding that in AS3 code.
>
> Another side problem here is that we need to include @keyframe in compiler
> since Royale, as today, don't know how to deal with this.
>
> Thoughts?
>
>
>
> El vie., 14 sept. 2018 a las 8:45, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> Hi Carlos,
>>
>> We have not devoted much time and energy to an effects subsystem, so maybe
>> you will be the pioneer in this area.
>>
>> In my mind, there will be at least two kinds of effects subsystem:
>> planned and unplanned.
>>
>> In a planned effects subsystem, the assumption is that most users will
>> want to implement an effect/transition. The StatesWithTransitionsImpl is
>> an early example of that. Such a subsystem should have a "lifecycle". A
>> known set of events should be dispatched that provide useful opportunities
>> to change the effects start and end conditions. For state changes, the
>> events should be something like transitionStart, transitionEnd,
>> stateChanged. For your cases, the events might be something like
>> effectStart, effectEnd, open/close. If you get the right set of events,
>> then the work you want to defer should happen on an lifecycle event instead
>> of a timer event.
>>
>> In an unplanned effects subsystem, the event system is more
>> sophisticated. The assumption is that it will be rare to have an effect in
>> response to some change in the component. So hide/show effects, selection
>> and focus effects and things like that would be "unplanned". I hope we
>> can find a way to do this in a PAYG way with different/heavier beads, but
>> that is a bit tricky for hide/show since it is built into UIBase. In an
>> unplanned system, there will either be cancelable "ing" events or the
>> target classes have to be able to reverse a property change without
>> flicker.
>>
>> For example, right now if you set the UIBase visible property to false,
>> the component becomes invisible immediately. And similarly if you set
>> visible=true, the component becomes visible immediately. Adding unplanned
>> effect support to visible would require dispatching a cancelable
>> visibleChanging event before actually setting the browser's CSS display
>> property that an effect instance would listen for and cancel, then wait for
>> the effectEnd event and then finally actually set the visible property. Or
>> we'd have to be confident that you can set the CSS display property and set
>> it back without flicker.
>>
>> In summary, having the right events should eliminate the need for timing
>> events.
>>
>> My 2 cents,
>> -Alex
>>
>>
>> On 9/13/18, 2:34 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> Hi Alex,
>> I'm with you. Don't like setTimeOut. But I needed in Jewel in at least
>> 3
>> scenearios. I'd love to change it sometime in the future, but for now
>> don't
>> know how.
>> I think the actual ways to defer something are:
>> -setTimeOut
>> -setInterval
>> -requestAnimationFrame
>>
>> the first one is in SWF, so the solution is cross SWF/JS, although if
>> we
>> add other targets, maybe will require changes.
>> the second seems to be the worse.
>> the latest seems the actual way to do things in JS, but I tried and
>> didn't
>> work for me, and I suppose we'll need to abstract it to something
>> usable in
>> SWF and future targets.
>>
>> My concrete case in the three ocassions is when I instantiate a
>> component
>> and add a class name to make the component animate (transition)
>> through
>> CSS. For example Alert, DateField and ComboBox popups components and
>> then
>> add a class ".open" in CSS, so we need at least 300-400ms so the
>> transition
>> can play.
>>
>> Any other way to do it would be good to know in order to upgrade this
>> implementations.
>>
>> Thanks
>>
>> Carlos
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>>
>>
Royale Transitions, Effects, States infrastructure [was: Re:
[royale-asjs] branch develop updated: I think this fixes Menu]
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
renaming this to other thread since I think this deserves its space to
planning.
Right now, in Jewel, we try to get most of "eye candy" things through CSS
class selectors. This means that we defer this to the CSS "engine". The
same happens with Jewel layouts, that are based on add the proper class
selectors.
This for now is working, but I think is not the Royale way, since I see
some drawbacks:
- you don't have control in Royale of the things deferred to CSS.
- targets like SWF, or future targets, could be left since this strategy is
platform dependent
And some issues:
- States subsystems is not playing nicely with class selectors. It can't
recreate the class selectors the component has before the state change
- As I stated in other thread recently, although we introduced a way to
deal with classList, since is not part of UIBase, we can see it's not
playing nicely with the rest of Royale and it's causing to introduce more
code in lost of classes (checking for ClassSelectorList in Jewel and Basic
Code will discover all places where I had to inject the same code, what
seems not optimal.
So, I think we should refactor now (post release) how we deal with class
names (before the ball gets bigger), and think a way to play with
transitions and effects in a more Royale way. I think first is very needed,
and second can wait a bit more...
For example for HTML, I envision using StatesWithTransitionImpl to deal
with class selectors that will play, in HTML, transitions, so effectStart,
transitionStart, or effectEnd, or transitionEnd, could make an "addClass",
"removeClass" or "toggleClass" and the those class selectors will define
the platform (in this case CSS) way to deal with the effect, and avoid hard
coding that in AS3 code.
Another side problem here is that we need to include @keyframe in compiler
since Royale, as today, don't know how to deal with this.
Thoughts?
El vie., 14 sept. 2018 a las 8:45, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Hi Carlos,
>
> We have not devoted much time and energy to an effects subsystem, so maybe
> you will be the pioneer in this area.
>
> In my mind, there will be at least two kinds of effects subsystem:
> planned and unplanned.
>
> In a planned effects subsystem, the assumption is that most users will
> want to implement an effect/transition. The StatesWithTransitionsImpl is
> an early example of that. Such a subsystem should have a "lifecycle". A
> known set of events should be dispatched that provide useful opportunities
> to change the effects start and end conditions. For state changes, the
> events should be something like transitionStart, transitionEnd,
> stateChanged. For your cases, the events might be something like
> effectStart, effectEnd, open/close. If you get the right set of events,
> then the work you want to defer should happen on an lifecycle event instead
> of a timer event.
>
> In an unplanned effects subsystem, the event system is more
> sophisticated. The assumption is that it will be rare to have an effect in
> response to some change in the component. So hide/show effects, selection
> and focus effects and things like that would be "unplanned". I hope we
> can find a way to do this in a PAYG way with different/heavier beads, but
> that is a bit tricky for hide/show since it is built into UIBase. In an
> unplanned system, there will either be cancelable "ing" events or the
> target classes have to be able to reverse a property change without
> flicker.
>
> For example, right now if you set the UIBase visible property to false,
> the component becomes invisible immediately. And similarly if you set
> visible=true, the component becomes visible immediately. Adding unplanned
> effect support to visible would require dispatching a cancelable
> visibleChanging event before actually setting the browser's CSS display
> property that an effect instance would listen for and cancel, then wait for
> the effectEnd event and then finally actually set the visible property. Or
> we'd have to be confident that you can set the CSS display property and set
> it back without flicker.
>
> In summary, having the right events should eliminate the need for timing
> events.
>
> My 2 cents,
> -Alex
>
>
> On 9/13/18, 2:34 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
> I'm with you. Don't like setTimeOut. But I needed in Jewel in at least
> 3
> scenearios. I'd love to change it sometime in the future, but for now
> don't
> know how.
> I think the actual ways to defer something are:
> -setTimeOut
> -setInterval
> -requestAnimationFrame
>
> the first one is in SWF, so the solution is cross SWF/JS, although if
> we
> add other targets, maybe will require changes.
> the second seems to be the worse.
> the latest seems the actual way to do things in JS, but I tried and
> didn't
> work for me, and I suppose we'll need to abstract it to something
> usable in
> SWF and future targets.
>
> My concrete case in the three ocassions is when I instantiate a
> component
> and add a class name to make the component animate (transition)
> through
> CSS. For example Alert, DateField and ComboBox popups components and
> then
> add a class ".open" in CSS, so we need at least 300-400ms so the
> transition
> can play.
>
> Any other way to do it would be good to know in order to upgrade this
> implementations.
>
> Thanks
>
> Carlos
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
>
>
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
We have not devoted much time and energy to an effects subsystem, so maybe you will be the pioneer in this area.
In my mind, there will be at least two kinds of effects subsystem: planned and unplanned.
In a planned effects subsystem, the assumption is that most users will want to implement an effect/transition. The StatesWithTransitionsImpl is an early example of that. Such a subsystem should have a "lifecycle". A known set of events should be dispatched that provide useful opportunities to change the effects start and end conditions. For state changes, the events should be something like transitionStart, transitionEnd, stateChanged. For your cases, the events might be something like effectStart, effectEnd, open/close. If you get the right set of events, then the work you want to defer should happen on an lifecycle event instead of a timer event.
In an unplanned effects subsystem, the event system is more sophisticated. The assumption is that it will be rare to have an effect in response to some change in the component. So hide/show effects, selection and focus effects and things like that would be "unplanned". I hope we can find a way to do this in a PAYG way with different/heavier beads, but that is a bit tricky for hide/show since it is built into UIBase. In an unplanned system, there will either be cancelable "ing" events or the target classes have to be able to reverse a property change without flicker.
For example, right now if you set the UIBase visible property to false, the component becomes invisible immediately. And similarly if you set visible=true, the component becomes visible immediately. Adding unplanned effect support to visible would require dispatching a cancelable visibleChanging event before actually setting the browser's CSS display property that an effect instance would listen for and cancel, then wait for the effectEnd event and then finally actually set the visible property. Or we'd have to be confident that you can set the CSS display property and set it back without flicker.
In summary, having the right events should eliminate the need for timing events.
My 2 cents,
-Alex
On 9/13/18, 2:34 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
I'm with you. Don't like setTimeOut. But I needed in Jewel in at least 3
scenearios. I'd love to change it sometime in the future, but for now don't
know how.
I think the actual ways to defer something are:
-setTimeOut
-setInterval
-requestAnimationFrame
the first one is in SWF, so the solution is cross SWF/JS, although if we
add other targets, maybe will require changes.
the second seems to be the worse.
the latest seems the actual way to do things in JS, but I tried and didn't
work for me, and I suppose we'll need to abstract it to something usable in
SWF and future targets.
My concrete case in the three ocassions is when I instantiate a component
and add a class name to make the component animate (transition) through
CSS. For example Alert, DateField and ComboBox popups components and then
add a class ".open" in CSS, so we need at least 300-400ms so the transition
can play.
Any other way to do it would be good to know in order to upgrade this
implementations.
Thanks
Carlos
El jue., 13 sept. 2018 a las 22:20, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> I didn't see anywhere in the article where it guaranteed that both up and
> click are sequential in the queue. Sharing the heap isn't the issue here.
>
> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp.
> UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer
> and mouse up in another renderer. In some interaction models that does
> change selection, but I don't think CLICK is the right semantic.
>
> Further, I would like to discourage use of setTimeout in the framework.
> The framework has little control over the behavior of application event
> handlers. With many browsers having immediate screen updates (as opposed
> to Flash's deferred rendering), postponing work with setTimeout can result
> in unexpected behavior, and can result in callLater "wars" where more and
> more code has to keep deferring work with setTimeout because some lower
> layer also used setTimeout. Deferring work should be the option of the
> application developer as much as possible.
>
> My 2 cents,
> -Alex
>
> On 9/13/18, 11:36 AM, "Harbs" <ha...@gmail.com> wrote:
>
> I once read that the way setTimeout works is that it’s added to the
> next event loop. That would mean that both mouseup and click would be
> executed in the current event loop and the setTimout would be delayed to
> the next one (i..e between 4ms and 10ms later).
>
> I can’t find the article at the moment, but my understanding is that
> this is a safe way to guarantee later execution in all browsers.
>
> The MDN doc has a decent explanation.[1] Both mouseup and click would
> be on the same heap.
>
> Harbs
>
> [1]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7Ce9e70e18f63c44371e3e08d619c09f72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724712428363224&sdata=rFOw5xW60cVeAnFJkoG48tx0vNp1xMJ7RWEFhd6TIEA%3D&reserved=0
> > On Sep 13, 2018, at 6:54 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > Is setTimeout guaranteed to run after the CLICK event?
> >
> > On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org>" <
> harbs@apache.org <ma...@apache.org>> wrote:
> >
> > This is an automated email from the ASF dual-hosted git
> repository.
> >
> > harbs pushed a commit to branch develop
> > in repository
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce9e70e18f63c44371e3e08d619c09f72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724712428363224&sdata=6VEy8klIqRFbFnbGZXbPX7dH1UzQNQbnVHbhsnyAGig%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7Ce9e70e18f63c44371e3e08d619c09f72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724712428363224&sdata=6VEy8klIqRFbFnbGZXbPX7dH1UzQNQbnVHbhsnyAGig%3D&reserved=0
> >
> >
> >
> > The following commit(s) were added to refs/heads/develop by this
> push:
> > new e1ec25e I think this fixes Menu
> > e1ec25e is described below
> >
> > commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
> > Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
> > AuthorDate: Thu Sep 13 16:14:03 2018 +0300
> >
> > I think this fixes Menu
> > ---
> > .../projects/Basic/src/main/resources/defaults.css | 1 +
> > .../controllers/ItemRendererMouseController.as | 1 -
> > .../controllers/MenuSelectionMouseController.as | 33
> ++++++++++++++--------
> > 3 files changed, 23 insertions(+), 12 deletions(-)
> >
> > diff --git
> a/frameworks/projects/Basic/src/main/resources/defaults.css
> b/frameworks/projects/Basic/src/main/resources/defaults.css
> > index f88da20..15cb4e6 100644
> > --- a/frameworks/projects/Basic/src/main/resources/defaults.css
> > +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
> > @@ -545,6 +545,7 @@ Panel
> > IBeadModel:
> ClassReference("org.apache.royale.html.beads.models.PanelModel");
> > IBeadView:
> ClassReference("org.apache.royale.html.beads.PanelView");
> > IPanelLayout:
> ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
> > + IPanelContentArea:
> ClassReference("org.apache.royale.html.Container");
> >
> > background-color: #FFFFFF;
> > border: 1px solid #333333
> > diff --git
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> > index f408a71..6073264 100644
> > ---
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> > +++
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> > @@ -92,7 +92,6 @@ COMPILE::JS {
> > goog.events.listen(element,
> goog.events.EventType.MOUSEOUT, this.handleMouseOut);
> > goog.events.listen(element,
> goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
> > goog.events.listen(element,
> goog.events.EventType.CLICK, this.handleMouseUp);
> > - goog.events.listen(element,
> goog.events.EventType.MOUSEUP, this.handleMouseUp);
> > }
> > }
> >
> > diff --git
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> > index 5f986bb..6a09a52 100644
> > ---
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> > +++
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> > @@ -127,6 +127,8 @@ package
> org.apache.royale.html.beads.controllers
> > * @playerversion Flash 10.2
> > * @playerversion AIR 2.6
> > * @productversion Royale 0.9
> > + * @royaleignorecoercion org.apache.royale.core.UIBase
> > + * @royaleignorecoercion org.apache.royale.core.IUIBase
> > */
> > protected function hideOpenMenus():void
> > {
> > @@ -137,8 +139,9 @@ package
> org.apache.royale.html.beads.controllers
> > if (menu.parent != null) {
> > var
> controller:MenuSelectionMouseController =
> menu.getBeadByType(MenuSelectionMouseController) as
> MenuSelectionMouseController;
> >
> controller.removeClickOutHandler(menu);
> > - var host:IPopUpHost =
> UIUtils.findPopUpHost(_strand as IUIBase);
> > -
> host.popUpParent.removeElement(menu);
> > + var host:IPopUpHost =
> UIUtils.findPopUpHost(menu as IUIBase);
> > + if(host)
> > +
> host.popUpParent.removeElement(menu);
> > }
> > }
> > MenuModel.clearMenuList();
> > @@ -163,6 +166,8 @@ package
> org.apache.royale.html.beads.controllers
> > * @playerversion Flash 10.2
> > * @playerversion AIR 2.6
> > * @productversion Royale 0.9
> > + * @royaleignorecoercion org.apache.royale.core.IUIBase
> > + * @royaleignorecoercion
> org.apache.royale.events.IEventDispatcher
> > */
> > public function
> removeClickOutHandler(menu:Object):void
> > {
> > @@ -191,23 +196,29 @@ package
> org.apache.royale.html.beads.controllers
> >
> > /**
> > * @royaleignorecoercion HTMLElement
> > + * @royaleignorecoercion
> org.apache.royale.core.IUIBase
> > * @private
> > */
> > COMPILE::JS
> > protected function
> hideMenu_internal(event:BrowserEvent):void
> > {
> > var menu:IMenu = _strand as IMenu;
> > + var menuElem:HTMLElement = (_strand as
> IUIBase).element as HTMLElement;
> > + var menuBarElement:HTMLElement;
> > if (menu.parentMenuBar)
> > {
> > - var menuBarElement:HTMLElement =
> (menu.parentMenuBar as IUIBase).element as HTMLElement;
> > - var target:HTMLElement = event.target as
> HTMLElement;
> > - while (target != null)
> > - {
> > - if (target == menuBarElement) return;
> > - target = target.parentNode as HTMLElement;
> > - }
> > - }
> > - hideOpenMenus();
> > + menuBarElement = (menu.parentMenuBar as
> IUIBase).element as HTMLElement;
> > + }
> > + var target:HTMLElement = event.target as
> HTMLElement;
> > + while (target != null)
> > + {
> > + var comp:IUIBase =
> target["royale_wrapper"];
> > + if(comp && (comp is IMenu || comp
> == menu.parentMenuBar) ) return;
> > + // if (target == menuElem ||
> (menuBarElement && target == menuBarElement) ) return;
> > + target = target.parentNode as
> HTMLElement;
> > + }
> > +
> > + setTimeout(hideOpenMenus);
> > }
> > }
> > }
> > \ No newline at end of file
>
>
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce9e70e18f63c44371e3e08d619c09f72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724712428363224&sdata=J4RDrhC2cAR6tvF29tuc1G0Lrv7IKRlqomILOCHiuxU%3D&reserved=0
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
I'm with you. Don't like setTimeOut. But I needed in Jewel in at least 3
scenearios. I'd love to change it sometime in the future, but for now don't
know how.
I think the actual ways to defer something are:
-setTimeOut
-setInterval
-requestAnimationFrame
the first one is in SWF, so the solution is cross SWF/JS, although if we
add other targets, maybe will require changes.
the second seems to be the worse.
the latest seems the actual way to do things in JS, but I tried and didn't
work for me, and I suppose we'll need to abstract it to something usable in
SWF and future targets.
My concrete case in the three ocassions is when I instantiate a component
and add a class name to make the component animate (transition) through
CSS. For example Alert, DateField and ComboBox popups components and then
add a class ".open" in CSS, so we need at least 300-400ms so the transition
can play.
Any other way to do it would be good to know in order to upgrade this
implementations.
Thanks
Carlos
El jue., 13 sept. 2018 a las 22:20, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> I didn't see anywhere in the article where it guaranteed that both up and
> click are sequential in the queue. Sharing the heap isn't the issue here.
>
> I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp.
> UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer
> and mouse up in another renderer. In some interaction models that does
> change selection, but I don't think CLICK is the right semantic.
>
> Further, I would like to discourage use of setTimeout in the framework.
> The framework has little control over the behavior of application event
> handlers. With many browsers having immediate screen updates (as opposed
> to Flash's deferred rendering), postponing work with setTimeout can result
> in unexpected behavior, and can result in callLater "wars" where more and
> more code has to keep deferring work with setTimeout because some lower
> layer also used setTimeout. Deferring work should be the option of the
> application developer as much as possible.
>
> My 2 cents,
> -Alex
>
> On 9/13/18, 11:36 AM, "Harbs" <ha...@gmail.com> wrote:
>
> I once read that the way setTimeout works is that it’s added to the
> next event loop. That would mean that both mouseup and click would be
> executed in the current event loop and the setTimout would be delayed to
> the next one (i..e between 4ms and 10ms later).
>
> I can’t find the article at the moment, but my understanding is that
> this is a safe way to guarantee later execution in all browsers.
>
> The MDN doc has a decent explanation.[1] Both mouseup and click would
> be on the same heap.
>
> Harbs
>
> [1]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C576c9eb8f72f4456b8de08d619a7e21e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724606177243994&sdata=k2OOBE6%2BB6q53vlxPSHkm6ZUfqKhGlEmhS54Xj%2FWNDU%3D&reserved=0
> > On Sep 13, 2018, at 6:54 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > Is setTimeout guaranteed to run after the CLICK event?
> >
> > On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org>" <
> harbs@apache.org <ma...@apache.org>> wrote:
> >
> > This is an automated email from the ASF dual-hosted git
> repository.
> >
> > harbs pushed a commit to branch develop
> > in repository
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C576c9eb8f72f4456b8de08d619a7e21e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724606177243994&sdata=tl2ADaUxtE4RW1eYucJAULvVhoibVGWfCqzfXidCF6E%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C576c9eb8f72f4456b8de08d619a7e21e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724606177243994&sdata=tl2ADaUxtE4RW1eYucJAULvVhoibVGWfCqzfXidCF6E%3D&reserved=0
> >
> >
> >
> > The following commit(s) were added to refs/heads/develop by this
> push:
> > new e1ec25e I think this fixes Menu
> > e1ec25e is described below
> >
> > commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
> > Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
> > AuthorDate: Thu Sep 13 16:14:03 2018 +0300
> >
> > I think this fixes Menu
> > ---
> > .../projects/Basic/src/main/resources/defaults.css | 1 +
> > .../controllers/ItemRendererMouseController.as | 1 -
> > .../controllers/MenuSelectionMouseController.as | 33
> ++++++++++++++--------
> > 3 files changed, 23 insertions(+), 12 deletions(-)
> >
> > diff --git
> a/frameworks/projects/Basic/src/main/resources/defaults.css
> b/frameworks/projects/Basic/src/main/resources/defaults.css
> > index f88da20..15cb4e6 100644
> > --- a/frameworks/projects/Basic/src/main/resources/defaults.css
> > +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
> > @@ -545,6 +545,7 @@ Panel
> > IBeadModel:
> ClassReference("org.apache.royale.html.beads.models.PanelModel");
> > IBeadView:
> ClassReference("org.apache.royale.html.beads.PanelView");
> > IPanelLayout:
> ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
> > + IPanelContentArea:
> ClassReference("org.apache.royale.html.Container");
> >
> > background-color: #FFFFFF;
> > border: 1px solid #333333
> > diff --git
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> > index f408a71..6073264 100644
> > ---
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> > +++
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> > @@ -92,7 +92,6 @@ COMPILE::JS {
> > goog.events.listen(element,
> goog.events.EventType.MOUSEOUT, this.handleMouseOut);
> > goog.events.listen(element,
> goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
> > goog.events.listen(element,
> goog.events.EventType.CLICK, this.handleMouseUp);
> > - goog.events.listen(element,
> goog.events.EventType.MOUSEUP, this.handleMouseUp);
> > }
> > }
> >
> > diff --git
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> > index 5f986bb..6a09a52 100644
> > ---
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> > +++
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> > @@ -127,6 +127,8 @@ package
> org.apache.royale.html.beads.controllers
> > * @playerversion Flash 10.2
> > * @playerversion AIR 2.6
> > * @productversion Royale 0.9
> > + * @royaleignorecoercion org.apache.royale.core.UIBase
> > + * @royaleignorecoercion org.apache.royale.core.IUIBase
> > */
> > protected function hideOpenMenus():void
> > {
> > @@ -137,8 +139,9 @@ package
> org.apache.royale.html.beads.controllers
> > if (menu.parent != null) {
> > var
> controller:MenuSelectionMouseController =
> menu.getBeadByType(MenuSelectionMouseController) as
> MenuSelectionMouseController;
> >
> controller.removeClickOutHandler(menu);
> > - var host:IPopUpHost =
> UIUtils.findPopUpHost(_strand as IUIBase);
> > -
> host.popUpParent.removeElement(menu);
> > + var host:IPopUpHost =
> UIUtils.findPopUpHost(menu as IUIBase);
> > + if(host)
> > +
> host.popUpParent.removeElement(menu);
> > }
> > }
> > MenuModel.clearMenuList();
> > @@ -163,6 +166,8 @@ package
> org.apache.royale.html.beads.controllers
> > * @playerversion Flash 10.2
> > * @playerversion AIR 2.6
> > * @productversion Royale 0.9
> > + * @royaleignorecoercion org.apache.royale.core.IUIBase
> > + * @royaleignorecoercion
> org.apache.royale.events.IEventDispatcher
> > */
> > public function
> removeClickOutHandler(menu:Object):void
> > {
> > @@ -191,23 +196,29 @@ package
> org.apache.royale.html.beads.controllers
> >
> > /**
> > * @royaleignorecoercion HTMLElement
> > + * @royaleignorecoercion
> org.apache.royale.core.IUIBase
> > * @private
> > */
> > COMPILE::JS
> > protected function
> hideMenu_internal(event:BrowserEvent):void
> > {
> > var menu:IMenu = _strand as IMenu;
> > + var menuElem:HTMLElement = (_strand as
> IUIBase).element as HTMLElement;
> > + var menuBarElement:HTMLElement;
> > if (menu.parentMenuBar)
> > {
> > - var menuBarElement:HTMLElement =
> (menu.parentMenuBar as IUIBase).element as HTMLElement;
> > - var target:HTMLElement = event.target as
> HTMLElement;
> > - while (target != null)
> > - {
> > - if (target == menuBarElement) return;
> > - target = target.parentNode as HTMLElement;
> > - }
> > - }
> > - hideOpenMenus();
> > + menuBarElement = (menu.parentMenuBar as
> IUIBase).element as HTMLElement;
> > + }
> > + var target:HTMLElement = event.target as
> HTMLElement;
> > + while (target != null)
> > + {
> > + var comp:IUIBase =
> target["royale_wrapper"];
> > + if(comp && (comp is IMenu || comp
> == menu.parentMenuBar) ) return;
> > + // if (target == menuElem ||
> (menuBarElement && target == menuBarElement) ) return;
> > + target = target.parentNode as
> HTMLElement;
> > + }
> > +
> > + setTimeout(hideOpenMenus);
> > }
> > }
> > }
> > \ No newline at end of file
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I didn't see anywhere in the article where it guaranteed that both up and click are sequential in the queue. Sharing the heap isn't the issue here.
I'm still surprised the fix isn't to not dispatch ITEM_CLICK on MouseUp. UP doesn't guarantee CLICK, IMO. You could mouse down in one renderer and mouse up in another renderer. In some interaction models that does change selection, but I don't think CLICK is the right semantic.
Further, I would like to discourage use of setTimeout in the framework. The framework has little control over the behavior of application event handlers. With many browsers having immediate screen updates (as opposed to Flash's deferred rendering), postponing work with setTimeout can result in unexpected behavior, and can result in callLater "wars" where more and more code has to keep deferring work with setTimeout because some lower layer also used setTimeout. Deferring work should be the option of the application developer as much as possible.
My 2 cents,
-Alex
On 9/13/18, 11:36 AM, "Harbs" <ha...@gmail.com> wrote:
I once read that the way setTimeout works is that it’s added to the next event loop. That would mean that both mouseup and click would be executed in the current event loop and the setTimout would be delayed to the next one (i..e between 4ms and 10ms later).
I can’t find the article at the moment, but my understanding is that this is a safe way to guarantee later execution in all browsers.
The MDN doc has a decent explanation.[1] Both mouseup and click would be on the same heap.
Harbs
[1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FJavaScript%2FEventLoop&data=02%7C01%7Caharui%40adobe.com%7C576c9eb8f72f4456b8de08d619a7e21e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724606177243994&sdata=k2OOBE6%2BB6q53vlxPSHkm6ZUfqKhGlEmhS54Xj%2FWNDU%3D&reserved=0
> On Sep 13, 2018, at 6:54 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Is setTimeout guaranteed to run after the CLICK event?
>
> On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org>" <harbs@apache.org <ma...@apache.org>> wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> harbs pushed a commit to branch develop
> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C576c9eb8f72f4456b8de08d619a7e21e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724606177243994&sdata=tl2ADaUxtE4RW1eYucJAULvVhoibVGWfCqzfXidCF6E%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C576c9eb8f72f4456b8de08d619a7e21e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724606177243994&sdata=tl2ADaUxtE4RW1eYucJAULvVhoibVGWfCqzfXidCF6E%3D&reserved=0>
>
>
> The following commit(s) were added to refs/heads/develop by this push:
> new e1ec25e I think this fixes Menu
> e1ec25e is described below
>
> commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
> AuthorDate: Thu Sep 13 16:14:03 2018 +0300
>
> I think this fixes Menu
> ---
> .../projects/Basic/src/main/resources/defaults.css | 1 +
> .../controllers/ItemRendererMouseController.as | 1 -
> .../controllers/MenuSelectionMouseController.as | 33 ++++++++++++++--------
> 3 files changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css b/frameworks/projects/Basic/src/main/resources/defaults.css
> index f88da20..15cb4e6 100644
> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
> @@ -545,6 +545,7 @@ Panel
> IBeadModel: ClassReference("org.apache.royale.html.beads.models.PanelModel");
> IBeadView: ClassReference("org.apache.royale.html.beads.PanelView");
> IPanelLayout: ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
> + IPanelContentArea: ClassReference("org.apache.royale.html.Container");
>
> background-color: #FFFFFF;
> border: 1px solid #333333
> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> index f408a71..6073264 100644
> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> @@ -92,7 +92,6 @@ COMPILE::JS {
> goog.events.listen(element, goog.events.EventType.MOUSEOUT, this.handleMouseOut);
> goog.events.listen(element, goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
> goog.events.listen(element, goog.events.EventType.CLICK, this.handleMouseUp);
> - goog.events.listen(element, goog.events.EventType.MOUSEUP, this.handleMouseUp);
> }
> }
>
> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> index 5f986bb..6a09a52 100644
> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> @@ -127,6 +127,8 @@ package org.apache.royale.html.beads.controllers
> * @playerversion Flash 10.2
> * @playerversion AIR 2.6
> * @productversion Royale 0.9
> + * @royaleignorecoercion org.apache.royale.core.UIBase
> + * @royaleignorecoercion org.apache.royale.core.IUIBase
> */
> protected function hideOpenMenus():void
> {
> @@ -137,8 +139,9 @@ package org.apache.royale.html.beads.controllers
> if (menu.parent != null) {
> var controller:MenuSelectionMouseController = menu.getBeadByType(MenuSelectionMouseController) as MenuSelectionMouseController;
> controller.removeClickOutHandler(menu);
> - var host:IPopUpHost = UIUtils.findPopUpHost(_strand as IUIBase);
> - host.popUpParent.removeElement(menu);
> + var host:IPopUpHost = UIUtils.findPopUpHost(menu as IUIBase);
> + if(host)
> + host.popUpParent.removeElement(menu);
> }
> }
> MenuModel.clearMenuList();
> @@ -163,6 +166,8 @@ package org.apache.royale.html.beads.controllers
> * @playerversion Flash 10.2
> * @playerversion AIR 2.6
> * @productversion Royale 0.9
> + * @royaleignorecoercion org.apache.royale.core.IUIBase
> + * @royaleignorecoercion org.apache.royale.events.IEventDispatcher
> */
> public function removeClickOutHandler(menu:Object):void
> {
> @@ -191,23 +196,29 @@ package org.apache.royale.html.beads.controllers
>
> /**
> * @royaleignorecoercion HTMLElement
> + * @royaleignorecoercion org.apache.royale.core.IUIBase
> * @private
> */
> COMPILE::JS
> protected function hideMenu_internal(event:BrowserEvent):void
> {
> var menu:IMenu = _strand as IMenu;
> + var menuElem:HTMLElement = (_strand as IUIBase).element as HTMLElement;
> + var menuBarElement:HTMLElement;
> if (menu.parentMenuBar)
> {
> - var menuBarElement:HTMLElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
> - var target:HTMLElement = event.target as HTMLElement;
> - while (target != null)
> - {
> - if (target == menuBarElement) return;
> - target = target.parentNode as HTMLElement;
> - }
> - }
> - hideOpenMenus();
> + menuBarElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
> + }
> + var target:HTMLElement = event.target as HTMLElement;
> + while (target != null)
> + {
> + var comp:IUIBase = target["royale_wrapper"];
> + if(comp && (comp is IMenu || comp == menu.parentMenuBar) ) return;
> + // if (target == menuElem || (menuBarElement && target == menuBarElement) ) return;
> + target = target.parentNode as HTMLElement;
> + }
> +
> + setTimeout(hideOpenMenus);
> }
> }
> }
> \ No newline at end of file
Re: [royale-asjs] branch develop updated: I think this fixes Menu
Posted by Harbs <ha...@gmail.com>.
I once read that the way setTimeout works is that it’s added to the next event loop. That would mean that both mouseup and click would be executed in the current event loop and the setTimout would be delayed to the next one (i..e between 4ms and 10ms later).
I can’t find the article at the moment, but my understanding is that this is a safe way to guarantee later execution in all browsers.
The MDN doc has a decent explanation.[1] Both mouseup and click would be on the same heap.
Harbs
[1]https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop
> On Sep 13, 2018, at 6:54 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Is setTimeout guaranteed to run after the CLICK event?
>
> On 9/13/18, 6:14 AM, "harbs@apache.org <ma...@apache.org>" <harbs@apache.org <ma...@apache.org>> wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> harbs pushed a commit to branch develop
> in repository https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C1ae20fcfaca24ad2792f08d6197acee6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724412586134726&sdata=gasHWKJBGUaGc6k7gqt2fJcI3iQ2qp4Xjjst7SA7a%2FE%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git&data=02%7C01%7Caharui%40adobe.com%7C1ae20fcfaca24ad2792f08d6197acee6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636724412586134726&sdata=gasHWKJBGUaGc6k7gqt2fJcI3iQ2qp4Xjjst7SA7a%2FE%3D&reserved=0>
>
>
> The following commit(s) were added to refs/heads/develop by this push:
> new e1ec25e I think this fixes Menu
> e1ec25e is described below
>
> commit e1ec25e0d8b1e59bfbb1e3d0cf856fe9dfb4dc5e
> Author: Harbs <harbs@in-tools.com <ma...@in-tools.com>>
> AuthorDate: Thu Sep 13 16:14:03 2018 +0300
>
> I think this fixes Menu
> ---
> .../projects/Basic/src/main/resources/defaults.css | 1 +
> .../controllers/ItemRendererMouseController.as | 1 -
> .../controllers/MenuSelectionMouseController.as | 33 ++++++++++++++--------
> 3 files changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css b/frameworks/projects/Basic/src/main/resources/defaults.css
> index f88da20..15cb4e6 100644
> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
> @@ -545,6 +545,7 @@ Panel
> IBeadModel: ClassReference("org.apache.royale.html.beads.models.PanelModel");
> IBeadView: ClassReference("org.apache.royale.html.beads.PanelView");
> IPanelLayout: ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
> + IPanelContentArea: ClassReference("org.apache.royale.html.Container");
>
> background-color: #FFFFFF;
> border: 1px solid #333333
> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> index f408a71..6073264 100644
> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/ItemRendererMouseController.as
> @@ -92,7 +92,6 @@ COMPILE::JS {
> goog.events.listen(element, goog.events.EventType.MOUSEOUT, this.handleMouseOut);
> goog.events.listen(element, goog.events.EventType.MOUSEDOWN, this.handleMouseDown);
> goog.events.listen(element, goog.events.EventType.CLICK, this.handleMouseUp);
> - goog.events.listen(element, goog.events.EventType.MOUSEUP, this.handleMouseUp);
> }
> }
>
> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> index 5f986bb..6a09a52 100644
> --- a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/controllers/MenuSelectionMouseController.as
> @@ -127,6 +127,8 @@ package org.apache.royale.html.beads.controllers
> * @playerversion Flash 10.2
> * @playerversion AIR 2.6
> * @productversion Royale 0.9
> + * @royaleignorecoercion org.apache.royale.core.UIBase
> + * @royaleignorecoercion org.apache.royale.core.IUIBase
> */
> protected function hideOpenMenus():void
> {
> @@ -137,8 +139,9 @@ package org.apache.royale.html.beads.controllers
> if (menu.parent != null) {
> var controller:MenuSelectionMouseController = menu.getBeadByType(MenuSelectionMouseController) as MenuSelectionMouseController;
> controller.removeClickOutHandler(menu);
> - var host:IPopUpHost = UIUtils.findPopUpHost(_strand as IUIBase);
> - host.popUpParent.removeElement(menu);
> + var host:IPopUpHost = UIUtils.findPopUpHost(menu as IUIBase);
> + if(host)
> + host.popUpParent.removeElement(menu);
> }
> }
> MenuModel.clearMenuList();
> @@ -163,6 +166,8 @@ package org.apache.royale.html.beads.controllers
> * @playerversion Flash 10.2
> * @playerversion AIR 2.6
> * @productversion Royale 0.9
> + * @royaleignorecoercion org.apache.royale.core.IUIBase
> + * @royaleignorecoercion org.apache.royale.events.IEventDispatcher
> */
> public function removeClickOutHandler(menu:Object):void
> {
> @@ -191,23 +196,29 @@ package org.apache.royale.html.beads.controllers
>
> /**
> * @royaleignorecoercion HTMLElement
> + * @royaleignorecoercion org.apache.royale.core.IUIBase
> * @private
> */
> COMPILE::JS
> protected function hideMenu_internal(event:BrowserEvent):void
> {
> var menu:IMenu = _strand as IMenu;
> + var menuElem:HTMLElement = (_strand as IUIBase).element as HTMLElement;
> + var menuBarElement:HTMLElement;
> if (menu.parentMenuBar)
> {
> - var menuBarElement:HTMLElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
> - var target:HTMLElement = event.target as HTMLElement;
> - while (target != null)
> - {
> - if (target == menuBarElement) return;
> - target = target.parentNode as HTMLElement;
> - }
> - }
> - hideOpenMenus();
> + menuBarElement = (menu.parentMenuBar as IUIBase).element as HTMLElement;
> + }
> + var target:HTMLElement = event.target as HTMLElement;
> + while (target != null)
> + {
> + var comp:IUIBase = target["royale_wrapper"];
> + if(comp && (comp is IMenu || comp == menu.parentMenuBar) ) return;
> + // if (target == menuElem || (menuBarElement && target == menuBarElement) ) return;
> + target = target.parentNode as HTMLElement;
> + }
> +
> + setTimeout(hideOpenMenus);
> }
> }
> }
> \ No newline at end of file