Re: [royale-asjs] branch develop updated: join all emphasis button styles in one single property and its constants, and update all examples accordingly

[Harbs]

I like “emphasis”. Nice.

> On Jun 14, 2018, at 4:17 PM, carlosrov...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> carlosrovira pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> 
> 
> The following commit(s) were added to refs/heads/develop by this push:
> new 457a6f9  join all emphasis button styles in one single property and 
> its constants, and update all examples accordingly
> 457a6f9 is described below
> 
> commit 457a6f9cf2c581a9f8091c8e708c92e96f8faf96
> Author: Carlos Rovira 
> AuthorDate: Thu Jun 14 15:17:17 2018 +0200
> 
>join all emphasis button styles in one single property and its constants, 
> and update all examples accordingly
> ---
> .../royale/BE0002_Using_Jewel_Alert_Control.mxml   |   2 +-
> .../royale/BE0003_Using_Jewel_Slider_Control.mxml  |   2 +-
> .../BE0004_Adding_an_item_to_a_Jewel_List.mxml |   2 +-
> ...005_Creating_a_group_of_Jewel_RadioButtons.mxml |   2 +-
> ...ns_from_a_group_of_jewel_checkbox_controls.mxml |   2 +-
> ..._Using_View_States_to_show_or_hide_content.mxml |   2 +-
> .../src/main/royale/ButtonPlayGround.mxml  |  16 +-
> .../src/main/royale/ListPlayGround.mxml|   8 +-
> .../src/main/royale/SliderPlayGround.mxml  |   7 +-
> .../src/main/royale/TextInputPlayGround.mxml   |   9 +-
> .../RemoteObjectAMFTest/src/main/royale/App.mxml   |   8 +-
> .../main/royale/org/apache/royale/jewel/Button.as  | 165 +
> .../apache/royale/jewel/beads/views/AlertView.as   |   4 +-
> .../jewel/beads/views/JewelLabelViewBead.mxml  |   2 +-
> 14 files changed, 77 insertions(+), 154 deletions(-)
> 
> diff --git 
> a/examples/blog/BE0002_Using_Jewel_Alert_Control/src/main/royale/BE0002_Using_Jewel_Alert_Control.mxml
>  
> b/examples/blog/BE0002_Using_Jewel_Alert_Control/src/main/royale/BE0002_Using_Jewel_Alert_Control.mxml
> index b498192..35441d2 100644
> --- 
> a/examples/blog/BE0002_Using_Jewel_Alert_Control/src/main/royale/BE0002_Using_Jewel_Alert_Control.mxml
> +++ 
> b/examples/blog/BE0002_Using_Jewel_Alert_Control/src/main/royale/BE0002_Using_Jewel_Alert_Control.mxml
> @@ -46,7 +46,7 @@
> 
> 
> 
> - click="clickHandler(event)"/>
> + click="clickHandler(event)"/>
> 
> 
> 
> diff --git 
> a/examples/blog/BE0003_Using_Jewel_Slider_Control/src/main/royale/BE0003_Using_Jewel_Slider_Control.mxml
>  
> b/examples/blog/BE0003_Using_Jewel_Slider_Control/src/main/royale/BE0003_Using_Jewel_Slider_Control.mxml
> index 8a701c6..2ac86e9 100644
> --- 
> a/examples/blog/BE0003_Using_Jewel_Slider_Control/src/main/royale/BE0003_Using_Jewel_Slider_Control.mxml
> +++ 
> b/examples/blog/BE0003_Using_Jewel_Slider_Control/src/main/royale/BE0003_Using_Jewel_Slider_Control.mxml
> @@ -50,7 +50,7 @@
>  maximum="300"
> valueChange="onValueChange(event)"/>
> 
> - height="80" secondary="true"
> + height="80" emphasis="secondary"
> click="clickHandler(event)"/>
> 
> 
> diff --git 
> a/examples/blog/BE0004_Adding_an_item_to_a_Jewel_List/src/main/royale/BE0004_Adding_an_item_to_a_Jewel_List.mxml
>  
> b/examples/blog/BE0004_Adding_an_item_to_a_Jewel_List/src/main/royale/BE0004_Adding_an_item_to_a_Jewel_List.mxml
> index f03c341..4111f04 100644
> --- 
> a/examples/blog/BE0004_Adding_an_item_to_a_Jewel_List/src/main/royale/BE0004_Adding_an_item_to_a_Jewel_List.mxml
> +++ 
> b/examples/blog/BE0004_Adding_an_item_to_a_Jewel_List/src/main/royale/BE0004_Adding_an_item_to_a_Jewel_List.mxml
> @@ -50,7 +50,7 @@
> 
> 
> 
> - click="clickHandler(event)"/>
> + click="clickHandler(event)"/>
> 
> 
> 
> diff --git 
> a/examples/blog/BE0005_Creating_a_group_of_Jewel_RadioButtons/src/main/royale/BE0005_Creating_a_group_of_Jewel_RadioButtons.mxml
>  
> b/examples/blog/BE0005_Creating_a_group_of_Jewel_RadioButtons/src/main/royale/BE0005_Creating_a_group_of_Jewel_RadioButtons.mxml
> index 07657be..265c5e6 100644
> --- 
> a/examples/blog/BE0005_Creating_a_group_of_Jewel_RadioButtons/src/main/royale/BE0005_Creating_a_group_of_Jewel_RadioButtons.mxml
> +++ 
> b/examples/blog/BE0005_Creating_a_group_of_Jewel_RadioButtons/src/main/royale/BE0005_Creating_a_group_of_Jewel_RadioButtons.mxml
> @@ -50,7 +50,7 @@
> 
> 
> 
> - click="opt3disable.disabled = !opt3disable.disabled"/>
> + click="opt3disable.disabled = !opt3disable.disabled"/>
> 
> 
> 
> diff --git 
> a/examples/blog/BE0007_Selecting_options_from_a_group_of_jewel_checkbox_controls/src/main/royale/BE0007_Selecting_options_from_a_group_of_jewel_checkbox_controls.mxml
>  
> b/examples/blog/BE0007_Selecting_options_from_a_group_of_jewel_checkbox_controls/src/main/royale/BE0007_Selecting_options_from_a_group_of_jewel_checkbox_controls.mxml
> index cd7d2f3..f3aeae7 100644
> --- 
> 

Problem with "this" inside static method

[Harbs]

I have the following class:
https://paste.apache.org/r7Ek <https://paste.apache.org/r7Ek>

Which gets cross-compiled to:
https://paste.apache.org/3k1r <https://paste.apache.org/3k1r>

The problem is here:
struct.process = function():void {
if (this.version === 0) {
for (var i:int = 0; i < this.offsets.length; i++) {
this.offsets[i] <<= 1;
}
}
};

In this case, “this” refers to the “struct” VersionedStruct instance. (At least 
in Javascript. Am I correct in assuming that’s the case in ActionScript as 
well?)

However, it gets cross-compiled to the following where “this" is the global 
this:

var /** @type {Function} */ __localFn0__ = function() {
  if (this.version === 0) {
for (var /** @type {number} */ i = 0; i < this.offsets.length; i++) {
  this.offsets[i] <<= 1;
}
  }
}
com.printui.fontkit.tables.loca.struct.process = __localFn0__;

What is the purpose of pulling the inline function out?

Harbs

Re: Problem with "this" inside static method

[Harbs]

> I'm unclear as to what the desired JS output really should be.  Would it 
> really work in JS if the function was directly assigned to a slot on the 
> instance instead of a temporary variable first?  If so why?

Yes. Because it’s a reference to an instance variable function “cal"l can 
replace “this” in that case.

> I'm also surprised that in JS, a function call can't have its 'this' pointer 
> reassigned by Function.call.  What is the actual JS that is running?

Struct.prototype.decode = function(stream, parent, length) {
  var res, _ref;
  if (length == null) {
length = 0;
  }
  res = this._setup(stream, parent, length);
  this._parseFields(stream, res, this.fields);
  if ((_ref = this.process) != null) {
_ref.call(res, stream);
  }
  return res;
};

_ref.call(res, stream) did not work because despite res being passed into the 
function, “this” remained the global this in the static function.

I’m really not sure why passing in this does not work on static functions. I 
was surprised myself.

FWIW, I rewrote the code to avoid using “this”, but it’s probably not a bad 
idea to fix this if possible…

Harbs

> On Jun 18, 2018, at 7:09 AM, Alex Harui  wrote:
> 
> Without actually looking at the compiler, I think that functions that are not 
> methods are pulled out and declared early for ES5 (strict?) reasons.  I'm not 
> sure there is a good distinction between a "local function" and assigning a 
> function to something.
> 
> IIRC, "assigning" some functions like in a function as a parameter like 
> addEventListener is supposed to generate Language.closure wrappers to make a 
> "closure" and bind the 'this' pointer to the method.
> 
> I'm unclear as to what the desired JS output really should be.  Would it 
> really work in JS if the function was directly assigned to a slot on the 
> instance instead of a temporary variable first?  If so why?
> 
> I'm also surprised that in JS, a function call can't have its 'this' pointer 
> reassigned by Function.call.  What is the actual JS that is running?
> 
> -Alex
> 
> On 6/17/18, 7:29 AM, "Harbs"  wrote:
> 
>An additional related problem:
> 
>Using “call” with a different “this” will not work with the aliased 
> functions either.
> 
>This is proving to be a challenge for me…
> 
>Harbs
> 
>> On Jun 17, 2018, at 12:02 PM, Harbs  wrote:
>> 
>> I have the following class:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fr7Ek=02%7C01%7Caharui%40adobe.com%7Cd50a81aaa8f8453ae0f408d5d45eb567%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636648425616368813=5Jz5bTTwhdwweaam%2BghkMCSwkM4WWyqnWHhr%2BrDpub8%3D=0
>>  
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Fr7Ek=02%7C01%7Caharui%40adobe.com%7Cd50a81aaa8f8453ae0f408d5d45eb567%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636648425616368813=5Jz5bTTwhdwweaam%2BghkMCSwkM4WWyqnWHhr%2BrDpub8%3D=0>
>> 
>> Which gets cross-compiled to:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2F3k1r=02%7C01%7Caharui%40adobe.com%7Cd50a81aaa8f8453ae0f408d5d45eb567%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636648425616378822=t50ucBXXnOezZW9mt%2BuMH5J5N%2BlJGGJBoBer7SkYU7I%3D=0
>>  
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2F3k1r=02%7C01%7Caharui%40adobe.com%7Cd50a81aaa8f8453ae0f408d5d45eb567%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636648425616378822=t50ucBXXnOezZW9mt%2BuMH5J5N%2BlJGGJBoBer7SkYU7I%3D=0>
>> 
>> The problem is here:
>> struct.process = function():void {
>>if (this.version === 0) {
>>for (var i:int = 0; i < this.offsets.length; i++) {
>>this.offsets[i] <<= 1;
>>}
>>}
>> };
>> 
>> In this case, “this” refers to the “struct” VersionedStruct instance. (At 
>> least in Javascript. Am I correct in assuming that’s the case in 
>> ActionScript as well?)
>> 
>> However, it gets cross-compiled to the following where “this" is the global 
>> this:
>> 
>> var /** @type {Function} */ __localFn0__ = function() {
>>  if (this.version === 0) {
>>for (var /** @type {number} */ i = 0; i < this.offsets.length; i++) {
>>  this.offsets[i] <<= 1;
>>}
>>  }
>> }
>> com.printui.fontkit.tables.loca.struct.process = __localFn0__;
>> 
>> What is the purpose of pulling the inline function out?
>> 
>> Harbs
> 
> 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

> On Jun 8, 2018, at 1:11 AM, Alex Harui  wrote:
> 
>In your animation code example, having the offsetParent code in the setter 
> makes the animation *way* less efficient. There is a an extra forced reflow 
> for every assignment of the new value.
> 
> I don't understand this point.  Can you provide more detail?  I would imagine 
> animations are going to cause reflows.   If there is a way to do animations 
> without resulting in a reflow that would be great.

The point is that there is a forced reflow. There will definitely be a reflow 
when the browser draws the animation change, but the offsetParent code forces 
the browser to calculate an extra reflow during the code execution prior to 
setting the x value.

This has two problems:
1. There is two reflows per cycle instead of one. If the animation sets both x 
and y values, there will be three reflows (the first two forced) instead of one.
2. The first reflow is forced to happen during javascript execution rather than 
when the browser decides it’s the optimum time to do so.

> 
>> I think you are saying there is a bug in the current code, but it somehow 
>> involves offsetParent changing.  Can you explain what causes offsetParent to 
>> change?
> 
>If/when the parent (or grandparent or great-grandparent, etc.) element 
> position changes from static to some other value, the offsetParent will 
> change.
> 
> Again, how important/prevalent is such a scenario?

It’s hard to say, but one such scenario sparked this discussion. I think that 
avoiding lifecycle issues is pretty important.

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

I was waiting to test it.

Here’s the results:



http://ns.adobe.com/mxml/2009;
xmlns:js="library://ns.apache.org/royale/basic" xmlns:ns1="*" 
applicationComplete="onComplete()" >

















Traces:

org.apache.royale.geom.Point {x: 30, y: 30}

I think that’s the result you wanted.

As to why: because it adds 20 to the bounding box of the element which is 10,10.

Mind you: The *visual* placement of the word Hello is actually 10,10 rather 
than 30,30, but the *logical* placement of it is 30,30. The reason is because 
the x and y values have no effect. To make the visual placement match the 
logical placement, the position of “child” needs to be changed to relative.

Harbs

> On Jun 8, 2018, at 1:50 AM, Alex Harui  wrote:
> 
> Harbs,
> 
> I posted a 3 MXML tag example.  Will it work like it does in Flex with your 
> changes?  If so, how/why?
> 
> If not, then we need the old code.  It is unfortunate that it causes extra 
> reflows, but setting x,y should be rare.  And if you can propose a different 
> solution that is PAYG, even better.  I keep wondering if we should go back to 
> setting position!=static on the parentNode when x,y is set.
> 
> The scenario where offsetParent changes also needs to be understood to know 
> how rare it is or if it is a result of some other bug.  We have to be careful 
> about spending lots of time on these cases if they are corner cases or a 
> side-effect.
> 
> All I'm trying to do is make sure your analysis and proposed changes are 
> correct.  There have been scenarios cited (RoyaleStore) and solutions 
> proposed (Application * selector0 that weren't valid so I'm just trying to 
> help make sure this is right.  It just isn't making sense to me that 
> offsetParent doesn't matter in the x,y calculation or that there is framework 
> code that changes offsetParent.  I don't want to worry about the performance 
> of x,y being set if most UI really shouldn't be setting it.  But for sure, it 
> has to produce the right values.
> 
> Thanks,
> -Alex
> 
> On 6/7/18, 3:26 PM, "Harbs"  wrote:
> 
> 
>> On Jun 8, 2018, at 1:11 AM, Alex Harui  wrote:
>> 
>>   In your animation code example, having the offsetParent code in the setter 
>> makes the animation *way* less efficient. There is a an extra forced reflow 
>> for every assignment of the new value.
>> 
>> I don't understand this point.  Can you provide more detail?  I would 
>> imagine animations are going to cause reflows.   If there is a way to do 
>> animations without resulting in a reflow that would be great.
> 
>The point is that there is a forced reflow. There will definitely be a 
> reflow when the browser draws the animation change, but the offsetParent code 
> forces the browser to calculate an extra reflow during the code execution 
> prior to setting the x value.
> 
>This has two problems:
>1. There is two reflows per cycle instead of one. If the animation sets 
> both x and y values, there will be three reflows (the first two forced) 
> instead of one.
>2. The first reflow is forced to happen during javascript execution rather 
> than when the browser decides it’s the optimum time to do so.
> 
>> 
>>> I think you are saying there is a bug in the current code, but it somehow 
>>> involves offsetParent changing.  Can you explain what causes offsetParent 
>>> to change?
>> 
>>   If/when the parent (or grandparent or great-grandparent, etc.) element 
>> position changes from static to some other value, the offsetParent will 
>> change.
>> 
>> Again, how important/prevalent is such a scenario?
> 
>It’s hard to say, but one such scenario sparked this discussion. I think 
> that avoiding lifecycle issues is pretty important.
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

We could always have a bead which sets:

.foo *{
   position: static;
}
To reset the defaults of all elements below “foo” to static.

Of course to change it to something else, you’d need:
.foo .baz{
   position: absolute;
}

I’m not sure how well this would work with the Jewel layout beads. I’m not sure 
what the specificity is on that.

Harbs

> On Jun 11, 2018, at 10:11 AM, Alex Harui  wrote:
> 
> The emulation Application is based on Container and thus creates a Div.  It 
> may not stay that way, but we did it so that the SystemManager can parent the 
> app like it does in Flex.
> 
> Feel free to commit the bead.  It won't hurt anything and some folks will be 
> able to use it.  I'm still wondering what the right answer is going to be for 
> the emulation component sets.  Or what to do if someone does have some part 
> of the DOM that they do not want style.position set.  There is no CSS way to 
> specify "set style on all parents", AFAIK, which is would help reduce 
> side-effects.
> 
> Later,
> -Alex
> 
> On 6/8/18, 9:02 AM, "Harbs"  wrote:
> 
>> Interesting idea, but I thought there was concern about the global selector 
>> affecting HTML around the app?
> 
>Currently, we don’t have an Application class that attaches to regular 
> divs It always controls the body element. Since we control the whole page, 
> it’s not a problem. If we do get to the point where a Royale app can be 
> injected into a random div, then setting a global selector might be a problem 
> if there’s other HTML which relies on static. We can have heavier-duty beads 
> to deal with setting relative positioning in those cases.
> 
>Harbs
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

FWIW, I’ve found that the single-most painful part of developing using Royale 
has been layouts.

I *think* defaulting to relative might help some issues, but things like 
percentages simply don’t work as you’d expect in HTML. I have been forced to 
stick calc() css in at least 12 places in my app.

> On Jun 11, 2018, at 11:00 AM, Carlos Rovira  wrote:
> 
> Hi,
> 
> I'm finding some problems with all this in Jewel as I go deeper with
> layouts. I'll write about it soon, I hope to solve some issue and left most
> important to discuss.
> As I get something working, I see a collateral effect that makes other
> thing that was working fail on some way...it's like a puzzle where
> positioning, layout, states must adjust to work ok. And still I'm getting
> hard time with ClassSelectorList. I think we have an huge issue with class
> name handling through Royale, since is not consistent, and class names are
> essential in html. For example since layouts class names are some kind of
> "typenames", those are removed when a user adds some class...
> 
> This is a sneak peak of what I'm finding, and hope to work more over it and
> try to raise only essential issues
> 
> 
> 
> 2018-06-11 9:36 GMT+02:00 Harbs :
> 
>> We could always have a bead which sets:
>> 
>> .foo *{
>>   position: static;
>> }
>> To reset the defaults of all elements below “foo” to static.
>> 
>> Of course to change it to something else, you’d need:
>> .foo .baz{
>>   position: absolute;
>> }
>> 
>> I’m not sure how well this would work with the Jewel layout beads. I’m not
>> sure what the specificity is on that.
>> 
>> Harbs
>> 
>>> On Jun 11, 2018, at 10:11 AM, Alex Harui 
>> wrote:
>>> 
>>> The emulation Application is based on Container and thus creates a Div.
>> It may not stay that way, but we did it so that the SystemManager can
>> parent the app like it does in Flex.
>>> 
>>> Feel free to commit the bead.  It won't hurt anything and some folks
>> will be able to use it.  I'm still wondering what the right answer is going
>> to be for the emulation component sets.  Or what to do if someone does have
>> some part of the DOM that they do not want style.position set.  There is no
>> CSS way to specify "set style on all parents", AFAIK, which is would help
>> reduce side-effects.
>>> 
>>> Later,
>>> -Alex
>>> 
>>> On 6/8/18, 9:02 AM, "Harbs"  wrote:
>>> 
>>>> Interesting idea, but I thought there was concern about the global
>> selector affecting HTML around the app?
>>> 
>>>   Currently, we don’t have an Application class that attaches to
>> regular divs It always controls the body element. Since we control the
>> whole page, it’s not a problem. If we do get to the point where a Royale
>> app can be injected into a random div, then setting a global selector might
>> be a problem if there’s other HTML which relies on static. We can have
>> heavier-duty beads to deal with setting relative positioning in those cases.
>>> 
>>>   Harbs
>>> 
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: [royale-asjs] branch develop updated: fix latest commit, since binary data to string method was not really working

[Harbs]

FWIW, I always check web API support in MDN and caniuse.com before using them 
in Royale.

Some more details win this specific issue:

It looks like you added toString() to BinaryData and changed UIDUtils to use 
that.

I don’t think a toString method in BinaryData makes sense. Flash was very smart 
about how it converted to a string. It was able to use the system encoding if 
available. etc.

Trying to emulate that kind of behavior in BinaryData is not going to be very 
PAYG. BinaryData already has UTF methods which cover the vast majority of text 
needs with BinaryData. Other types of text conversions should be handled using 
utility functions if needed.

There are ways to get cross-browser support similar to TextEncoder, but it’s 
not very PAYG either.[1]

My $0.02,
Harbs

[1]https://stackoverflow.com/questions/6965107/converting-between-strings-and-arraybuffers
 
<https://stackoverflow.com/questions/6965107/converting-between-strings-and-arraybuffers>
> On Jun 11, 2018, at 12:02 PM, Yishay Weiss  wrote:
> 
> Carols,
> 
> 
> 
> This breaks our app on IE and Edge, as they don’t support TextDecoder. Can 
> you fix this?
> 
> 
> 
> 
> From: carlosrov...@apache.org 
> Sent: Sunday, May 27, 2018 11:29:14 PM
> To: comm...@royale.apache.org
> Subject: [royale-asjs] branch develop updated: fix latest commit, since 
> binary data to string method was not really working
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> carlosrovira pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> 
> 
> The following commit(s) were added to refs/heads/develop by this push:
> new 028a26a  fix latest commit, since binary data to string method was 
> not really working
> 028a26a is described below
> 
> commit 028a26ad29aac3740f150f9b971e310731a69db9
> Author: Carlos Rovira 
> AuthorDate: Sun May 27 22:28:57 2018 +0200
> 
>fix latest commit, since binary data to string method was not really 
> working
> ---
> .../Core/src/main/royale/org/apache/royale/utils/BinaryData.as| 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>  
> b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> index 0aa3097..5500c8f 100644
> --- 
> a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> +++ 
> b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
> @@ -213,7 +213,7 @@ public class BinaryData implements IBinaryDataInput, 
> IBinaryDataOutput
> 
> COMPILE::JS
> {
> -return String.fromCharCode.apply(null, new Uint16Array(ba));
> +return (new TextDecoder("utf-8")).decode(ba);
> }
> }
> 
> @@ -804,7 +804,7 @@ public class BinaryData implements IBinaryDataInput, 
> IBinaryDataOutput
> }
> COMPILE::JS
> {
> -return _len;;
> +return _len;
> }
> }
> 
> 
> --
> To stop receiving notification emails like this one, please contact
> carlosrov...@apache.org.

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

The problem is that the child does not have a way of knowing what the extra 
space surrounding the parent (such as padding) will be.

One day, I’m probably going to work on a constrained layout…

> On Jun 11, 2018, at 1:20 PM, Yishay Weiss  wrote:
> 
> I guess we’re a bit prejudiced coming from Flex. Once you let go of the 
> notion that percentages are not of the available space but of the total 
> parent space, it sort of makes sense.

Re: [royale-asjs] branch develop updated: fix latest commit, since binary data to string method was not really working

[Harbs]

Why do you need toString rather than readUTFBytes()? FWIW, readUTFBytes() 
already falls back to TextDecoder when available.

> On Jun 11, 2018, at 2:07 PM, Carlos Rovira  wrote:
> 
> Hi,
> 
> no problem, we can go back to how it was that line before. I changed it be
> have the same in all that class, but wasn't aware of that problem.
> So I'll change to what we had, and make to String do the same. I think it
> should work the same and as well work on IE/Edge
> 
> I'll take a look right now
> 
> 2018-06-11 11:13 GMT+02:00 Harbs  <mailto:harbs.li...@gmail.com>>:
> 
>> FWIW, I always check web API support in MDN and caniuse.com before using
>> them in Royale.
>> 
>> Some more details win this specific issue:
>> 
>> It looks like you added toString() to BinaryData and changed UIDUtils to
>> use that.
>> 
>> I don’t think a toString method in BinaryData makes sense. Flash was very
>> smart about how it converted to a string. It was able to use the system
>> encoding if available. etc.
>> 
>> Trying to emulate that kind of behavior in BinaryData is not going to be
>> very PAYG. BinaryData already has UTF methods which cover the vast majority
>> of text needs with BinaryData. Other types of text conversions should be
>> handled using utility functions if needed.
>> 
>> There are ways to get cross-browser support similar to TextEncoder, but
>> it’s not very PAYG either.[1]
>> 
>> My $0.02,
>> Harbs
>> 
>> [1]https://stackoverflow.com/questions/6965107/converting-
>> between-strings-and-arraybuffers <https://stackoverflow.com/ 
>> <https://stackoverflow.com/>
>> questions/6965107/converting-between-strings-and-arraybuffers>
>>> On Jun 11, 2018, at 12:02 PM, Yishay Weiss 
>> wrote:
>>> 
>>> Carols,
>>> 
>>> 
>>> 
>>> This breaks our app on IE and Edge, as they don’t support TextDecoder.
>> Can you fix this?
>>> 
>>> 
>>> 
>>> 
>>> From: carlosrov...@apache.org 
>>> Sent: Sunday, May 27, 2018 11:29:14 PM
>>> To: comm...@royale.apache.org
>>> Subject: [royale-asjs] branch develop updated: fix latest commit, since
>> binary data to string method was not really working
>>> 
>>> This is an automated email from the ASF dual-hosted git repository.
>>> 
>>> carlosrovira pushed a commit to branch develop
>>> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>>> 
>>> 
>>> The following commit(s) were added to refs/heads/develop by this push:
>>>new 028a26a  fix latest commit, since binary data to string method
>> was not really working
>>> 028a26a is described below
>>> 
>>> commit 028a26ad29aac3740f150f9b971e310731a69db9
>>> Author: Carlos Rovira 
>>> AuthorDate: Sun May 27 22:28:57 2018 +0200
>>> 
>>>   fix latest commit, since binary data to string method was not really
>> working
>>> ---
>>> .../Core/src/main/royale/org/apache/royale/utils/BinaryData.as|
>> 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git 
>>> a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>> b/frameworks/projects/Core/src/main/royale/org/apache/
>> royale/utils/BinaryData.as
>>> index 0aa3097..5500c8f 100644
>>> --- a/frameworks/projects/Core/src/main/royale/org/apache/
>> royale/utils/BinaryData.as
>>> +++ b/frameworks/projects/Core/src/main/royale/org/apache/
>> royale/utils/BinaryData.as
>>> @@ -213,7 +213,7 @@ public class BinaryData implements IBinaryDataInput,
>> IBinaryDataOutput
>>> 
>>>COMPILE::JS
>>>{
>>> -return String.fromCharCode.apply(null, new
>> Uint16Array(ba));
>>> +return (new TextDecoder("utf-8")).decode(ba);
>>>}
>>>}
>>> 
>>> @@ -804,7 +804,7 @@ public class BinaryData implements IBinaryDataInput,
>> IBinaryDataOutput
>>>}
>>>COMPILE::JS
>>>{
>>> -return _len;;
>>> +return _len;
>>>}
>>>}
>>> 
>>> 
>>> --
>>> To stop receiving notification emails like this one, please contact
>>> carlosrov...@apache.org.
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira <http://about.me/carlosrovira>

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

Not disagreeing with anything you write here…

FWIW, I was thinking of adding a “constrainment” bead which would allow 
left/right/top/bottom values. This would likely work in the context of other 
layouts and be applied to components directly.

> On Jun 11, 2018, at 6:43 PM, Alex Harui  wrote:
> 
> So yeah, % works differently in Royale compared to Flex for some layouts, but 
> may not for other layouts.  It is ok if Harbs app couldn't use some of our 
> Basic layouts without adding calc().  If other sites can go to production 
> without using calc() then our simplest layouts should allow them to do so.  
> If there is a pattern where many apps use calc() a certain way, that should 
> be encapsulated into another layout in Royale.

Re: BinaryData and odd bytes

[Harbs]

DataView works in IE10+. The problem with DataView as that it’s slow.

> On Jun 19, 2018, at 9:24 PM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> for me any improvement seems ok, just ensure it works in all browsers
> (specially IE11)
> 
> thanks
> 
> 2018-06-19 19:25 GMT+02:00 Alex Harui :
> 
>> Isn't ByteArray mapped to UInt8Array?
>> 
>> On 6/19/18, 10:07 AM, "Harbs"  wrote:
>> 
>>BinaryData uses TypedArrays to read data. It seems that if the
>> ArrayBuffer does not divide evenly into the target TypedArray, you get a
>> runtime error.
>> 
>>For example:
>> 
>>readShort() works like this:
>>var ret:int = new Int16Array(ba, _position, 1)[0];
>> 
>>If _position is not divisible by 2 (i.e. an odd number), this causes a
>> RTE.
>> 
>>readInt() has a similar problem that _position needs to be divisible
>> by 4, etc.
>> 
>>Am I correct that Flash’s ByteArray works correctly in this situation?
>> We can use DataViews to solve the problem or we can read the bytes directly.
>> 
>>Thanks,
>>Harbs
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: BinaryData and odd bytes

[Harbs]

Yes. But you can convert from one TypedArray to another. That’s how the class 
handles reading multi-byte data.

The single underlying ArrayBuffer can be accessed by different TypedArrays.

> On Jun 19, 2018, at 8:25 PM, Alex Harui  wrote:
> 
> Isn't ByteArray mapped to UInt8Array?
> 
> On 6/19/18, 10:07 AM, "Harbs"  wrote:
> 
>BinaryData uses TypedArrays to read data. It seems that if the ArrayBuffer 
> does not divide evenly into the target TypedArray, you get a runtime error.
> 
>For example:
> 
>readShort() works like this:
>var ret:int = new Int16Array(ba, _position, 1)[0];
> 
>If _position is not divisible by 2 (i.e. an odd number), this causes a RTE.
> 
>readInt() has a similar problem that _position needs to be divisible by 4, 
> etc.
> 
>Am I correct that Flash’s ByteArray works correctly in this situation? We 
> can use DataViews to solve the problem or we can read the bytes directly.
> 
>Thanks,
>Harbs
> 

Re: Migrating Enterprise Flex Application

[Harbs]

Yes. You can see a demo of our app here:
https://marketinginflection.com/printui-demo.php 
<https://marketinginflection.com/printui-demo.php>

The business logic ported like a dream. We had to rewrite large portions of the 
view, but it was due to a modernization anyway.

We started our migration close to 2 years ago. It took about 17 months from 
when we started the migration until we had clients able to use the HTML version 
of the app.

If we were to do the migration today, it would take a fraction of the time. A 
lot of the time went to filling in missing pieces of Royale (i.e. E4X, Graphics 
and drawing APIs, porting TLF, filling in and adding components, etc.)

I find that we’re about as productive in Royale as we were working in Flex — 
possibly more so.

Prior to doing the Flex migration, we developed an Angular version of our app 
which was seriously dumbed down. It took nearly as long to develop as the 
Royale application and is nowhere near as capable. The Angular app is unwieldy 
to develop and performance is slow.

We’ve found the following advantages in regard to Flash:

1. The compiled minified HTML application is about half the size of the Flash 
application.
2. The app loads between 5 and 10 *times* faster than the Flash application did.
3. Debugging in the browser is IMO easier than Flash.
4. The browser profiling tools are great.
5. The application is general is much more performant than the Flash one thanks 
(I believe) to the improved Royale architecture.

Some more observations:
1. The performance of the native Royale components is amazing. Very fast!
2. It’s very helpful to see where XML performance takes a hit. We were able to 
use the profiler to discover where we had unnecessary E4X filtering and 
expressions when results could easily be cached.
3. I was pleased with E4X results in general, but I added a JXON class for 
lighter-weight XML processing.
4. We used a couple of third party components namely http://rangeslider.js.org/ 
<http://rangeslider.js.org/> and http://bgrins.github.io/spectrum/ 
<http://bgrins.github.io/spectrum/> I was surprised to discover that these 
components were by an order of a magnitude slower than any of the Royale 
components. They added so much overhead that the delay was noticeable and I had 
to implement some customizations to mitigate the effects of these.

Issues:
1. Debugging minified issues is difficult.
2. I’ve found some difficulty with layout situations that was easier in Flex. 
Of course, these problems are no better using other JS frameworks — probably 
worse.

I have other smaller applications developed with Royale as well. I don’t regret 
going this path at all!

HTH,
Harbs

> On Jun 19, 2018, at 6:57 PM, Alex Harui  wrote:
> 
> Yes.  PrintUI is our biggest example.  Harbs can share more details.
> 
> -Alex
> 
> On 6/19/18, 3:24 AM, "chembali"  wrote:
> 
>Has anyone ( big scale ) successfully migrated to Apache Royale from Flex? 
> I
>want to make sure that this migration path is a viable option for me? 
> Please
>share your thoughts. 
> 
>Thank you
>Sajith
> 
> 
> 
>--
>Sent from: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7C722806578bc447770e8a08d5d5cecfe0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636650006607089540=qfDnc3ElRa9Nhwi%2FKAoJdNC67JYFp8UP49hA5Zdjq14%3D=0
> 
> 

BinaryData and odd bytes

[Harbs]

BinaryData uses TypedArrays to read data. It seems that if the ArrayBuffer does 
not divide evenly into the target TypedArray, you get a runtime error.

For example:

readShort() works like this:
var ret:int = new Int16Array(ba, _position, 1)[0];

If _position is not divisible by 2 (i.e. an odd number), this causes a RTE.

readInt() has a similar problem that _position needs to be divisible by 4, etc.

Am I correct that Flash’s ByteArray works correctly in this situation? We can 
use DataViews to solve the problem or we can read the bytes directly.

Thanks,
Harbs

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

Before we go on, I just want to comment on this.

First of all, Piotr regularly comments on code that I (and others) commit. He 
has very often raised good points which prompted me to fix things that would 
have otherwise gone unnoticed. I appreciate it very much. Alex has called me 
out on many issues as well. It causes me to better think about the code I 
write. I wouldn’t want it any other way.

We *should* be looking at each other's code. That’s what “Commit Then Review” 
is all about. If we have to hesitate before we point things out or if we get 
defensive when others ask us to do things differently than we thought to do at 
first, the quality of our work will suffer.

Additionally, we’re not talking about looking at small changes with a 
magnifying glass here. We’re talking about major changes to the existing 
architecture of the framework. They might be warranted, but they might not. 
Discussing all the pertinent points is crucial to getting it right. If it takes 
more time, then that’s the cost of working together to reach consensus. Speed 
of coding might suffer a bit, but it will strengthen us as a community which is 
way more important. I want us *all* to come away from this discussion feeling 
like we're making the right decisions.

Are we on the same page here? I think this is important.

Thanks,
Harbs

> On May 30, 2018, at 5:17 PM, Carlos Rovira  wrote:
> 
> I think so... but hope this resolves soon, I think this discussions should
> be more agile and we shouldn't be looking with magnifying glass others
> changes.
> For example, I trust changes done by Alex, Piotr and yoursdo you think
> I'm analyzing Combobox changes...no, don't understand a month of discussion
> something that should be more coding than writing mails. So hope we'll be
> getting to a close too :)

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

Comments inline.

> On May 31, 2018, at 10:44 AM, Carlos Rovira  wrote:
> 
> I think there's a cost, don't know if the cost is higher or lower.

My question is whether we would actually be avoiding this cost by pulling the 
CSS out of Basic. I don’t know the answer to this question. I suspect that the 
compiler needs to analyze all the CSS files in every swc in the libs folder 
whether they are used or not. If that’s the case, there’s nothing to gain by 
pulling out the CSS for at least 90% of the use cases of Royale. Almost all 
Royale users will have the full lib of swcs.

> To me is
> not only the cost, is about as well as methodology. For me is incorrect to
> have a CSS always be compiled, no matter what kind of application I'll be
> constructing, even if nothing of that CSS goes into the final Application.
> You're making a useless compilation, that can introduce bugs or not, or you
> must keep and eye always that is not doing wrong things. If you don't put
> that CSS in mandatory SWC, your problems are all gone. I think CSS should
> be *always* in optional SWCs. For me maybe this is the most important
> concept or rule we should follow.

In theory, I agree with you. In practice, I’m not so sure.

The problem with pulling the TLC components out of Basic is that it requires a 
separate dependency for use. That makes more work for someone using Maven (for 
example). Also the likelihood of NONE of the TLCs to be used by other component 
sets is slim. I believe that Basic (or Express) composite components (such as 
ComboBox, DataGrid, etc.) should be used in Jewel and just the views should be 
swapped out. Dictating that Jewel can’t use Basic TLCs simply on principle is 
something I have a hard time with.

If using them would have a concrete negative effect on an app, I agree that it 
would be a problem, but I think we’ve determined that to not be the case.

Thanks,
Harbs

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Harbs]

I’m not talking about solving subclassing here.

I’m talking about one thing: How to determine what classnames the compiler 
writes to HTML CSS files for specific types.

Carlos and I would both like for the compiler to compile:
j|Button{
   background-color: #fff;
}

To: 
.jewel.Button{
   background-color: #fff;
}

Rather than:
org_apache_royale_jewel_Button{
   background-color: #fff;
}

And we all agree that we don’t want:
.Button{
   background-color: #fff;
}

The question is how to accomplish that. We’re suggesting to include some kind 
of meta tag or comment in the Button class source which acts as a compiler 
directive to specify exactly what to output. If you have another suggestion on 
how we can achieve that goal, that’s fine too.

Makes sense?
Harbs

> On May 31, 2018, at 12:30 AM, Alex Harui  wrote:
> 
> There has always been an option to keep/strip metadata in the output.  It is 
> -compiler.keep-as3-metadata.
> 
> I don't think I understand what you are proposing with metadata.  I thought 
> I'd shown that there was no easy way to solve what the runtime 
> (ValuesManager) should do. I thought we'd agreed upthread that metadata was 
> not required, and we would decide on some short-name abbreviations based on 
> the fully qualified names (package and class name).   The abbreviation scheme 
> doesn't have to be perfect, as long as it reduces likelihood of collision at 
> very low cost.  An example might be that you can register abbreviation 
> mappings so we say that "oarh" is short for "org.apache.royale.html".
> 
> Thoughts?
> -Alex
> 
> On 5/29/18, 5:47 AM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
> 
>Sorry for the delay in response here. I was not feeling very well last 
> week… (I forgot how much work an infant is…) ;-)
> 
>I think it’s time to wrap this up.
> 
>I don’t think there’s any completely PAYG solution to this problem. I 
> think conflicts need to be prevented by default.
> 
>I like the metadata and .basic.Button approach and I think it’s more PAYG 
> than org_apache_royale_html_Button. Theoretically, component sets can just 
> use “Button” and ignore conflicts for complete PAYG (although I would not 
> recommend that).
> 
>We should definitely use metadata that does not insure a runtime tax. If 
> we could somehow strip out the bracket metadata, I prefer that. Using 
> metadata would allow different component sets to make their own decisions.
> 
>Thanks,
>Harbs
> 
>> On May 21, 2018, at 7:41 PM, Alex Harui  wrote:
>> 
>> I think we are in agreement.  My most recent posts were intended to show 
>> that #2 is not easily solvable, if at all, and thus we should not invest 
>> time or energy there.
>> 
>> My only suggestions regarding #1 is that we do not invent a second naming 
>> system, and that whatever we do is PAYG in the sense that I don’t expect 
>> users to mix component sets as much as borrow beads from other component 
>> sets.  Folks who have the goal of building the smallest possible app with 
>> only one component set should not pay for the possibility of mixing in other 
>> component sets.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 5/21/18, 7:00 AM, "carlos.rov...@gmail.com 
>> <mailto:carlos.rov...@gmail.com> <mailto:carlos.rov...@gmail.com 
>> <mailto:carlos.rov...@gmail.com>> on behalf of Carlos Rovira" 
>> > <mailto:carlos.rov...@gmail.com><mailto:carlos.rov...@gmail.com 
>> <mailto:carlos.rov...@gmail.com>> on behalf of carlosrov...@apache.org 
>> <mailto:carlosrov...@apache.org> <mailto:carlosrov...@apache.org 
>> <mailto:carlosrov...@apache.org>>> wrote:
>> 
>>   I think Harbs is right here.
>> 
>>   We should take into account that as we focus on presentation (CSS, styles,
>>   drawings, colors, fonts) things are showing that before passed unnoticed.
>>   And now we have the chance to address all of this to make architecture and
>>   presentation get to its best. Both things are equally important here,
>>   Royale finaly has to be very careful with visual things since we are an
>>   interface framework, so if we get styling things works as flexible as
>>   possible, we can expect designers to work with royale.
>> 
>>   Thanks
>> 
>>   2018-05-21 11:35 GMT+02:00 Harbs > <mailto:harbs.li...@gmail.com>>:
>> 
>>> I’m getting confused.
>>> 
>>> Let me try and summarize the issues as I understand them:
>>> 
>>> There are two different types of issues: Compile time issues, and runtime
>>> issues.
>>> 
>>> C

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

I’m planning on working on this.

I think it’s very solvable.

> On May 31, 2018, at 9:02 AM, Carlos Rovira  wrote:
> 
>> 
>> I believe we still need a volunteer to change the royale-asjs code to
>> eliminate use of class selectors in its defaults.css files.
>> 
> 
> I think this should be done by someone like Peter that is more aware of the
> implications on that part.

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

The point of analyzing css is one I hadn’t thought of.

I’m a bit unclear on how the compiler deals with Framework CSS files. How does 
the compiler know which CSS files it needs to examine?

Most compiler methods use royalelib which points to a folder with all the 
Royale swcs. Does it make a difference whether a specific swc is actually used?

Unless you are using Maven, the full set of framework libs will always be 
downloaded. If Maven caches a particular sac, would that be in the royale lib 
path as well?

What is the performance hit on analyzing a swc css file? If we’re talking a few 
ms or less, I don’t think it’s worth worrying about.

Thanks,
Harbs

> On May 31, 2018, at 9:02 AM, Carlos Rovira  wrote:
> 
>> I see a claim that there is a problem because of the compiler parsing a
>> CSS file from a SWC where that CSS will not be used.  Is there proof that
>> it is a significant performance problem?  Such a claim should be backed by
>> data from an experiment by making the Basic defaults.css one blank line and
>> see if compile time of a Jewel-only example speeds up in a significant
>> way.  Also, we already have an -exclude-defaults-css-files option.  It
>> currently does not prevent parsing of the CSS file, but we could make it
>> so.
> 
> 
> I don't say it was a performance issue, I said that is no point in process
> a CSS that will never be use.
> As well if exclude option continues parsing the CSS, seems a bit incomplete
> right?

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Harbs]

Right.

> On May 31, 2018, at 10:29 AM, Carlos Rovira  wrote:
> 
> Just an important point here: I understand that in this case, we're talking
> about a metadata analyzed at compiler time, so there's no cost at runtime
> and that metadata will not be preserved. I think that would be great
> improvement
> 
> I think Alex is thinking in some kind of metadata at runtime, but I
> understand this is not the case.
> 
> thanks
> 
> 2018-05-31 8:58 GMT+02:00 Harbs  <mailto:harbs.li...@gmail.com>>:
> 
>> I’m not talking about solving subclassing here.
>> 
>> I’m talking about one thing: How to determine what classnames the compiler
>> writes to HTML CSS files for specific types.
>> 
>> Carlos and I would both like for the compiler to compile:
>> j|Button{
>>   background-color: #fff;
>> }
>> 
>> To:
>> .jewel.Button{
>>   background-color: #fff;
>> }
>> 
>> Rather than:
>> org_apache_royale_jewel_Button{
>>   background-color: #fff;
>> }
>> 
>> And we all agree that we don’t want:
>> .Button{
>>   background-color: #fff;
>> }
>> 
>> The question is how to accomplish that. We’re suggesting to include some
>> kind of meta tag or comment in the Button class source which acts as a
>> compiler directive to specify exactly what to output. If you have another
>> suggestion on how we can achieve that goal, that’s fine too.
>> 
>> Makes sense?
>> Harbs
>> 
>>> On May 31, 2018, at 12:30 AM, Alex Harui 
>> wrote:
>>> 
>>> There has always been an option to keep/strip metadata in the output.
>> It is -compiler.keep-as3-metadata.
>>> 
>>> I don't think I understand what you are proposing with metadata.  I
>> thought I'd shown that there was no easy way to solve what the runtime
>> (ValuesManager) should do. I thought we'd agreed upthread that metadata was
>> not required, and we would decide on some short-name abbreviations based on
>> the fully qualified names (package and class name).   The abbreviation
>> scheme doesn't have to be perfect, as long as it reduces likelihood of
>> collision at very low cost.  An example might be that you can register
>> abbreviation mappings so we say that "oarh" is short for
>> "org.apache.royale.html".
>>> 
>>> Thoughts?
>>> -Alex
>>> 
>>> On 5/29/18, 5:47 AM, "Harbs" >> <mailto:harbs.li...@gmail.com> > harbs.li...@gmail.com <mailto:harbs.li...@gmail.com>>> wrote:
>>> 
>>>   Sorry for the delay in response here. I was not feeling very well
>> last week… (I forgot how much work an infant is…) ;-)
>>> 
>>>   I think it’s time to wrap this up.
>>> 
>>>   I don’t think there’s any completely PAYG solution to this problem. I
>> think conflicts need to be prevented by default.
>>> 
>>>   I like the metadata and .basic.Button approach and I think it’s more
>> PAYG than org_apache_royale_html_Button. Theoretically, component sets can
>> just use “Button” and ignore conflicts for complete PAYG (although I would
>> not recommend that).
>>> 
>>>   We should definitely use metadata that does not insure a runtime tax.
>> If we could somehow strip out the bracket metadata, I prefer that. Using
>> metadata would allow different component sets to make their own decisions.
>>> 
>>>   Thanks,
>>>   Harbs
>>> 
>>>> On May 21, 2018, at 7:41 PM, Alex Harui >>> <mailto:aha...@adobe.com.INVALID>>
>> wrote:
>>>> 
>>>> I think we are in agreement.  My most recent posts were intended to
>> show that #2 is not easily solvable, if at all, and thus we should not
>> invest time or energy there.
>>>> 
>>>> My only suggestions regarding #1 is that we do not invent a second
>> naming system, and that whatever we do is PAYG in the sense that I don’t
>> expect users to mix component sets as much as borrow beads from other
>> component sets.  Folks who have the goal of building the smallest possible
>> app with only one component set should not pay for the possibility of
>> mixing in other component sets.
>>>> 
>>>> My 2 cents,
>>>> -Alex
>>>> 
>>>> On 5/21/18, 7:00 AM, "carlos.rov...@gmail.com 
>>>> <mailto:carlos.rov...@gmail.com> > carlos.rov...@gmail.com <mailto:carlos.rov...@gmail.com>> 
>> <mailto:carlos.rov...@gmail.com <mailto:carlos.rov...@gmail.com> > carlos.ro

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

To me, there are two classes of TLCs.

1. Simple TLCs are components such as Button, Checkbox, DropDownList etc. Which 
are designed to represent a single HTML element. For these components I 
completely understand and agree with your decision to *NOT* subclass Basic 
TLCs. The styling paradigm is different. We don’t want to bring in the 
superclass CSS, etc. We are in agreement here.

2, Composite TLCs are components such as ComboBox, DataGrid, possibly 
ImageButon etc. The components are basically UIBase components which describe 
how the pieces are wired together. The views are separate components that are 
declared. For these TLCs, there shouldn’t be a need to duplicate the classes or 
subclass the classes in Jewel at all. It should be possible to simply use Basic 
or Express composite TLCs and simply declare a Jewel view to use with them.

Is there an issue that I’m missing here?

Harbs

> On May 31, 2018, at 12:12 PM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> concreting more over if Jewel should or not extend Basic TLCs. That I think
> is the real point now to discuss. I'm sure it should not be the case. To
> sum to all that I exposed, it was not clearly sufficient enough (that I
> think it should be). Why I want all the class definitions overhead it will
> cause?
> 
> Why have the basic Button file with all the class text definitions and then
> the jewel Button file with all the definitions there? Think that we don't
> get anything profitable from all that overhead. I think that reusable code
> are pieces to construct, but not pieces designed to be final in some case.
> So to build a house I use bricks, cement, beams, and so on, but then I
> don't use the house to make a castle.
> 
> Moreover, think that Basic needs to change some component part...then maybe
> Jewel can't do that... that's a huge problem. So think that in the house I
> want to change a window from a place to another, then the castle will need
> to live with that without any reason and possibility to not be affected.
> 
> You must to recognize that although the theory here is good (remember that
> I started to be aligned with that), the reality is not the same.
> 
> My experience in many things in life make think that not all is 100% black
> or white. I think is great the philosophy we have on PAYG, beads and reuse,
> but I the case of TLCs and see that as something optionally extendible, but
> not mandatory. Or in other words TLCs are almost a leaf usable component
> that is mainly designed with a concrete end or use, and work great in
> aggregation (i.e: Express), but should not be part of any mandatory use.
> It's building blocks, in opposite, (the bricks) need to be enforced to
> reuse as much as we can.
> 
> Hope this additional vision will help on the overall discussion.
> 
> 
> 
> 
> 
> 2018-05-31 10:05 GMT+02:00 Harbs :
> 
>> Comments inline.
>> 
>>> On May 31, 2018, at 10:44 AM, Carlos Rovira 
>> wrote:
>>> 
>>> I think there's a cost, don't know if the cost is higher or lower.
>> 
>> My question is whether we would actually be avoiding this cost by pulling
>> the CSS out of Basic. I don’t know the answer to this question. I suspect
>> that the compiler needs to analyze all the CSS files in every swc in the
>> libs folder whether they are used or not. If that’s the case, there’s
>> nothing to gain by pulling out the CSS for at least 90% of the use cases of
>> Royale. Almost all Royale users will have the full lib of swcs.
>> 
>>> To me is
>>> not only the cost, is about as well as methodology. For me is incorrect
>> to
>>> have a CSS always be compiled, no matter what kind of application I'll be
>>> constructing, even if nothing of that CSS goes into the final
>> Application.
>>> You're making a useless compilation, that can introduce bugs or not, or
>> you
>>> must keep and eye always that is not doing wrong things. If you don't put
>>> that CSS in mandatory SWC, your problems are all gone. I think CSS should
>>> be *always* in optional SWCs. For me maybe this is the most important
>>> concept or rule we should follow.
>> 
>> In theory, I agree with you. In practice, I’m not so sure.
>> 
>> The problem with pulling the TLC components out of Basic is that it
>> requires a separate dependency for use. That makes more work for someone
>> using Maven (for example). Also the likelihood of NONE of the TLCs to be
>> used by other component sets is slim. I believe that Basic (or Express)
>> composite components (such as ComboBox, DataGrid, etc.) should be used in
>> Jewel and just the views should be swapped out. Dictating that Jewel can’t
>> use Basic TLCs simply on principle is something I have a hard time with.
>> 
>> If using them would have a concrete negative effect on an app, I agree
>> that it would be a problem, but I think we’ve determined that to not be the
>> case.
>> 
>> Thanks,
>> Harbs
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: [royale-asjs] branch feature/revert-refactor updated: Item Renderer firing itemChanged when mouse is dragged over item renderer and released

[Harbs]

This change looks correct to me and fixed the bug as I observed it.

Any idea why was mouse up used instead of click in the first place?

I assume the same fix should be applied to the swf block?

Harbs

> On May 27, 2018, at 2:24 PM, ha...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> harbs pushed a commit to branch feature/revert-refactor
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> 
> 
> The following commit(s) were added to refs/heads/feature/revert-refactor by 
> this push:
> new 3c61cf6  Item Renderer firing itemChanged when mouse is dragged over 
> item renderer and released
> 3c61cf6 is described below
> 
> commit 3c61cf64218eade1d74a69d08894483c33374bd1
> Author: Harbs <ha...@in-tools.com>
> AuthorDate: Sun May 27 14:24:17 2018 +0300
> 
>Item Renderer firing itemChanged when mouse is dragged over item renderer 
> and released
> ---
> .../apache/royale/html/beads/controllers/ItemRendererMouseController.as | 2 +-
> .../royale/org/apache/royale/html/supportClasses/StringItemRenderer.as  | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
> 
> 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 c9c53e5..a040368 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
> @@ -91,7 +91,7 @@ COMPILE::JS {
>   goog.events.listen(element, 
> goog.events.EventType.MOUSEOVER, this.handleMouseOver);
>   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.MOUSEUP, this.handleMouseUp);
> + goog.events.listen(element, 
> goog.events.EventType.CLICK, this.handleMouseUp);
>   }
>   }
>   
> diff --git 
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/supportClasses/StringItemRenderer.as
>  
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/supportClasses/StringItemRenderer.as
> index b49c826..5487068 100644
> --- 
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/supportClasses/StringItemRenderer.as
> +++ 
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/supportClasses/StringItemRenderer.as
> @@ -28,10 +28,10 @@ package org.apache.royale.html.supportClasses
> COMPILE::JS
> {
> import org.apache.royale.core.WrappedHTMLElement;
> + import org.apache.royale.html.util.addElementToWrapper;
> }
> import org.apache.royale.events.Event;
> import org.apache.royale.html.beads.ITextItemRenderer;
> -import org.apache.royale.html.util.addElementToWrapper;
> 
>   /**
>*  The StringItemRenderer class displays data in string form using the 
> data's toString()
> 
> -- 
> To stop receiving notification emails like this one, please contact
> ha...@apache.org.

Re: [royale-asjs] branch feature/revert-refactor updated: Item Renderer firing itemChanged when mouse is dragged over item renderer and released

[Harbs]

The problem was with a mousedown outside the renderer and a mouseup inside the 
renderer. That should not be handled as an itemClick.

> On May 27, 2018, at 2:29 PM, Piotr Zarzycki <piotrzarzyck...@gmail.com> wrote:
> 
> I'm using that renderer a lot but didn't notice anything wrong with that,
> although it looks like your fix is good. I hope to check it once all stuff
> back to normal in develop.
> 
> Thanks,
> Piotr
> 
> 2018-05-27 13:26 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> 
>> This change looks correct to me and fixed the bug as I observed it.
>> 
>> Any idea why was mouse up used instead of click in the first place?
>> 
>> I assume the same fix should be applied to the swf block?
>> 
>> Harbs
>> 
>>> On May 27, 2018, at 2:24 PM, ha...@apache.org wrote:
>>> 
>>> This is an automated email from the ASF dual-hosted git repository.
>>> 
>>> harbs pushed a commit to branch feature/revert-refactor
>>> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>>> 
>>> 
>>> The following commit(s) were added to refs/heads/feature/revert-refactor
>> by this push:
>>>new 3c61cf6  Item Renderer firing itemChanged when mouse is dragged
>> over item renderer and released
>>> 3c61cf6 is described below
>>> 
>>> commit 3c61cf64218eade1d74a69d08894483c33374bd1
>>> Author: Harbs <ha...@in-tools.com>
>>> AuthorDate: Sun May 27 14:24:17 2018 +0300
>>> 
>>>   Item Renderer firing itemChanged when mouse is dragged over item
>> renderer and released
>>> ---
>>> .../apache/royale/html/beads/controllers/ItemRendererMouseController.as
>> | 2 +-
>>> .../royale/org/apache/royale/html/supportClasses/StringItemRenderer.as
>> | 2 +-
>>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> 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 c9c53e5..a040368 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
>>> @@ -91,7 +91,7 @@ COMPILE::JS {
>>>  goog.events.listen(element,
>> goog.events.EventType.MOUSEOVER, this.handleMouseOver);
>>>  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.MOUSEUP, this.handleMouseUp);
>>> + goog.events.listen(element,
>> goog.events.EventType.CLICK, this.handleMouseUp);
>>>  }
>>>  }
>>> 
>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/html/supportClasses/StringItemRenderer.as
>> b/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/html/supportClasses/StringItemRenderer.as
>>> index b49c826..5487068 100644
>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/html/supportClasses/StringItemRenderer.as
>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/html/supportClasses/StringItemRenderer.as
>>> @@ -28,10 +28,10 @@ package org.apache.royale.html.supportClasses
>>>COMPILE::JS
>>>{
>>>import org.apache.royale.core.WrappedHTMLElement;
>>> + import org.apache.royale.html.util.addElementToWrapper;
>>>}
>>>import org.apache.royale.events.Event;
>>>import org.apache.royale.html.beads.ITextItemRenderer;
>>> -import org.apache.royale.html.util.addElementToWrapper;
>>> 
>>>  /**
>>>   *  The StringItemRenderer class displays data in string form
>> using the data's toString()
>>> 
>>> --
>>> To stop receiving notification emails like this one, please contact
>>> ha...@apache.org.
>> 
>> 
> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

gt; a lots of beads, since the right bead file to process is only the UI Set
> the user wants to use.
>  1.a-If you want to use Jewel, but declare first Jewel and then Basic,
> Basic setup wins over Jewel, and this shows clearly that this is nothing
> good.
>  1.b- This introduces, unwanted content, increase size, and is a hole of
> possible problems that we are creating  for free. This one solely is huge
> one.
> 2.- We as well remove the processing of CSS html rules, that are equally a
> generator of free problems.

These three are all bugs. I agree that we need to fix this, but I don’t think 
it’s an argument to change the lib structure.

> 3.- Something that comes clearly as you think more in it... why make Jewel
> dependent of Basic if Jewel don't extend any Basic component?

As I explained above, I don’t think this is (or should be) true.

> 3.a- If we continue thinking in that, why we are separating in libraries
> if we finaly link all? If we link all, then we should join Core, Basic,
> Jewel, Binding, Network, and so on…

Good question. For me, the primary reason to have separate projects is 
compilation speed while working on the framework.

The larger the code base gets, the longer it takes to compile and the heavier 
it is on IDEs. By breaking the framework into smaller projects, that allows for 
partial compilation and only opening a single smaller project in an IDE at a 
time.


> 4.- Separation is good since this make framework developers try to use the
> logical pieces they have. In the current way, we'll tend to mess things
> since we have lots of pieces available and can take the easy way.

I don’t understand what you mean here.

> 5.- The new dependencies is more flexible: we can use Jewel, and at a time,
> use Basic if we want, is up to the user to choose it, and that's more
> powerful that make them link a Basic UI Set that maybe he doesn't want use
> never

I keep hearing more flexible, but I don’t understand how and why. No one is 
forced to use any specific part of Basic. It’s there to take what's needed and 
ignore the rest.

> 6.- Why make an UI Set principal over the others? what have Basic over
> Jewel, or the opposite? Those are the same, but we have more than one since
> are designed with different goals in mind, so there's no point on make one
> link another (and again more over when the new one doesn't use any single
> class from the parent). That's for me clearly useless.

No. Basic is a “base” component set designed to have its pieces used by other 
component sets or directly by application developers. You don’t need to use 
*all* of Basic, but you are almost guaranteed to use *some* of Basic. Jewel 
is/was already doing that before you tried to separate pieces out. If we 
implemented things right, there should be no tax by making Basic a dependency.

> 7.- Future major versions: Some time in the future we'll want to create
> v2.0. As happen with many other projects (think for example in Flex with
> v1.0, 2.0, 3.0, 4.0) each major release implies dramatic changes. If you
> change from Java 5 to 6, 7, 8, 9...or Spring framework from 2.0, 3.0,
> 4.0...you know what I'm talking about. So for Royale this dependency design
> makes us more flexible and capable to make a 2.0, 3.0, and so on without
> affect 1.0 in a hard way, so our users will be less affected and will be
> able to upgrade in a more easy way.

I completely lost you here. What is the difference whether you call the 
dependency Foundation or Basic?

> 8.-Because as I said before, we have the same benefits than before, but now
> we have many more. While in the other way we are less flexible, more rigid
> and that's worse for Royale.
> 
> I think this is the major point of discussion we have, and hope that all
> points exposed will be sufficient to show the benefits and advantages of
> the dependencies. For me the major point
> is that we should not have any library in the tree of dependencies that has
> a CSS wiring beads, and that library is mandatory in all Royale
> applications. I think that's the main point of problems
> and we should fix it. that should be a rule "Mandatory libraries in a
> royale application can't have a CSS that wire code (beads)", for that
> reason, that part of Basic (controls, components and CSS should be in
> their own library Basic.swc, and the reusable code be in a common library
> that the rest can use (i.e: Foundation.swc)

It seems that your main point comes back to CSS. If we can’t fix the bugs 
related to the CSS, then I completely agree with you. We can’t have Basic CSS 
causing lots of classes and CSS to be included in apps for no good reason. 
However, I think those bugs are very fixable.

I’d also like to comment on this:

>> - As Harbs is saying, and I said earlier, Core is intended to be
>> implementation-

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

Sorry for my delayed response to all of this. I’ve been kind of out of it…

Can we try and get clear on the problems? I’d really like to figure out what we 
agree on before we try to nail down a solution.

I’d like to start with Alex’s list:
> First, the hopefully easy things we can agree on:
> -I have no objection to dropping "Bead" off of bead class names
> -I have no objection to moving all views into a view subfolder as long as 
> nobody else is concerned about the size and performance issues.
> -I have no objection to moving classes in Basic that are 
> org.apache.royale.html to org.apache.royale.basic.
> -I have no objection to doing a massive rename and long as it isn't me doing 
> the work.
> -Whatever is in Core and Basic now or before Carlos's started moving things 
> around is not perfect.

I agree with this completely. Carlos, do you agree as well? (I would be willing 
to help out with a rename, but I want to make sure it doesn't cause too much 
disruption.

Thanks,
Harbs

> On May 23, 2018, at 12:43 AM, Alex Harui  wrote:
> 
> Hi Carlos,
> 
> I guess I don't understand why separating beads from TLCs is better.  How 
> will that make things better for users or other component set developers?  
> That would effectively double the number of SWCs and each TLC SWC will need 
> its bead SWC.  That doesn't sound like a good thing to me, but if that's what 
> other folks want to do, that's fine with me.
> 
> I was just looking through the classes in Jewel.  It looks like JeweL doesn't 
> have a DataGrid yet..  When it does, I would think you will want to use the 
> DataGridModel from Express as it handles both Arrays and ICollectionViews.  
> We will probably create a similar model bead that takes both ICollectionViews 
> and Arrays for Lists and put that in Express as well.  Then we might decide 
> that is better for Jewel to use that model instead.  Or maybe we'll decide to 
> create a JewelExpress set that has those more general models that don't 
> require as much configuration.  Anyway, I hope you agree that at some point, 
> these more general models will be used by Express and some flavor of Jewel.  
> I don't think this general model should go in Core, or Basic (or some new 
> category called Foundation).  And at that point, Jewel or JewelExpress is 
> going to re-use that code in Express.
> 
> Component sets are encouraged to re-use existing code from any other SWC 
> since I think we've agreed that re-use is important.
> 
> My 2 cents,
> -Alex
> 
> On 5/21/18, 11:16 AM, "carlos.rov...@gmail.com 
> <mailto:carlos.rov...@gmail.com> on behalf of Carlos Rovira" 
> mailto:carlos.rov...@gmail.com> on behalf of 
> carlosrov...@apache.org <mailto:carlosrov...@apache.org>> wrote:
> 
>Hi Alex
> 
>what do you think about separating the part in Basic that is inherently the
>same as in Jewel (Button, CheckBox, TextInput, List, ...) along with CSS
>that wire the beads for Basic UI set, and left the fundamental building
>blocks as something that is not Core but can be reused by Basic and Jewel
>(Let's call this "Foundation" Lib, I even like this name for this library).
> 
>I mean that having "Foundation" lib and "Basic" lib, will be more clear,
>since we can expect what is in Basic will be never reused to build other UI
>Sets (MDL, or others can still hang from there or if someone wants to take
>the time refactor it).
> 
>Foundation will not have any CSS wiring beads. We can return classes from
>Core to Foundation.
> 
>Basic will have its own CSS wiring beads, the same for Jewel. Both will
>requiere Core and Foundation.
> 
>I assume this will make all of us happy.
> 
>We can as well do the package name changes to ensure consistency along all
>code and libraries.
> 
>Let me know what do you think
> 
>thanks
> 
>Carlos
> 
> 
>2018-05-21 19:38 GMT+02:00 Alex Harui :
> 
>> I understand this isn't the latest post on this thread, but it is the
>> easiest one for me to reply to:
>> 
>> First, the hopefully easy things we can agree on:
>> -I have no objection to dropping "Bead" off of bead class names
>> -I have no objection to moving all views into a view subfolder as long as
>> nobody else is concerned about the size and performance issues.
>> -I have no objection to moving classes in Basic that are
>> org.apache.royale.html to org.apache.royale.basic.
>> -I have no objection to doing a massive rename and long as it isn't me
>> doing the work.
>> -Whatever is in Core and Basic now or before Carlos's started moving
>> things around is not perfect.

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Harbs]

Sorry for the delay in response here. I was not feeling very well last week… (I 
forgot how much work an infant is…) ;-)

I think it’s time to wrap this up.

I don’t think there’s any completely PAYG solution to this problem. I think 
conflicts need to be prevented by default.

I like the metadata and .basic.Button approach and I think it’s more PAYG than 
org_apache_royale_html_Button. Theoretically, component sets can just use 
“Button” and ignore conflicts for complete PAYG (although I would not recommend 
that).

We should definitely use metadata that does not insure a runtime tax. If we 
could somehow strip out the bracket metadata, I prefer that. Using metadata 
would allow different component sets to make their own decisions.

Thanks,
Harbs

> On May 21, 2018, at 7:41 PM, Alex Harui  wrote:
> 
> I think we are in agreement.  My most recent posts were intended to show that 
> #2 is not easily solvable, if at all, and thus we should not invest time or 
> energy there.
> 
> My only suggestions regarding #1 is that we do not invent a second naming 
> system, and that whatever we do is PAYG in the sense that I don’t expect 
> users to mix component sets as much as borrow beads from other component 
> sets.  Folks who have the goal of building the smallest possible app with 
> only one component set should not pay for the possibility of mixing in other 
> component sets.
> 
> My 2 cents,
> -Alex
> 
> On 5/21/18, 7:00 AM, "carlos.rov...@gmail.com 
> <mailto:carlos.rov...@gmail.com> on behalf of Carlos Rovira" 
> mailto:carlos.rov...@gmail.com> on behalf of 
> carlosrov...@apache.org <mailto:carlosrov...@apache.org>> wrote:
> 
>I think Harbs is right here.
> 
>We should take into account that as we focus on presentation (CSS, styles,
>drawings, colors, fonts) things are showing that before passed unnoticed.
>And now we have the chance to address all of this to make architecture and
>presentation get to its best. Both things are equally important here,
>Royale finaly has to be very careful with visual things since we are an
>interface framework, so if we get styling things works as flexible as
>possible, we can expect designers to work with royale.
> 
>Thanks
> 
>2018-05-21 11:35 GMT+02:00 Harbs :
> 
>> I’m getting confused.
>> 
>> Let me try and summarize the issues as I understand them:
>> 
>> There are two different types of issues: Compile time issues, and runtime
>> issues.
>> 
>> Compile time issues are:
>> 1. Compiled css files do not differentiate between different packages.
>> (i.e. ImageButton type selectors will always compile to and .ImageButton
>> class selector, no matter what the package name is.
>> 2. There’s no way to prevent superclass dependencies from being included
>> in output when they are specified in Type selectors in Royale CSS files.
>> 
>> Runtime issues:
>> 1. Because of the issue in #1 above, there can be css styling conflicts
>> across component sets.
>> 
>> I’m pretty sure that ValuesManager is currently working fine.
>> 
>> From my perspective, the only issue which *needs* to be solved is compiler
>> issue #1. That seems like a relatively simple issue to solve. Solving that
>> does not require any runtime metadata. All we need is for the “typenames”
>> variable in a class to match whatever class name selector the compiler
>> outputs in the CSS file. It does *not* need to be the same qualified class
>> name that the ValuesManager uses at runtime. The classname that’s actually
>> assigned to the HTML element needs to match the CSS class selector in the
>> CSS file and it needs to be unique across packages.
>> 
>> Resolving this will fix all the runtime issue that I know of.
>> 
>> Resolving compiler issue #2 is a nice “plus” if we can do it. It would
>> allow subclassing components without necessarily bringing in all the
>> superclass CSS dependencies. I *think* your main points have to do with
>> issue #2.
>> 
>> Are we on the same page here, or am I missing something?
>> 
>> Harbs
>> 
>> 
>>> On May 19, 2018, at 2:50 AM, Alex Harui 
>> wrote:
>>> 
>>> 
>>> 
>>> On 5/18/18, 2:50 AM, "Harbs"  wrote:
>>>   And basic.css has:
>>>   RadioButton
>>>   {
>>>  font-size: 12px;
>>>  font-family: sans-serif;
>>>   }
>>> 
>>>   RadioButton is a Royale Type Selector as it should be. No discussion
>> on that front (with the exception that the styling should be removed from
>> the defaults.css).
>>> 
>>>   

Re: [Discussion] Summarizing all discussion about Royale organization and structure

[Harbs]

> On May 29, 2018, at 4:48 PM, Olaf Krueger  wrote:
> 
> Hi Carlos,
> 
> thanks for summarizing all this stuff.
> 
> @all
> I have not followed all the discussions, but I would like to ask if that
> what Carlos has presented is consensual.

Foundation Is what Carlos is proposing as a new way of organizing things. I 
think we need a lot of discussion before we can decide on something like that.

> 
>> Remove "Bead" ending from beads to make it all less verbose. 
> 
> Are there still any other ways of recognizing a bead then?
> Or doesn't it matter if something is a bead or whatever other?

I think all beads should be in some kind of bead package path.

> 
>> I offer my time to make this happen. 
> 
> Maybe I am wrong, but I guess these changes affect every existing Royale
> application and I could imagine that during this refactoring others maybe
> ran into merge conflicts.
> Do you have a strategy how this refactoring could be done as "quiet as
> possible"? 
> 
> Thanks,
> Olaf
> 
> 
> 
> 
> 
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Royale - BlazeDS working

[Harbs]

Very impressive! Great work! :-)

Harbs

> On May 31, 2018, at 9:51 PM, Carlos Rovira  wrote:
> 
> Forgot to share the info in Github page :)
> 
> https://github.com/apache/royale-asjs/wiki/Apache-Royale-communication-with-AMF-and-RemoteObject
>  
> <https://github.com/apache/royale-asjs/wiki/Apache-Royale-communication-with-AMF-and-RemoteObject>
> 
> 2018-05-31 20:49 GMT+02:00 Carlos Rovira  <mailto:carlosrov...@apache.org>>:
> Hi,
> 
> I get Royale working with BlazeDS. People using BlazeDS should be able to 
> finally start developing with Royale now! :)
> 
> Right now I'm test it with both the SampleAmfWebApp (in our repo) and with my 
> own backend (real flex/java app), and seems to work in both.
> 
> Things to have into account: While "clientId" is now working (we send the 
> required PING command, get the DSId and store it for later communication), we 
> need to use it with small messages turned off (blazeds turn it on by default).
> 
> This is the configuration per channel:
> 
> 
>   
> 
> false
> 
> 
> I think small messages are only something that will make our implementation 
> shine, but really is not required. I think that will improve a bit over the 
> normal message size. If you use as well the CompressedRemoteObject, that will 
> be a killer communication! :) 
> 
> About small messages, I'm trying to get it work, I uploaded the work 
> currently done, but still needs more to get it fully working.
> 
> As well I uploaded a SimpleRemoteObject that is a simpler version that should 
> work with AMF backends that require less things like AMFPHP. As I don't use 
> AMFPHP since many years I can say too much about it, but hope others will use 
> and report if something more is needed (The same for other AMF 
> implementations in other technologies).
> 
> Thanks!
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira <http://about.me/carlosrovira>
> 
> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira <http://about.me/carlosrovira>
> 

Last class selectors

[Harbs]

The only class selectors left in Basic defaults.css is:

.Application *, .royale *, . royale *:before, . royale *:after {
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}

I’m not sure how to best get rid of this.

Thoughts?
Harbs

Re: [royale-asjs] branch develop updated: Removed unselectable selector

[Harbs]

It does add the style to the class list.

The only question is how to add the selector to the CSS.

Thanks,
Harbs

> On Jun 4, 2018, at 10:24 AM, Carlos Rovira  wrote:
> 
> Hi,
> 
> I think as Alex that better way for this is the bead add the css style to
> classList.
> 
> thanks
> 
> 2018-06-04 6:33 GMT+02:00 Alex Harui :
> 
>> IMO, the better fix would be to just rename the selector in defaults.css
>> to be UnselectableElementBead and have UnselectableElementBead add
>> "UnselectableElementBead" to the classList.
>> 
>> Or am I not understanding what this does?
>> 
>> -Alex
>> 
>> 
>> On 6/2/18, 1:59 PM, "Harbs"  wrote:
>> 
>>What I really wanted to do here was create some self invoking code
>> which was run when the UnselectableElementBead class was loaded.
>> 
>>Is there any way of doing that without writing a static method and
>> invoking that?
>> 
>>Thanks,
>>Harbs
>> 
>> 
>>> On Jun 2, 2018, at 11:39 PM, 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=02%7C01%7Caharui%40adobe.com%7C9369538a50114755520308d5c8cb
>> b09c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636635699536531937=iPymBmOQfeD1312Szlsc6Fwc4E5GU2
>> Kj3OwfvmWh%2Bzk%3D=0
>>> 
>>> 
>>> The following commit(s) were added to refs/heads/develop by this
>> push:
>>>new b157ecf  Removed unselectable selector
>>> b157ecf is described below
>>> 
>>> commit b157ecff5ea11ff2035e105f266b0925c1970005
>>> Author: Harbs 
>>> AuthorDate: Sat Jun 2 23:39:28 2018 +0300
>>> 
>>>   Removed unselectable selector
>>> ---
>>> .../projects/Basic/src/main/resources/defaults.css |  9 -
>>> .../royale/html/beads/UnselectableElementBead.as   | 22
>> ++
>>> 2 files changed, 22 insertions(+), 9 deletions(-)
>>> 
>>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css
>> b/frameworks/projects/Basic/src/main/resources/defaults.css
>>> index ea02120..23a324d 100644
>>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>>> @@ -26,15 +26,6 @@
>>>  box-sizing: border-box;
>>> }
>>> 
>>> -.unselectable
>>> -{
>>> - -moz-user-select: -moz-none;
>>> - -khtml-user-select: none;
>>> - -webkit-user-select: none;
>>> - -o-user-select: none;
>>> - user-select: none;
>>> -}
>>> -
>>> Alert
>>> {
>>>  IBeadLayout: ClassReference("org.apache.royale.html.beads.layouts.
>> VerticalFlexLayout");
>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/html/beads/UnselectableElementBead.as b/frameworks/projects/Basic/
>> src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
>>> index 6697472..c80c907 100644
>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/html/beads/UnselectableElementBead.as
>>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/html/beads/UnselectableElementBead.as
>>> @@ -34,6 +34,27 @@ package org.apache.royale.html.beads
>>>  public class UnselectableElementBead implements IBead
>>>  {
>>>  /**
>>> +  * @royaleignorecoercion HTMLStyleElement
>>> +  */
>>> + private static function insertRule():void
>>> + {
>>> + // only do this once...
>>> + if(ruleInserted)
>>> + return;
>>> + ruleInserted = true;
>>> + // Inject a new css selector
>>> + COMPILE::JS
>>> + {
>>> + var style:HTMLStyleElement =
>> document.createElement('style') as HTMLStyleElement;
>>> + style.type = 'text/css';
>>> + style.innerHTML = '.unselectable
>> {-moz-user-select: none;-webkit-user-select: none;-ms-user-select:
>> none;user-select: none;}';
>>> + document.getElementsByTagName(
>> 'head')[0].appendChild(style);
>>> + }
>>> +
>>> + }
>>> + private static var ruleInserted:Boolean;
>>> +
>>> + /**
>>>   *  constructor.
>>>   *
>>>   *  @langversion 3.0
>>> @@ -57,6 +78,7 @@ package org.apache.royale.html.beads
>>>   */
>>>  public function set strand(value:IStrand):void
>>>  {
>>> + insertRule();
>>>  _strand = value;
>>> 
>>>  COMPILE::JS
>>> 
>>> --
>>> To stop receiving notification emails like this one, please contact
>>> ha...@apache.org.
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Incorrect descendent CSS output

[Harbs]

The following CSS:

TitleBar CloseButton
{
width: 16px;
height: 16px;
margin: 0px;
}

is output as:

.TitleBar CloseButton {
margin: 0px;
width: 16px;
height: 16px;
}

Instead of:

.TitleBar .CloseButton {
margin: 0px;
width: 16px;
height: 16px;
}

I think this is a bug.

Harbs

Re: [royale-asjs] branch develop updated: Added utility function to dynamically add CSS selectors

[Harbs]

FYI, this requires changes to the externs committed here:
https://github.com/royale-extras/closure-compiler/commit/323c6b5f37973fac2bd611bfeb6f80359e3bbc98
 
<https://github.com/royale-extras/closure-compiler/commit/323c6b5f37973fac2bd611bfeb6f80359e3bbc98>

> On Jun 4, 2018, at 12:04 PM, Carlos Rovira  wrote:
> 
> Great! This seems to be very useful!
> 
> thanks! :)
> 
> 2018-06-04 10:22 GMT+02:00 :
> 
>> This is an automated email from the ASF dual-hosted git repository.
>> 
>> harbs pushed a commit to branch develop
>> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>> 
>> 
>> The following commit(s) were added to refs/heads/develop by this push:
>> new 50ca711  Added utility function to dynamically add CSS selectors
>> 50ca711 is described below
>> 
>> commit 50ca711de856475536ea26934023ccb2ebdfc360
>> Author: Harbs 
>> AuthorDate: Mon Jun 4 11:22:53 2018 +0300
>> 
>>Added utility function to dynamically add CSS selectors
>> 
>>I’m not sure if there’s a good way to do this for swf.
>> ---
>> .../projects/Core/src/main/royale/CoreClasses.as   |  2 +
>> .../apache/royale/utils/css/addDynamicSelector.as  | 57
>> ++
>> 2 files changed, 59 insertions(+)
>> 
>> diff --git a/frameworks/projects/Core/src/main/royale/CoreClasses.as
>> b/frameworks/projects/Core/src/main/royale/CoreClasses.as
>> index a0a0b58..ee14d3a 100644
>> --- a/frameworks/projects/Core/src/main/royale/CoreClasses.as
>> +++ b/frameworks/projects/Core/src/main/royale/CoreClasses.as
>> @@ -303,6 +303,8 @@ internal class CoreClasses
>>import org.apache.royale.utils.date.addSeconds; addSeconds;
>>import org.apache.royale.utils.date.addYears; addYears;
>> 
>> +   import org.apache.royale.utils.css.addDynamicSelector;
>> addDynamicSelector;
>> +
>> import org.apache.royale.core.TextLineMetrics; TextLineMetrics;
>> import org.apache.royale.utils.ClassSelectorList; ClassSelectorList;
>> }
>> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/
>> royale/utils/css/addDynamicSelector.as b/frameworks/projects/Core/
>> src/main/royale/org/apache/royale/utils/css/addDynamicSelector.as
>> new file mode 100644
>> index 000..b7e495a
>> --- /dev/null
>> +++ b/frameworks/projects/Core/src/main/royale/org/apache/
>> royale/utils/css/addDynamicSelector.as
>> @@ -0,0 +1,57 @@
>> +///
>> /
>> +//
>> +//  Licensed to the Apache Software Foundation (ASF) under one or more
>> +//  contributor license agreements.  See the NOTICE file distributed with
>> +//  this work for additional information regarding copyright ownership.
>> +//  The ASF licenses this file to You under the Apache License, Version
>> 2.0
>> +//  (the "License"); you may not use this file except in compliance with
>> +//  the License.  You may obtain a copy of the License at
>> +//
>> +//  http://www.apache.org/licenses/LICENSE-2.0
>> +//
>> +//  Unless required by applicable law or agreed to in writing, software
>> +//  distributed under the License is distributed on an "AS IS" BASIS,
>> +//  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>> implied.
>> +//  See the License for the specific language governing permissions and
>> +//  limitations under the License.
>> +//
>> +///
>> /
>> +package org.apache.royale.utils.css
>> +{
>> +import org.apache.royale.core.IUIBase;
>> +
>> +/**
>> + *  Adds a CSS selector dynamically at runtime.
>> + *
>> + *  @param selector The CSS selector.
>> + *
>> + *  @param rule The CSS rule to apply.
>> + *
>> + *  @langversion 3.0
>> + *  @productversion Royale 0.9.3
>> + *  @royaleignorecoercion CSSStyleSheet
>> +*  @royaleignorecoercion HTMLStyleElement
>> + */
>> +public function addDynamicSelector(selector:String, rule:String):void
>> +{
>> +COMPILE::JS
>> +{
>> +var selectorString:String = selector + ' { ' + rule + ' }'
>> +var element:HTMLStyleElement = 
>> document.getElementById("royale_dynamic_css")
>> as HTMLStyleElement;
>> +if(element)
>> +{
>> +var sheet:CSSStyleSheet = element.sheet as CSSStyleSheet;
>> +  

Re: [royale-asjs] branch develop updated: Added utility function to dynamically add CSS selectors

[Harbs]

The Royale build pulls the externs from that repo. We have lots of changes on 
top of Google externs that we need. We used to use patch files, but it was 
cumbersome. Applying the changes directly to a fork works better.

I was just letting you know that if your build does not work, you might need to 
clear out your local cache.

HTH,
Harbs

> On Jun 4, 2018, at 12:30 PM, Carlos Rovira  wrote:
> 
> ok, but then don't understand that we have code that is not usable by our
> own.
> I think if that code can't be used, it should be as well in Royale-extras
> libs, so people wanting to use should grab both the modified closure
> compiler and the library with code that uses it
> 
> make this sense?
> 
> Thanks
> 
> 2018-06-04 11:10 GMT+02:00 Harbs  <mailto:harbs.li...@gmail.com>>:
> 
>> FYI, this requires changes to the externs committed here:
>> https://github.com/royale-extras/closure-compiler/commit/ 
>> <https://github.com/royale-extras/closure-compiler/commit/>
>> 323c6b5f37973fac2bd611bfeb6f80359e3bbc98 <https://github.com/royale- 
>> <https://github.com/royale->
>> extras/closure-compiler/commit/323c6b5f37973fac2bd611bfeb6f80359e3bbc98>
>> 
>>> On Jun 4, 2018, at 12:04 PM, Carlos Rovira 
>> wrote:
>>> 
>>> Great! This seems to be very useful!
>>> 
>>> thanks! :)
>>> 
>>> 2018-06-04 10:22 GMT+02:00 :
>>> 
>>>> This is an automated email from the ASF dual-hosted git repository.
>>>> 
>>>> harbs pushed a commit to branch develop
>>>> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>>>> 
>>>> 
>>>> The following commit(s) were added to refs/heads/develop by this push:
>>>>new 50ca711  Added utility function to dynamically add CSS selectors
>>>> 50ca711 is described below
>>>> 
>>>> commit 50ca711de856475536ea26934023ccb2ebdfc360
>>>> Author: Harbs 
>>>> AuthorDate: Mon Jun 4 11:22:53 2018 +0300
>>>> 
>>>>   Added utility function to dynamically add CSS selectors
>>>> 
>>>>   I’m not sure if there’s a good way to do this for swf.
>>>> ---
>>>> .../projects/Core/src/main/royale/CoreClasses.as   |  2 +
>>>> .../apache/royale/utils/css/addDynamicSelector.as  | 57
>>>> ++
>>>> 2 files changed, 59 insertions(+)
>>>> 
>>>> diff --git a/frameworks/projects/Core/src/main/royale/CoreClasses.as
>>>> b/frameworks/projects/Core/src/main/royale/CoreClasses.as
>>>> index a0a0b58..ee14d3a 100644
>>>> --- a/frameworks/projects/Core/src/main/royale/CoreClasses.as
>>>> +++ b/frameworks/projects/Core/src/main/royale/CoreClasses.as
>>>> @@ -303,6 +303,8 @@ internal class CoreClasses
>>>>   import org.apache.royale.utils.date.addSeconds; addSeconds;
>>>>   import org.apache.royale.utils.date.addYears; addYears;
>>>> 
>>>> +   import org.apache.royale.utils.css.addDynamicSelector;
>>>> addDynamicSelector;
>>>> +
>>>>import org.apache.royale.core.TextLineMetrics; TextLineMetrics;
>>>>import org.apache.royale.utils.ClassSelectorList;
>> ClassSelectorList;
>>>> }
>>>> diff --git a/frameworks/projects/Core/src/main/royale/org/apache/
>>>> royale/utils/css/addDynamicSelector.as b/frameworks/projects/Core/
>>>> src/main/royale/org/apache/royale/utils/css/addDynamicSelector.as
>>>> new file mode 100644
>>>> index 000..b7e495a
>>>> --- /dev/null
>>>> +++ b/frameworks/projects/Core/src/main/royale/org/apache/
>>>> royale/utils/css/addDynamicSelector.as
>>>> @@ -0,0 +1,57 @@
>>>> +///
>>>> /
>>>> +//
>>>> +//  Licensed to the Apache Software Foundation (ASF) under one or more
>>>> +//  contributor license agreements.  See the NOTICE file distributed
>> with
>>>> +//  this work for additional information regarding copyright ownership.
>>>> +//  The ASF licenses this file to You under the Apache License, Version
>>>> 2.0
>>>> +//  (the "License"); you may not use this file except in compliance
>> with
>>>> +//  the License.  You may obtain a copy of the License at
>>>> +//
>>>> +//  http://www.apache.org/licenses/LICENSE-2.0
>>>> +//
>>>> +/

Re: [royale-asjs] branch develop updated: remove invalid "; utf8" in all inlined svg images

[Harbs]

Looking at the Jewel themes, I thought of a possible suggestion for specifying 
SVG color:

Instead of inlining  fill='#{encodecolor($primary-color)}’, I’m wondering if it 
might be better to give the elements a class. Something like this:



and elsewhere:
.primary-fill{
   fill: $primary-color;
}

The same for secondary, strokes, etc.

It might even make sense to specify classes for primary and secondary colors 
and background colors, etc.

Doing so, might make it easier to swap color schemes. It’ll probably also 
result in simpler CSS.

Just a thought, :-)
Harbs

> On Jun 4, 2018, at 1:19 PM, carlosrov...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> carlosrovira pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
> 
> 
> The following commit(s) were added to refs/heads/develop by this push:
> new 9525660  remove invalid ";utf8" in all inlined svg images
> new db4b818  Merge branch 'develop' of 
> https://github.com/apache/royale-asjs into develop
> 9525660 is described below
> 
> commit 95256606096972af65d00a578741afd697a39c1e
> Author: Carlos Rovira 
> AuthorDate: Mon Jun 4 12:18:50 2018 +0200
> 
>remove invalid ";utf8" in all inlined svg images
> ---
> frameworks/themes/JewelTheme/src/main/resources/defaults.css | 12 ++--
> .../src/main/sass/components-primary/_checkbox.sass  | 10 +-
> .../src/main/sass/components-primary/_radiobutton.sass   | 10 +-
> .../JewelTheme/src/main/sass/components-primary/_slider.sass |  2 +-
> 4 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/frameworks/themes/JewelTheme/src/main/resources/defaults.css 
> b/frameworks/themes/JewelTheme/src/main/resources/defaults.css
> index 0663ee5..253b8c0 100644
> --- a/frameworks/themes/JewelTheme/src/main/resources/defaults.css
> +++ b/frameworks/themes/JewelTheme/src/main/resources/defaults.css
> @@ -236,14 +236,14 @@ j|Card {
>   border-radius: 3px;
> }
> .jewel.checkbox input:checked, .jewel.checkbox input:checked:active {
> -  background: url("data:image/svg+xml;utf8, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-763, -290)'> fill='%233CADF1' points='3 13 9 18 19 7 16 5 9 13 6 
> 10'>"), #f8f8f8;
> +  background: url("data:image/svg+xml, xmlns='http://www.w3.org/2000/svg'> transform='translate(760, 285)'>"), #f8f8f8;
>   background-repeat: no-repeat;
>   background-size: 90%;
>   background-position: center;
>   background-attachment: fixed;
> }
> .jewel.checkbox input:checked:checked:focus, .jewel.checkbox 
> input:checked:checked:active:focus, .jewel.checkbox 
> input:checked:active:checked:focus, .jewel.checkbox 
> input:checked:active:checked:active:focus {
> -  background: url("data:image/svg+xml;utf8, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-763, -290)'> fill='%233CADF1' points='3 13 9 18 19 7 16 5 9 13 6 
> 10'>"), #b3dffa;
> +  background: url("data:image/svg+xml, xmlns='http://www.w3.org/2000/svg'> transform='translate(760, 285)'>"), #b3dffa;
>   background-repeat: no-repeat;
>   background-size: 90%;
>   background-position: center;
> @@ -263,7 +263,7 @@ j|Card {
>   color: silver;
> }
> .jewel.checkbox input[disabled]:checked {
> -  background: url("data:image/svg+xml;utf8, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-763, -290)'> fill='%23cc' points='3 13 9 18 19 7 16 5 9 13 6 
> 10'>"), #f3f3f3;
> +  background: url("data:image/svg+xml, xmlns='http://www.w3.org/2000/svg'> transform='translate(760, 285)'>"), #f3f3f3;
>   background-size: 90%;
>   background-position: center;
>   background-repeat: no-repeat;
> @@ -371,14 +371,14 @@ j|Card {
>   border-radius: 50%;
> }
> .jewel.radiobutton input:checked, .jewel.radiobutton input:checked:active {
> -  background: url("data:image/svg+xml;utf8, version='1.1' xmlns='http://www.w3.org/2000/svg'> transform='translate(-616, -350)'> fill='%233CADF1' cx='11' cy='11' r='6'>"), #f8f8f8;
> +  background: url("data:image/svg+xml, xmlns='http://www.w3.org/2000/svg'> transform='translate(611, 345)'> r='6'>"), #f8f8f8;
>   background-repeat: no-repeat;
>   background-size: 60%;
>   background-position: center;
>   background-attachment: fixed;
> }
> .jewel.radiobutton input:checked:checked:focus, .jewel.radiobutton 
> input:checked:checked:active:focus, .jewel.radiobutton 
> input:checked:active:checked:focus, .jewel.radiobutton 
> input:checked:active:checked:active:focus {
> -  background: url("data:image/svg+xml;utf8, ver

Re: [royale-asjs] branch develop updated: Removed unselectable selector

[Harbs]

The closest example that we have is probably DisabledBead and 
DisabledAlphaBead. The DisabledAlphaBead applies styling (i.e. an alpha) when 
the DisabledBead disables a component.

I was suggesting that there could be a UnselectableAppearance bead which gets 
applied together with the UnselectableBead and could apply CSS properties. That 
would free the user from having to know which selectors are used.

Harbs

> On Jun 4, 2018, at 7:24 PM, Alex Harui  wrote:
> 
> I think it is too early Monday for me.  I don't understand what you mean by 
> "styling could also be a bead".  How would folks discover the selector?
> 
> Thanks,
> -Alex
> 
> On 6/4/18, 9:16 AM, "Harbs"  wrote:
> 
>Fair enough.
> 
>Of course the styling could also be a bead…
> 
>> On Jun 4, 2018, at 7:14 PM, Alex Harui  wrote:
>> 
>> IMO, it is easier for folks to know that there is a selector to override or 
>> add styles to if it is in one of our .css files instead of buried in code.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 6/4/18, 9:11 AM, "Harbs" > <mailto:harbs.li...@gmail.com>> wrote:
>> 
>>> I don't know why someone would want to override unselectable styles, but 
>>> the first idea that popped into my head was a different background color so 
>>> folks knew not to even bother to select text in the unselectable controls.  
>>> Another possibility is that there are other styles that may be needed 
>>> someday that control how screen readers deal with unselectable controls.
>> 
>>   Ah. You mean add additional styles. There’s no reason they couldn’t add an 
>> additional .unselectable selector with styling elsewhere in the CSS. I could 
>> go either way on this. If folks feel strongly it should be a “proper” 
>> selector, I’ll do that.
>> 
>>   Thanks,
>>   Harbs
>> 
>>> On Jun 4, 2018, at 7:07 PM, Alex Harui  wrote:
>>> 
>>> Feel free to change the name of the bead so that the Type Selector name 
>>> looks "better".  I think we agreed to drop the "Bead" portion of names 
>>> going forward.
>>> 
>>> If you are absolutely sure nobody will ever need to override what is in 
>>> that selector, then I'm fine with injecting it with code and using the new 
>>> utility function you created, but otherwise, I would hope we try to write 
>>> the framework without injecting styles with code.  Having overrideable 
>>> selectors should be the recommended practice for a framework.  We want 
>>> everything to be override-able.
>>> 
>>> I don't know why someone would want to override unselectable styles, but 
>>> the first idea that popped into my head was a different background color so 
>>> folks knew not to even bother to select text in the unselectable controls.  
>>> Another possibility is that there are other styles that may be needed 
>>> someday that control how screen readers deal with unselectable controls.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 6/4/18, 8:48 AM, "Harbs" >> <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>>> <mailto:harbs.li...@gmail.com>>> wrote:
>>> 
>>>  That would probably work. I’m not totally happy with that selector name.
>>> 
>>>  I can switch the implementation if you think that’s better. I’m not sure 
>>> why a user would override an “unelectable” style though.
>>> 
>>>  Harbs
>>> 
>>>> On Jun 4, 2018, at 6:45 PM, Alex Harui >>> <mailto:aha...@adobe.com.INVALID>> wrote:
>>>> 
>>>> Hi Harbs,
>>>> 
>>>> My suggestion for adding the selector is to make the selector look like a 
>>>> Type/Element Selector with the name "UnselectableElementBead".  If you do 
>>>> that, then wouldn't that selector be dropped out if nobody is using 
>>>> UnselectableElementBead?
>>>> 
>>>> I would hope we could find a solution that doesn't result in code 
>>>> injecting styles as that sort of screws up users overriding those styles.
>>>> 
>>>> My 2 cents,
>>>> -Alex
>>>> 
>>>> On 6/4/18, 1:14 AM, "Harbs" >>> <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>>>> <mailto:harbs.li...@gmail.com>> <mailto:harbs.li...@gmail.com 
>>>> <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>>>> <mailto:harbs.li...@gmail.com>

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

No. It’s one css selector in the CSS. No inline styles.

> On Jun 4, 2018, at 11:38 PM, Piotr Zarzycki  wrote:
> 
> Doing that does this mean that we are getting back to the previous state,
> where we have had position=relative everywhere ?
> 
> pon., 4 cze 2018 o 22:32 Harbs  napisał(a):
> 
>> Yes. But it cascades down.
>> 
>> I manually made this change to the TreeExample project, and it fixed the
>> bug.
>> 
>>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>>> 
>>> I'm still not understanding.  Style.position is not inheriting so how
>> would it cascade down?  Isn't .Application only applied to the ?
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>>> 
>>>   I’m suggesting that we change defaults.css
>>> 
>>>   from:
>>>   Application
>>>   {
>>>  padding: 0px;
>>>  margin: 0px;
>>>   }
>>> 
>>>   to:
>>>   Application
>>>   {
>>>  padding: 0px;
>>>  margin: 0px;
>>>  position: relative;
>>>   }
>>> 
>>>   I believe this will resolve this issue as the default would cascade
>> down to all sub-elements. The default would be relative, but beads would be
>> free to change that to whatever they want.
>>> 
>>>   Of course, that would dictate that UIBase belongs in Basic and not
>> Core… ;-)
>>> 
>>>   Harbs
>>> 
>>>> On Jun 4, 2018, at 7:10 PM, Alex Harui 
>> wrote:
>>>> 
>>>> I’m not sure exactly what change you are proposing, but UIBase used to
>> set position=relative on all positioners.  We took that away so that the
>> "flex" and other display/layout styles would not have to deal with the
>> excess clutter and overhead of having set position on so many elements in
>> the DOM.  Via PAYG, only the elements that need to have a style.position
>> should have it set.
>>>> 
>>>> My 2 cents,
>>>> -Alex
>>>> 
>>>> On 6/4/18, 8:44 AM, "Harbs"  wrote:
>>>> 
>>>>  It just occurred to me that the problem is due to the default
>> position being static.
>>>> 
>>>>  I just added position: relative; to the .Application css and that
>> resolved the issue as well.
>>>> 
>>>>  I wonder if we could completely do away with the offsetParent logic
>> in UIBase if we make the default position: relative. That would have a
>> major positive impact on performance.
>>>> 
>>>>  Thoughts?
>>>>  Harbs
>>>> 
>>>>> On Jun 4, 2018, at 6:36 PM, Alex Harui 
>> wrote:
>>>>> 
>>>>> Hi Yishay,
>>>>> 
>>>>> IMO, the new fix is better.  And you took the right approach by
>> examining the code flow in the debugger.  When layout fails for what
>> appears to be a timing issue (in this case, offsetParent not set), we
>> definitely want to take the time to carefully analyze why there is a timing
>> issue instead of apply code to work around the current lifecycle.
>>>>> 
>>>>> I'm not sure we can recommend a general pattern for layouts.  I think
>> there is some PAYG involved.  It could be that in some cases the View
>> should be responsible for setting style.position.  Then the layouts don't
>> have to spend the time verifying style.position.  In other cases the
>> layouts could be used in places where other potential layouts don't rely on
>> style.position being a particular value.  I think BasicLayout for
>> Containers is an example.
>>>>> 
>>>>> The code you used could be put into a utility function for layouts to
>> use to guarantee that x,y will work as expected.
>>>>> 
>>>>> Thanks,
>>>>> -Alex
>>>>> 
>>>>> On 6/4/18, 8:22 AM, "yishayw"  wrote:
>>>>> 
>>>>> Looking at it some more it has nothing to do with data binding. I
>> pushed a
>>>>> different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes
>> the
>>>>> layout itself. Here it's assumed the offsetParent is explicitly set
>> before
>>>>> children's x and y are set. Should this be a general pattern?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Sent from:
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

Sorry I was a bit confused. The selector that works is:

.Application * {
position: relative;
}

> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
> 
> Yes. But it cascades down.
> 
> I manually made this change to the TreeExample project, and it fixed the bug.
> 
>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>> 
>> I'm still not understanding.  Style.position is not inheriting so how would 
>> it cascade down?  Isn't .Application only applied to the ?
>> 
>> Thanks,
>> -Alex
>> 
>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>> 
>>   I’m suggesting that we change defaults.css
>> 
>>   from:
>>   Application
>>   {
>>  padding: 0px;
>>  margin: 0px;
>>   }
>> 
>>   to:
>>   Application
>>   {
>>  padding: 0px;
>>  margin: 0px;
>>  position: relative;
>>   }
>> 
>>   I believe this will resolve this issue as the default would cascade down 
>> to all sub-elements. The default would be relative, but beads would be free 
>> to change that to whatever they want.
>> 
>>   Of course, that would dictate that UIBase belongs in Basic and not Core… 
>> ;-)
>> 
>>   Harbs
>> 
>>> On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
>>> 
>>> I’m not sure exactly what change you are proposing, but UIBase used to set 
>>> position=relative on all positioners.  We took that away so that the "flex" 
>>> and other display/layout styles would not have to deal with the excess 
>>> clutter and overhead of having set position on so many elements in the DOM. 
>>>  Via PAYG, only the elements that need to have a style.position should have 
>>> it set.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 6/4/18, 8:44 AM, "Harbs"  wrote:
>>> 
>>>  It just occurred to me that the problem is due to the default position 
>>> being static.
>>> 
>>>  I just added position: relative; to the .Application css and that resolved 
>>> the issue as well.
>>> 
>>>  I wonder if we could completely do away with the offsetParent logic in 
>>> UIBase if we make the default position: relative. That would have a major 
>>> positive impact on performance.
>>> 
>>>  Thoughts?
>>>  Harbs
>>> 
>>>> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
>>>> 
>>>> Hi Yishay,
>>>> 
>>>> IMO, the new fix is better.  And you took the right approach by examining 
>>>> the code flow in the debugger.  When layout fails for what appears to be a 
>>>> timing issue (in this case, offsetParent not set), we definitely want to 
>>>> take the time to carefully analyze why there is a timing issue instead of 
>>>> apply code to work around the current lifecycle.
>>>> 
>>>> I'm not sure we can recommend a general pattern for layouts.  I think 
>>>> there is some PAYG involved.  It could be that in some cases the View 
>>>> should be responsible for setting style.position.  Then the layouts don't 
>>>> have to spend the time verifying style.position.  In other cases the 
>>>> layouts could be used in places where other potential layouts don't rely 
>>>> on style.position being a particular value.  I think BasicLayout for 
>>>> Containers is an example.
>>>> 
>>>> The code you used could be put into a utility function for layouts to use 
>>>> to guarantee that x,y will work as expected.
>>>> 
>>>> Thanks,
>>>> -Alex
>>>> 
>>>> On 6/4/18, 8:22 AM, "yishayw"  wrote:
>>>> 
>>>> Looking at it some more it has nothing to do with data binding. I pushed a
>>>> different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes the
>>>> layout itself. Here it's assumed the offsetParent is explicitly set before
>>>> children's x and y are set. Should this be a general pattern?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Sent from: 
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 

Re: Descendent selector issue

[Harbs]

Of course. That was the distinction I was making. Sorry for not making my point 
clearer.

Combination selectors (i.e. no space) work as expected.
Descendant selectors (i.e with space) do not.
I have not tested children selectors (i.e. “>”) or sibling selectors (i.e. “+” 
and “~”). I don’t know whether those are omitted.

My point is that if the ancestor is not used, the selector is not needed in the 
app and it should be omitted.

Hope that’s clearer… ;-)
Harbs

> On Jun 1, 2018, at 11:51 AM, Idylog - Nicolas Granon  
> wrote:
> 
> May I remind that the space between two selectors *is* significant.
> 
> Hope this helps
> 
> Nicolas Granon
> 
> 
> 
>> -Message d'origine-
>> De : Harbs [mailto:harbs.li...@gmail.com]
>> Envoyé : vendredi 1 juin 2018 10:40
>> À : dev@royale.apache.org
>> Objet : Descendent selector issue
>> 
>> TitleBar has the following CSS in defaults:
>> 
>> TitleBar .TitleBarTitle {
>>  font-weight: bold;
>>  padding: 0;
>>  margin: 0;
>> }
>> 
>> This seems to cause the CSS to be always output even if TitleBar is not
>> used.
>> 
>> Interestingly, the following CSS
>> ToggleTextButton.selected
>> {
>>  background-color: #d8d8d8;
>>  border: 1px solid #808080;
>>  padding: 4px;
>> }
>> 
>> does get omitted if ToggleTextButton is not used.
>> 
>> Is it correct to assume that this is a bug and if the parent/ancestor
>> the selector is not used, the CSS should be omitted?
>> 
>> Harbs
> 

Descendent selector issue

[Harbs]

TitleBar has the following CSS in defaults:

TitleBar .TitleBarTitle {
font-weight: bold;
padding: 0;
margin: 0;
}

This seems to cause the CSS to be always output even if TitleBar is not used.

Interestingly, the following CSS
ToggleTextButton.selected
{
background-color: #d8d8d8;
border: 1px solid #808080;
padding: 4px;
}

does get omitted if ToggleTextButton is not used.

Is it correct to assume that this is a bug and if the parent/ancestor the 
selector is not used, the CSS should be omitted?

Harbs

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

Hi Carlos,

Let me try and summarize in a nutshell the difference of opinion.

1. Should Jewel need/use Basic TLCs and CSS? You think no. Alex and I think yes.
2. Can we reach a point that by fixing all issues, there will be no runtime 
penalty of making Basic TLCs a dependency? You think no. Alex and I think yes.
3. Is there an issue with having to process Basic CSS during compilation and if 
yes can this be avoided? No-one has data on this yet. You think likely yes. I 
think likely no. Neither one of us really know the answer to this question.

I think that’s the sum total of the disagreement here. Agree?

I’d like to propose the following way forward.

1. Both Basic (Foundation) pieces and Basic TLCs should have the same package 
paths and namespaces.
2. By doing this, it will be very painless to pull Basic TLCs out of Basic into 
a separate project or merge it back in. (i.e. BasicComponents) (Either now, or 
in the future.)
3. Give Alex and me an opportunity to fix all issues and demonstrate that there 
will be no tax by making Basic TLCs a dependency.
4. Let’s complete Jewel and see wether there is a reason to use the TLCs/CSS.
5. Let’s do research on whether CSS processing during compilation is an issue 
and try and figure out our options if it is.
6. If we can’t make all the pieces of Basic truly optional, I’ll help you pull 
the Basic TLCs and CSS out into a separate project.

Would this be acceptable?

Thanks,
Harbs

> On Jun 1, 2018, at 11:25 AM, Carlos Rovira  wrote:
> 
> Hi Alex,
> 
> 2018-06-01 8:08 GMT+02:00 Alex Harui :
>> 
>> 
>>Key word here is *optional* not *mandatory*. Take this in mind, since
>> while
>>I have the option to use it or not, I even should have the option to
>> link
>>it or not, since there's no obligation or requeriment to use.
>> 
>> Everything is currently optional the way we have it, but the principle of
>> code re-use is primary.
> 
> 
> I think here can't agree. Until the refactor, I couldn't get rid off all
> the Basic things I didn't want. Rigth now is truly optional. In all
> possible views (code, css and library linking), while still you can take
> the old route as well. Everybody wins here.
> 
> 
>> Copying code to avoid a project dependency is not a recommended practice.
>> 
> 
> If I copy code is to change it. In the final picture you should never see
> the same code. For example yesterday I notice the existence of UIDUtils,
> that was almost the same code than RPCUIutils, so I removed the later. This
> days I plan to work on jewel layouts. This code is already different, but
> it will be even more, more CSS based and with more features. But it started
> as a copy of similar layout code in Basic. I think that's a normal process.
> 
> 
>> 
>> The Emulation set will use Basic beads for models and controllers and lots
>> of other things, if the simple implementations suffice.
>> 
> 
> I think this will be difficult or at least I don't see how that will work.
> If MXRoyale Button wants to have the Jewel visuals, it will need Jewel
> Button, not Basic Button, and the Jewel Theme. In general, Jewel controls
> and components setup a concrete visual structure through "createElementwith
> a concrete style structure that MXRoyale will need to replicate in code. So
> Basic seems very far from this requirement. for complex components where
> views are in place is more natural to use Jewel parts than go Basic. For
> example Slider in Basic has a different approach than in Jewel, so trying
> to make the visuals in Jewel work with Basic won't work.
> 
> I think to make this happen we should think not in actual Basic or Jewel
> but in only one unified set that can rely less in createElement and more in
> view implementations so we can have separated SWCs with Basic and Jewel
> views.
> 
> 
>> I mentioned this before.  The DataGridModel in Express is type-agnostic
>> (dataProvider is Object) whereas in Basic is assumes the dataProvider is an
>> Array.  And you can configure the Basic one to use different dataProviders
>> of different types.  That's on purpose, for PAYG (no extra code to handle
>> different types) and to help folks ensure type-safety.  But our users want
>> less configuration so you can pass "anything" into Express DataGrid's
>> dataProvider, just like Flex.
>> 
> 
> In Jewel, List has the problem that ICollectionView was not sufficient, so
> it has an extension of that class to use ArrayList that seems to be the
> normal use case.
> But people can override that bead for general use or in a particular case.
> 
> 
>>Doubling no, jut one: Foundation - Basic. The rest is up to
>> discussion, but
>>since are not required right now (a

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

ater? don't
> understand why...when you have a simpler and better way that is removing
> the dependency and it's the most easy and quick way and will preserver the
> integrity always in the future.

Because I don’t think that removing the dependency is the right thing to do. 
Again, whether I’m right or wrong will become clearer as Jewel gets completed. 
If I’m wrong, I’ll be happy to pull out the Basic TLCs myself.

> 
>> 6. If we can’t make all the pieces of Basic truly optional, I’ll help you
>> pull the Basic TLCs and CSS out into a separate project.
>> 
>> 
> Ok, my only concern here is how to do this plan, since I see many problems
> that only can be making just what I can avoid.

What problems do you envision that are stopping the 0.9.3 release? Can we get 
things working for the release and then take it from there?

I’m working on getting rid of all the class selectors which are bringing Basic 
pieces into Jewel. Please give me a chance to finish this work.

Thanks,
Harbs

Re: Descendent selector issue

[Harbs]

Ah.

I did not think of modules. Good point.

> On Jun 1, 2018, at 8:04 PM, Alex Harui  wrote:
> 
> AIUI:
> 
> TitleBar .TitleBarTitle  means "any component with the className 
> "TitleBarTitle" that is a child of a TitleBar.
> 
> ToggleTextButton.selected means "Any ToggleTextButton that ALSO has the 
> classname "selected"
> 
> Without digging through the code, my recollection of the logic says only the 
> last "selector"  is used to determine whether the CSS rules are kept or not.  
> In the first case, the last selector is ".TitleBarTitle" and in the second, 
> it is "ToggleTextButton.selected".
> 
> Should it work this way?  Maybe.  In the general case of multiple module 
> applications, the compiler cannot know if some component will be given the 
> className "TitleBarTitle" and added to a TitleBar that came from some other 
> module.  But it can know that there are no ToggleTextButtons in the current 
> module it is compiling.  So I think that's why it works the way it does.  And 
> maybe that is right.  Don't know.  IMO, just like we are replacing other 
> class selectors with subclasses, the same should be done for whatever is 
> being assigned the className TitleBarTitle.
> 
> HTH,
> -Alex
> 
> On 6/1/18, 2:09 AM, "Harbs"  wrote:
> 
>Of course. That was the distinction I was making. Sorry for not making my 
> point clearer.
> 
>Combination selectors (i.e. no space) work as expected.
>Descendant selectors (i.e with space) do not.
>I have not tested children selectors (i.e. “>”) or sibling selectors (i.e. 
> “+” and “~”). I don’t know whether those are omitted.
> 
>My point is that if the ancestor is not used, the selector is not needed 
> in the app and it should be omitted.
> 
>Hope that’s clearer… ;-)
>Harbs
> 
>> On Jun 1, 2018, at 11:51 AM, Idylog - Nicolas Granon  
>> wrote:
>> 
>> May I remind that the space between two selectors *is* significant.
>> 
>> Hope this helps
>> 
>> Nicolas Granon
>> 
>> 
>> 
>>> -Message d'origine-
>>> De : Harbs [mailto:harbs.li...@gmail.com]
>>> Envoyé : vendredi 1 juin 2018 10:40
>>> À : dev@royale.apache.org
>>> Objet : Descendent selector issue
>>> 
>>> TitleBar has the following CSS in defaults:
>>> 
>>> TitleBar .TitleBarTitle {
>>> font-weight: bold;
>>> padding: 0;
>>> margin: 0;
>>> }
>>> 
>>> This seems to cause the CSS to be always output even if TitleBar is not
>>> used.
>>> 
>>> Interestingly, the following CSS
>>> ToggleTextButton.selected
>>> {
>>> background-color: #d8d8d8;
>>> border: 1px solid #808080;
>>> padding: 4px;
>>> }
>>> 
>>> does get omitted if ToggleTextButton is not used.
>>> 
>>> Is it correct to assume that this is a bug and if the parent/ancestor
>>> the selector is not used, the CSS should be omitted?
>>> 
>>> Harbs
>> 
> 
> 
> 

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

Hi Carlos,

I think our wires are still crossed. Rather than me trying to address your 
points below, I think we still need to work on definitions. Let me try like 
this:

A Jewel dependency on “Foundation” is OK for you, but a dependency on “Basic” 
is not. Right?

In your view, which files in the Basic project make it “Basic” rather than 
“Foundation”? Put another way: Which files can we remove from Basic to make it 
“Foundation”?

If we can narrow this down to a list of files which you believe make a 
dependency “bad”, I think that focuses the issue a lot better. We don’t need a 
full list of files at the moment, but a sampling of the files that you view as 
“bad dependencies” would make it much clearer for me (and others). If you 
prefer, I could compose a list of files myself, but I’d like to hear from you 
what you think.

Thanks,
Harbs

> On Jun 1, 2018, at 5:55 PM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> 2018-06-01 13:07 GMT+02:00 Harbs :
> 
>> 
>> We both agree that Jewel should have a dependency on “Foundation” or
>> “Basic”. The only question is TLCs. What practical difference does this
>> point have?
>> 
>> 
> All thoughts about why not make TLCs and CSS was exposed several times. I
> think you already know what I think about it. Don't think write about it
> one more time have sense.
> I think you don't expose opposite arguments. Maybe this part is in a field
> dominated by a mixture of technical issues and how each of us likes to
> codify things and for this reason is hard to reach consensus. I believe
> that your vision may be correct, but I personally see more benefits in
> which I am defending. If I must to choose only on arguments or evidences, I
> think the way I'm proposing should be the way to go.
> 
> 
> 
>>> 
>>>> 
>>>> I’d like to propose the following way forward.
>>>> 
>>>> 1. Both Basic (Foundation) pieces and Basic TLCs should have the same
>>>> package paths and namespaces.
>>>> 
>>> 
>>> Don't think so. If you want to promote reusable pieces, the refactor of
>>> names should make them go to a different package other than Basic. It's
>>> like to propose to put on a jewel package would be a bad decision. In the
>>> refactor I was for "core", since the common pieces was in Core. So I
>> think
>>> it will depend on the name of the library to choose. For me Basic is a
>> good
>>> name for Basic UI Set since clearly states what all the code there do. I
>>> still think Foundation is a good name, but if you don't like, I think you
>>> should propose other one that seems more appropriate.
>> 
>> I really don’t care very much what the project name is. “Base” “Basic” and
>> “Foundation” are all good. To me they all mean the same thing.
> 
> 
> I really see a tangible difference between "foundation" pieces to use all
> over other royale parts and "basic" pieces that are the most basic or base
> representation while express or jewel are more complex and pursue different
> complex scenarios (so is basic vs complex).
> 
> 
>> I’d prefer to stick with Basic because I don’t see a gain in renaming it.
>> Foundation is a “long” name. I don’t see a reason to make the name longer.
>> I feel very strongly that the TLCs should have the same paths and
>> namespaces as the rest of Basic.
> 
> I consider Basic TLCs a part of the Basic concept. Even if Jewel doesn’t
>> end up using it, other component sets likely will. Creating a new package
>> path and namespace serves no function and makes things more difficult. Why
>> go there?
>> 
> 
> ok, for this is not crucial, is only something that the other name like me
> more and fit for me more, but in this part I'm ok if finaly we need to go
> with "basic". In every negotiation we can't get *all*
> 
> 
> 
>> 
>>> 
>>>> 2. By doing this, it will be very painless to pull Basic TLCs out of
>> Basic
>>>> into a separate project or merge it back in. (i.e. BasicComponents)
>> (Either
>>>> now, or in the future.)
>>>> 
>>> 
>>> I think we must be doing it moving little by little and ensuring after a
>>> little refactor all continues working.
>> 
>> Moving what? I don’t think moving the entire list of TLCs (i.e. what is
>> used in the Basic CSS) is more than a few hours of work.
>> 
> 
> In fact the initial refactor took me 2 days of about 10-12 work hours to
> complete. This will take a time to do it, but it can be done without
> problem with patience and perseverance.
> 
>> 
>> Basic *is* that s

Re: [royale-asjs] 01/02: global point should ignore window scrolling

[Harbs]

Good point.

I’ll try to convert these to utility functions.

FWIW, The only difference is "- window.scrollX”.

I’m also pretty sure that the “older browser fallback” which is a major part of 
the code is not necessary. getBoundingClientRec() seems to be supported back 
through IE9.[1] We should probably clean out the “offset” code.

Harbs

[1]https://caniuse.com/#search=getBoundingClientRect 
<https://caniuse.com/#search=getBoundingClientRect>


> On Jun 1, 2018, at 7:22 PM, Alex Harui  wrote:
> 
> For PAYG, should we have a version of the API that worries about window 
> scrolling and one that doesn't?  If your app is designed not to scroll, I 
> would think you wouldn't have to pay for this extra code?
> 
> -Alex
> 
> On 6/1/18, 4:26 AM, "ha...@apache.org <mailto:ha...@apache.org>" 
> mailto: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=02%7C01%7Caharui%40adobe.com%7C85aafe13907e4728298508d5c7b28caa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634492071894168=upjYhaXnXu4zo0rSp731%2ByM89crQMlK%2BothTSTXQlqA%3D=0
>  
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git=02%7C01%7Caharui%40adobe.com%7C85aafe13907e4728298508d5c7b28caa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634492071894168=upjYhaXnXu4zo0rSp731%2ByM89crQMlK%2BothTSTXQlqA%3D=0>
> 
>commit e5328655b9991fe44b92c61d1b18aa7a4cc104b5
>Author: Harbs mailto:ha...@in-tools.com>>
>AuthorDate: Tue May 29 12:25:55 2018 +0300
> 
>global point should ignore window scrolling
>---
> .../royale/org/apache/royale/utils/PointUtils.as   | 28 
> +-
> 1 file changed, 17 insertions(+), 11 deletions(-)
> 
>diff --git 
> a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/PointUtils.as
>  
> b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/PointUtils.as
>index 264102c..f96e61c 100644
>--- 
> a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/PointUtils.as
>+++ 
> b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/PointUtils.as
>@@ -71,18 +71,24 @@ package org.apache.royale.utils
> var x:Number = pt.x;
> var y:Number = pt.y;
> var element:HTMLElement = local.element as HTMLElement;
>+  if ( element.getBoundingClientRect ) {// TODO 
> take scrollbar widths into account
>+  var rect:Object = 
> element.getBoundingClientRect();
>+  x = x - rect.left - window.scrollX;
>+  y = y - rect.top - window.scrollY;
>+  } else { // for older browsers, but 
> offsetParent is soon to be deprecated from chrome
> 
>-do {
>-x -= element.offsetLeft;
>-y -= element.offsetTop;
>-  if (local['parent'] !== undefined) {
>-local = local.parent;
>-element = local ? local.element as HTMLElement : 
> null;
>-} else {
>-element = null;
>+do {
>+x -= element.offsetLeft;
>+y -= element.offsetTop;
>+if (local['parent'] !== undefined) {
>+local = local.parent;
>+element = local ? local.element as 
> HTMLElement : null;
>+} else {
>+element = null;
>+}
> }
>+while (element);
> }
>-while (element);
> return new org.apache.royale.geom.Point(x, y);
> 
> }
>@@ -119,8 +125,8 @@ package org.apache.royale.utils
> 
>   if ( element.getBoundingClientRect ) {// TODO 
> take scrollbar widths into account
>   var rect:Object = 
> element.getBoundingClientRect();
>-  x = rect.left + x;
>-  y = rect.top + y;
>+  x = rect.left + x + window.scrollX;
>+  y = r

Re: [royale-asjs] branch develop updated: Removed unselectable selector

[Harbs]

What I really wanted to do here was create some self invoking code which was 
run when the UnselectableElementBead class was loaded.

Is there any way of doing that without writing a static method and invoking 
that?

Thanks,
Harbs


> On Jun 2, 2018, at 11:39 PM, 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://gitbox.apache.org/repos/asf/royale-asjs.git
> 
> 
> The following commit(s) were added to refs/heads/develop by this push:
> new b157ecf  Removed unselectable selector
> b157ecf is described below
> 
> commit b157ecff5ea11ff2035e105f266b0925c1970005
> Author: Harbs 
> AuthorDate: Sat Jun 2 23:39:28 2018 +0300
> 
>Removed unselectable selector
> ---
> .../projects/Basic/src/main/resources/defaults.css |  9 -
> .../royale/html/beads/UnselectableElementBead.as   | 22 ++
> 2 files changed, 22 insertions(+), 9 deletions(-)
> 
> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css 
> b/frameworks/projects/Basic/src/main/resources/defaults.css
> index ea02120..23a324d 100644
> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
> @@ -26,15 +26,6 @@
>   box-sizing: border-box;
> }
> 
> -.unselectable
> -{
> - -moz-user-select: -moz-none;
> - -khtml-user-select: none;
> - -webkit-user-select: none;
> - -o-user-select: none;
> - user-select: none;
> -}
> -
> Alert
> {
>   IBeadLayout: 
> ClassReference("org.apache.royale.html.beads.layouts.VerticalFlexLayout");
> diff --git 
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
>  
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
> index 6697472..c80c907 100644
> --- 
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
> +++ 
> b/frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
> @@ -34,6 +34,27 @@ package org.apache.royale.html.beads
>   public class UnselectableElementBead implements IBead
>   {
>   /**
> +  * @royaleignorecoercion HTMLStyleElement
> +  */
> + private static function insertRule():void
> + {
> + // only do this once...
> + if(ruleInserted)
> + return;
> + ruleInserted = true;
> + // Inject a new css selector
> + COMPILE::JS
> + {
> + var style:HTMLStyleElement = 
> document.createElement('style') as HTMLStyleElement;
> + style.type = 'text/css';
> + style.innerHTML = '.unselectable 
> {-moz-user-select: none;-webkit-user-select: none;-ms-user-select: 
> none;user-select: none;}';
> + 
> document.getElementsByTagName('head')[0].appendChild(style);
> + }
> +
> + }
> + private static var ruleInserted:Boolean;
> +
> + /**
>*  constructor.
>*
>*  @langversion 3.0
> @@ -57,6 +78,7 @@ package org.apache.royale.html.beads
>*/
>   public function set strand(value:IStrand):void
>   {
> + insertRule();
>   _strand = value;
> 
>   COMPILE::JS
> 
> -- 
> To stop receiving notification emails like this one, please contact
> ha...@apache.org.

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

Any other selector should disable that one because that’s about as unspecific 
as you can get and the higher level of specificity always wins.

> On Jun 5, 2018, at 8:00 AM, Alex Harui  wrote:
> 
> Ah, ok.  How would a user disable that selector in case it did something 
> undesirable?
> 
> -Alex
> 
> On 6/4/18, 1:56 PM, "Harbs"  wrote:
> 
>Sorry I was a bit confused. The selector that works is:
> 
>.Application * {
>   position: relative;
>}
> 
>> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
>> 
>> Yes. But it cascades down.
>> 
>> I manually made this change to the TreeExample project, and it fixed the bug.
>> 
>>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>>> 
>>> I'm still not understanding.  Style.position is not inheriting so how would 
>>> it cascade down?  Isn't .Application only applied to the ?
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>>> 
>>>  I’m suggesting that we change defaults.css
>>> 
>>>  from:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>>  }
>>> 
>>>  to:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>> position: relative;
>>>  }
>>> 
>>>  I believe this will resolve this issue as the default would cascade down 
>>> to all sub-elements. The default would be relative, but beads would be free 
>>> to change that to whatever they want.
>>> 
>>>  Of course, that would dictate that UIBase belongs in Basic and not Core… 
>>> ;-)
>>> 
>>>  Harbs
>>> 
>>>> On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
>>>> 
>>>> I’m not sure exactly what change you are proposing, but UIBase used to set 
>>>> position=relative on all positioners.  We took that away so that the 
>>>> "flex" and other display/layout styles would not have to deal with the 
>>>> excess clutter and overhead of having set position on so many elements in 
>>>> the DOM.  Via PAYG, only the elements that need to have a style.position 
>>>> should have it set.
>>>> 
>>>> My 2 cents,
>>>> -Alex
>>>> 
>>>> On 6/4/18, 8:44 AM, "Harbs"  wrote:
>>>> 
>>>> It just occurred to me that the problem is due to the default position 
>>>> being static.
>>>> 
>>>> I just added position: relative; to the .Application css and that resolved 
>>>> the issue as well.
>>>> 
>>>> I wonder if we could completely do away with the offsetParent logic in 
>>>> UIBase if we make the default position: relative. That would have a major 
>>>> positive impact on performance.
>>>> 
>>>> Thoughts?
>>>> Harbs
>>>> 
>>>>> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
>>>>> 
>>>>> Hi Yishay,
>>>>> 
>>>>> IMO, the new fix is better.  And you took the right approach by examining 
>>>>> the code flow in the debugger.  When layout fails for what appears to be 
>>>>> a timing issue (in this case, offsetParent not set), we definitely want 
>>>>> to take the time to carefully analyze why there is a timing issue instead 
>>>>> of apply code to work around the current lifecycle.
>>>>> 
>>>>> I'm not sure we can recommend a general pattern for layouts.  I think 
>>>>> there is some PAYG involved.  It could be that in some cases the View 
>>>>> should be responsible for setting style.position.  Then the layouts don't 
>>>>> have to spend the time verifying style.position.  In other cases the 
>>>>> layouts could be used in places where other potential layouts don't rely 
>>>>> on style.position being a particular value.  I think BasicLayout for 
>>>>> Containers is an example.
>>>>> 
>>>>> The code you used could be put into a utility function for layouts to use 
>>>>> to guarantee that x,y will work as expected.
>>>>> 
>>>>> Thanks,
>>>>> -Alex
>>>>> 
>>>>> On 6/4/18, 8:22 AM, "yishayw"  wrote:
>>>>> 
>>>>> Looking at it some more it has nothing to do with data binding. I pushed a
>>>>> different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes the
>>>>> layout itself. Here it's assumed the offsetParent is explicitly set before
>>>>> children's x and y are set. Should this be a general pattern?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Sent from: 
>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 

Re: Incorrect descendent CSS output

[Harbs]

Thanks.

I just observed a new problem. I have not pulled in your changes, so I don’t 
know if it’s fixed, but it used to work correctly.

Much of the following css is now being stripped out.

CSS in the http://www.w3.org/1999/xhtml <http://www.w3.org/1999/xhtml> 
namespace should always be left in.

@namespace "http://www.w3.org/1999/xhtml;;
.printui_app .PUITabContainer .tabs {
display: table;
table-layout: fixed;
width: 100%;
transform: translateY(5px);
padding-left:0px;
background-color: #4d4d4d;
margin-top:0px;
}
.tabs > li {
transition-duration: .1s;
display: table-cell;
list-style: none;
text-align: center;
/* padding: 0px 20px 25px 20px; */
position: relative;
overflow: hidden;
cursor: pointer;
color: white; 
z-index: 1;
}
.tabs > li:before {
z-index: -1;
position: absolute;
content: "";
width: 100%;
height: 120%;
top: 0;
left: 0;
background-color: rgba(255, 255, 255, 0.3);
-webkit-transform: translateY(100%);
transform: translateY(100%);
transition-duration: .1s;
border-radius: 5px 5px 0 0;
}
.tabs > li:hover:before {
-webkit-transform: translateY(70%);
transform: translateY(70%);
}
.tabs > li.active {
color:#00;
/* color: #50555a; */
}
.tabs > li.active:before {
transition-duration: .1s;
background-color: #f3f3f3;
z-index: -1;
-webkit-transform: translateY(0);
transform: translateY(0);
}

.tab__content {
/* background-color: white; */
position: relative;
width: 100%;
border-radius: 5px;
padding-left: 0px;
}
.tab__content > li {
width: 100%;
position: absolute;
top: 0;
left: 0;
display: none;
list-style: none;
}
.tab__content > li .content__wrapper {
/*text-align: left;*/
border-radius: 5px;
width: calc(100% - 10px);
/* padding: 45px 40px 40px 40px; */
padding-left: 10px;
/* background-color: white; */
}
> On Jun 4, 2018, at 8:22 PM, Alex Harui  wrote:
> 
> I pushed a change that should fix that.
> 
> On 6/4/18, 1:40 AM, "Harbs"  wrote:
> 
>The following CSS:
> 
>TitleBar CloseButton
>{
>   width: 16px;
>   height: 16px;
>   margin: 0px;
>}
> 
>is output as:
> 
>.TitleBar CloseButton {
>margin: 0px;
>width: 16px;
>height: 16px;
>}
> 
>Instead of:
> 
>.TitleBar .CloseButton {
>margin: 0px;
>width: 16px;
>height: 16px;
>}
> 
>I think this is a bug.
> 
>Harbs
> 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

Yeah. If you’d need static for some reason, you’d specify that. I think needing 
static instead of relative would be pretty rare. Here’s an interesting 
article.[1]

I think the fact that static is the default in HTML is more of conceptual 
decision (less opinion on positioning) than a practical one (static leads to 
unexpected layout).

Even describing what static does is complicated as opposed to relative which is 
conceptually simple.[2]

All in all, relative seems like the right default for Royale apps to have.

My $0.02,
Harbs

[1]https://css-tricks.com/what-if-there-was-no-position-static/ 
<https://css-tricks.com/what-if-there-was-no-position-static/>
[2]https://stackoverflow.com/questions/15111549/why-is-a-div-with-position-absolute-not-by-default-relative-to-the-document
 
<https://stackoverflow.com/questions/15111549/why-is-a-div-with-position-absolute-not-by-default-relative-to-the-document>

> On Jun 5, 2018, at 8:23 AM, Alex Harui  wrote:
> 
> What I'm wondering is how you would make it so it was as if that selector 
> wasn't specified at all.  I guess the default value for position is "static" 
> so the user would specify position: static?
> 
> -Alex
> 
> On 6/4/18, 10:03 PM, "Harbs"  wrote:
> 
>Any other selector should disable that one because that’s about as 
> unspecific as you can get and the higher level of specificity always wins.
> 
>> On Jun 5, 2018, at 8:00 AM, Alex Harui  wrote:
>> 
>> Ah, ok.  How would a user disable that selector in case it did something 
>> undesirable?
>> 
>> -Alex
>> 
>> On 6/4/18, 1:56 PM, "Harbs"  wrote:
>> 
>>   Sorry I was a bit confused. The selector that works is:
>> 
>>   .Application * {
>>  position: relative;
>>   }
>> 
>>> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
>>> 
>>> Yes. But it cascades down.
>>> 
>>> I manually made this change to the TreeExample project, and it fixed the 
>>> bug.
>>> 
>>>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>>>> 
>>>> I'm still not understanding.  Style.position is not inheriting so how 
>>>> would it cascade down?  Isn't .Application only applied to the ?
>>>> 
>>>> Thanks,
>>>> -Alex
>>>> 
>>>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>>>> 
>>>> I’m suggesting that we change defaults.css
>>>> 
>>>> from:
>>>> Application
>>>> {
>>>>padding: 0px;
>>>>margin: 0px;
>>>> }
>>>> 
>>>> to:
>>>> Application
>>>> {
>>>>padding: 0px;
>>>>margin: 0px;
>>>>position: relative;
>>>> }
>>>> 
>>>> I believe this will resolve this issue as the default would cascade down 
>>>> to all sub-elements. The default would be relative, but beads would be 
>>>> free to change that to whatever they want.
>>>> 
>>>> Of course, that would dictate that UIBase belongs in Basic and not Core… 
>>>> ;-)
>>>> 
>>>> Harbs
>>>> 
>>>>> On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
>>>>> 
>>>>> I’m not sure exactly what change you are proposing, but UIBase used to 
>>>>> set position=relative on all positioners.  We took that away so that the 
>>>>> "flex" and other display/layout styles would not have to deal with the 
>>>>> excess clutter and overhead of having set position on so many elements in 
>>>>> the DOM.  Via PAYG, only the elements that need to have a style.position 
>>>>> should have it set.
>>>>> 
>>>>> My 2 cents,
>>>>> -Alex
>>>>> 
>>>>> On 6/4/18, 8:44 AM, "Harbs"  wrote:
>>>>> 
>>>>> It just occurred to me that the problem is due to the default position 
>>>>> being static.
>>>>> 
>>>>> I just added position: relative; to the .Application css and that 
>>>>> resolved the issue as well.
>>>>> 
>>>>> I wonder if we could completely do away with the offsetParent logic in 
>>>>> UIBase if we make the default position: relative. That would have a major 
>>>>> positive impact on performance.
>>>>> 
>>>>> Thoughts?
>>>>> Harbs
>>>>> 
>>>>>> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
>>>>>>

Re: Last class selectors

[Harbs]

FYI, application size stacks up very nicely when compared to other frameworks:

https://gist.github.com/Restuta/cda69e50a853aa64912d 
<https://gist.github.com/Restuta/cda69e50a853aa64912d>

24KB gzipped *with all application logic* is right in there with the smallest 
frameworks *sans the actual application*!

> On Jun 5, 2018, at 2:38 PM, Carlos Rovira  wrote:
> 
> Congrats Harbs! :)
> 
> as I just responded to Alex, I hope to give a try to all this soon as I get
> finish some work I have in my hands right now. Maybe in one or two days
> from now.
> 
> Thanks!
> 
> Carlos
> 
> 
> 2018-06-04 15:48 GMT+02:00 Harbs :
> 
>> FYI, I just compiled a bare-bones app, and a Basic app with a View,
>> VContainer and Label is 85KB uncompressed. 24KB gzipped. It looks like
>> there’s no extra classes.
>> 
>> The CSS is 546 bytes and 222 bytes gzipped. There’s no extra css either,
>> although som empty selectors could use some cleanup.
>> 
>> Harbs
>> 
>>> On Jun 4, 2018, at 4:27 PM, Harbs  wrote:
>>> 
>>> The only class selectors left in Basic defaults.css is:
>>> 
>>> .Application *, .royale *, . royale *:before, . royale *:after {
>>>  -moz-box-sizing: border-box;
>>>  -webkit-box-sizing: border-box;
>>>  box-sizing: border-box;
>>> }
>>> 
>>> I’m not sure how to best get rid of this.
>>> 
>>> Thoughts?
>>> Harbs
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: Incorrect descendent CSS output

[Harbs]

That one snuck in by mistake. It’s not being stripped out…

> On Jun 5, 2018, at 10:24 PM, Harbs  wrote:
> 
>  .tab__content > li .content__wrapper

Re: How to replace Flex Path in Royale

[Harbs]

Does this help?
http://royale.apache.org/asdoc/#!org.apache.royale.svg/Path 


> On Jun 5, 2018, at 11:08 PM, Piotr Zarzycki  wrote:
> 
> Hi Guys,
> 
> I have a component where 90% of it is Path [1] class which is drawing for
> me. If I would like to port that component and draw exactly the same thing
> in Royale - How approach to that task ?
> 
> [1] https://flex.apache.org/asdoc/spark/primitives/Path.html
> 
> Thanks,
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> *

Re: How to replace Flex Path in Royale

[Harbs]

The link was to our ASDoc. Not sure why it didn’t work.

We have an svg Path class which is similar to the spark one.

Drawing command are slightly different, but the same idea.

Have you looked at it?

> On Jun 6, 2018, at 12:03 AM, Piotr Zarzycki  wrote:
> 
> Unfortunately link doesn't work for me. Can you post code in
> paste.apache.org <http://paste.apache.org/>.
> 
> Thanks,
> Piotr
> 
> wt., 5 cze 2018 o 22:45 Harbs  <mailto:harbs.li...@gmail.com>> napisał(a):
> 
>> Does this help?
>> http://royale.apache.org/asdoc/#!org.apache.royale.svg/Path 
>> <http://royale.apache.org/asdoc/#!org.apache.royale.svg/Path> <
>> http://royale.apache.org/asdoc/#!org.apache.royale.svg/Path 
>> <http://royale.apache.org/asdoc/#!org.apache.royale.svg/Path>>
>> 
>>> On Jun 5, 2018, at 11:08 PM, Piotr Zarzycki 
>> wrote:
>>> 
>>> Hi Guys,
>>> 
>>> I have a component where 90% of it is Path [1] class which is drawing for
>>> me. If I would like to port that component and draw exactly the same
>> thing
>>> in Royale - How approach to that task ?
>>> 
>>> [1] https://flex.apache.org/asdoc/spark/primitives/Path.html
>>> 
>>> Thanks,
>>> --
>>> 
>>> Piotr Zarzycki
>>> 
>>> Patreon: *https://www.patreon.com/piotrzarzycki
>>> <https://www.patreon.com/piotrzarzycki>*
>> 
>> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki 
> <https://www.patreon.com/piotrzarzycki>
> <https://www.patreon.com/piotrzarzycki 
> <https://www.patreon.com/piotrzarzycki>>*

Re: Incorrect descendent CSS output

[Harbs]

Done.

That does seem to fix the problem.

Of course, things like .Menu{} (for org.apache.royale.html.Menu) now became 
Menu{}. Considering that Menu is actually a List which is a div and not a menu 
element, this will break any styling applied to Menu components… There might be 
others. Not sure what the easiest way to solve this problem is.

I’m pretty sure we also still have to deal with avoiding component conflicts.

So, my problem is now working, but we’re not out of the woods… ;-)

Harbs

> On Jun 6, 2018, at 12:08 AM, Alex Harui  wrote:
> 
> 
> 
> On 6/5/18, 2:01 PM, "Harbs"  wrote:
> 
>OK. And that will only work for the html namespace?
> 
> Don’t know for sure.  It appears that the namespace is not retained.  So I 
> think if you add a component to Jewel call "h4" its type selector may be in 
> all output.  We might need to fix that, but there are probably bigger fish to 
> fry.
> 
> HTH,
> -Alex
> 
>> On Jun 5, 2018, at 11:57 PM, Alex Harui  wrote:
>> 
>> 
>> 
>> On 6/5/18, 12:24 PM, "Harbs"  wrote:
>> 
>>   It doesn’t look like the fix helped.
>> 
>>   The following selectors are still being stripped out. I did not understand 
>> how the commit depends on namespaces. We should keep *all* selectors for 
>> generic HTML. 
>> 
>> Please add *all* selectors to htmlElementNames in 
>> JSCSSCompilationSession.java
>> 
>> Thanks,
>> -Alex
>> 
> 
> 
> 

Re: Incorrect descendent CSS output

[Harbs]

It doesn’t look like the fix helped.

The following selectors are still being stripped out. I did not understand how 
the commit depends on namespaces. We should keep *all* selectors for generic 
HTML. The way that’s currently declared is by using the “http :// www .w3 
.org/1999/xhtml” namespace.

.tabs > li {
transition-duration: .1s;
display: table-cell;
list-style: none;
text-align: center;
/* padding: 0px 20px 25px 20px; */
position: relative;
overflow: hidden;
cursor: pointer;
color: white; 
z-index: 1;
}
.tabs > li:before {
z-index: -1;
position: absolute;
content: "";
width: 100%;
height: 120%;
top: 0;
left: 0;
background-color: rgba(255, 255, 255, 0.3);
-webkit-transform: translateY(100%);
transform: translateY(100%);
transition-duration: .1s;
border-radius: 5px 5px 0 0;
}
.tabs > li:hover:before {
-webkit-transform: translateY(70%);
transform: translateY(70%);
}
.tabs > li.active {
color:#00;
/* color: #50555a; */
}
.tabs > li.active:before {
transition-duration: .1s;
background-color: #f3f3f3;
z-index: -1;
-webkit-transform: translateY(0);
transform: translateY(0);
}

.tab__content > li {
width: 100%;
position: absolute;
top: 0;
left: 0;
display: none;
list-style: none;
}
.tab__content > li .content__wrapper {
/*text-align: left;*/
border-radius: 5px;
width: calc(100% - 10px);
/* padding: 45px 40px 40px 40px; */
padding-left: 10px;
/* background-color: white; */
}
.tab__content > li {
width: 100%;
position: absolute;
top: 0;
left: 0;
display: none;
list-style: none;
}
> On Jun 5, 2018, at 7:56 PM, Alex Harui  wrote:
> 
> Good catch.  I pushed a fix that will fix that and hopefully not drag other 
> selectors back in.
> 
> -Alex
> 
> On 6/4/18, 9:48 PM, "Harbs"  wrote:
> 
>Thanks.
> 
>I just observed a new problem. I have not pulled in your changes, so I 
> don’t know if it’s fixed, but it used to work correctly.
> 
>Much of the following css is now being stripped out.
> 
>CSS in the 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml=02%7C01%7Caharui%40adobe.com%7C55c9d1dca2fd4f9c04f408d5ca9f8cb3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637708993352897=EzUPmX2Ht%2FN4b3ubGVZhGoMkeEQqtFHXIJhF%2FZgjCFQ%3D=0
>  
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml=02%7C01%7Caharui%40adobe.com%7C55c9d1dca2fd4f9c04f408d5ca9f8cb3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637708993352897=EzUPmX2Ht%2FN4b3ubGVZhGoMkeEQqtFHXIJhF%2FZgjCFQ%3D=0>
>  namespace should always be left in.
> 
>@namespace 
> "https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml=02%7C01%7Caharui%40adobe.com%7C55c9d1dca2fd4f9c04f408d5ca9f8cb3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637708993352897=EzUPmX2Ht%2FN4b3ubGVZhGoMkeEQqtFHXIJhF%2FZgjCFQ%3D=0;;
>.printui_app .PUITabContainer .tabs {
>display: table;
>table-layout: fixed;
>width: 100%;
>transform: translateY(5px);
>padding-left:0px;
>background-color: #4d4d4d;
>margin-top:0px;
>}
>.tabs > li {
>transition-duration: .1s;
>display: table-cell;
>list-style: none;
>text-align: center;
>/* padding: 0px 20px 25px 20px; */
>position: relative;
>overflow: hidden;
>cursor: pointer;
>color: white; 
>z-index: 1;
>}
>.tabs > li:before {
>z-index: -1;
>position: absolute;
>content: "";
>width: 100%;
>height: 120%;
>top: 0;
>left: 0;
>background-color: rgba(255, 255, 255, 0.3);
>-webkit-transform: translateY(100%);
>transform: translateY(100%);
>transition-duration: .1s;

Re: Last class selectors

[Harbs]

I think you’re theoretically supposed to be able to use the map.js file to 
debug minified code too, but I have yet to manage to do that.

> On Jun 5, 2018, at 11:46 PM, Carlos Rovira  wrote:
> 
> ok, but I thought that for debugging we had all we need in js-debug
> version, and js-release, does not had anything. I'm still confusing with
> it...
> 
> 2018-06-05 21:09 GMT+02:00 Harbs :
> 
>> The js.map file is used for debugging source code.
>> 
>>> so very good right? ;)
>> 
>> Yup! :-)
>> 
>>> On Jun 5, 2018, at 8:35 PM, Carlos Rovira 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> for example latest view state example in js-release is:
>>> 
>>> index.html - 2kb
>>> .js - 110kb
>>> .css - 16kb
>>> 
>>> so 128kb -> gzip - 33kb
>>> 
>>> (and js.map - 293 kb -> this file I assume is not needed right? what's
>> the
>>> purpose? If I remove it the app works the same)
>>> 
>>> This is using some layouts, Button, TextInput, Card ,view states and
>> beads,
>>> so very good right? ;)
>>> 
>>> 
>>> 2018-06-05 19:01 GMT+02:00 Alex Harui :
>>> 
>>>> I just compiled HelloWorld.  It is 79K.  That's bigger than it used to
>>>> be.  In looking at the js-debug version, there are some .js files from
>> the
>>>> framework that might be eliminated if we want to take the time.
>>>> 
>>>> It is nice to know that we can create small apps, although I'm wondering
>>>> if it is a fair comparison.  The other frameworks generally have
>> fancier UI
>>>> widgets with more elements in the DOM and more CSS to make it look
>> great.
>>>> Jewel is providing those same fancier UI widgets and it also will come
>> at
>>>> some cost.
>>>> 
>>>> My 2 cents,
>>>> -Alex
>>>> 
>>>> On 6/5/18, 6:57 AM, "Harbs"  wrote:
>>>> 
>>>>   Sure.
>>>> 
>>>>   For kicks, I looked at three other non-trivial apps I have.They all
>>>> have a whole pile of components in use and lots of business logic.
>>>> 
>>>>   Gzipped, they weigh in at: 91KB, 100KB and 117KB respectively.
>>>> 
>>>>   Even the biggest one is still less than some of the frameworks alone.
>>>> 
>>>>   Harbs
>>>> 
>>>>> On Jun 5, 2018, at 3:10 PM, Carlos Rovira 
>>>> wrote:
>>>>> 
>>>>> But, you version is only with a part of Royale, if you put a button,
>>>> will
>>>>> grow, if put a TextInput, will grow and so
>>>>> I think the comparison should be with almost all code involved
>>>> right? I
>>>>> don't think the rest of frameworks listed there will be showing
>>>> parts, but
>>>>> the whole library.
>>>>> 
>>>>> 2018-06-05 13:48 GMT+02:00 Harbs >>> harbs.li...@gmail.com>>:
>>>>> 
>>>>>> FYI, application size stacks up very nicely when compared to other
>>>>>> frameworks:
>>>>>> 
>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>> https%3A%2F%2Fgist.github.com%2FRestuta%2Fcda69e50a853aa64912d=
>>>> 02%7C01%7Caharui%40adobe.com%7C684ff80e790aac1708d5caec404f%
>>>> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636638038403206781=
>>>> INLNGTTuYDwM%2FRtYV8LQ4pY5S4%2FOdmOs6JWzsYxAQZA%3D=0 <
>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>> https%3A%2F%2Fgist.github.com%2FRestuta%2Fcda69e50a853aa64912d=
>>>> 02%7C01%7Caharui%40adobe.com%7C684ff80e790aac1708d5caec404f%
>>>> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636638038403206781=
>>>> INLNGTTuYDwM%2FRtYV8LQ4pY5S4%2FOdmOs6JWzsYxAQZA%3D=0> <
>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>> https%3A%2F%2Fgist.github.com%2FRestuta%2Fcda69e50a853aa64912d=
>>>> 02%7C01%7Caharui%40adobe.com%7C684ff80e790aac1708d5caec404f%
>>>> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636638038403206781=
>>>> INLNGTTuYDwM%2FRtYV8LQ4pY5S4%2FOdmOs6JWzsYxAQZA%3D=0 <
>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>> https%3A%2F%2Fgist.github.com%2FRestuta%2Fcda69e50a853aa64912d=
>>>> 02%7C01%7Caharui%40adobe.com%7C684ff80e790aac1708d5caec404f%
>>>> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7

Re: Incorrect descendent CSS output

[Harbs]

OK. And that will only work for the html namespace?

> On Jun 5, 2018, at 11:57 PM, Alex Harui  wrote:
> 
> 
> 
> On 6/5/18, 12:24 PM, "Harbs"  wrote:
> 
>It doesn’t look like the fix helped.
> 
>The following selectors are still being stripped out. I did not understand 
> how the commit depends on namespaces. We should keep *all* selectors for 
> generic HTML. 
> 
> Please add *all* selectors to htmlElementNames in JSCSSCompilationSession.java
> 
> Thanks,
> -Alex
> 

Re: Incorrect descendent CSS output

[Harbs]

Hmm. I wonder if CSSSemanticAnalyzer.resolveSelectors could stuff the selector 
namespace into the ICSSSelector. It seems to be looping through them anyway. 
ICSSSeelctor would need a new property for this.) Is 
CSSSemanticAnalyzer.resolveSelectors called before 
JSCSSCompilationSession.cssRuleToString?

> On Jun 6, 2018, at 1:01 AM, Harbs  wrote:
> 
> I’m not using menu, and it’s pretty doubtful anyone else is using it yet 
> either, so yeah, it’s probably safe to remove it temporarily. Not sure which 
> other elements might cause problems.
> 
> Another one which we really should fix is Button (because Button component 
> styling effects every button element in the app even if it’s not a “Button” 
> component). That’s something I’ve struggled with... But removing that one is 
> going to cause problems…
> 
> I did notice that CSSSemanticAnalyzer is checking for the xhtml namespace, 
> but it’s only doing so for the default namespace. ICSSSelector seems to have 
> a prefix, but no namespace (unless I’m missing something).
> 
> Harbs
> 
>> On Jun 6, 2018, at 12:51 AM, Alex Harui  wrote:
>> 
>> The data structure seems to have a slot to hold a namespace.  I think there 
>> is code somewhere that checks the namespace to avoid the outputting some 
>> error, but it may not be storing it.
>> 
>> The short term solution may be to remove menu from the list of htmlelements. 
>>  Does anybody actually use it?
>> 
>> HTH,
>> -Alex
>> 
>> On 6/5/18, 2:46 PM, "Harbs"  wrote:
>> 
>>   I think it’s line 189. It checks if the lowercase string matches. Only if 
>> that check fails does it enter the logic to figure out where to insert the 
>> dot. I’m really not sure how to fix this though… :-(
>> 
>>   We’d need menu{} to stay menu{} for html elements, but become .menu{} for 
>> other component types. FWIW, I think all selectors are case insensitive.
>> 
>>   Harbs
>> 
>>> On Jun 6, 2018, at 12:32 AM, Alex Harui  wrote:
>>> 
>>> 
>>> 
>>> On 6/5/18, 2:29 PM, "Harbs"  wrote:
>>> 
>>>  Done.
>>> 
>>>  That does seem to fix the problem.
>>> 
>>>  Of course, things like .Menu{} (for org.apache.royale.html.Menu) now 
>>> became Menu{}. Considering that Menu is actually a List which is a div and 
>>> not a menu element, this will break any styling applied to Menu components… 
>>> There might be others. Not sure what the easiest way to solve this problem 
>>> is.
>>> 
>>> I'm not sure what that would be the case.  Maybe debug through it or add 
>>> System.out.println.  I think ArrayList.contains() is case sensitive, so I'm 
>>> surprised that "Menu" is matching "menu".
>>> 
>>> Or am I not understanding your point?
>>> -Alex
>>> 
>>> 
>> 
>> 
>> 
> 

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Harbs]

While I was trying to figure out how the compiler handles CSS, a new idea came 
to me which I think is better than any of the ideas we had until now (if I 
might say so myself). ;-p

Basically, we can just use the component manifest file.

One of the issues I was struggling with is that if the type selector is defined 
and hard-coded in the component class, that very much limits how other 
component sets can use the component. I think this is part of what was 
bothering Carlos as well.

By adding a new attribute to components, I think we can solve this problem very 
nicely. For example in express-manifest:
 On Jun 1, 2018, at 9:25 AM, Alex Harui  wrote:
> 
> OK, then I think we are on roughly the same page.  Earlier I proposed a map 
> of package names to short names.  However, I just realized that it needs to 
> be a map of MXML namespaces to short names, and metadata won't work because I 
> think the rules get chosen by MXML namespace instead of package names because 
> you can map the same class into different MXML namespaces.  If you want to 
> map "library://ns.apache.org/jewel " to 
> ".jewel." it would have the desired result.
> 
> My 2 cents,
> -Alex
> 
> On 5/30/18, 11:58 PM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
> 
>I’m not talking about solving subclassing here.
> 
>I’m talking about one thing: How to determine what classnames the compiler 
> writes to HTML CSS files for specific types.
> 
>Carlos and I would both like for the compiler to compile:
>j|Button{
>   background-color: #fff;
>}
> 
>To: 
>.jewel.Button{
>   background-color: #fff;
>}
> 
>Rather than:
>org_apache_royale_jewel_Button{
>   background-color: #fff;
>}
> 
>And we all agree that we don’t want:
>.Button{
>   background-color: #fff;
>}
> 
>The question is how to accomplish that. We’re suggesting to include some 
> kind of meta tag or comment in the Button class source which acts as a 
> compiler directive to specify exactly what to output. If you have another 
> suggestion on how we can achieve that goal, that’s fine too.
> 
>Makes sense?
>Harbs
> 
>> On May 31, 2018, at 12:30 AM, Alex Harui  wrote:
>> 
>> There has always been an option to keep/strip metadata in the output.  It is 
>> -compiler.keep-as3-metadata.
>> 
>> I don't think I understand what you are proposing with metadata.  I thought 
>> I'd shown that there was no easy way to solve what the runtime 
>> (ValuesManager) should do. I thought we'd agreed upthread that metadata was 
>> not required, and we would decide on some short-name abbreviations based on 
>> the fully qualified names (package and class name).   The abbreviation 
>> scheme doesn't have to be perfect, as long as it reduces likelihood of 
>> collision at very low cost.  An example might be that you can register 
>> abbreviation mappings so we say that "oarh" is short for 
>> "org.apache.royale.html".
>> 
>> Thoughts?
>> -Alex
>> 
>> On 5/29/18, 5:47 AM, "Harbs" > <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>> <mailto:harbs.li...@gmail.com>>> wrote:
>> 
>>   Sorry for the delay in response here. I was not feeling very well last 
>> week… (I forgot how much work an infant is…) ;-)
>> 
>>   I think it’s time to wrap this up.
>> 
>>   I don’t think there’s any completely PAYG solution to this problem. I 
>> think conflicts need to be prevented by default.
>> 
>>   I like the metadata and .basic.Button approach and I think it’s more PAYG 
>> than org_apache_royale_html_Button. Theoretically, component sets can just 
>> use “Button” and ignore conflicts for complete PAYG (although I would not 
>> recommend that).
>> 
>>   We should definitely use metadata that does not insure a runtime tax. If 
>> we could somehow strip out the bracket metadata, I prefer that. Using 
>> metadata would allow different component sets to make their own decisions.
>> 
>>   Thanks,
>>   Harbs
>> 
>>> On May 21, 2018, at 7:41 PM, Alex Harui >> <mailto:aha...@adobe.com.INVALID>> wrote:
>>> 
>>> I think we are in agreement.  My most recent posts were intended to show 
>>> that #2 is not easily solvable, if at all, and thus we should not invest 
>>> time or energy there.
>>> 
>>> My only suggestions regarding #1 is that we do not invent a second naming 
>>> system, and that whatever we do is PAYG in the sense that I don’t expect 
>>> users to mix

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

Yes. There is a lot to be said for your approach of using strictly classes for 
assigning layouts using CSS.

It prevents a lot of the reflowing problems.

I’m interested in seeing how far you can get with it. :-)

Harbs

> On Jun 6, 2018, at 10:58 AM, Carlos Rovira  wrote:
> 
> Hi Yishay,
> maybe mixing topics, but I only showing how I'm solving in jewel layouts.
> Why I'm creating new layouts? since I see many problems with mixing layout
> types (display: block, in other cases flex...), and seems inconsistent, so
> I'm trying to base all in Jewel in only one system. Flexbox is not the best
> (I think Grid would be better), but is supported in IE11, so is the middle
> point right now.
> A secondary motive was to get rid of JS loops or processing when possible,
> since layout and positioning nowadays is done completely in CSS, so Jewel
> layout has (for now), SWF code like in basic (can change when I reach to
> focus more on SWF part), but JS is turning to use only CSS class selectors,
> so the browsers handle all positioning. The work is still in progress, for
> now I get IE11 working again and things positioning right in all browsers,
> that is by itself a huge improvement over the jewel layout classes that we
> had some days ago. As Harbs said a collateral effect of all of this (but
> not a main one) is that we should end with "styles" set in HTML, or at
> least only use that if we want to make some dynamic change at runtime.
> 
> 
> 2018-06-06 7:52 GMT+02:00 Yishay Weiss :
> 
>> Ok, but why does that get in the way of ‘flex’ and other display/layout
>> styles?
>> 
>> 
>> 
>> 
>> From: Alex Harui 
>> Sent: Tuesday, June 5, 2018 7:53:51 PM
>> To: dev@royale.apache.org
>> Subject: Re: [royale-asjs] branch develop updated: Fixes #258. But is that
>> a proper fix?
>> 
>> If you look at the DOM generated back then, every tag had
>> "style="position:relative" on it.
>> 
>> -Alex
>> 
>> On 6/4/18, 11:53 PM, "yishayw"  wrote:
>> 
>>Alex Harui-2 wrote
>>> UIBase used to set position=relative on all positioners.  We took
>> that
>>> away so that the "flex" and other display/layout styles would not
>> have to
>>> deal with the excess clutter and overhead of having set position on
>> so
>>> many elements in the DOM.
>> 
>>Can you give an example of excess clutter caused by this?
>> 
>> 
>> 
>> 
>>--
>>Sent from: https://na01.safelinks.protection.outlook.com/?url=http%3A%
>> 2F%2Fapache-royale-development.20373.n8.nabble.com%2F=
>> 02%7C01%7Caharui%40adobe.com%7Cfe016d3a8a054079c23908d5cab10
>> 05c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63663778392
>> 0590036=mEUKysH2%2FsT4PtSe4ntWlFSZoz3B35zTEs3cJN288yE%3D=0
>> 
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: Incorrect descendent CSS output

[Harbs]

I think it’s line 189. It checks if the lowercase string matches. Only if that 
check fails does it enter the logic to figure out where to insert the dot. I’m 
really not sure how to fix this though… :-(

We’d need menu{} to stay menu{} for html elements, but become .menu{} for other 
component types. FWIW, I think all selectors are case insensitive.

Harbs

> On Jun 6, 2018, at 12:32 AM, Alex Harui  wrote:
> 
> 
> 
> On 6/5/18, 2:29 PM, "Harbs"  wrote:
> 
>Done.
> 
>That does seem to fix the problem.
> 
>Of course, things like .Menu{} (for org.apache.royale.html.Menu) now 
> became Menu{}. Considering that Menu is actually a List which is a div and 
> not a menu element, this will break any styling applied to Menu components… 
> There might be others. Not sure what the easiest way to solve this problem is.
> 
> I'm not sure what that would be the case.  Maybe debug through it or add 
> System.out.println.  I think ArrayList.contains() is case sensitive, so I'm 
> surprised that "Menu" is matching "menu".
> 
> Or am I not understanding your point?
> -Alex
> 
> 

Re: Incorrect descendent CSS output

[Harbs]

I’m not using menu, and it’s pretty doubtful anyone else is using it yet 
either, so yeah, it’s probably safe to remove it temporarily. Not sure which 
other elements might cause problems.

Another one which we really should fix is Button (because Button component 
styling effects every button element in the app even if it’s not a “Button” 
component). That’s something I’ve struggled with... But removing that one is 
going to cause problems…

I did notice that CSSSemanticAnalyzer is checking for the xhtml namespace, but 
it’s only doing so for the default namespace. ICSSSelector seems to have a 
prefix, but no namespace (unless I’m missing something).

Harbs

> On Jun 6, 2018, at 12:51 AM, Alex Harui  wrote:
> 
> The data structure seems to have a slot to hold a namespace.  I think there 
> is code somewhere that checks the namespace to avoid the outputting some 
> error, but it may not be storing it.
> 
> The short term solution may be to remove menu from the list of htmlelements.  
> Does anybody actually use it?
> 
> HTH,
> -Alex
> 
> On 6/5/18, 2:46 PM, "Harbs"  wrote:
> 
>I think it’s line 189. It checks if the lowercase string matches. Only if 
> that check fails does it enter the logic to figure out where to insert the 
> dot. I’m really not sure how to fix this though… :-(
> 
>We’d need menu{} to stay menu{} for html elements, but become .menu{} for 
> other component types. FWIW, I think all selectors are case insensitive.
> 
>Harbs
> 
>> On Jun 6, 2018, at 12:32 AM, Alex Harui  wrote:
>> 
>> 
>> 
>> On 6/5/18, 2:29 PM, "Harbs"  wrote:
>> 
>>   Done.
>> 
>>   That does seem to fix the problem.
>> 
>>   Of course, things like .Menu{} (for org.apache.royale.html.Menu) now 
>> became Menu{}. Considering that Menu is actually a List which is a div and 
>> not a menu element, this will break any styling applied to Menu components… 
>> There might be others. Not sure what the easiest way to solve this problem 
>> is.
>> 
>> I'm not sure what that would be the case.  Maybe debug through it or add 
>> System.out.println.  I think ArrayList.contains() is case sensitive, so I'm 
>> surprised that "Menu" is matching "menu".
>> 
>> Or am I not understanding your point?
>> -Alex
>> 
>> 
> 
> 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

I think the point was that the inline style needed to be removed in certain 
cases.

> On Jun 6, 2018, at 8:52 AM, Yishay Weiss  wrote:
> 
> Ok, but why does that get in the way of ‘flex’ and other display/layout 
> styles?
> 
> 
> 
> 
> From: Alex Harui 
> Sent: Tuesday, June 5, 2018 7:53:51 PM
> To: dev@royale.apache.org
> Subject: Re: [royale-asjs] branch develop updated: Fixes #258. But is that a 
> proper fix?
> 
> If you look at the DOM generated back then, every tag had 
> "style="position:relative" on it.
> 
> -Alex
> 
> On 6/4/18, 11:53 PM, "yishayw"  wrote:
> 
>Alex Harui-2 wrote
>> UIBase used to set position=relative on all positioners.  We took that
>> away so that the "flex" and other display/layout styles would not have to
>> deal with the excess clutter and overhead of having set position on so
>> many elements in the DOM.
> 
>Can you give an example of excess clutter caused by this?
> 
> 
> 
> 
>--
>Sent from: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cfe016d3a8a054079c23908d5cab1005c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637783920590036=mEUKysH2%2FsT4PtSe4ntWlFSZoz3B35zTEs3cJN288yE%3D=0
> 
> 

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

FYI, I applied this change to my PrintUI app and it seems like we had applied 
quite a few ugly work-arounds to get things to be positioned correctly. We did 
not realize at the time that it was due to the default being position: static. 
Switching the default to position: relative simplifies element positioning a 
lot, and enables us to get rid of a lot of positional overrides to make things 
stay where they should.

If there’s no objections, I’ll apply this change. It might require some changes 
to client apps, but this is mostly to remove work-arounds that shouldn’t have 
been required in the first place and I think it’s worth-while.

The change will also enable us to get rid of forced reflow when setting x and y 
values to UIBase which is a major performance sore-spot.

Harbs

> On Jun 5, 2018, at 8:00 AM, Alex Harui  wrote:
> 
> Ah, ok.  How would a user disable that selector in case it did something 
> undesirable?
> 
> -Alex
> 
> On 6/4/18, 1:56 PM, "Harbs"  wrote:
> 
>Sorry I was a bit confused. The selector that works is:
> 
>.Application * {
>   position: relative;
>}
> 
>> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
>> 
>> Yes. But it cascades down.
>> 
>> I manually made this change to the TreeExample project, and it fixed the bug.
>> 
>>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>>> 
>>> I'm still not understanding.  Style.position is not inheriting so how would 
>>> it cascade down?  Isn't .Application only applied to the ?
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>>> 
>>>  I’m suggesting that we change defaults.css
>>> 
>>>  from:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>>  }
>>> 
>>>  to:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>> position: relative;
>>>  }
>>> 
>>>  I believe this will resolve this issue as the default would cascade down 
>>> to all sub-elements. The default would be relative, but beads would be free 
>>> to change that to whatever they want.
>>> 
>>>  Of course, that would dictate that UIBase belongs in Basic and not Core… 
>>> ;-)
>>> 
>>>  Harbs
>>> 
>>>> On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
>>>> 
>>>> I’m not sure exactly what change you are proposing, but UIBase used to set 
>>>> position=relative on all positioners.  We took that away so that the 
>>>> "flex" and other display/layout styles would not have to deal with the 
>>>> excess clutter and overhead of having set position on so many elements in 
>>>> the DOM.  Via PAYG, only the elements that need to have a style.position 
>>>> should have it set.
>>>> 
>>>> My 2 cents,
>>>> -Alex
>>>> 
>>>> On 6/4/18, 8:44 AM, "Harbs"  wrote:
>>>> 
>>>> It just occurred to me that the problem is due to the default position 
>>>> being static.
>>>> 
>>>> I just added position: relative; to the .Application css and that resolved 
>>>> the issue as well.
>>>> 
>>>> I wonder if we could completely do away with the offsetParent logic in 
>>>> UIBase if we make the default position: relative. That would have a major 
>>>> positive impact on performance.
>>>> 
>>>> Thoughts?
>>>> Harbs
>>>> 
>>>>> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
>>>>> 
>>>>> Hi Yishay,
>>>>> 
>>>>> IMO, the new fix is better.  And you took the right approach by examining 
>>>>> the code flow in the debugger.  When layout fails for what appears to be 
>>>>> a timing issue (in this case, offsetParent not set), we definitely want 
>>>>> to take the time to carefully analyze why there is a timing issue instead 
>>>>> of apply code to work around the current lifecycle.
>>>>> 
>>>>> I'm not sure we can recommend a general pattern for layouts.  I think 
>>>>> there is some PAYG involved.  It could be that in some cases the View 
>>>>> should be responsible for setting style.position.  Then the layouts don't 
>>>>> have to spend the time verifying style.position.  In other cases the 
>>>>> layouts could be used in places where other potential layouts don't rely 
&

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Harbs]

> Button{
>   TypeNames: “.jewel.button”;
> }
> 
> should not be?
> 
> Button{
>   TypeNames: “jewel button”;
> }

Yup. You’re right. Typo there… ;-)

> (side question not related what does lookupOnly="true"?, I
> forgot completely about the use or need for that)

Others might have a better explanation, but my understanding is that's for 
component sets using classes from other packages. lookupOnly prevents the class 
from being written in the swc. So Express declares that it needs the 
org.apache.royale.html.Button class in Basic.swc and the class is not written a 
second time into Express.swc.

HTH,
Harbs

> On Jun 6, 2018, at 11:29 AM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> I reach to the same conclusion that "typeNames" set in the class code is
> not the best way to go, and not PAYG. A rule to follow should be that TLCs
> and other classes should never hardcode anything about layout, positioning,
> styles or classNames. So I think your strategy is good in concept, and
> maybe in the planned inmplementation, I'm seeing some things that maybe
> could not work:
> 
> Button{
>   TypeNames: “.jewel.button”;
> }
> 
> should not be?
> 
> Button{
>   TypeNames: “jewel button”;
> }
> 
> For implementation, I think #3 should be better, since is more PAYG, and we
> should have probably an extension of UIBase (somewhat "StyledUIBase" or
> whatever), so Basic should continue using UIBase, but Jewel is using some
> variables and methods in *all* components that should go to and
> intermediate class  UIBase -> StyledUIBase -> Button (Jewel), and in
> StyledUIBase we can implement what you say. I was planning to make
> StyledUIBase soon (is what we called JewelUIBase in other discussion some
> months ago), and will have mainly the protected var classSelectorList the
> override to setClassName that are things that are in all jewel controls and
> components, so to this we can add the setTypeNames as well and I think it
> would be ok that UI sets that will be more "Visual" attractive use this
> instead of its UIBase superclass.
> 
> Thoughts?
> 
> Carlos
> 
> (side question not related what does lookupOnly="true"?, I
> forgot completely about the use or need for that)
> 
> 
> 
> 2018-06-06 9:28 GMT+02:00 Harbs  <mailto:harbs.li...@gmail.com>>:
> 
>> While I was trying to figure out how the compiler handles CSS, a new idea
>> came to me which I think is better than any of the ideas we had until now
>> (if I might say so myself). ;-p
>> 
>> Basically, we can just use the component manifest file.
>> 
>> One of the issues I was struggling with is that if the type selector is
>> defined and hard-coded in the component class, that very much limits how
>> other component sets can use the component. I think this is part of what
>> was bothering Carlos as well.
>> 
>> By adding a new attribute to components, I think we can solve this problem
>> very nicely. For example in express-manifest:
>> > lookupOnly="true" typeNames=".express.Button”/>
>> 
>> Would define that any express|Button (used in an express namespace) should
>> be written with a selector of “.express.Button”. That is even if the class
>> is the same as one used by a different component set.
>> 
>> Of course, of that to work, the correct typeNames need to be assigned to
>> the classes. I think that could be defined in the CSS:
>> 
>> Button{
>>   TypeNames: “.express.Button”;
>> }
>> 
>> Of course, this would require using ValuesManager to look up the
>> classNames for the component (i.e. this.typeNames =
>> ValuesManager.valuesImpl.getValue(this, "typeNames") as String), so it’s
>> not completely PAYG.
>> 
>> I would suggest for this one of a few of courses of action:
>> 
>> 1. We could create a protected setTypeNames method in UIBase which would
>> be virtual and overridden by subclasses to either write the typeNames
>> directly or use the ValuesManager.
>> 2. We could create a protected setTypeNames method in UIBase which uses
>> the ValuesManager by default and the subclasses would only override the
>> method if they want to set it directly.
>> 3. We do nothing in UIBase, and each component decides whether to
>> implement a protected setTypeNames method (or similar) which could work in
>> one of the two aforementioned ways.
>> 
>> #3 is the most PAYG.
>> #2 is the least PAYG, but the most DRY. According to Royale principles, it
>> would generally not be the way we’d go, but I would prefer it because it
>> gives the mo

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Harbs]

> This just seems like too much work for the hopefully seldom case of mixing 
> TLC's from various component sets.

Well, I am already doing that… Maybe I’m the exception, but it’s not a 
theoretical need. ;-)

It also would enable us to use Basic and Express TLCs in Jewel — without 
subclassing at all.

There’s a bigger picture aspect of this as well which is probably most 
important. It would enable component sets to declare how their typenames should 
be written in CSS. Right now, Carlos is forced to write his Jewel CSS using 
class selectors. I would really like to be able to change that to type 
selectors and declaring the selectors in the manifest would enable that.

This might be something I could work on, but I’d likely need direction.

Thanks,
Harbs

> On Jun 6, 2018, at 6:33 PM, Alex Harui  wrote:
> 
> This just seems like too much work for the hopefully seldom case of mixing 
> TLC's from various component sets.  Remember that in "Terminology and 
> Concepts", the TLC's are just collections of beads.  There should be little 
> dependencies of the beads on the host strand.  Folks should be able to break 
> any TLC into its "exploded component".
> 
> There should be so little code in a TLC, that there really shouldn't be much 
> advantage to having a TLC in one component set subclass a TLC in another 
> component.  The big re-use of code should come from subclassing and 
> aggregating beads and reusing utility functions.
> 
> Any manually controlled naming scheme just sets up another place for mistakes 
> and collisions.  I think there are many more important things for us to work 
> on, like getting the emulation components to run.
> 
> My 2 cents,
> -Alex
> 
> On 6/6/18, 12:28 AM, "Harbs"  wrote:
> 
>While I was trying to figure out how the compiler handles CSS, a new idea 
> came to me which I think is better than any of the ideas we had until now (if 
> I might say so myself). ;-p
> 
>Basically, we can just use the component manifest file.
> 
>One of the issues I was struggling with is that if the type selector is 
> defined and hard-coded in the component class, that very much limits how 
> other component sets can use the component. I think this is part of what was 
> bothering Carlos as well.
> 
>By adding a new attribute to components, I think we can solve this problem 
> very nicely. For example in express-manifest:
> lookupOnly="true" typeNames=".express.Button”/>
> 
>Would define that any express|Button (used in an express namespace) should 
> be written with a selector of “.express.Button”. That is even if the class is 
> the same as one used by a different component set.
> 
>Of course, of that to work, the correct typeNames need to be assigned to 
> the classes. I think that could be defined in the CSS:
> 
>Button{
>   TypeNames: “.express.Button”;
>}
> 
>Of course, this would require using ValuesManager to look up the 
> classNames for the component (i.e. this.typeNames = 
> ValuesManager.valuesImpl.getValue(this, "typeNames") as String), so it’s not 
> completely PAYG.
> 
>I would suggest for this one of a few of courses of action:
> 
>1. We could create a protected setTypeNames method in UIBase which would 
> be virtual and overridden by subclasses to either write the typeNames 
> directly or use the ValuesManager.
>2. We could create a protected setTypeNames method in UIBase which uses 
> the ValuesManager by default and the subclasses would only override the 
> method if they want to set it directly.
>3. We do nothing in UIBase, and each component decides whether to 
> implement a protected setTypeNames method (or similar) which could work in 
> one of the two aforementioned ways.
> 
>#3 is the most PAYG.
>#2 is the least PAYG, but the most DRY. According to Royale principles, it 
> would generally not be the way we’d go, but I would prefer it because it 
> gives the most predictable behavior in terms of declarable CSS. TypeNames is 
> also pretty “Core” to Royale component sets, so it’s somewhat appropriate. It 
> also allows users to remove default CSS selectors from specific components 
> should they choose to do so.
> 
>Thoughts?
>Harbs
> 
>> On Jun 1, 2018, at 9:25 AM, Alex Harui  wrote:
>> 
>> OK, then I think we are on roughly the same page.  Earlier I proposed a map 
>> of package names to short names.  However, I just realized that it needs to 
>> be a map of MXML namespaces to short names, and metadata won't work because 
>> I think the rules get chosen by MXML namespace instead of package names 
>> because you can map the same class into different MXML namespac

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

> ... and not very PAYG.

On the contrary.

The same way we are applying box-sizing: border-box because it is a better 
default and prevents extra processing, applying relative instead of static as a 
default allows us to make assumptions that lets us use less code.

Yes. It’s a change, but it’s one which should make the default simpler and more 
PAYG.

I can do this on a branch and compile the examples. We can see how this effects 
them. Does that sound like a plan?

> On Jun 6, 2018, at 6:23 PM, Alex Harui  wrote:
> 
> This sounds scary to me because it affects the entire DOM, and not very PAYG. 
>  Maybe Carlos should try it on his Jewel layouts and see if anything breaks.
> 
> Some other implementation options would be to:
> 
> -Have the x,y setters set position on the parent.  I think we used to do this 
> and decided to not do it anymore
> -Have the x,y setters add a class selector to the parent.
> -Have a bead, like we've discussed for UnselectableElement, that brings in 
> the selector.
> -Have the layouts that allow for absolute positioning set the right styles or 
> selector on the parent.
> 
> My 2 cents,
> -Alex
> 
> On 6/5/18, 11:44 PM, "Harbs"  wrote:
> 
>FYI, I applied this change to my PrintUI app and it seems like we had 
> applied quite a few ugly work-arounds to get things to be positioned 
> correctly. We did not realize at the time that it was due to the default 
> being position: static. Switching the default to position: relative 
> simplifies element positioning a lot, and enables us to get rid of a lot of 
> positional overrides to make things stay where they should.
> 
>If there’s no objections, I’ll apply this change. It might require some 
> changes to client apps, but this is mostly to remove work-arounds that 
> shouldn’t have been required in the first place and I think it’s worth-while.
> 
>The change will also enable us to get rid of forced reflow when setting x 
> and y values to UIBase which is a major performance sore-spot.
> 
>Harbs
> 
>> On Jun 5, 2018, at 8:00 AM, Alex Harui  wrote:
>> 
>> Ah, ok.  How would a user disable that selector in case it did something 
>> undesirable?
>> 
>> -Alex
>> 
>> On 6/4/18, 1:56 PM, "Harbs"  wrote:
>> 
>>   Sorry I was a bit confused. The selector that works is:
>> 
>>   .Application * {
>>  position: relative;
>>   }
>> 
>>> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
>>> 
>>> Yes. But it cascades down.
>>> 
>>> I manually made this change to the TreeExample project, and it fixed the 
>>> bug.
>>> 
>>>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>>>> 
>>>> I'm still not understanding.  Style.position is not inheriting so how 
>>>> would it cascade down?  Isn't .Application only applied to the ?
>>>> 
>>>> Thanks,
>>>> -Alex
>>>> 
>>>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>>>> 
>>>> I’m suggesting that we change defaults.css
>>>> 
>>>> from:
>>>> Application
>>>> {
>>>>padding: 0px;
>>>>margin: 0px;
>>>> }
>>>> 
>>>> to:
>>>> Application
>>>> {
>>>>padding: 0px;
>>>>margin: 0px;
>>>>position: relative;
>>>> }
>>>> 
>>>> I believe this will resolve this issue as the default would cascade down 
>>>> to all sub-elements. The default would be relative, but beads would be 
>>>> free to change that to whatever they want.
>>>> 
>>>> Of course, that would dictate that UIBase belongs in Basic and not Core… 
>>>> ;-)
>>>> 
>>>> Harbs
>>>> 
>>>>> On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
>>>>> 
>>>>> I’m not sure exactly what change you are proposing, but UIBase used to 
>>>>> set position=relative on all positioners.  We took that away so that the 
>>>>> "flex" and other display/layout styles would not have to deal with the 
>>>>> excess clutter and overhead of having set position on so many elements in 
>>>>> the DOM.  Via PAYG, only the elements that need to have a style.position 
>>>>> should have it set.
>>>>> 
>>>>> My 2 cents,
>>>>> -Alex
>>>>> 
>>>>> On 6/4/18, 8:44 AM, "Harbs"  wrote:
>>>>> 
>>>>> It just occurred to me that the probl

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

I don’t think you realize the full extent of the effect. It’s not just “in 
case” someone wants x and y values. It’s also to *prevent the need* to specify 
x and y values which shouldn’t need to be specified.

Let’s take a piece of ProductsView in RoyaleStore:

















It’s using a flex layout. The flex layout should position the child elements. 
Unfortunately it doesn’t which is why we have the following code there:

 x="{filterGrip.width}”

Without that, the filterGrip space is not accounted for. This is because the 
default is static rather than relative. Changing the default to relative 
removes the necessity to specify an x position dependent on the sibling size.

I was forced to add similar code in my app.

We are also forced to add code to calculate offsetParent which is not PAYG both 
in terms of code and performance.

Simply put: static is a bad default. Default relative positioning gives more 
expected results in 99% of use cases and usually results in *less* code.

My $0.02,
Harbs

> On Jun 6, 2018, at 7:37 PM, Alex Harui  wrote:
> 
> Setting position:relative "just-in-case" someone needs to use x,y is not 
> PAYG, IMO.

Re: New blog example post "Using View States to show or hide content"

[Harbs]

FWIW, I tried  to remove that from the page, but it had no effect. I don’t know 
why.

I also tried to see how it was constructed in WordPress and I couldn’t see the 
code block at all. What was I missing there?

Harbs

> On Jun 7, 2018, at 10:50 AM, Carlos Rovira  wrote:
> 
> Hi Om,
> 
> thanks!, ok, I'll try to change height of code view for the current
> examples in the next update :)
> 
> 2018-06-06 20:52 GMT+02:00 OmPrakash Muppirala :
> 
>> Thanks for this, Carlos!
>> 
>> The snippet only shows 15 lines and then we need to scroll to see the
>> rest.  Can we make it show all the code by default?
>> 
>> Regards,
>> Om
>> 
>> On Wed, Jun 6, 2018 at 9:48 AM, Carlos Rovira 
>> wrote:
>> 
>>> Hi,
>>> 
>>> new blog post online:
>>> 
>>> https://royale.apache.org/using-view-states-to-show-or-hide-content/
>>> 
>>> Enjoy! :)
>>> 
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Harbs]

> IMO, if we all pitched in on emulation

> Perfection can be the enemy of success.  Sorry to be so selfish, but I am 
> just trying to keep my job.

Fair enough. If I were to pitch in with the emulation, what would you recommend 
I work on?

Harbs


> On Jun 6, 2018, at 9:24 PM, Alex Harui  wrote:
> 
> IMO, if we all pitched in on emulation, we would have many more migrating 
> users at the end of the year claiming that the UI is still a bit ugly.  If we 
> leave emulation to fewer people, then at the end of the year, we may not have 
> gotten all of the emulation components up and running and so fewer people 
> will try them.  IMO, every day we don't make migration easier, we lose more 
> potential users to other frameworks.
> 
> I have proposed workarounds that will let us avoid Type Selector name 
> collisions that won't take nearly as much of my time to assist with.  
> Perfection can be the enemy of success.  Sorry to be so selfish, but I am 
> just trying to keep my job.  You are not wrong to pursue new users who don't 
> have apps to migrate.  But I'm more certain that there are likely to be 
> important Adobe customers in the group with apps to migrate than the group 
> that will be new to Royale this year.
> 
> My 2 cents,
> -Alex

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

> So, IMO, it would be nice to do a similar investigation of controlsPallette.

You are right. Removing the y value has no effect.

I am wondering that maybe it makes sense to apply relative to the Container CSS 
selector and possibly a few others.

I’m trying to understand the specific cases where:
if (positioner.parentNode != positioner.offsetParent)

Is required in setX, get x and setY, get y in UIBase. I would *really* like to 
get rid of that code, and I’m, wondering what doing so would cause.

> On Jun 7, 2018, at 12:36 AM, Alex Harui  wrote:
> 
> In the case of the controlsPallette, how did it get its size?  I could 
> certainly understand that if you didn't have position!=static, that setting 
> top on the dockAndOuterContainer would have no effect, but you shouldn't have 
> had to set y or top in the first place.  IIRC, you couldn't use x,y in Flex 
> layouts like VerticalLayout/HorizontalLayout so migrating code shouldn't be 
> using it.  It is fine to create other layouts that support x,y as exceptions.
> 
> In general, for a framework, we want to make sure we understand and fix the 
> fundamental problem before we address any hacks/exceptions.  IMO, the 
> fundamental problem in the scenarios you've provided so far is that the 
> layout did not do what was expected so someone tried using x,y to fix it.  
> First we need that layout do what is expected, then worry about how folks 
> might resolve other issues, if any.
> 
> In ProductsView in RoyaleStore, the grip is an image loaded later, so there 
> might have been an issue there, especially on the SWF side, but I would 
> expect the browser to automatically re-layout once the grip image loaded.  I 
> dug through Git history and found that I was the one who hacked in the x,y.  
> It could be that early on, the layout did not use FlexBox so we had a similar 
> problem of responding to the grip image loading late.  But we should remove 
> the x,y and see if there is still a problem and ponder the right fix for 
> that.  ProductsView should not need to be setting x,y.
> 
> So, IMO, it would be nice to do a similar investigation of controlsPallette.  
> IMO, if you examine that div, it's offsetHeight should be 40 and if it is 
> then you shouldn't need to set style.top=40 on docAndOuterContainer which 
> means that it shouldn't matter what style.position is.
> 
> My 2 cents,
> -Alex
> 
> On 6/6/18, 2:12 PM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
> 
> 
>> On Jun 6, 2018, at 11:05 PM, Harbs  wrote:
>> 
>>  >text="{locStr.UPLOAD_YOUR_IMAGE}"/>
>> 
> 
>It actually, looks like the x and y values no longer have an effect on 
> this particular component, but there was clearly a reason they were needed to 
> be specified at some point…
> 
>Another one. I have an image which needs to stick to the bottom right of 
> the app. To do that I needed to following:
> 
>  top: calc(100% - 21px);
>  left: calc(100% - 187px);
>  position: fixed;
> 
>With a default of position: relative, I’m able to do this:
> 
>top: -21px;
>float: right;
>right: 10px;
> 
>This being said, it actually looks like I’m wrong about the way to set the 
> defaults being .Application *{}. This actually has a *higher* specificity 
> than .foo{}.[1]
> 
>I think the only way to guarantee that it’ll have a lower specificity than 
> other selectors is to use:
> 
>*{
>position: relative;
>}
> 
>I’m less happy about this option than ."Application *” because it’ll 
> effect elements outside the Royale app if it’s not in an iframe.
> 
>Harbs
> 
>
> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.smashingmagazine.com%2F2007%2F07%2Fcss-specificity-things-you-should-know%2F=02%7C01%7Caharui%40adobe.com%7C36c2eb99bf2e4b45c44d08d5cbf2422f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636639163710627765=1YPJLfmzcaeFlh%2Bu2FTmbTHgvIvS6n%2BhVQiZhiucJqs%3D=0
>  
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.smashingmagazine.com%2F2007%2F07%2Fcss-specificity-things-you-should-know%2F=02%7C01%7Caharui%40adobe.com%7C36c2eb99bf2e4b45c44d08d5cbf2422f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636639163710627765=1YPJLfmzcaeFlh%2Bu2FTmbTHgvIvS6n%2BhVQiZhiucJqs%3D=0>
>  
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.smashingmagazine.com%2F2007%2F07%2Fcss-specificity-things-you-should-know%2F=02%7C01%7Caharui%40adobe.com%7C36c2eb99bf2e4b45c44d08d5cbf2422f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636639163710627765=1YPJLfmzcaeFlh%2Bu2FTmbTHgvIvS6n%2BhVQiZhiucJqs%3D=0
>  
> <https://na0

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

Here’s one example very similar to the RoyaleStore problem:







Which produces:





The dockAndOuterContainer needed the y=“40” or it occupies the same space as 
the controlPalette. With a default of position: relative this is no longer 
needed.

I don’t know the full details, but flexbox does not allow for the space of the 
first item unless position is relative.

Here’s another one:







UPLOAD YOUR IMAGE

In this case, I needed to set the style directly (I don’t remember why, but I 
had a *very* hard time getting it to go where it belonged). The component had 
nothing which prevented the correct positioning itself, but it’s nested inside 
another component which uses a flexbox layout. I think that had something to do 
with the positioning problem. These issues are really hard to diagnose.

Again, a default of position: relative is the solution to this problem, and 
with that default, hard-coding the top and left values is no longer necessary.

My takeaway is simply that a default of relative gives more predictable results 
and layouts do not need to care what other layouts they are nested inside. 
That’s really important for predictable results in a framework.

> On Jun 6, 2018, at 9:43 PM, Alex Harui  wrote:
> 
> Can you provide more details where you needed to set x,y in your app?

Re: [Discussion] Summarizing all discussion about Royale organization and structure

[Harbs]

I agree that beads could use organization.

Model view and controller are easy ones. The rest of the categorization is 
harder.

Layout is also pretty well defined.

Here’s the rest of the categories I could come up with:

ItemRenderer factories
General factories (i.e. MenuFactory)
Beads that add visuals (i.e. subcomponents)
Beads that modify visuals
Beads that add or remove functionality

Harbs

> On May 29, 2018, at 5:26 PM, Carlos Rovira  wrote:
> 
> About beads: Right now all beads are mixed and the major problem I
> experience is to know what beads already exists and where I can find that
> code. For that reason, my proposal is to have a "bead" package, and then
> organize beads in sub packages: "views", "models", "controllers", then for
> controls: "ui" and inside "textinput", "button", "slider", and so...if a
> bead is cross control, then goes to "ui" directly (i.e: Disabled). if is
> cross controls and components, can go to "beads" directly. In that way a
> user can visit beads/ui/textinput and take a quick look of what behaviors
> we already implemented and support. Regargid drop of "Bead" in the name, it
> does not bring us nothing but size and verbosity since we write:
>  so we now "SomeBehaviour" is a bead.
> 
> How to do this? little by little. is not something we can work in a day, so
> we need to divide the problem and go diligently to complete this task. It
> will be made in a branch and then as tested be merged. People already
> royale are Wellcome to express thoughts about this in order to take into
> account (it is preferable to remain silent and get the problem as we
> release). People will need to make adjustments, but this will happen sooner
> or later if we want to stabilize on 1.0 some day.
> 
> Thanks
> 
> 
> 
> 
> 
> 2018-05-29 15:54 GMT+02:00 Harbs :
> 
>> 
>>> On May 29, 2018, at 4:48 PM, Olaf Krueger  wrote:
>>> 
>>> Hi Carlos,
>>> 
>>> thanks for summarizing all this stuff.
>>> 
>>> @all
>>> I have not followed all the discussions, but I would like to ask if that
>>> what Carlos has presented is consensual.
>> 
>> Foundation Is what Carlos is proposing as a new way of organizing things.
>> I think we need a lot of discussion before we can decide on something like
>> that.
>> 
>>> 
>>>> Remove "Bead" ending from beads to make it all less verbose.
>>> 
>>> Are there still any other ways of recognizing a bead then?
>>> Or doesn't it matter if something is a bead or whatever other?
>> 
>> I think all beads should be in some kind of bead package path.
>> 
>>> 
>>>> I offer my time to make this happen.
>>> 
>>> Maybe I am wrong, but I guess these changes affect every existing Royale
>>> application and I could imagine that during this refactoring others maybe
>>> ran into merge conflicts.
>>> Do you have a strategy how this refactoring could be done as "quiet as
>>> possible"?
>>> 
>>> Thanks,
>>> Olaf
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

Perfect.

I think we did a great job on the css part of this discussion. Let’s see if we 
ca come to a meeting of the minds on the rest. :-)

Let’s try and figure out what we all agree and don’t agree on.

The important pieces I see are:

1. How do we define what is “Core"?
2. Should package names match the project names?
3. Do we care to try and make package names shorter (i..e limit the level of 
folders)?
4. What are the advantages and disadvantages of making Basic a dependency for 
other component sets?
5. A question which might follow the ones above are whether we should add a new 
package. I’d rather wait to discuss this until we have some clarity on the ones 
above.

Can you think of any other questions we should be asking ourselves?

Thanks,
Harbs

> On May 29, 2018, at 4:41 PM, Carlos Rovira  wrote:
> 
> Hi,
> 
> completely.
> 
> two things:
> 
> 1. I propose in the new Discussion thread to make that work myself, but we
> can do together. I think the best way is to rename and move things in
> chunks so we make this in various steps, testing builds not break, and so
> onthis will take some days to reach a good shape.
> 2. I already said my work was totally incomplete. But as we need this
> discussion I didn't do more but fixing build.
> 
> 
> 2018-05-29 15:13 GMT+02:00 Harbs :
>> 
>>> First, the hopefully easy things we can agree on:
>>> -I have no objection to dropping "Bead" off of bead class names
>>> -I have no objection to moving all views into a view subfolder as long
>> as nobody else is concerned about the size and performance issues.
>>> -I have no objection to moving classes in Basic that are
>> org.apache.royale.html to org.apache.royale.basic.
>>> -I have no objection to doing a massive rename and long as it isn't me
>> doing the work.
>>> -Whatever is in Core and Basic now or before Carlos's started moving
>> things around is not perfect.
>> 
>> I agree with this completely. Carlos, do you agree as well? (I would be
>> willing to help out with a rename, but I want to make sure it doesn't cause
>> too much disruption.
>> 
>> Thanks,
>> Harbs
>> 
>>> On May 23, 2018, at 12:43 AM, Alex Harui 
>> wrote:
>>> 
>>> Hi Carlos,
>>> 
>>> I guess I don't understand why separating beads from TLCs is better.
>> How will that make things better for users or other component set
>> developers?  That would effectively double the number of SWCs and each TLC
>> SWC will need its bead SWC.  That doesn't sound like a good thing to me,
>> but if that's what other folks want to do, that's fine with me.
>>> 
>>> I was just looking through the classes in Jewel.  It looks like JeweL
>> doesn't have a DataGrid yet..  When it does, I would think you will want to
>> use the DataGridModel from Express as it handles both Arrays and
>> ICollectionViews.  We will probably create a similar model bead that takes
>> both ICollectionViews and Arrays for Lists and put that in Express as
>> well.  Then we might decide that is better for Jewel to use that model
>> instead.  Or maybe we'll decide to create a JewelExpress set that has those
>> more general models that don't require as much configuration.  Anyway, I
>> hope you agree that at some point, these more general models will be used
>> by Express and some flavor of Jewel.  I don't think this general model
>> should go in Core, or Basic (or some new category called Foundation).  And
>> at that point, Jewel or JewelExpress is going to re-use that code in
>> Express.
>>> 
>>> Component sets are encouraged to re-use existing code from any other SWC
>> since I think we've agreed that re-use is important.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 5/21/18, 11:16 AM, "carlos.rov...@gmail.com > carlos.rov...@gmail.com> on behalf of Carlos Rovira" <
>> carlos.rov...@gmail.com <mailto:carlos.rov...@gmail.com> on behalf of
>> carlosrov...@apache.org <mailto:carlosrov...@apache.org>> wrote:
>>> 
>>>   Hi Alex
>>> 
>>>   what do you think about separating the part in Basic that is
>> inherently the
>>>   same as in Jewel (Button, CheckBox, TextInput, List, ...) along with
>> CSS
>>>   that wire the beads for Basic UI set, and left the fundamental
>> building
>>>   blocks as something that is not Core but can be reused by Basic and
>> Jewel
>>>   (Let's call this "Foundation" Lib, I even like this name for this
>> library).
>>> 
>>>   I mean that having "Foundation" 

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

> On May 29, 2018, at 5:34 PM, Carlos Rovira  wrote:
> 
> Hi
> 
> 2018-05-29 16:00 GMT+02:00 Harbs  <mailto:harbs.li...@gmail.com>>:
>> 
>> 
>> 1. How do we define what is “Core"?
>> 
> 
> *Core*: This classes are needed to build a Royale
> 
> Application. All pieces here are required. No CSS is present here
> 
> to wire any concrete relationship between pieces, as well avoiding
> 
> possible inclussions of CSS rules and/or bugs in a final App.

OK. I define Core a bit differently. Core defines the *architecture* or 
“scaffolding” of a Royale application. I don’t believe a Royale application can 
be compiled from Core alone.

Core is assumed to be a prerequisite for almost all other Royale libs (except 
Testing and Language). It should not have dependencies on other libraries or 
particular implementation details.


>> 2. Should package names match the project names?
>> 
> 
> Normaly this is true always. Don't recall libraries with mixed package
> names.
> Some exceptions: Network has "net", but this is normal for less verbosity.

I’m not sure about this. I think It might be beneficial to discuss particulars 
to weigh the pros and cons on this. I don’t know where stand myself.

> 
>> 3. Do we care to try and make package names shorter (i..e limit the level
>> of folders)?
>> 
> 
> Yes, if we can, but in the case os beads, since we'll be using mostly on
> mxml, we put shorter class name over package levels. Even on AS3 in this
> case is better a longer import than multiple longer class names use.

I think I agree with this.

>> 4. What are the advantages and disadvantages of making Basic a dependency
>> for other component sets?
>> 
> 
> I think this is mostly explained here, and a image use to be better than
> thousand words, but the image mix graphs and explanations:
> https://snag.gy/DbH4iG.jpg <https://snag.gy/DbH4iG.jpg>

Here is what the dependencies are currently:
https://www.dropbox.com/s/8n3dxgv45qus3jp/royale.png?dl=0

I don’t understand the point of changing the dependencies around.

To me the advantages of making Basic a dependency is:

1. A clearer (to me), flatter dependency tree.
2. A “base” component set to use (or partially use) for composition.
3. A logical place to put shared beads.

What is gained by removing that dependency?

> 
>> 5. A question which might follow the ones above are whether we should add
>> a new package. I’d rather wait to discuss this until we have some clarity
>> on the ones above.
>> 
> 
> mmm...you mean to say "package" or new "library" (maybe you refer to
> "Foundation" here)

Yes. Or something else.

Thanks,
Harbs

Re: [Discussion] Summarizing all discussion about Royale organization and structure

[Harbs]

Do you have ideas for a naming structure?

> On May 29, 2018, at 5:50 PM, Carlos Rovira  wrote:
> 
> +1 Agree.
> 
> 2018-05-29 16:35 GMT+02:00 Harbs :
> 
>> I agree that beads could use organization.
>> 
>> Model view and controller are easy ones. The rest of the categorization is
>> harder.
>> 
>> Layout is also pretty well defined.
>> 
>> Here’s the rest of the categories I could come up with:
>> 
>> ItemRenderer factories
>> General factories (i.e. MenuFactory)
>> Beads that add visuals (i.e. subcomponents)
>> Beads that modify visuals
>> Beads that add or remove functionality
>> 
>> Harbs
>> 
>>> On May 29, 2018, at 5:26 PM, Carlos Rovira 
>> wrote:
>>> 
>>> About beads: Right now all beads are mixed and the major problem I
>>> experience is to know what beads already exists and where I can find that
>>> code. For that reason, my proposal is to have a "bead" package, and then
>>> organize beads in sub packages: "views", "models", "controllers", then
>> for
>>> controls: "ui" and inside "textinput", "button", "slider", and so...if a
>>> bead is cross control, then goes to "ui" directly (i.e: Disabled). if is
>>> cross controls and components, can go to "beads" directly. In that way a
>>> user can visit beads/ui/textinput and take a quick look of what behaviors
>>> we already implemented and support. Regargid drop of "Bead" in the name,
>> it
>>> does not bring us nothing but size and verbosity since we write:
>>>  so we now "SomeBehaviour" is a
>> bead.
>>> 
>>> How to do this? little by little. is not something we can work in a day,
>> so
>>> we need to divide the problem and go diligently to complete this task. It
>>> will be made in a branch and then as tested be merged. People already
>>> royale are Wellcome to express thoughts about this in order to take into
>>> account (it is preferable to remain silent and get the problem as we
>>> release). People will need to make adjustments, but this will happen
>> sooner
>>> or later if we want to stabilize on 1.0 some day.
>>> 
>>> Thanks
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 2018-05-29 15:54 GMT+02:00 Harbs :
>>> 
>>>> 
>>>>> On May 29, 2018, at 4:48 PM, Olaf Krueger 
>> wrote:
>>>>> 
>>>>> Hi Carlos,
>>>>> 
>>>>> thanks for summarizing all this stuff.
>>>>> 
>>>>> @all
>>>>> I have not followed all the discussions, but I would like to ask if
>> that
>>>>> what Carlos has presented is consensual.
>>>> 
>>>> Foundation Is what Carlos is proposing as a new way of organizing
>> things.
>>>> I think we need a lot of discussion before we can decide on something
>> like
>>>> that.
>>>> 
>>>>> 
>>>>>> Remove "Bead" ending from beads to make it all less verbose.
>>>>> 
>>>>> Are there still any other ways of recognizing a bead then?
>>>>> Or doesn't it matter if something is a bead or whatever other?
>>>> 
>>>> I think all beads should be in some kind of bead package path.
>>>> 
>>>>> 
>>>>>> I offer my time to make this happen.
>>>>> 
>>>>> Maybe I am wrong, but I guess these changes affect every existing
>> Royale
>>>>> application and I could imagine that during this refactoring others
>> maybe
>>>>> ran into merge conflicts.
>>>>> Do you have a strategy how this refactoring could be done as "quiet as
>>>>> possible"?
>>>>> 
>>>>> Thanks,
>>>>> Olaf
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

I’m taking out two snippets from what you write that I think might help bring 
us closer:
> 
> Right, that should go to Foundation, not Basic

What is the difference between “Foundation” and “Basic” other than name? We 
already have “Foundation”, but we call it “Basic”.

If I’m understanding you correctly, the only difference between them is 
defaults.css and basic.css in themes. Other than that *everything* in Basic 
could be considered “Foundation”. Even top level components in Basic could be 
considered “Foundation” because they are designed to be bare-bones. Any 
components that don’t fit that description in Basic need to be fixed.

Why are we making such a big deal over two css files? Right now, they are 
causing inflated application sizes. But we’ve determined that to be a bug In 
Basic. We need to fix the bug regardless. As long as they don’t cause the 
application size to increase (and I’m proposing they shouldn’t), why do we 
care? I don’t think we care that much whether we call it “Basic” or 
“Foundation”. Right?



>> 
>> I think we have a disconnect here.
>> 
>> Let’s take UIBase for example. UIBase has a lot of opinions on how things
>> should be implemented. It gets its children from HTML nodes. It assumes
>> that layout parents are not necessarily the immediate ones. It makes
>> assumptions on what events need to be dispatched. etc. I don’t think that
>> UIBase and friends belong in Core. In fact not every IUIBase even currently
>> in the app are UIBase subclasses. IUIBase belongs in Core because it
>> defines the function of a IUIBase. UIBase does not because it makes
>> implementation assumptions.
>> 
> 
> Here you and Alex think differently. I put UIBase in Core since was what
> Alex suggested. Finaly I think we all think almost the same, but is
> impossible to agree in 100% of things.

Maybe, maybe not. I don’t remember Alex suggesting this, but I could have 
missed it. I don’t think there is any absolute right and wrong here, but we 
*do* need definitions we can all agree on. If UIBase (for example) should go in 
Core, then we need a definition that we can agree on and document which fits 
that and makes it clear exactly what should and what shouldn’t go in Core.

> What we need to do is to move forward and continue build. We need to think
> about what is important for each one so we can get the best of us (not
> 100%). I for example was more for Core - Jewel, then you proposed
> Foundation (not me, it was you, remember? I only put a name that seems
> appropriate to me), so for me is ok.

I was actually proposing something slightly different. I was proposing pulling 
the top level components of Basic (or CSS) into a separate library. I was only 
proposing that if we can’t fix the CSS issues which I think we can.

> 
> What I'll never be in agreement is in having CSS that is processing bead
> linking as a mandatory dependency for all the technical reasons exposed

I completely agree with you on this. I thought that was clear from the CSS 
discussion.

> I think that is not in opposite of the rest of things you want, only for
> one of them, make all UI sets extend Basic classes, but I have a design
> rule in Jewel that is not extend Basic classes, so how we deal with that?

Basic classes, or Basic Top Level Components? I don’t see any reason why you 
should be avoiding anything other than TLCs which are specified in CSS and has 
different typeNames than Jewel ones.

> Should I continue as Piotr proposed in a fork and abandone Royale as others
> did? Or can we go forward and take the best of what all think?

Definitely work this through. :-) I think we can come to an agreement. I think 
we’re not so far apart.

Thanks,
Harbs

Re: [royale-asjs] branch develop updated: Removed duplicate Container

[Harbs]

Sorry about that.

Before this commit the build was failing. That was due to the fact that there 
were two different Container classes and mixed up references.

I’m out of time for today. If you don’t get to this before Saturday night, I’ll 
look at this then.

Harbs

> On Jun 1, 2018, at 6:13 PM, Carlos Rovira  wrote:
> 
> Harbs,
> 
> this commit is making the examples fail. I recommend you tu pass maven on
> examples folder to ensure that nothing is break
> 
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
> examples/Flat-0.9.3-SNAPSHOT-swf.swc:defaults.css(176): col: 17 Error:
> org.apache.royale.html.beads.ContainerView is not defined.
> 
> 
> 
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
> examples/Flat-0.9.3-SNAPSHOT-swf.swc:defaults.css(176): col: 17 Error:
> org.apache.royale.html.beads.ContainerView is not defined.
> 
> 
> 
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
> examples/Flat-0.9.3-SNAPSHOT-swf.swc:defaults.css(176): col: 17 Error:
> org.apache.royale.html.beads.ContainerView is not defined.
> 
> 
> 
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
> examples/Flat-0.9.3-SNAPSHOT-swf.swc:defaults.css(585): col: 17 Error:
> org.apache.royale.html.supportClasses.ContainerContentArea is not defined.
> 
> 
> 
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
> examples/Flat-0.9.3-SNAPSHOT-swf.swc:defaults.css(585): col: 17 Error:
> org.apache.royale.html.supportClasses.ContainerContentArea is not defined.
> 
> 
> 
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
> examples/Flat-0.9.3-SNAPSHOT-swf.swc:defaults.css(585): col: 17 Error:
> org.apache.royale.html.supportClasses.ContainerContentArea is not defined.
> 
> 
> 
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
> examples/Flat-0.9.3-SNAPSHOT-js.swc:defaults.css(176): col: 17 Error:
> org.apache.royale.html.beads.ContainerView is not defined.
> 
> 
> 
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
> examples/Flat-0.9.3-SNAPSHOT-js.swc:defaults.css(176): col: 17 Error:
> org.apache.royale.html.beads.ContainerView is not defined.
> 
> 
> 
> [*INFO*]
> **
> 
> [*INFO*] *Reactor Summary:*
> 
> [*INFO*]
> 
> [*INFO*] Apache Royale: Examples 0.9.3-SNAPSHOT . *SUCCESS* [
> 2.399 s]
> 
> [*INFO*] Apache Royale: Examples: Example-Tests . *SUCCESS* [
> 1.125 s]
> 
> [*INFO*] Apache Royale: Examples: Express ... *SUCCESS* [
> 0.657 s]
> 
> [*INFO*] Apache Royale: Examples: Express: DataBindingExample *SUCCESS* [
> 6.412 s]
> 
> [*INFO*] Apache Royale: Examples: Express: DataGridExample .. *SUCCESS* [
> 3.155 s]
> 
> [*INFO*] Apache Royale: Examples: Express: GitHubCommitLogViewer *SUCCESS*
> [  2.595 s]
> 
> [*INFO*] Apache Royale: Examples: Royale  *SUCCESS* [
> 0.631 s]
> 
> [*INFO*] Apache Royale: Examples: Royale: AccordionExample .. *SUCCESS* [
> 2.184 s]
> 
> [*INFO*] Apache Royale: Examples: Royale: AlertExample .. *SUCCESS* [
> 1.908 s]
> 
> [*INFO*] Apache Royale: Examples: Royale: ASDoc . *SUCCESS* [
> 3.421 s]
> 
> [*INFO*] Apache Royale: Examples: Royale: ChartExample .. *SUCCESS* [
> 2.378 s]
> 
> [*INFO*] Apache Royale: Examples: Royale: CordovaCameraExample *SUCCESS* [
> 1.843 s]
> 
> [*INFO*] Apache Royale: Examples: Royale: CreateJSExample ... *SUCCESS* [
> 1.775 s]
> 
> [*INFO*] Apache Royale: Examples: Royale: DataBindingExample  *SUCCESS* [
> 2.023 s]
> 
> [*INFO*] Apache Royale: Examples: Royale: DataBindingExample_as *SUCCESS*
> [  1.891 s]
> 
> [*INFO*] Apache Royale: Examples: Royale: DataBindingExample_Flat *FAILURE*
> [  1.468 s]
> 
> [*INFO*] Apache Royale: Examples: Royale: DataBindingExampleWithLayout
> *SKIPPED*
> 
> [*INFO*] Apache Royale: Examples: Royale: DataGridExample ... *SKIPPED*
> 
> [*INFO*] Apache Royale: Examples: Royale: DateControlsExample *SKIPPED*
> 
> [*INFO*] Apache Royale: Examples: Royale: DebuggingExample .. *SKIPPED*
> 
> [*INFO*] Apache Royale: Examples: Royale: DesktopMap  *SKIPPED*
> 
> [*INFO*] Apache Royale: Examples: Royale: DividedContainerExample *SKIPPED*
> 
> 2018-06-01 14:07 GMT+02:00 :
> 
>> This is an automated email from the ASF dual-hosted git repository.
>> 
>> harbs pushed a commit to branch develop
>> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>> 
>> 
>> The following commit(s) were added to refs/heads/develop by this push:
>> new e74e4d0  Removed duplicate Container
>> e74e4d0 is described below
>> 
>> commit e74

Re: [royale-asjs] branch develop updated: Removed duplicate Container

[Harbs]

I just looked at things and I have no idea what about my commit would have 
caused those errors.

I’ll look more when I come back online…

Harbs

> On Jun 1, 2018, at 6:40 PM, Harbs  wrote:
> 
> Sorry about that.
> 
> Before this commit the build was failing. That was due to the fact that there 
> were two different Container classes and mixed up references.
> 
> I’m out of time for today. If you don’t get to this before Saturday night, 
> I’ll look at this then.
> 
> Harbs
> 
>> On Jun 1, 2018, at 6:13 PM, Carlos Rovira  wrote:
>> 
>> Harbs,
>> 
>> this commit is making the examples fail. I recommend you tu pass maven on
>> examples folder to ensure that nothing is break
>> 
>> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
>> examples/Flat-0.9.3-SNAPSHOT-swf.swc:defaults.css(176): col: 17 Error:
>> org.apache.royale.html.beads.ContainerView is not defined.
>> 
>> 
>> 
>> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
>> examples/Flat-0.9.3-SNAPSHOT-swf.swc:defaults.css(176): col: 17 Error:
>> org.apache.royale.html.beads.ContainerView is not defined.
>> 
>> 
>> 
>> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
>> examples/Flat-0.9.3-SNAPSHOT-swf.swc:defaults.css(176): col: 17 Error:
>> org.apache.royale.html.beads.ContainerView is not defined.
>> 
>> 
>> 
>> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
>> examples/Flat-0.9.3-SNAPSHOT-swf.swc:defaults.css(585): col: 17 Error:
>> org.apache.royale.html.supportClasses.ContainerContentArea is not defined.
>> 
>> 
>> 
>> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
>> examples/Flat-0.9.3-SNAPSHOT-swf.swc:defaults.css(585): col: 17 Error:
>> org.apache.royale.html.supportClasses.ContainerContentArea is not defined.
>> 
>> 
>> 
>> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
>> examples/Flat-0.9.3-SNAPSHOT-swf.swc:defaults.css(585): col: 17 Error:
>> org.apache.royale.html.supportClasses.ContainerContentArea is not defined.
>> 
>> 
>> 
>> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
>> examples/Flat-0.9.3-SNAPSHOT-js.swc:defaults.css(176): col: 17 Error:
>> org.apache.royale.html.beads.ContainerView is not defined.
>> 
>> 
>> 
>> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/
>> examples/Flat-0.9.3-SNAPSHOT-js.swc:defaults.css(176): col: 17 Error:
>> org.apache.royale.html.beads.ContainerView is not defined.
>> 
>> 
>> 
>> [*INFO*]
>> **
>> 
>> [*INFO*] *Reactor Summary:*
>> 
>> [*INFO*]
>> 
>> [*INFO*] Apache Royale: Examples 0.9.3-SNAPSHOT . *SUCCESS* [
>> 2.399 s]
>> 
>> [*INFO*] Apache Royale: Examples: Example-Tests . *SUCCESS* [
>> 1.125 s]
>> 
>> [*INFO*] Apache Royale: Examples: Express ... *SUCCESS* [
>> 0.657 s]
>> 
>> [*INFO*] Apache Royale: Examples: Express: DataBindingExample *SUCCESS* [
>> 6.412 s]
>> 
>> [*INFO*] Apache Royale: Examples: Express: DataGridExample .. *SUCCESS* [
>> 3.155 s]
>> 
>> [*INFO*] Apache Royale: Examples: Express: GitHubCommitLogViewer *SUCCESS*
>> [  2.595 s]
>> 
>> [*INFO*] Apache Royale: Examples: Royale  *SUCCESS* [
>> 0.631 s]
>> 
>> [*INFO*] Apache Royale: Examples: Royale: AccordionExample .. *SUCCESS* [
>> 2.184 s]
>> 
>> [*INFO*] Apache Royale: Examples: Royale: AlertExample .. *SUCCESS* [
>> 1.908 s]
>> 
>> [*INFO*] Apache Royale: Examples: Royale: ASDoc . *SUCCESS* [
>> 3.421 s]
>> 
>> [*INFO*] Apache Royale: Examples: Royale: ChartExample .. *SUCCESS* [
>> 2.378 s]
>> 
>> [*INFO*] Apache Royale: Examples: Royale: CordovaCameraExample *SUCCESS* [
>> 1.843 s]
>> 
>> [*INFO*] Apache Royale: Examples: Royale: CreateJSExample ... *SUCCESS* [
>> 1.775 s]
>> 
>> [*INFO*] Apache Royale: Examples: Royale: DataBindingExample  *SUCCESS* [
>> 2.023 s]
>> 
>> [*INFO*] Apache Royale: Examples: Royale: DataBindingExample_as *SUCCESS*
>> [  1.891 s]
>> 
>> [*INFO*] Apache Royale: Examples: Royale: DataBindingExample_Flat *FAILURE*
>> [  1.468 s]
>> 
>> [*INFO*] Apache Royale: Examples: Royale: DataBindingExampleWithLayout
>> *SKIPPED*
>> 
>> [*INFO*] Apache Royale: Examples: Royale: DataGridExample ... *SKIPPED*
>> 
>> [*INFO*] Apache Royale: Examples: Royale: DateControlsExample *SKIPPED*
>> 
>> [*INFO

Re: Restructuring Composite Components

[Harbs]

I don’t think so. The List is a component within ComboBox. I think the basic 
structure of ComboBox makes sense as is. I think it’s the View which needs work.

It’s possible that an Express ComboBox might have additional properties to make 
it easier to set the labelField, listHeight, etc.

I’m primarily trying to figure out the best way to declare the “skin pieces” of 
the view.

Harbs

> On May 31, 2018, at 5:17 PM, Piotr Zarzycki  wrote:
> 
> Hi Harbs,
> 
> What if ComboBox will extend DataContainer? It will be at some point list
> itself. Than the rest responsibility is in View. We know that ComboBox is
> always list, so if someone would like to change the other parts need to
> have dive into view.
> 
> On the other hand this solution probably is less flexible than having
> through css some parts of that component.
> 
> Thanks,
> Piotr
> 
> 
> czw., 31 maj 2018 o 15:35 Harbs  napisał(a):
> 
>> I’m working on redoing ComboBox and I could use some input on best
>> practices.
>> 
>> Right now, ComboBox has ComboBox view which has three components
>> hard-wired in. It has TextInput, TextButton, and List. If any visuals or
>> behavior need to be changed, the entire view needs to be rewritten. We’ve
>> already had two cases where I needed a new view. One was to disable the
>> TextInput input and change the button appearance. The second was to support
>> images in a dropdown.
>> 
>> It seems to me like the ComboBoxView should add the three components based
>> on declared classes. I think there should be 1. A “Button” component. 2. An
>> ItemRenderer component for the “input” which displays the selected item. 3.
>> A List component for displaying the dropdown. The question I’m struggling
>> with is how to declare these.
>> 
>> I don’t think it makes sense to make these all beads. Currently Buttons
>> are not beads.
>> 
>> Should we add interfaces (i.e. IButton) and declare the classes using
>> interfaces? I mean something similar to IItemRenderer.
>> 
>> Maybe just use ValuesManager to just lookup some other “name”? We’re
>> currently doing something similar with ColumnClassName in DynamicDataGrid.
>> 
>> Other ideas?
>> 
>> Thanks,
>> Harbs
> 
> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

I’m not sure if we’re communicating.

Composite TLCs have many pieces and only some of them are related to View. 
DataGrid has 5 class reference and only one is IBeadView. DataGrid uses 
DataGridColumnList which has 9 class references. One is view and another which 
might (or might not) need replacement is layout. Other than these classes, the 
whole component should just work as-is in Jewel. All you need is to swap out 
the IBeadView and/or part of the view.

We *would* need to make sure that the swapped view classes are not imported 
unnecessarily. (I’m not sure if they are or not.) If they are, I think it’s 
clear that is a bug which needs to be fixed no-matter. Defaults should not be 
imported if overridden by applications.

Maybe we should wait on this decision until Jewel is more complete? It’s 
possible that you are right and none of the TLCs will end up in Jewel. It’s 
possible I’m right and they will. I don’t see how restructuring Basic is 
necessary until we’re sure of the outcome of that.

Thoughts?
Harbs

> On May 31, 2018, at 2:10 PM, Carlos Rovira  wrote:
> 
>> 2, Composite TLCs are components such as ComboBox, DataGrid, possibly
>> ImageButon etc. The components are basically UIBase components which
>> describe how the pieces are wired together. The views are separate
>> components that are declared. For these TLCs, there shouldn’t be a need to
>> duplicate the classes or subclass the classes in Jewel at all. It should be
>> possible to simply use Basic or Express composite TLCs and simply declare a
>> Jewel view to use with them.
>> 
>> 
> yes, if you are seeing that the compositing TLCs are Jewel TLCs. For
> example, ComboBox will compose a Jewel Button not Basic Button, to comply
> with the overall set and purpose. As well will compose a TextInput and a
> List from Jewel, not from Basic. Take into account that the first thing a
> Jewel TLC (basic or complex) will do is set typeNames in constructor to
> "jewel XXX", and then define "component parts" like button:Button (of Jewel
> set).
> 
> Image Button will as well composite a Jewel Button. DataGrid is a complex
> TLC that will be using jewel TLCs and other build blocks currently in
> Basic, that should move to Foundation (or whatever we want to call to
> "reusable library with common code and beads").
> 
> What is clear is that all pieces that are reusable in ComboBox, DataGrid or
> ImageButton will be used to create those components in Jewel, as many as we
> can.
> All those components will have its own Jewel view to make its own visuals,
> like SliderView in jewel needs that code that is different to basic one
> since it "fills" the bar as we move the thumb.
> 
> 
> 
>> Is there an issue that I’m missing here?
>> 
>> Harbs
>> 
>>> On May 31, 2018, at 12:12 PM, Carlos Rovira 
>> wrote:
>>> 
>>> Hi Harbs,
>>> 
>>> concreting more over if Jewel should or not extend Basic TLCs. That I
>> think
>>> is the real point now to discuss. I'm sure it should not be the case. To
>>> sum to all that I exposed, it was not clearly sufficient enough (that I
>>> think it should be). Why I want all the class definitions overhead it
>> will
>>> cause?
>>> 
>>> Why have the basic Button file with all the class text definitions and
>> then
>>> the jewel Button file with all the definitions there? Think that we don't
>>> get anything profitable from all that overhead. I think that reusable
>> code
>>> are pieces to construct, but not pieces designed to be final in some
>> case.
>>> So to build a house I use bricks, cement, beams, and so on, but then I
>>> don't use the house to make a castle.
>>> 
>>> Moreover, think that Basic needs to change some component part...then
>> maybe
>>> Jewel can't do that... that's a huge problem. So think that in the house
>> I
>>> want to change a window from a place to another, then the castle will
>> need
>>> to live with that without any reason and possibility to not be affected.
>>> 
>>> You must to recognize that although the theory here is good (remember
>> that
>>> I started to be aligned with that), the reality is not the same.
>>> 
>>> My experience in many things in life make think that not all is 100%
>> black
>>> or white. I think is great the philosophy we have on PAYG, beads and
>> reuse,
>>> but I the case of TLCs and see that as something optionally extendible,
>> but
>>> not mandatory. Or in other words TLCs are almost a leaf usable component
>>> that is mainly designed w

Restructuring Composite Components

[Harbs]

I’m working on redoing ComboBox and I could use some input on best practices.

Right now, ComboBox has ComboBox view which has three components hard-wired in. 
It has TextInput, TextButton, and List. If any visuals or behavior need to be 
changed, the entire view needs to be rewritten. We’ve already had two cases 
where I needed a new view. One was to disable the TextInput input and change 
the button appearance. The second was to support images in a dropdown.

It seems to me like the ComboBoxView should add the three components based on 
declared classes. I think there should be 1. A “Button” component. 2. An 
ItemRenderer component for the “input” which displays the selected item. 3. A 
List component for displaying the dropdown. The question I’m struggling with is 
how to declare these.

I don’t think it makes sense to make these all beads. Currently Buttons are not 
beads.

Should we add interfaces (i.e. IButton) and declare the classes using 
interfaces? I mean something similar to IItemRenderer.

Maybe just use ValuesManager to just lookup some other “name”? We’re currently 
doing something similar with ColumnClassName in DynamicDataGrid.

Other ideas?

Thanks,
Harbs

Re: Restructuring Composite Components

[Harbs]

An additional wrinkle in this problem is wether there’s any way to specify the 
parts of the view using MXML, or it has to be in CSS.

If they are beads, that problem is simplified. If not, is there a way to add to 
ValueManager via MXML?

Harbs

> On May 31, 2018, at 6:09 PM, Harbs  wrote:
> 
> I don’t think so. The List is a component within ComboBox. I think the basic 
> structure of ComboBox makes sense as is. I think it’s the View which needs 
> work.
> 
> It’s possible that an Express ComboBox might have additional properties to 
> make it easier to set the labelField, listHeight, etc.
> 
> I’m primarily trying to figure out the best way to declare the “skin pieces” 
> of the view.
> 
> Harbs
> 
>> On May 31, 2018, at 5:17 PM, Piotr Zarzycki  
>> wrote:
>> 
>> Hi Harbs,
>> 
>> What if ComboBox will extend DataContainer? It will be at some point list
>> itself. Than the rest responsibility is in View. We know that ComboBox is
>> always list, so if someone would like to change the other parts need to
>> have dive into view.
>> 
>> On the other hand this solution probably is less flexible than having
>> through css some parts of that component.
>> 
>> Thanks,
>> Piotr
>> 
>> 
>> czw., 31 maj 2018 o 15:35 Harbs  napisał(a):
>> 
>>> I’m working on redoing ComboBox and I could use some input on best
>>> practices.
>>> 
>>> Right now, ComboBox has ComboBox view which has three components
>>> hard-wired in. It has TextInput, TextButton, and List. If any visuals or
>>> behavior need to be changed, the entire view needs to be rewritten. We’ve
>>> already had two cases where I needed a new view. One was to disable the
>>> TextInput input and change the button appearance. The second was to support
>>> images in a dropdown.
>>> 
>>> It seems to me like the ComboBoxView should add the three components based
>>> on declared classes. I think there should be 1. A “Button” component. 2. An
>>> ItemRenderer component for the “input” which displays the selected item. 3.
>>> A List component for displaying the dropdown. The question I’m struggling
>>> with is how to declare these.
>>> 
>>> I don’t think it makes sense to make these all beads. Currently Buttons
>>> are not beads.
>>> 
>>> Should we add interfaces (i.e. IButton) and declare the classes using
>>> interfaces? I mean something similar to IItemRenderer.
>>> 
>>> Maybe just use ValuesManager to just lookup some other “name”? We’re
>>> currently doing something similar with ColumnClassName in DynamicDataGrid.
>>> 
>>> Other ideas?
>>> 
>>> Thanks,
>>> Harbs
>> 
>> 
>> 
>> -- 
>> 
>> Piotr Zarzycki
>> 
>> Patreon: *https://www.patreon.com/piotrzarzycki
>> <https://www.patreon.com/piotrzarzycki>*
> 

Re: Last class selectors

[Harbs]

FYI, I just compiled a bare-bones app, and a Basic app with a View, VContainer 
and Label is 85KB uncompressed. 24KB gzipped. It looks like there’s no extra 
classes. 

The CSS is 546 bytes and 222 bytes gzipped. There’s no extra css either, 
although som empty selectors could use some cleanup.

Harbs

> On Jun 4, 2018, at 4:27 PM, Harbs  wrote:
> 
> The only class selectors left in Basic defaults.css is:
> 
> .Application *, .royale *, . royale *:before, . royale *:after {
>   -moz-box-sizing: border-box;
>   -webkit-box-sizing: border-box;
>   box-sizing: border-box;
> }
> 
> I’m not sure how to best get rid of this.
> 
> Thoughts?
> Harbs

Re: [royale-asjs] branch develop updated: Removed unselectable selector

[Harbs]

> I don't know why someone would want to override unselectable styles, but the 
> first idea that popped into my head was a different background color so folks 
> knew not to even bother to select text in the unselectable controls.  Another 
> possibility is that there are other styles that may be needed someday that 
> control how screen readers deal with unselectable controls.

Ah. You mean add additional styles. There’s no reason they couldn’t add an 
additional .unselectable selector with styling elsewhere in the CSS. I could go 
either way on this. If folks feel strongly it should be a “proper” selector, 
I’ll do that.

Thanks,
Harbs

> On Jun 4, 2018, at 7:07 PM, Alex Harui  wrote:
> 
> Feel free to change the name of the bead so that the Type Selector name looks 
> "better".  I think we agreed to drop the "Bead" portion of names going 
> forward.
> 
> If you are absolutely sure nobody will ever need to override what is in that 
> selector, then I'm fine with injecting it with code and using the new utility 
> function you created, but otherwise, I would hope we try to write the 
> framework without injecting styles with code.  Having overrideable selectors 
> should be the recommended practice for a framework.  We want everything to be 
> override-able.
> 
> I don't know why someone would want to override unselectable styles, but the 
> first idea that popped into my head was a different background color so folks 
> knew not to even bother to select text in the unselectable controls.  Another 
> possibility is that there are other styles that may be needed someday that 
> control how screen readers deal with unselectable controls.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 8:48 AM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
> 
>That would probably work. I’m not totally happy with that selector name.
> 
>I can switch the implementation if you think that’s better. I’m not sure 
> why a user would override an “unelectable” style though.
> 
>Harbs
> 
>> On Jun 4, 2018, at 6:45 PM, Alex Harui  wrote:
>> 
>> Hi Harbs,
>> 
>> My suggestion for adding the selector is to make the selector look like a 
>> Type/Element Selector with the name "UnselectableElementBead".  If you do 
>> that, then wouldn't that selector be dropped out if nobody is using 
>> UnselectableElementBead?
>> 
>> I would hope we could find a solution that doesn't result in code injecting 
>> styles as that sort of screws up users overriding those styles.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 6/4/18, 1:14 AM, "Harbs" > <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>> <mailto:harbs.li...@gmail.com>>> wrote:
>> 
>>   It does add the style to the class list.
>> 
>>   The only question is how to add the selector to the CSS.
>> 
>>   Thanks,
>>   Harbs
>> 
>>> On Jun 4, 2018, at 10:24 AM, Carlos Rovira >> <mailto:carlosrov...@apache.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> I think as Alex that better way for this is the bead add the css style to
>>> classList.
>>> 
>>> thanks
>>> 
>>> 2018-06-04 6:33 GMT+02:00 Alex Harui >> <mailto:aha...@adobe.com.invalid>>:
>>> 
>>>> IMO, the better fix would be to just rename the selector in defaults.css
>>>> to be UnselectableElementBead and have UnselectableElementBead add
>>>> "UnselectableElementBead" to the classList.
>>>> 
>>>> Or am I not understanding what this does?
>>>> 
>>>> -Alex
>>>> 
>>>> 
>>>> On 6/2/18, 1:59 PM, "Harbs" >>> <mailto:harbs.li...@gmail.com>> wrote:
>>>> 
>>>>  What I really wanted to do here was create some self invoking code
>>>> which was run when the UnselectableElementBead class was loaded.
>>>> 
>>>>  Is there any way of doing that without writing a static method and
>>>> invoking that?
>>>> 
>>>>  Thanks,
>>>>  Harbs
>>>> 
>>>> 
>>>>> On Jun 2, 2018, at 11:39 PM, ha...@apache.org <mailto: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://na01.safelinks

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

I’m suggesting that we change defaults.css

from:
Application
{
padding: 0px;
margin: 0px;
}

to:
Application
{
padding: 0px;
margin: 0px;
position: relative;
}

I believe this will resolve this issue as the default would cascade down to all 
sub-elements. The default would be relative, but beads would be free to change 
that to whatever they want.

Of course, that would dictate that UIBase belongs in Basic and not Core… ;-)

Harbs

> On Jun 4, 2018, at 7:10 PM, Alex Harui  wrote:
> 
> I’m not sure exactly what change you are proposing, but UIBase used to set 
> position=relative on all positioners.  We took that away so that the "flex" 
> and other display/layout styles would not have to deal with the excess 
> clutter and overhead of having set position on so many elements in the DOM.  
> Via PAYG, only the elements that need to have a style.position should have it 
> set.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 8:44 AM, "Harbs"  wrote:
> 
>It just occurred to me that the problem is due to the default position 
> being static.
> 
>I just added position: relative; to the .Application css and that resolved 
> the issue as well.
> 
>I wonder if we could completely do away with the offsetParent logic in 
> UIBase if we make the default position: relative. That would have a major 
> positive impact on performance.
> 
>Thoughts?
>Harbs
> 
>> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
>> 
>> Hi Yishay,
>> 
>> IMO, the new fix is better.  And you took the right approach by examining 
>> the code flow in the debugger.  When layout fails for what appears to be a 
>> timing issue (in this case, offsetParent not set), we definitely want to 
>> take the time to carefully analyze why there is a timing issue instead of 
>> apply code to work around the current lifecycle.
>> 
>> I'm not sure we can recommend a general pattern for layouts.  I think there 
>> is some PAYG involved.  It could be that in some cases the View should be 
>> responsible for setting style.position.  Then the layouts don't have to 
>> spend the time verifying style.position.  In other cases the layouts could 
>> be used in places where other potential layouts don't rely on style.position 
>> being a particular value.  I think BasicLayout for Containers is an example.
>> 
>> The code you used could be put into a utility function for layouts to use to 
>> guarantee that x,y will work as expected.
>> 
>> Thanks,
>> -Alex
>> 
>> On 6/4/18, 8:22 AM, "yishayw"  wrote:
>> 
>>   Looking at it some more it has nothing to do with data binding. I pushed a
>>   different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes the
>>   layout itself. Here it's assumed the offsetParent is explicitly set before
>>   children's x and y are set. Should this be a general pattern?
>> 
>> 
>> 
>> 
>>   --
>>   Sent from: 
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
>> 
>> 
> 
> 
> 

Re: [royale-asjs] branch develop updated: Removed unselectable selector

[Harbs]

Fair enough.

Of course the styling could also be a bead…

> On Jun 4, 2018, at 7:14 PM, Alex Harui  wrote:
> 
> IMO, it is easier for folks to know that there is a selector to override or 
> add styles to if it is in one of our .css files instead of buried in code.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 9:11 AM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
> 
>> I don't know why someone would want to override unselectable styles, but the 
>> first idea that popped into my head was a different background color so 
>> folks knew not to even bother to select text in the unselectable controls.  
>> Another possibility is that there are other styles that may be needed 
>> someday that control how screen readers deal with unselectable controls.
> 
>Ah. You mean add additional styles. There’s no reason they couldn’t add an 
> additional .unselectable selector with styling elsewhere in the CSS. I could 
> go either way on this. If folks feel strongly it should be a “proper” 
> selector, I’ll do that.
> 
>Thanks,
>Harbs
> 
>> On Jun 4, 2018, at 7:07 PM, Alex Harui  wrote:
>> 
>> Feel free to change the name of the bead so that the Type Selector name 
>> looks "better".  I think we agreed to drop the "Bead" portion of names going 
>> forward.
>> 
>> If you are absolutely sure nobody will ever need to override what is in that 
>> selector, then I'm fine with injecting it with code and using the new 
>> utility function you created, but otherwise, I would hope we try to write 
>> the framework without injecting styles with code.  Having overrideable 
>> selectors should be the recommended practice for a framework.  We want 
>> everything to be override-able.
>> 
>> I don't know why someone would want to override unselectable styles, but the 
>> first idea that popped into my head was a different background color so 
>> folks knew not to even bother to select text in the unselectable controls.  
>> Another possibility is that there are other styles that may be needed 
>> someday that control how screen readers deal with unselectable controls.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 6/4/18, 8:48 AM, "Harbs" > <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>> <mailto:harbs.li...@gmail.com>>> wrote:
>> 
>>   That would probably work. I’m not totally happy with that selector name.
>> 
>>   I can switch the implementation if you think that’s better. I’m not sure 
>> why a user would override an “unelectable” style though.
>> 
>>   Harbs
>> 
>>> On Jun 4, 2018, at 6:45 PM, Alex Harui >> <mailto:aha...@adobe.com.INVALID>> wrote:
>>> 
>>> Hi Harbs,
>>> 
>>> My suggestion for adding the selector is to make the selector look like a 
>>> Type/Element Selector with the name "UnselectableElementBead".  If you do 
>>> that, then wouldn't that selector be dropped out if nobody is using 
>>> UnselectableElementBead?
>>> 
>>> I would hope we could find a solution that doesn't result in code injecting 
>>> styles as that sort of screws up users overriding those styles.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 6/4/18, 1:14 AM, "Harbs" >> <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>>> <mailto:harbs.li...@gmail.com>> <mailto:harbs.li...@gmail.com 
>>> <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>>> <mailto:harbs.li...@gmail.com>>>> wrote:
>>> 
>>>  It does add the style to the class list.
>>> 
>>>  The only question is how to add the selector to the CSS.
>>> 
>>>  Thanks,
>>>  Harbs
>>> 
>>>> On Jun 4, 2018, at 10:24 AM, Carlos Rovira >>> <mailto:carlosrov...@apache.org> <mailto:carlosrov...@apache.org 
>>>> <mailto:carlosrov...@apache.org>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I think as Alex that better way for this is the bead add the css style to
>>>> classList.
>>>> 
>>>> thanks
>>>> 
>>>> 2018-06-04 6:33 GMT+02:00 Alex Harui >>> <mailto:aha...@adobe.com.invalid> <mailto:aha...@adobe.com.invalid 
>>>> <mailto:aha...@adobe.com.invalid>>>:
>>>> 
>>>>> IMO, the better fix would be to just rename the selector in defaults.css
>>>>> to be UnselectableElementBea

Re: [royale-asjs] branch develop updated: Removed unselectable selector

[Harbs]

That would probably work. I’m not totally happy with that selector name.

I can switch the implementation if you think that’s better. I’m not sure why a 
user would override an “unelectable” style though.

Harbs

> On Jun 4, 2018, at 6:45 PM, Alex Harui  wrote:
> 
> Hi Harbs,
> 
> My suggestion for adding the selector is to make the selector look like a 
> Type/Element Selector with the name "UnselectableElementBead".  If you do 
> that, then wouldn't that selector be dropped out if nobody is using 
> UnselectableElementBead?
> 
> I would hope we could find a solution that doesn't result in code injecting 
> styles as that sort of screws up users overriding those styles.
> 
> My 2 cents,
> -Alex
> 
> On 6/4/18, 1:14 AM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
> 
>It does add the style to the class list.
> 
>The only question is how to add the selector to the CSS.
> 
>Thanks,
>Harbs
> 
>> On Jun 4, 2018, at 10:24 AM, Carlos Rovira  wrote:
>> 
>> Hi,
>> 
>> I think as Alex that better way for this is the bead add the css style to
>> classList.
>> 
>> thanks
>> 
>> 2018-06-04 6:33 GMT+02:00 Alex Harui :
>> 
>>> IMO, the better fix would be to just rename the selector in defaults.css
>>> to be UnselectableElementBead and have UnselectableElementBead add
>>> "UnselectableElementBead" to the classList.
>>> 
>>> Or am I not understanding what this does?
>>> 
>>> -Alex
>>> 
>>> 
>>> On 6/2/18, 1:59 PM, "Harbs"  wrote:
>>> 
>>>   What I really wanted to do here was create some self invoking code
>>> which was run when the UnselectableElementBead class was loaded.
>>> 
>>>   Is there any way of doing that without writing a static method and
>>> invoking that?
>>> 
>>>   Thanks,
>>>   Harbs
>>> 
>>> 
>>>> On Jun 2, 2018, at 11:39 PM, 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=02%7C01%7Caharui%40adobe.com%7C9369538a50114755520308d5c8cb
>>> b09c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636635699536531937=iPymBmOQfeD1312Szlsc6Fwc4E5GU2
>>> Kj3OwfvmWh%2Bzk%3D=0
>>>> 
>>>> 
>>>> The following commit(s) were added to refs/heads/develop by this
>>> push:
>>>>   new b157ecf  Removed unselectable selector
>>>> b157ecf is described below
>>>> 
>>>> commit b157ecff5ea11ff2035e105f266b0925c1970005
>>>> Author: Harbs 
>>>> AuthorDate: Sat Jun 2 23:39:28 2018 +0300
>>>> 
>>>>  Removed unselectable selector
>>>> ---
>>>> .../projects/Basic/src/main/resources/defaults.css |  9 -
>>>> .../royale/html/beads/UnselectableElementBead.as   | 22
>>> ++
>>>> 2 files changed, 22 insertions(+), 9 deletions(-)
>>>> 
>>>> diff --git a/frameworks/projects/Basic/src/main/resources/defaults.css
>>> b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>> index ea02120..23a324d 100644
>>>> --- a/frameworks/projects/Basic/src/main/resources/defaults.css
>>>> +++ b/frameworks/projects/Basic/src/main/resources/defaults.css
>>>> @@ -26,15 +26,6 @@
>>>> box-sizing: border-box;
>>>> }
>>>> 
>>>> -.unselectable
>>>> -{
>>>> - -moz-user-select: -moz-none;
>>>> - -khtml-user-select: none;
>>>> - -webkit-user-select: none;
>>>> - -o-user-select: none;
>>>> - user-select: none;
>>>> -}
>>>> -
>>>> Alert
>>>> {
>>>> IBeadLayout: ClassReference("org.apache.royale.html.beads.layouts.
>>> VerticalFlexLayout");
>>>> diff --git a/frameworks/projects/Basic/src/main/royale/org/apache/
>>> royale/html/beads/UnselectableElementBead.as b/frameworks/projects/Basic/
>>> src/main/royale/org/apache/royale/html/beads/UnselectableElementBead.as
>>>> index 6697472..c80c907 100644
>>>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/
>>> royale/html/beads/UnselectableEleme

Re: [royale-asjs] branch develop updated: Fixes #258. But is that a proper fix?

[Harbs]

It just occurred to me that the problem is due to the default position being 
static.

I just added position: relative; to the .Application css and that resolved the 
issue as well.

I wonder if we could completely do away with the offsetParent logic in UIBase 
if we make the default position: relative. That would have a major positive 
impact on performance.

Thoughts?
Harbs

> On Jun 4, 2018, at 6:36 PM, Alex Harui  wrote:
> 
> Hi Yishay,
> 
> IMO, the new fix is better.  And you took the right approach by examining the 
> code flow in the debugger.  When layout fails for what appears to be a timing 
> issue (in this case, offsetParent not set), we definitely want to take the 
> time to carefully analyze why there is a timing issue instead of apply code 
> to work around the current lifecycle.
> 
> I'm not sure we can recommend a general pattern for layouts.  I think there 
> is some PAYG involved.  It could be that in some cases the View should be 
> responsible for setting style.position.  Then the layouts don't have to spend 
> the time verifying style.position.  In other cases the layouts could be used 
> in places where other potential layouts don't rely on style.position being a 
> particular value.  I think BasicLayout for Containers is an example.
> 
> The code you used could be put into a utility function for layouts to use to 
> guarantee that x,y will work as expected.
> 
> Thanks,
> -Alex
> 
> On 6/4/18, 8:22 AM, "yishayw"  wrote:
> 
>Looking at it some more it has nothing to do with data binding. I pushed a
>different fix (799f1878250d8c69347f08442c2c333740efdb8d) that changes the
>layout itself. Here it's assumed the offsetParent is explicitly set before
>children's x and y are set. Should this be a general pattern?
> 
> 
> 
> 
>--
>Sent from: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F=02%7C01%7Caharui%40adobe.com%7Cb3fbf0fe3aef48f404ce08d5ca2f0006%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637225574936981=tQL6czkhz6TGNfiVuLzM8BpNPd%2BudGur3FGTGyZUJew%3D=0
> 
> 

Re: [royale-compiler] branch develop updated: compiler-jx: added js-dynamic-access-unknown-members compiler option to have emitter use dynamic bracket access when the right side of a member access exp

[Harbs]

Thanks for this Josh!

I just tested this on a very complex library project with crazy complex untyped 
data structures. It works great!

I wish we had this option when I was working on my app. I spent many hours 
chasing down minification issues that could have been fixed by this option.

I also think it should default to true.

Thanks,
Harbs

> On Jun 26, 2018, at 9:56 PM, joshtynj...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> joshtynjala pushed a commit to branch develop
> in repository https://gitbox.apache.org/repos/asf/royale-compiler.git
> 
> 
> The following commit(s) were added to refs/heads/develop by this push:
> new 48d86c8  compiler-jx: added js-dynamic-access-unknown-members 
> compiler option to have emitter use dynamic bracket access when the right 
> side of a member access expression cannot be resolved to a definition.
> 48d86c8 is described below
> 
> commit 48d86c8c4b235ce60b282ad16d62d4ff87c3746b
> Author: Josh Tynjala 
> AuthorDate: Tue Jun 26 11:55:56 2018 -0700
> 
>compiler-jx: added js-dynamic-access-unknown-members compiler option to 
> have emitter use dynamic bracket access when the right side of a member 
> access expression cannot be resolved to a definition.
> 
>In other words, myObj.dynamicMember will become myObj['dynamicMember']. 
> Known members will use the regular dot syntax. Useful for stopping the 
> Closure compiler from renaming members that are dynamic, such as members of 
> an object literal. Defaults to false to avoid breaking anything. However, I 
> think it makes sense to have it default to true instead to give developers a 
> better user experience.
> ---
> .../royale/compiler/clients/JSConfiguration.java   | 26 
> .../codegen/js/jx/MemberAccessEmitter.java | 47 +++---
> .../js/royale/TestDynamicAccessUnknownMembers.java | 71 ++
> 3 files changed, 137 insertions(+), 7 deletions(-)
> 
> diff --git 
> a/compiler-jx/src/main/java/org/apache/royale/compiler/clients/JSConfiguration.java
>  
> b/compiler-jx/src/main/java/org/apache/royale/compiler/clients/JSConfiguration.java
> index 0e6caf5..5433608 100644
> --- 
> a/compiler-jx/src/main/java/org/apache/royale/compiler/clients/JSConfiguration.java
> +++ 
> b/compiler-jx/src/main/java/org/apache/royale/compiler/clients/JSConfiguration.java
> @@ -137,6 +137,32 @@ public class JSConfiguration extends Configuration
> }
> 
> //
> +// 'js-dynamic-access-unknown-members'
> +//
> +
> +private boolean jsDynamicAccessUnknownMembers = false;
> +
> +public boolean getJsDynamicAccessUnknownMembers()
> +{
> +return jsDynamicAccessUnknownMembers;
> +}
> +
> +/**
> + * If the definition of a member cannot be resolved, emit dynamic access
> + * instead of normal member access. Ensures that dynamic members aren't
> + * renamed.
> + * 
> + * myObject.memberAccess becomes 
> myObject["memberAccess"]
> + */
> +@Config
> +@Mapping("js-dynamic-access-unknown-members")
> +public void setJsDynamicAccessUnknownMembers(ConfigurationValue cv, 
> boolean value)
> +throws ConfigurationException
> +{
> +jsDynamicAccessUnknownMembers = value;
> +}
> +
> +//
> // 'compiler.js-external-library-path' option
> //
> 
> diff --git 
> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
>  
> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> index d308d34..b7a577c 100644
> --- 
> a/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> +++ 
> b/compiler-jx/src/main/java/org/apache/royale/compiler/internal/codegen/js/jx/MemberAccessEmitter.java
> @@ -32,12 +32,14 @@ import 
> org.apache.royale.compiler.internal.codegen.js.goog.JSGoogEmitterTokens;
> import 
> org.apache.royale.compiler.internal.codegen.js.jx.BinaryOperatorEmitter.DatePropertiesGetters;
> import org.apache.royale.compiler.internal.definitions.AccessorDefinition;
> import org.apache.royale.compiler.internal.definitions.FunctionDefinition;
> +import org.apache.royale.compiler.internal.projects.RoyaleJSProject;
> import org.apache.royale.compiler.internal.tree.as.DynamicAccessNode;
> import org.apache.royale.compiler.internal.tree.as.FunctionCallNode;
> import org.apache.royale.compiler.internal.tree.as.GetterNode;
> import org.apache.royale.compiler.internal.tree.as.IdentifierNode;
> import org.apache.royale.compiler.internal.tree.as.MemberAccessExpressionNode;
> import 
> org.apache.royale.

Re: [royale-compiler] branch develop updated: compiler-jx: added js-dynamic-access-unknown-members compiler option to have emitter use dynamic bracket access when the right side of a member access exp

[Harbs]

We’ve discussed this in the past.

Basically:
Before this option, all Object literals and Object access were being renamed by 
the Google Closure compiler. This caused untyped object references to be very 
fragile and tend to break when the code is minimized.

This option changes all unknown references to quoted references. This means 
object literals will have property names quoted (i.e. {“name”:”Harbs”} instead 
of {name:”Harbs”} and foo[“name”] instead of foo.name. This is the recommended 
practice by Google when renaming properties might have unwanted consequences. 
https://developers.google.com/closure/compiler/docs/api-tutorial3 
<https://developers.google.com/closure/compiler/docs/api-tutorial3>

The downside of this change is that Objects might be minimized less than 
without this option. But it’s much safer. Another downside is that it 
encourages users to use Object.

I spent many hours quoting object literals due to minimizing bugs. I expect 
this to be a pain point for lots of others too.

Harbs

> On Jun 27, 2018, at 10:57 PM, Carlos Rovira  wrote:
> 
> Hi
> 
> sorry, but I'd like to know more about this. I'm curious, what does this
> change?
> thanks! :)
> 
> 2018-06-27 15:55 GMT+02:00 Harbs :
> 
>> Thanks for this Josh!
>> 
>> I just tested this on a very complex library project with crazy complex
>> untyped data structures. It works great!
>> 
>> I wish we had this option when I was working on my app. I spent many hours
>> chasing down minification issues that could have been fixed by this option.
>> 
>> I also think it should default to true.
>> 
>> Thanks,
>> Harbs
>> 
>>> On Jun 26, 2018, at 9:56 PM, joshtynj...@apache.org wrote:
>>> 
>>> This is an automated email from the ASF dual-hosted git repository.
>>> 
>>> joshtynjala pushed a commit to branch develop
>>> in repository https://gitbox.apache.org/repos/asf/royale-compiler.git
>>> 
>>> 
>>> The following commit(s) were added to refs/heads/develop by this push:
>>>new 48d86c8  compiler-jx: added js-dynamic-access-unknown-members
>> compiler option to have emitter use dynamic bracket access when the right
>> side of a member access expression cannot be resolved to a definition.
>>> 48d86c8 is described below
>>> 
>>> commit 48d86c8c4b235ce60b282ad16d62d4ff87c3746b
>>> Author: Josh Tynjala 
>>> AuthorDate: Tue Jun 26 11:55:56 2018 -0700
>>> 
>>>   compiler-jx: added js-dynamic-access-unknown-members compiler option
>> to have emitter use dynamic bracket access when the right side of a member
>> access expression cannot be resolved to a definition.
>>> 
>>>   In other words, myObj.dynamicMember will become
>> myObj['dynamicMember']. Known members will use the regular dot syntax.
>> Useful for stopping the Closure compiler from renaming members that are
>> dynamic, such as members of an object literal. Defaults to false to avoid
>> breaking anything. However, I think it makes sense to have it default to
>> true instead to give developers a better user experience.
>>> ---
>>> .../royale/compiler/clients/JSConfiguration.java   | 26 
>>> .../codegen/js/jx/MemberAccessEmitter.java | 47 +++---
>>> .../js/royale/TestDynamicAccessUnknownMembers.java | 71
>> ++
>>> 3 files changed, 137 insertions(+), 7 deletions(-)
>>> 
>>> diff --git 
>>> a/compiler-jx/src/main/java/org/apache/royale/compiler/clients/JSConfiguration.java
>> b/compiler-jx/src/main/java/org/apache/royale/compiler/
>> clients/JSConfiguration.java
>>> index 0e6caf5..5433608 100644
>>> --- a/compiler-jx/src/main/java/org/apache/royale/compiler/
>> clients/JSConfiguration.java
>>> +++ b/compiler-jx/src/main/java/org/apache/royale/compiler/
>> clients/JSConfiguration.java
>>> @@ -137,6 +137,32 @@ public class JSConfiguration extends Configuration
>>>}
>>> 
>>>//
>>> +// 'js-dynamic-access-unknown-members'
>>> +//
>>> +
>>> +private boolean jsDynamicAccessUnknownMembers = false;
>>> +
>>> +public boolean getJsDynamicAccessUnknownMembers()
>>> +{
>>> +return jsDynamicAccessUnknownMembers;
>>> +}
>>> +
>>> +/**
>>> + * If the definition of a member cannot be resolved, emit dynamic
>> access
>>> + * instead of normal member access. Ensures that dynamic members
>> aren't
>>> + * renamed.
>>> + *
>>> + * myObject.memberAccess beco

Re: [royale-asjs] branch develop updated: Shifting 24 bits converted to negative int value

[Harbs]

I already switched to using the unsigned shift operator. I’m more trying to 
understand if there are issues I’m not getting.

I wonder if all the uint read methods should be using the unsigned shift 
operator to ensure the number type is an unsigned integer before returning the 
value, but I’m not sure it really has an effect on the bits. Adding an extra 
operation which doesn’t do anything is silly.

If you have any ideas for tests which could be effected by bits that are set 
wrong somehow, I’d love to add those…

Regarding performance, it does seem like shift operators are for the most part 
more efficient, but it depends on the browser. Safari had an improvement of 
between 2 and three times for 16 bit conversions. Chrome was actually a bit 
slower with short operators until the enable-profiling flag was enabled. Then 
shift operators where about 50% faster. Of course, <<24 >>0 is two operations 
instead of one, so I’m guessing that performance gains over multiplication will 
be less (but I could be wrong).

Thanks,
Harbs

> On Jun 25, 2018, at 8:08 PM, Alex Harui  wrote:
> 
> My main concern is having Royale "do the right thing".  I believe that some 
> of our migrating users have code that uses bit shifting and if it doesn't 
> work correctly on JS it would seem a bit ugly to recommend that they also use 
> multiplication.  If ">>> 0" works, that is something the compiler could 
> automatically generate so users don't have to touch migrating code that bit 
> shifts unsigned integers.
> 
> If it is really important to you to use multiplication in BinaryData, fine, 
> but I think folks will eventually notice and wonder why.
> 
> I don't know how the browsers actually work these days or will work in the 
> future, but I'm more likely to bet that they will optimize bit shifting if we 
> can help them infer types. I'm not sure they can as easily infer types from 
> multiplication as from actual bit shifting.
> 
> Finally, way back in the day, bit shifting was much faster than floating 
> point multiplication, but you never know how much overhead there is in the 
> browser runtime.
> 
> My 2 cents,
> -Alex
> 
> On 6/25/18, 12:57 AM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
> 
>I didn’t find that >>> 0 trick before. Interesting.
> 
>I guess I could switch the calculation to (val << 24) >>> 0 which seems to 
> give the correct results, but I’m really not sure what your concern is with 
> the multiplication. All we’re doing is getting the numeric value of the last 
> byte. I don’t see how we could get a different result after adding the four 
> byte values together.
> 
>Thanks,
>Harbs
> 
>> On Jun 25, 2018, at 10:46 AM, Alex Harui > <mailto:aha...@adobe.com.INVALID>> wrote:
>> 
>> Here's an article that might help.  
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D=0
>>  
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D=0>
>> 
>> It's great that you have it working with multiply, but my main concern is if 
>> existing code being migrated uses shift operators and whether JS will 
>> produce different results than SWF.  Maybe we need to do the >>> 0 trick 
>> mentioned in this article.
>> 
>> HTH,
>> -Alex
>> 
>> On 6/24/18, 11:49 PM, "Harbs"  wrote:
>> 
>>   readUnsignedInt() was returning the wrong value when the last bit was 1 
>> (i.e. a negative int instead of a large uint). Using multiplication on the 
>> last byte instead of bit shifting fixed the problem. It works because 
>> multiplication will always give the same correct positive value. I think 
>> that’s the simplest way to resolve this.
>> 
>>   Thanks,
>>   Harbs
>> 
>>> On Jun 25, 2018, at 9:32 AM, Alex Harui  wrote:
>>> 
>>> Yeah, that article is addressing what I meant by "out of range" or an 
>>> "signed int read".  What method is this that you are changing?  If this is 
>>> all unsigned, then the issue may not be the shifting, but rather the values 
>>> being tested or the final conversion of 

Re: [royale-asjs] branch develop updated: Shifting 24 bits converted to negative int value

[Harbs]

I think it’s a type conversion. Maybe there’s no overhead if the value happens 
to already be an unsigned int. Don’t know…

> On Jun 25, 2018, at 8:23 PM, Alex Harui  wrote:
> 
> I'm still pondering if there are issues.  More related to lots of integer 
> math like is used in MD5.
> 
> FWIW, I'm not clear that ">>> 0" actually results in a call to the CPU's 
> shift operator or even the Browser's shift code.  It might just be used for 
> type inferencing.
> 
> My 2 cents,
> -Alex
> 
> On 6/25/18, 10:18 AM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
> 
>I already switched to using the unsigned shift operator. I’m more trying 
> to understand if there are issues I’m not getting.
> 
>I wonder if all the uint read methods should be using the unsigned shift 
> operator to ensure the number type is an unsigned integer before returning 
> the value, but I’m not sure it really has an effect on the bits. Adding an 
> extra operation which doesn’t do anything is silly.
> 
>If you have any ideas for tests which could be effected by bits that are 
> set wrong somehow, I’d love to add those…
> 
>Regarding performance, it does seem like shift operators are for the most 
> part more efficient, but it depends on the browser. Safari had an improvement 
> of between 2 and three times for 16 bit conversions. Chrome was actually a 
> bit slower with short operators until the enable-profiling flag was enabled. 
> Then shift operators where about 50% faster. Of course, <<24 >>0 is two 
> operations instead of one, so I’m guessing that performance gains over 
> multiplication will be less (but I could be wrong).
> 
>Thanks,
>Harbs
> 
>> On Jun 25, 2018, at 8:08 PM, Alex Harui  wrote:
>> 
>> My main concern is having Royale "do the right thing".  I believe that some 
>> of our migrating users have code that uses bit shifting and if it doesn't 
>> work correctly on JS it would seem a bit ugly to recommend that they also 
>> use multiplication.  If ">>> 0" works, that is something the compiler could 
>> automatically generate so users don't have to touch migrating code that bit 
>> shifts unsigned integers.
>> 
>> If it is really important to you to use multiplication in BinaryData, fine, 
>> but I think folks will eventually notice and wonder why.
>> 
>> I don't know how the browsers actually work these days or will work in the 
>> future, but I'm more likely to bet that they will optimize bit shifting if 
>> we can help them infer types. I'm not sure they can as easily infer types 
>> from multiplication as from actual bit shifting.
>> 
>> Finally, way back in the day, bit shifting was much faster than floating 
>> point multiplication, but you never know how much overhead there is in the 
>> browser runtime.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 6/25/18, 12:57 AM, "Harbs" > <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>> <mailto:harbs.li...@gmail.com>>> wrote:
>> 
>>   I didn’t find that >>> 0 trick before. Interesting.
>> 
>>   I guess I could switch the calculation to (val << 24) >>> 0 which seems to 
>> give the correct results, but I’m really not sure what your concern is with 
>> the multiplication. All we’re doing is getting the numeric value of the last 
>> byte. I don’t see how we could get a different result after adding the four 
>> byte values together.
>> 
>>   Thanks,
>>   Harbs
>> 
>>> On Jun 25, 2018, at 10:46 AM, Alex Harui >> <mailto:aha...@adobe.com.INVALID> <mailto:aha...@adobe.com.INVALID 
>>> <mailto:aha...@adobe.com.INVALID>>> wrote:
>>> 
>>> Here's an article that might help.  
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D=0
>>>  
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise-operations-on-32-bit-unsigned-ints%3Frq%3D1=02%7C01%7Caharui%40adobe.com%7Cc1b81673ea22436323fe08d5da7157df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655102772966878=NrDyYfPqE2PKnzCHOZlyOPppaLYQukFzBTq9UeRvVhg%3D=0>
>>>  
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F6798111%2Fbitwise

Re: [royale-asjs] branch develop updated: Shifting 24 bits converted to negative int value

[Harbs]

I didn’t find that >>> 0 trick before. Interesting.

I guess I could switch the calculation to (val << 24) >>> 0 which seems to give 
the correct results, but I’m really not sure what your concern is with the 
multiplication. All we’re doing is getting the numeric value of the last byte. 
I don’t see how we could get a different result after adding the four byte 
values together.

Thanks,
Harbs

> On Jun 25, 2018, at 10:46 AM, Alex Harui  wrote:
> 
> Here's an article that might help.  
> https://stackoverflow.com/questions/6798111/bitwise-operations-on-32-bit-unsigned-ints?rq=1
> 
> It's great that you have it working with multiply, but my main concern is if 
> existing code being migrated uses shift operators and whether JS will produce 
> different results than SWF.  Maybe we need to do the >>> 0 trick mentioned in 
> this article.
> 
> HTH,
> -Alex
> 
> On 6/24/18, 11:49 PM, "Harbs"  wrote:
> 
>readUnsignedInt() was returning the wrong value when the last bit was 1 
> (i.e. a negative int instead of a large uint). Using multiplication on the 
> last byte instead of bit shifting fixed the problem. It works because 
> multiplication will always give the same correct positive value. I think 
> that’s the simplest way to resolve this.
> 
>Thanks,
>Harbs
> 
>> On Jun 25, 2018, at 9:32 AM, Alex Harui  wrote:
>> 
>> Yeah, that article is addressing what I meant by "out of range" or an 
>> "signed int read".  What method is this that you are changing?  If this is 
>> all unsigned, then the issue may not be the shifting, but rather the values 
>> being tested or the final conversion of the bits to the returned value.
>> 
>> IOW, an unsigned int can just plain start as 0xFF00.  And if the browser 
>> is going to convert that to a signed int (actually, a float, I think), then 
>> we have to make sure we find the right way to convert that value as a uint.  
>> It might require stuffing a DataView or even using parseFloat.  Not sure.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 6/24/18, 11:11 PM, "Harbs"  wrote:
>> 
>>   It seemed strange to me too. I found this:
>>   
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D=0
>>  
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D=0>
>> 
>>> On Jun 25, 2018, at 9:07 AM, Alex Harui  wrote:
>>> 
>>> FWIW, this does not make sense.  Shifting to the left shouldn't cause 
>>> sign-bit extending.   I suppose it could shift a 1 into the sign bit, but 
>>> that implies a signed int read, or the data was out of range.
>>> 
>>> Of course, I could be wrong...
>>> -Alex
>>> 
>>> On 6/24/18, 12:25 PM, "ha...@apache.org <mailto:ha...@apache.org>" 
>>> mailto: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=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D=0
>>>  
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D=0>
>>> 
>>> 
>>>  The following commit(s) were added to refs/heads/develop by this push:
>>>   new ce95546  Shifting 24 bits converted to negative int value
>>>  ce95546 is described below
>>> 
>>>  commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
>>>  Author: Harbs mailto:ha...@in-tools.com>>
>>>  AuthorDate: Sun Jun 24 22:25:37 2018 +0300
>>> 
>>>  Shifting 24 bits converted to negative int val

Re: [royale-asjs] branch develop updated: Shifting 24 bits converted to negative int value

[Harbs]

It seemed strange to me too. I found this:
https://stackoverflow.com/questions/18034974/why-in-javascript-expression-255-24-is-a-negative-number
 
<https://stackoverflow.com/questions/18034974/why-in-javascript-expression-255-24-is-a-negative-number>

> On Jun 25, 2018, at 9:07 AM, Alex Harui  wrote:
> 
> FWIW, this does not make sense.  Shifting to the left shouldn't cause 
> sign-bit extending.   I suppose it could shift a 1 into the sign bit, but 
> that implies a signed int read, or the data was out of range.
> 
> Of course, I could be wrong...
> -Alex
> 
> On 6/24/18, 12:25 PM, "ha...@apache.org <mailto:ha...@apache.org>" 
> mailto: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=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D=0
>  
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D=0>
> 
> 
>The following commit(s) were added to refs/heads/develop by this push:
> new ce95546  Shifting 24 bits converted to negative int value
>ce95546 is described below
> 
>commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
>Author: Harbs mailto:ha...@in-tools.com>>
>AuthorDate: Sun Jun 24 22:25:37 2018 +0300
> 
>Shifting 24 bits converted to negative int value
>---
> .../Core/src/main/royale/org/apache/royale/utils/BinaryData.as| 4 
> ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
>diff --git 
> a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>  
> b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>index c430369..fad4ea3 100644
>--- 
> a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>+++ 
> b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>@@ -665,9 +665,9 @@ public class BinaryData implements IBinaryDataInput, 
> IBinaryDataOutput
> {
> var arr:Uint8Array = getTypedArray();
> if(endian == Endian.BIG_ENDIAN){
>-return (arr[_position++] << 24) + (arr[_position++] << 
> 16) + ( arr[_position++] << 8) + arr[_position++];
>+return (arr[_position++] * 16777216) + (arr[_position++] 
> << 16) + ( arr[_position++] << 8) + arr[_position++];
> } else {
>-return arr[_position++] + ( arr[_position++] << 8) + 
> (arr[_position++] << 16) + (arr[_position++] << 24)
>+return arr[_position++] + ( arr[_position++] << 8) + 
> (arr[_position++] << 16) + (arr[_position++] * 16777216)
> }
> }
> }

Re: [royale-asjs] branch develop updated: Shifting 24 bits converted to negative int value

[Harbs]

readUnsignedInt() was returning the wrong value when the last bit was 1 (i.e. a 
negative int instead of a large uint). Using multiplication on the last byte 
instead of bit shifting fixed the problem. It works because multiplication will 
always give the same correct positive value. I think that’s the simplest way to 
resolve this.

Thanks,
Harbs

> On Jun 25, 2018, at 9:32 AM, Alex Harui  wrote:
> 
> Yeah, that article is addressing what I meant by "out of range" or an "signed 
> int read".  What method is this that you are changing?  If this is all 
> unsigned, then the issue may not be the shifting, but rather the values being 
> tested or the final conversion of the bits to the returned value.
> 
> IOW, an unsigned int can just plain start as 0xFF00.  And if the browser 
> is going to convert that to a signed int (actually, a float, I think), then 
> we have to make sure we find the right way to convert that value as a uint.  
> It might require stuffing a DataView or even using parseFloat.  Not sure.
> 
> My 2 cents,
> -Alex
> 
> On 6/24/18, 11:11 PM, "Harbs"  wrote:
> 
>It seemed strange to me too. I found this:
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D=0
>  
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F18034974%2Fwhy-in-javascript-expression-255-24-is-a-negative-number=02%7C01%7Caharui%40adobe.com%7C5d2e791d3ff0427b519508d5da6282f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636655038993975700=jXJWpzL16YFtQt5AMqVWk6rj%2BYUYCSDI8OTngaZrcYw%3D=0>
> 
>> On Jun 25, 2018, at 9:07 AM, Alex Harui  wrote:
>> 
>> FWIW, this does not make sense.  Shifting to the left shouldn't cause 
>> sign-bit extending.   I suppose it could shift a 1 into the sign bit, but 
>> that implies a signed int read, or the data was out of range.
>> 
>> Of course, I could be wrong...
>> -Alex
>> 
>> On 6/24/18, 12:25 PM, "ha...@apache.org <mailto:ha...@apache.org>" 
>> mailto: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=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D=0
>>  
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git=02%7C01%7Caharui%40adobe.com%7Ce941b0896db44fa2127c08d5da08491f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636654651499005568=h3WWynmXGQXTRqmzte46oprTRzZf0abvL7cfCEmSgZA%3D=0>
>> 
>> 
>>   The following commit(s) were added to refs/heads/develop by this push:
>>new ce95546  Shifting 24 bits converted to negative int value
>>   ce95546 is described below
>> 
>>   commit ce95546395ade51c63ba9b8a9cff7c63477b8c4a
>>   Author: Harbs mailto:ha...@in-tools.com>>
>>   AuthorDate: Sun Jun 24 22:25:37 2018 +0300
>> 
>>   Shifting 24 bits converted to negative int value
>>   ---
>>.../Core/src/main/royale/org/apache/royale/utils/BinaryData.as| 4 
>> ++--
>>1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>>   diff --git 
>> a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>  
>> b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>   index c430369..fad4ea3 100644
>>   --- 
>> a/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>   +++ 
>> b/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as
>>   @@ -665,9 +665,9 @@ public class BinaryData implements IBinaryDataInput, 
>> IBinaryDataOutput
>>{
>>var arr:Uint8Array = getTypedArray();
>>if(endian == Endian.BIG_ENDIAN){
>>   -return (arr[_position++] << 24) + (arr[_position++] << 
>> 16) + ( arr[_position++] << 8) + arr[_position++];
>>   +return (arr[_position++] * 16777216) + (arr[_position++] 
>> << 16) + ( arr[_position++] << 8) + arr[_position++];
>>} else {
>>   -return arr[_position++] + ( arr[_position++] << 8) + 
>> (arr[_position++] << 16) + (arr[_position++] << 24)
>>   +return arr[_position++] + ( arr[_position++] << 8) + 
>> (arr[_position++] << 16) + (arr[_position++] * 16777216)
>>}
>>}
>>}
> 
> 
> 

Re: BinaryData and odd bytes

[Harbs]

Done.

Thanks.

> On Jun 25, 2018, at 1:41 AM, Greg Dove  wrote:
> 
> btw, a quick scan of the code let me find something that is an obvious typo
> (mine I expect)
> https://github.com/apache/royale-asjs/blob/develop/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as#L170
>  
> 
> 
> you might want to fix that if you're still 'in the code'.

Re: BinaryData and odd bytes

[Harbs]

I switched float and double functions to always use DataView. If we could 
eliminate DataView instantiation we could probably improve performance with 
that. I tried a single instance, but I got bounds errors.

All read and write functions should work correctly now (the DM5 error 
not-withstanding). There should be test cases to cover everything. (Unless I 
missed some edge cases.) It’s possible that the float methods could be improved 
with math, but I’m done for now. If anyone wants to improve things further, 
feel free…

Harbs

> On Jun 24, 2018, at 4:46 AM, Greg Dove  wrote:
> 
> I think DataView might be a lot faster than it was a couple of years ago.
> At least it seems to be (on Chrome/windows on the machine I am currently
> using) (and it should only need a single instance like the Uint8Array, for
> the current buffer, I think, instead of 'new DataView' )
> 
> On Sun, Jun 24, 2018 at 1:19 PM Greg Dove  wrote:
> 
>> 
>> I tried to add in the extra test, but messed up I think because it did not
>> copy over the original tests in the revision (even though I was 'adding' a
>> new test). I have not used jsperf before, so probably did something stupid.
>> On the face of it, it certainly does look like the byte level stuff is
>> faster.
>> 
>> 
>> On Sun, Jun 24, 2018 at 10:32 AM Greg Dove  wrote:
>> 
>>> 
>>> Harbs, for the typed array test, try using the ArrayBuffer in the
>>> constructor instead of the Uint8Array, I think you might see a difference
>>> here.
>>> 
>>> 
>>> On Sun, Jun 24, 2018 at 10:09 AM Harbs  wrote:
>>> 
>>>> I created a jsperf which compares different read methods, and the one I
>>>> changed it to seems fastest by far:
>>>> https://jsperf.com/typedarray-read-performance/1 <
>>>> https://jsperf.com/typedarray-read-performance/1>
>>>> 
>>>> The only optimization which might give slight gains is to use shift
>>>> operators instead of multiplication. Enabling the --enable-benchmarking
>>>> flag in Chrome seemed to indicate that there’s up to a 10% performance
>>>> increase of the shift operators over multiplication. Logically, shift
>>>> operators should be cheaper. In Safari, the shift operator gave a
>>>> performance boost of 3 times the multiplication.
>>>> 
>>>> I only tested 16 bit uints. It might be worthwhile adding ints and 32
>>>> bit.
>>>> 
>>>> Thanks,
>>>> Harbs
>>>> 
>>>>> On Jun 22, 2018, at 8:58 AM, Alex Harui 
>>>> wrote:
>>>>> 
>>>>> It is definitely true that I don't know how expensive instantiation of
>>>> small instances is in the browser.  Might even be different in different
>>>> browsers.  There should also be function call overhead in calling the
>>>> constructor as well.  On the other hand, maybe using the typed arrays helps
>>>> with the browser's type inferencing and there is some advantage there that
>>>> also assumes the equivalent of word/long alignments.
>>>>> 
>>>>> If TypeArrays really aren't that expensive to instantiate, it may be
>>>> that the way to handle floats/doubles is to copy bytes into a new
>>>> BinaryData and convert that to the appropriate TypedArray.  That should
>>>> ensure that there won't be alignment issues.
>>>>> 
>>>>> IMO, this discussion shows the importance of providing choices.  You
>>>> can have a much simpler variant that assumes certain endian and thus save a
>>>> whole bunch of byte swapping.  You might in fact have a faster
>>>> implementation if you can guarantee/assume alignment.
>>>>> 
>>>>> HTH,
>>>>> -Alex
>>>>> 
>>>>> On 6/21/18, 3:01 PM, "Greg Dove"  wrote:
>>>>> 
>>>>>   ' If you have the time to resolve these remaining issues, that
>>>> would be
>>>>>   awesome.'
>>>>> 
>>>>>   Happy to commit to doing this by mid-July if that works. I do have
>>>> downtime
>>>>>   in July that I can use for Royale, but I also need to set up for
>>>> Royale
>>>>>   development again because I have changed machines.
>>>>> 
>>>>> 
>>>>>   On Fri, Jun 22, 2018 at 9:13 AM Harbs 
>>>> wrote:
>>>>> 
>>>>>> Cool.
>>>>>> 
>>>>>> FYI there are still some issues to resolve:
>

Re: MD5 [was: Re: BinaryData and odd bytes]

[Harbs]

> On Jun 23, 2018, at 7:45 AM, Alex Harui  wrote:
> 
> Thanks for digging into it.
> 
> If I understand correctly, the AS code had a bug and should not have had the 
> s[] code in it.

Correct.

> The JS problem is interesting.  Some internet articles claim that JS does not 
> have integers at all.  So not sure what to make of the article you linked to. 
>  The code in the JS MD5 implementation is solving some other problem.  It 
> does not seem to try to sign extend the values, maybe because the values in 
> an MD5 calculation are all unsigned.
> 
> We may need to understand which modern browsers that we support (IE11, 
> Chrome, FireFox, Android, IOS Safari) might have these issues.  We might have 
> to generate a "safeAdd()" instead of just "+" when we know the types are all 
> integers.  And implement smarter coercions as described in the article you 
> linked to.  Which browser(s) did you test with?

Chrome, Firefox and Safari. All on Mac.

I’ve used BinaryData pretty extensively and I haven’t had issues. I don’t 
understand why MD5 was failing, but it seems like whatever the issue is is 
pretty fringe.

> -Alex
> 
> On 6/22/18, 3:21 AM, "Harbs"  <mailto:harbs.li...@gmail.com>> wrote:
> 
>In Flash, the error is ReferenceError: Error: 1069.
> 
>I took another look and it looks like the problem is the bracketed access 
> to the BinaryData.
> 
>The code s[ i / 8 ] needs to be changed to either s.readByteAt(i/8) or 
> s.array[i/8].
> 
>Making either of these changes fixed the Flash error, but did not fix the 
> JS error:
>expected 80338e79d2ca9b9c090ebaaa2ef293c7 but was: 
> 996f93cb21f81b54962909fd0ea18074
> 
>I’m guessing that the problem is related to the comment here in the JS MD5 
> implementation:
> 
>   * Add integers, wrapping at 2^32. This uses 16-bit operations 
> internally
>   * to work around bugs in some JS interpreters.
> 
>I think part of the problem is that JS only has 32 bit ints. I did not 
> follow this article completely, but this might shed some light:
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.vjeux.com%2F2013%2Fjavascript%2Fconversion-from-uint8-to-int8-x-24.html=02%7C01%7Caharui%40adobe.com%7C21a1876d2a9b4e569ba008d5d829de4a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636652596694550635=YyxMW%2BZfeuhZ1x8w%2BMxetw8FoZGhEqU0jIkZxyDc%2Bpg%3D=0
>  
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.vjeux.com%2F2013%2Fjavascript%2Fconversion-from-uint8-to-int8-x-24.html=02%7C01%7Caharui%40adobe.com%7C21a1876d2a9b4e569ba008d5d829de4a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636652596694550635=YyxMW%2BZfeuhZ1x8w%2BMxetw8FoZGhEqU0jIkZxyDc%2Bpg%3D=0>
>  
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.vjeux.com%2F2013%2Fjavascript%2Fconversion-from-uint8-to-int8-x-24.html=02%7C01%7Caharui%40adobe.com%7C21a1876d2a9b4e569ba008d5d829de4a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636652596694550635=YyxMW%2BZfeuhZ1x8w%2BMxetw8FoZGhEqU0jIkZxyDc%2Bpg%3D=0
>  
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.vjeux.com%2F2013%2Fjavascript%2Fconversion-from-uint8-to-int8-x-24.html=02%7C01%7Caharui%40adobe.com%7C21a1876d2a9b4e569ba008d5d829de4a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636652596694550635=YyxMW%2BZfeuhZ1x8w%2BMxetw8FoZGhEqU0jIkZxyDc%2Bpg%3D=0>>
> 
>Harbs
> 
>> On Jun 22, 2018, at 9:22 AM, Alex Harui  wrote:
>> 
>> On 6/21/18, 11:20 AM, "Harbs"  wrote:
>> 
>>   The MD5 test actually failed in Flash too. Although the error was 
>> different.
>> 
>>   I’m not sure why it was failing. I’m pretty sure the code was the same as 
>> the Flex version with ByteArray swapped for BinaryData.
>> 
>> Even more bothersome.  We really should dig deeper on this.  We can't have 
>> other people's business logic have similar issues.  Any volunteers?
>> 
>> -Alex

Re: BinaryData and odd bytes

[Harbs]

I created a jsperf which compares different read methods, and the one I changed 
it to seems fastest by far:
https://jsperf.com/typedarray-read-performance/1 
<https://jsperf.com/typedarray-read-performance/1>

The only optimization which might give slight gains is to use shift operators 
instead of multiplication. Enabling the --enable-benchmarking flag in Chrome 
seemed to indicate that there’s up to a 10% performance increase of the shift 
operators over multiplication. Logically, shift operators should be cheaper. In 
Safari, the shift operator gave a performance boost of 3 times the 
multiplication.

I only tested 16 bit uints. It might be worthwhile adding ints and 32 bit.

Thanks,
Harbs

> On Jun 22, 2018, at 8:58 AM, Alex Harui  wrote:
> 
> It is definitely true that I don't know how expensive instantiation of small 
> instances is in the browser.  Might even be different in different browsers.  
> There should also be function call overhead in calling the constructor as 
> well.  On the other hand, maybe using the typed arrays helps with the 
> browser's type inferencing and there is some advantage there that also 
> assumes the equivalent of word/long alignments.
> 
> If TypeArrays really aren't that expensive to instantiate, it may be that the 
> way to handle floats/doubles is to copy bytes into a new BinaryData and 
> convert that to the appropriate TypedArray.  That should ensure that there 
> won't be alignment issues.
> 
> IMO, this discussion shows the importance of providing choices.  You can have 
> a much simpler variant that assumes certain endian and thus save a whole 
> bunch of byte swapping.  You might in fact have a faster implementation if 
> you can guarantee/assume alignment.
> 
> HTH,
> -Alex
> 
> On 6/21/18, 3:01 PM, "Greg Dove"  wrote:
> 
>' If you have the time to resolve these remaining issues, that would be
>awesome.'
> 
>Happy to commit to doing this by mid-July if that works. I do have downtime
>in July that I can use for Royale, but I also need to set up for Royale
>development again because I have changed machines.
> 
> 
>On Fri, Jun 22, 2018 at 9:13 AM Harbs  wrote:
> 
>> Cool.
>> 
>> FYI there are still some issues to resolve:
>> 
>> 1. readFloat and readDouble should have the same issues as the various int
>> read methods. I did not fix that yet because calculating floats and doubles
>> is harder than ints. I’m not sure of the best way to handle that. One way
>> is to create a new temporary ArrayBuffer with only the necessary bytes and
>> read that. Another would be to use DataViews for floats and doubles. A
>> third would be to actually do the math for floating point numbers…
>> 
>> 2. I did not fix any of the write methods. They should have the same issue
>> as the read methods.
>> 
>> If you have the time to resolve these remaining issues, that would be
>> awesome. :-)
>> 
>> Harbs
>> 
>>> On Jun 21, 2018, at 11:55 PM, Greg Dove  wrote:
>>> 
>>> Thanks Harbs - that short explanation makes it very clear.  Thanks for
>>> fixing my broken implementation :). I am guilty of not covering 'real
>>> world' combinations in the tests, which was what I used to guide
>>> development when I was working on this originally.
>>> 
>>> I am pretty sure I did have also have an interim implementation doing the
>>> bytewise reads/writes and dealing with endian-ness branching along the
>> way,
>>> then I switched to using the typed arrays when I saw a performance boost.
>>> I wish I had written something like your new test before I did that :).
>>> I did a quick search for this and read up on the issue about the offset.
>> I
>>> guess that also partly explains why the typed array performance is
>> 'faster'
>>> (possibly due to the alignment I mean). And I did not do memory
>> profiling,
>>> so maybe Alex is right - there could also have been a massive GC dump
>> after
>>> my large loop tests, something that I was not seeing because I was only
>>> focused on speed at the time.
>>> 
>>> I had to add the 'sysEndian' flag approach internally when I switched to
>>> using the typed arrays (and only reordering the result if it was
>> different
>>> to the 'native' endian used in the typed arrays). If everything is based
>> on
>>> bytewise approach now, that flag should no longer be needed I think (you
>>> may already have done that, I did not look at your changes in detail yet
>> -
>>> will check them out this weekend).
>>> 
>>> Obviously having this working cor