Re: [royale-asjs] branch develop updated: new blog example for using view states

[Carlos Rovira]

Hi,

I'm preparing a new example about basic view states, and I find a bug.

The view loose the layout bead when switch 2 times if I remove the first
one (that is not needed).





If you can check this project, you'll see the effect if comment lines 40 to
42 (the verticallayout)
I think this happens with Jewel since it uses css class selectors instead
of hardcoded values. But is a bug.

If someone can point me where to look this problem, I'll look tomorrow.
This bug of loosing bead layout generate different strange behaviors
depending on the code, this one only shows this particular one.

Thanks.



2018-06-01 21:04 GMT+02:00 :

> 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 3f4dde9  new blog example for using view states
> 3f4dde9 is described below
>
> commit 3f4dde9b46278977fc8a71952b29d8da00f24fa8
> Author: Carlos Rovira 
> AuthorDate: Fri Jun 1 21:04:32 2018 +0200
>
> new blog example for using view states
> ---
>  .../resources/META-INF/flex/services-config.xml|   2 +-
>  ...ing_View_States_in_a_Royale_Application.as3proj |  95
> +
>  .../README.txt |  30 ++
>  .../asconfig.json  |  31 ++
>  .../build.xml  |  63 
>  .../pom.xml| 112
> +
>  .../resources/jewel-example-index-template.html|  31 ++
>  .../src/main/resources/styles.css  |  28 ++
>  ..._Using_View_States_in_a_Royale_Application.mxml |  68 +
>  .../Jewel/src/main/resources/jewel-manifest.xml|   2 +
>  .../beads/controls/textinput/PasswordInput.as  | 101
> +++
>  11 files changed, 562 insertions(+), 1 deletion(-)
>
> diff --git a/examples/amf/SampleAmfWebApp/src/main/
> resources/META-INF/flex/services-config.xml b/examples/amf/
> SampleAmfWebApp/src/main/resources/META-INF/flex/services-config.xml
> index a168757..59ab362 100644
> --- a/examples/amf/SampleAmfWebApp/src/main/resources/META-INF/flex/
> services-config.xml
> +++ b/examples/amf/SampleAmfWebApp/src/main/resources/META-INF/flex/
> services-config.xml
> @@ -45,7 +45,7 @@
>  5000 heartbeat-millis>
>  true
>  
> -false
> +true
>  
>
>  
> diff --git a/examples/blog/BE0008_Using_View_States_in_a_Royale_
> Application/BE0008_Using_View_States_in_a_Royale_Application.as3proj
> b/examples/blog/BE0008_Using_View_States_in_a_Royale_
> Application/BE0008_Using_View_States_in_a_Royale_Application.as3proj
> new file mode 100644
> index 000..dc44dcd
> --- /dev/null
> +++ b/examples/blog/BE0008_Using_View_States_in_a_Royale_
> Application/BE0008_Using_View_States_in_a_Royale_Application.as3proj
> @@ -0,0 +1,95 @@
> +
> +
> +
> +  
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +  
> +  !-- Other classes to be compiled into your SWF --
> +  
> +
> +  
> +  
> +  
> +  
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +  
> +  
> +  
> +  
> +  
> +  
> +
> +
> +  
> +  
> +  
> +
> +  
> +  
> +  null
> +  null
> +  
> +
> +
> +
> +
> +
> +  
> +  
> +
> +
> +
> +
> +
> +null
> +null
> +null
> +null
> +  
> +
> \ No newline at end of file
> diff --git 
> a/examples/blog/BE0008_Using_View_States_in_a_Royale_Application/README.txt
> b/examples/blog/BE0008_Using_View_States_in_a_Royale_
> Application/README.txt
> new file mode 100644
> index 000..9b9cff2
> --- /dev/null
> +++ b/examples/blog/BE0008_Using_View_States_in_a_Royale_
> Application/README.txt
> @@ -0,0 +1,30 @@
> +///
> /
> +//
> +//  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.
> +//

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

[Carlos Rovira]

Hi Harbs,
just fixed it, and must say that I don't find why removing the duplicate
class expose a wrong path in CSS for ContainerView bead :?

2018-06-01 17:51 GMT+02:00 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*] 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 

Re: Descendent selector issue

[Alex Harui]

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: Need some help with Small Messages

[Alex Harui]

On 6/1/18, 3:43 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

>
> Now to your main question.  Are you sure that code 168 is an AMF type
> code?  I could certainly be wrong, but it occurred to me that the 168
> could just be the first byte in serialized data of the message and that 
the
> AMF decoding should instantiate the object based on the class alias then
> see if it implements IExternalizable and call readExternal without
> bothering to examine that byte in the stream.
>

ok, so if I understand right I must pass the rest of data in AMFBinaryData
to "readExternal" method? If so, readExternal expects an IDataInputand
is not clear to me how as well give that part of the data Array (maybe I
should create a temporal data array that holds data from current position
to the end of the array?
Sorry but as you is not my area of expertise.

I'm just guessing, but if AMFBinaryData implements IDataInput, then I would 
pass the AMFBinaryData to readExternal.  The readExternal calls should grab the 
next set of bytes out of the AMFBinaryData and use it to deserialize and when 
it returns, the AMFBinaryData should be set so the next bytes will be used  to 
generate the next object, if any.  In theory the readExternal of an 
IExternalizable should not play with the current position of the input 
IDataInput other than pulling bytes from the IDataInput.  At least, that's 
worth a try, IMO.

HTH,
-Alex

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

[Alex Harui]

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

commit e5328655b9991fe44b92c61d1b18aa7a4cc104b5
Author: Harbs 
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 = rect.top + y + window.scrollY;
} else { // for older browsers, but 
offsetParent is soon to be deprecated from from chrome
do {
x += element.offsetLeft;

-- 
To stop receiving notification emails like this one, please contact
ha...@apache.org.

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*] 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 e74e4d095050477db43ac57f8928803b18961c38
>>> Author: Harbs 
>>> AuthorDate: Fri Jun 1 15:06:56 2018 +0300

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 e74e4d095050477db43ac57f8928803b18961c38
>> Author: Harbs 
>> AuthorDate: Fri Jun 1 15:06:56 2018 +0300
>> 
>>Removed duplicate Container
>> 
>>There was a Container class in both core and html with references to
>> both.
>> ---
>> .../Basic/src/main/resources/basic-manifest.xml|   2 +-
>> .../royale/org/apache/royale/core/Container.as | 164
>> -
>> .../org/apache/royale/html/beads/AlertView.as  |   2 +-
>> 

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

[Carlos Rovira]

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 e74e4d095050477db43ac57f8928803b18961c38
> Author: Harbs 
> AuthorDate: Fri Jun 1 15:06:56 2018 +0300
>
> Removed duplicate Container
>
> There was a Container class in both core and html with references to
> both.
> ---
>  .../Basic/src/main/resources/basic-manifest.xml|   2 +-
>  .../royale/org/apache/royale/core/Container.as | 164
> -
>  .../org/apache/royale/html/beads/AlertView.as  |   2 +-
>  .../royale/html/beads/ControlBarMeasurementBead.as |   2 +-
>  .../org/apache/royale/html/beads/DataGridView.as   |   2 +-
>  .../apache/royale/html/beads/DateChooserView.as|   2 +-
>  .../org/apache/royale/html/beads/IDataGridView.as  |   2 +-
>  .../org/apache/royale/html/beads/PanelView.as  |   2 +-
>  .../royale/html/beads/PanelWithControlBarView.as   |   2 +-
>  .../org/apache/royale/html/beads/TreeGridView.as   |   2 +-
>  mustella/tests/basicTests/shim/VBox.as |   2 +-
>  11 files changed, 10 insertions(+), 174 deletions(-)
>
> diff --git 

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

[Carlos Rovira]

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 shared library. To prevent linking to Basic (TLCs), we can
> move the Basic TLCs out of Basic *at any time*. I don’t see why we need to
> *do anything* right now (except get everything working for a release).
> Jewel apps might be slightly larger for a month or two until we get this
> sorted out, but what’s the rush?
>

Harbs, I completely disagree with that path. Is to come back to insert
entropy and bad practices again, or go to backwards. For me this point is
crucial. Again, we must see what points are very important  and for me this
is not important, is crucial. Think that if you don't like my path, you
always can have again Core - Basic, and I should have Core - Foundation -
Jewel. We will have duplicated code, and will have 2 valid options  living
together, but I don't see other way.


>
> Just consider Basic “Foundation” and ignore all the TLCs for the time
> being. If it’s the right thing to move the TLCs out, we can do that later.
>
>
I think the best path to make us all happy is to set up a new "foundation"
or (whatever the name you want) and be moving things there.
This way, I don't have to link Basic and live 1-2-3 months with the
problem,and we all can move things little by little without problem. This
paths makes the same that you want, but without introducing the problem
again. Can you consider that path?


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

But Harbs, I think that we actually 

Jenkins build is back to normal : royale-asjs_jsonly #888

[apacheroyaleci]

See 

Build failed in Jenkins: royale-asjs_jsonly #887

[apacheroyaleci]

See 


Changes:

[harbs] Item Renderer firing itemChanged when mouse is dragged over item

[harbs] Created getLabelFromData utility function

[harbs] Added VerticalAlignChildren bead

[harbs] global point should ignore window scrolling

[harbs] Enable DropDown separators

--
[...truncated 1.10 MB...]
 [java] Writing file: js\out\org\apache\royale\binding\PropertyWatcher.js
 [java] Compiling file: org.apache.royale.binding.SimpleBinding
 [java] Writing file: js\out\org\apache\royale\binding\SimpleBinding.js
 [java] Compiling file: org.apache.royale.binding.GenericBinding
 [java] Writing file: js\out\org\apache\royale\binding\GenericBinding.js
 [java] Compiling file: org.apache.royale.binding.ItemRendererSimpleBinding
 [java] Writing file: 
js\out\org\apache\royale\binding\ItemRendererSimpleBinding.js
 [java] Compiling file: org.apache.royale.binding.ContainerDataBinding
 [java] Writing file: 
js\out\org\apache\royale\binding\ContainerDataBinding.js
 [java] Compiling file: org.apache.royale.binding.MXMLBeadViewDataBinding
 [java] Writing file: 
js\out\org\apache\royale\binding\MXMLBeadViewDataBinding.js
 [java] Compiling file: BindingClasses
 [java] Writing file: js\out\BindingClasses.js
 [java] Compiling file: org.apache.royale.binding.ChainBinding
 [java] Writing file: js\out\org\apache\royale\binding\ChainBinding.js
 [java] 3.8418996 seconds
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
 [copy] Copying 1 file to 


main:

copy-swc:

check-for-tests:

test:

main:

Collections:

clean:

check-for-tests:

clean-tests:

check-compiler-home:

check-transpiler-home:

check-compiler:

compile:

compile-js:
   [delete] Deleting: 


clean:

check-compiler-home:

check-transpiler-home:

check-compiler:

compile:
 [echo] Cross-compiling CollectionsJS.swc
 [echo] ROYALE_COMPILER_HOME: 

[mkdir] Created dir: 

 [java] args:
 [java] 
+royalelib=
 [java] -compiler.strict-xml=true
 [java] -compiler.targets=SWF,JSRoyale
 [java] 
-output=
 [java] 
-load-config=
 [java] 
-load-config+=
 [java] target:SWF
 [java] target:JSRoyale
 [java] COMPC
 [java] Loading configuration: 

 [java] Loading configuration: 

 [java] 
 [java] 27951 bytes written to 

 in 1.650 seconds
 [java] COMPCJSCRoyale
 [java] Copy library.swf
 [java] Compiling file: CollectionsClasses
 [java] Writing file: js\out\CollectionsClasses.js
 [java] Compiling file: org.apache.royale.collections.ICollection
 [java] Writing file: js\out\org\apache\royale\collections\ICollection.js
 [java] Compiling file: org.apache.royale.collections.ICollectionView
 [java] Writing file: 
js\out\org\apache\royale\collections\ICollectionView.js
 [java] Compiling file: org.apache.royale.collections.TreeData
 [java] Writing file: js\out\org\apache\royale\collections\TreeData.js
 [java] Compiling file: org.apache.royale.collections.parsers.IInputParser
 [java] Writing file: 
js\out\org\apache\royale\collections\parsers\IInputParser.js
 [java] Compiling file: 
org.apache.royale.collections.parsers.JSONInputParser
 [java] Writing file: 
js\out\org\apache\royale\collections\parsers\JSONInputParser.js
 [java] Compiling file: org.apache.royale.collections.IArrayList
 [java] Writing file: js\out\org\apache\royale\collections\IArrayList.js
 [java] Compiling file: 

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

[Harbs]

Hi Carlos,

Comments inline.

> 
> 4. Methodology: Royale should not impose linking of libraries, other that
> Language, Test and Core. I think yes. Alex and you think no.

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?

> 
>> 
>> 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’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?

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

> 
>> 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.
>> 
> 
> Here we have a problem. I think we need to fix things and that should make
> many problems are gone. But although the problems are gone, we have a
> different approach in how to build Jewel components for you Jewel Button
> extends Basic Button, for me Jewel Button extends UIBase... how can we
> overcome it?
> For me your option is less flexible than mine, and I give you many
> arguments, while I don't see any arguments in favor of making Jewel extend
> Basic TLCs
> I think that's the problem here.

I think I understand your arguments, but it does not feel like you understand 
mine. I think that by actually doing the work, the arguments will become 
clearer. Again: I’m *not* proposing that Jewel should extend *all* of Basic 
TLCs. I’m suggesting that it’s appropriate for it to extend *some* of them. I 
think time will show whether I’m right or wrong. What is the harm in letting 
time tell who’s right?

> 
>> 4. Let’s complete Jewel and see wether there is a reason to use the
>> TLCs/CSS.
>> 
> 
> But, in my previous email I said that If I want to continue working in
> Jewel components I need to continue moving things to a library shared.

Basic *is* that shared library. To prevent linking to Basic (TLCs), we can move 
the Basic TLCs out of Basic *at any time*. I don’t see why we need to *do 
anything* right now (except get everything working for a release). Jewel apps 
might be slightly larger for a month or two until we get this sorted out, but 
what’s the rush?

> So to complete since I don't consider the option of linking Basic how can I
> perform the completion? Coming code to Jewel? Is not an option for any of us
> Moving to Core? I think we are still discussing what to do. I only can
> create Foundation lib and move there, while keeping the same in Basic
> temporarily and link Foundation
> to Jewel.
> 
> If you have some additional way to do this that not implies link Basic let
> me know.

Just consider Basic “Foundation” and ignore all the TLCs for the time being. If 
it’s the right thing to move the TLCs out, we can do that later.

> 
>> 5. Let’s do research on whether CSS processing during compilation is an
>> issue and try and figure out our options if it is.
>> 
> 
> Imagine you get to fix bugs and fix current CSS so you get rid of all the
> current problemsThen you prefer to continue in the same way that
> already was clearly problematic, and will bring more problems later? 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 

Build failed in Jenkins: royale-asjs_jsonly #886

[apacheroyaleci]

See 


Changes:

[harbs] Made SpinnerButton a proper type

[harbs] Remove Slider class selectors

[harbs] Removed ToggleTextButton class selector

[harbs] Merge

[harbs] Added TreeGridListArea class

--
[...truncated 1.11 MB...]
 [java] args:
 [java] 
+royalelib=
 [java] -compiler.strict-xml=true
 [java] -compiler.targets=SWF,JSRoyale
 [java] 
-output=
 [java] 
-load-config=
 [java] 
-load-config+=
 [java] target:SWF
 [java] target:JSRoyale
 [java] COMPC
 [java] Loading configuration: 

 [java] Loading configuration: 

 [java] 
 [java] 27951 bytes written to 

 in 1.654 seconds
 [java] COMPCJSCRoyale
 [java] Copy library.swf
 [java] Compiling file: CollectionsClasses
 [java] Writing file: js\out\CollectionsClasses.js
 [java] Compiling file: org.apache.royale.collections.ICollection
 [java] Writing file: js\out\org\apache\royale\collections\ICollection.js
 [java] Compiling file: org.apache.royale.collections.ICollectionView
 [java] Writing file: 
js\out\org\apache\royale\collections\ICollectionView.js
 [java] Compiling file: org.apache.royale.collections.TreeData
 [java] Writing file: js\out\org\apache\royale\collections\TreeData.js
 [java] Compiling file: org.apache.royale.collections.parsers.IInputParser
 [java] Writing file: 
js\out\org\apache\royale\collections\parsers\IInputParser.js
 [java] Compiling file: 
org.apache.royale.collections.parsers.JSONInputParser
 [java] Writing file: 
js\out\org\apache\royale\collections\parsers\JSONInputParser.js
 [java] Compiling file: org.apache.royale.collections.IArrayList
 [java] Writing file: js\out\org\apache\royale\collections\IArrayList.js
 [java] Compiling file: org.apache.royale.collections.ArrayList
 [java] Writing file: js\out\org\apache\royale\collections\ArrayList.js
 [java] Compiling file: org.apache.royale.collections.FlattenedList
 [java] Writing file: js\out\org\apache\royale\collections\FlattenedList.js
 [java] Compiling file: org.apache.royale.collections.IHierarchicalData
 [java] Writing file: 
js\out\org\apache\royale\collections\IHierarchicalData.js
 [java] Compiling file: org.apache.royale.collections.Collection
 [java] Writing file: js\out\org\apache\royale\collections\Collection.js
 [java] Compiling file: 
org.apache.royale.collections.converters.IItemConverter
 [java] Writing file: 
js\out\org\apache\royale\collections\converters\IItemConverter.js
 [java] Compiling file: 
org.apache.royale.collections.converters.JSONItemConverter
 [java] Writing file: 
js\out\org\apache\royale\collections\converters\JSONItemConverter.js
 [java] Compiling file: org.apache.royale.collections.HierarchicalData
 [java] Writing file: 
js\out\org\apache\royale\collections\HierarchicalData.js
 [java] Compiling file: org.apache.royale.collections.LazyCollection
 [java] Writing file: js\out\org\apache\royale\collections\LazyCollection.js
 [java] 3.3785512 seconds
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
 [copy] Copying 1 file to 


main:

copy-swc:

check-for-tests:

test:

main:

Basic:

clean:

check-for-tests:

clean-tests:

check-compiler-home:

check-transpiler-home:

check-compiler:

compile:

compile-js:
   [delete] Deleting: 


clean:

check-compiler-home:

check-transpiler-home:

check-compiler:

compile:
 [echo] Cross-compiling BasicJS.swc
 [echo] ROYALE_COMPILER_HOME: 

[mkdir] Created dir: 

Re: Need some help with Small Messages

[Carlos Rovira]

Hi Alex,

2018-06-01 5:50 GMT+02:00 Alex Harui :

>
>
> First, regarding your question about whether the parameter should be
> AMFBInaryData or BinaryData, IMO, the answer should be that the parameter
> should be an interface.


We can create a IBinaryData interface, maybe only marker, since I think
most of the methods are different. In Flash there's only one ByteArray, and
then an ObjectEncoding property.
Other option would be some refactor to have only one class, and people
wanting AMF compose the code making it optional.


> If there aren't backward compatibility constraints, we should try to use
> interfaces more in new APIs.  In looking around, I noticed that there is:
>
> Core/src/main/royale/org/apache/royale/utils/IBinaryDataInput.as
> Network/src/main/royale/org/apache/royale/net/utils/IDataInput.as
> Storage/src/main/royale/org/apache/royale/storage/file/IDataInput.as
>
> Seems like there should either be only one,


Right, we need to remove and unify. As I did with UIDUtils/RPCUIDUtils, I
prefer to try to make this work and then refactor and remove and check all
continue working ok.


> and AMFBinaryData and BinaryData should both implement it, or maybe one
> interface should extend the other.  So some refactoring is probably
> warranted there.
>

Agree


>
> Now to your main question.  Are you sure that code 168 is an AMF type
> code?  I could certainly be wrong, but it occurred to me that the 168
> could just be the first byte in serialized data of the message and that the
> AMF decoding should instantiate the object based on the class alias then
> see if it implements IExternalizable and call readExternal without
> bothering to examine that byte in the stream.
>

ok, so if I understand right I must pass the rest of data in AMFBinaryData
to "readExternal" method? If so, readExternal expects an IDataInputand
is not clear to me how as well give that part of the data Array (maybe I
should create a temporal data array that holds data from current position
to the end of the array?
Sorry but as you is not my area of expertise.

thanks


>
> HTH,
> -Alex
>
> On 5/31/18, 4:57 PM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> To be more clear on this, what I need is some guidance on how to deal I
> readValueObject(), EXTERNALIZED_OBJECT case and if I must pass the
> rest of
> data to the AcknowledgeMessageExt.readExternal method, or pass the
> entire
> AMFBinaryData to that method. Or another thing I don't have in mind.
>
> thanks!
>
>
> 2018-06-01 1:37 GMT+02:00 Carlos Rovira :
>
> > Hi,
> >
> > in order to finish Small Messages implementation I need some
> guidance.
> > Hope you guys could throw some light on this.
> >
> > When turning small messages on, BlazeDS send serialized version of
> some
> > messages. For example the most important is "*DSK*" (the
> > registerClassAlias for *AcknowledgeMessageExt.as*), in this case we
> get a
> > type code *168* in "*readObject*" method from *AMFBinaryData*. We
> can get
> > as well *169* and *161* codes, don't know if there's more since I
> > couldn't find any documentation about this.
> >
> > So in *readValueObject*() I introduced a new case
> *EXTERNALIZED_OBJECT*
> > (that is a constant with 168 value)
> >
> > Inside we need to deal with the deserialization of the
> > *AcknowledgeMessageExt* message (the *DSK*).
> >
> > This kind of messages like the rest implements all *IExternalizable*
> > methods (*readExternal*, *writeExternal*), that receive a
> *IDataInput*
> > and *IDataOutput* respectively.
> > I get all this code of messages from Flex RPC compile correctly .
> Here I
> > have a doubt:
> >
> > ** When I have a ByteArray param here it should be BinaryData or
> > AMFBinaryData in Royale?* (I suppose the second, but can't ensure it)
> >
> > Finally the main problem...How can I deserialize the DSK object that
> comes
> > vía AMF
> >
> > 1.-* I'm pretty sure that AMFBinaryData must implement IDataInput and
> > IDataOutput since is the object I suppose I must to pass to
> readExternal or
> > writeExternal right?*
> >
> > 2.- In *readValueObject*(), case *EXTERNALIZED_OBJECT* I tried to do
> > something like:
> >
> > *var dsk: AcknowledgeMessageExt = new AcknowledgeMessageExt()*
> > *dsk.readExternal (this);*
> > *value = dsk;*
> >
> > this is not working, if not we'll be done ;)
> >
> > But as I don't know how flash IExternalizable works under the hood, I
> > don't know how to deal with this in Royale.
> >
> > I suppose that Flash Player manages the readExternal and
> writeExternal
> > methods under the hood, right? but in Royale I suppose we need to
> call it
> > ourselves.
> >
> > Maybe the IExternalizable, IDataOutput and IDataInput are not right
> as I
> > write those. Notice that the last two 

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

[Carlos Rovira]

Hi Harbs

2018-06-01 11:03 GMT+02:00 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?
>

4. Methodology: Royale should not impose linking of libraries, other that
Language, Test and Core. I think yes. Alex and you think no.


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


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


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

Here we have a problem. I think we need to fix things and that should make
many problems are gone. But although the problems are gone, we have a
different approach in how to build Jewel components for you Jewel Button
extends Basic Button, for me Jewel Button extends UIBase... how can we
overcome it?
For me your option is less flexible than mine, and I give you many
arguments, while I don't see any arguments in favor of making Jewel extend
Basic TLCs
I think that's the problem here.


> 4. Let’s complete Jewel and see wether there is a reason to use the
> TLCs/CSS.
>

But, in my previous email I said that If I want to continue working in
Jewel components I need to continue moving things to a library shared.
So to complete since I don't consider the option of linking Basic how can I
perform the completion? Coming code to Jewel? Is not an option for any of us
Moving to Core? I think we are still discussing what to do. I only can
create Foundation lib and move there, while keeping the same in Basic
temporarily and link Foundation
to Jewel.

If you have some additional way to do this that not implies link Basic let
me know.


> 5. Let’s do research on whether CSS processing during compilation is an
> issue and try and figure out our options if it is.
>

Imagine you get to fix bugs and fix current CSS so you get rid of all the
current problemsThen you prefer to continue in the same way that
already was clearly problematic, and will bring more problems later? 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.


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


> 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 

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
> 

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 (are already not linked or mandatory)
>> like
>>MDL, CreateJS, and more, I'm fine with it. I recommend in the future
>>refactor as well, but that should be made by volunteers if they want
>> 
>> I think that's inconsistent.  If you agree above that some other component
>> set can re-use Jewel Views, then you 

Re: Descendent selector issue

[Andrew Wetmore]

Am I seeing a space here before the period?

TitleBar .TitleBarTitle

Would that cause the bad behavior?

On Fri, Jun 1, 2018 at 5:40 AM, Harbs  wrote:

> 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




-- 
Andrew Wetmore

http://cottage14.blogspot.com/

RE: Descendent selector issue

[Idylog - Nicolas Granon]

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)

[Carlos Rovira]

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 (are already not linked or mandatory)
> like
> MDL, CreateJS, and more, I'm fine with it. I recommend in the future
> refactor as well, but that should be made by volunteers if they want
>
> I think that's inconsistent.  If you agree above that some other component
> set can re-use Jewel Views, then you will need to break Jewel beads out
> into a separate SWC as well according to your arguments.  And that will
> double the number of SWCs.  Instead, I think we have ways to use the
> current organization to address your concerns about extra CSS processing.
>
>

I think there's a misunderstanding here. Let's see If I can explain what I
really want to mean: Right now Basic has all code needed to build a UI Set
plus, the concrete implementation of that UI Set plus a CSS that wires all
of it in a concrete waty. I think that's not right. If you extract all
reusable code to Foundation library, you'll get with a library (Basic) with
just TLCs and CSS, and that library will have exact same pieces than
(Jewel), TLCs of that concrete implementation that are not reusable at all,
and CSS that wires a concrete setup of beads (in Core, Foundation and the
particular UI Set). As we said MDL or CreateJS are not our main target, so
other volunteers should take that into account if they want or leave it as
is, since the new setup supports it, while the old one is more restrictive
and we have no option to setup one wat or the other.


> But links all existing available libraries? when you program in C++ you
> link what you need. So in Royale there's no point to link a Basic UI
> Set
> (TLCs and CSS) if I'm going to not use it, but use another one.
>
> The user is in complete control over the number of SWCs that get read in,
> even for Ant, IDEs and command-line users.


That's not true in the old setup. The compiler process *reads* all CSS and
if we have not bugs nothing will end there. And more important, I 

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

[Alex Harui]

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"  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>> 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 
 > on behalf of Carlos Rovira" 
mailto:carlos.rov...@gmail.com>> on behalf of 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 

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

[Alex Harui]

I'm replying to my post again even though it isn't the latest.At the end I 
address what I think is a misconception that I saw in those more recent posts.

>   We want these beads, even high level beads, to be re-usable in multiple
> components sets.


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.  Copying code to avoid a project dependency is not a 
recommended practice.

> There may be a SuperJewel someday or variants on Jewel with completely
> different names that borrow beads from Jewel under the principle of
> re-using code.


That will requiere that SuperJewel links Jewel to use it, as well Express
need to link Basic. CreateJS does need to link Jewel, that will be
pointless.


> The Emulation set will probably use Jewel views.


Hope so, so MXRoyale will link Jewel since it needs, while Basic not since
it never will use it.

The Emulation set will use Basic beads for models and controllers and lots of 
other things, if the simple implementations suffice.

> Our users have asked for our component sets to require little
> configuration, so Jewel should re-use Express beads.
>

Can give an example of a reusable Express bead in Jewel. FWIK Express is an
aggregation of Basic UI Set, so it makes less need of configuration in
final code, so a Button can integrate Disabled bead. Don't have in mind a
reusable case of Express in Jewel, since Jewel doesn't use Basic at all.

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.

>
> I think you are making the argument for doubling the number of SWCs so
> that beads go in a SWC and TLCs that use those beads go in a separate SWC.


Doubling no, jut one: Foundation - Basic. The rest is up to discussion, but
since are not required right now (are already not linked or mandatory) like
MDL, CreateJS, and more, I'm fine with it. I recommend in the future
refactor as well, but that should be made by volunteers if they want

I think that's inconsistent.  If you agree above that some other component set 
can re-use Jewel Views, then you will need to break Jewel beads out into a 
separate SWC as well according to your arguments.  And that will double the 
number of SWCs.  Instead, I think we have ways to use the current organization 
to address your concerns about extra CSS processing.


> There isn't an Apache Commons analogy for that since JARs are dynamically
> linked.  But in statically-linked libraries like C/C++ on Windows, the
> compiler does visit entire libraries and only links in what is needed.
>

But links all existing available libraries? when you program in C++ you
link what you need. So in Royale there's no point to link a Basic UI Set
(TLCs and CSS) if I'm going to not use it, but use another one.
   
The user is in complete control over the number of SWCs that get read in, even 
for Ant, IDEs and command-line users.  The compiler only reads in the SWCs it 
is told to read in.  The default royale-config.xml currently uses a wildcard.  
Will it always?  Maybe not if we someday have enough SWCs that reading them all 
in becomes a problem.   If you specify the exact set of SWCs that you would in 
a Maven pom, you will enjoy the same benefits of the compiler only reading 
those SWCs, if any.  It is simply a trade-off of configuration effort vs 
compile-time.  Also having more SWCs get loaded should mean more options 
offered in code-hinting which is, IMO a good thing for now, but probably not in 
the future.  So, don't be worried about how many SWCs get read in.  Users can 
control that.

I am going to try to move the exclude-defaults-css to the loading phase instead 
of the output phase.  I think once I finish that and Harbs finishes removing 
class selectors we can see if there are any remaining issues or concerns with 
the current set of libraries.

HTH,
-Alex