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?

[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%7Cfe016d3a8a054079c23908d5cab1005c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637783920590036=mEUKysH2%2FsT4PtSe4ntWlFSZoz3B35zTEs3cJN288yE%3D=0

Re: Problem with Debugger in VSCode

[Piotr Zarzycki]

Hi Om,

I've tried Chrome and have the same issue. I will try as you said with the
console.

Thanks,
Piotr

On Wed, Jun 6, 2018, 2:24 AM OmPrakash Muppirala 
wrote:

> I've seen some flakiness with this in the past.  Some things that could
> help is: after starting the app in the browser, open the developer console,
> then go back to VS and hit the reload button.  That should activate the
> debugger.
>
> Another thing, is try using Chrome as your browser?
>
> Hope that helps.
>
> Thanks,
> Om
>
> On Tue, Jun 5, 2018 at 12:50 PM, Piotr Zarzycki  >
> wrote:
>
> > Hi Guys,
> >
> > Does anyone who is using VSCode has problem with debugging app? I've
> > created Hello World app and tried to debug it but debugger cannot connect
> > with app at all. When I hit Menu "Debug" -> "Start Debugging" -
> Application
> > has been launched, but debugger seems to be dead, no stop on breakpoints.
> >
> > My asconfig [1], launch.json [2]. I'm using JS only Nighly build of
> Royale
> > - I have just tested with build number #926.
> >
> > VSCode version: Version 1.23.1
> > AS3 & MXML Engine: 0.12.0
> >
> > Anyone experience the same ? Or can check whether have the same problem?
> >
> > [1] https://paste.apache.org/ulBB
> > [2] https://paste.apache.org/g8I5
> >
> > Thanks,
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > *
> >
>

Re: Problem with Debugger in VSCode

[OmPrakash Muppirala]

I've seen some flakiness with this in the past.  Some things that could
help is: after starting the app in the browser, open the developer console,
then go back to VS and hit the reload button.  That should activate the
debugger.

Another thing, is try using Chrome as your browser?

Hope that helps.

Thanks,
Om

On Tue, Jun 5, 2018 at 12:50 PM, Piotr Zarzycki 
wrote:

> Hi Guys,
>
> Does anyone who is using VSCode has problem with debugging app? I've
> created Hello World app and tried to debug it but debugger cannot connect
> with app at all. When I hit Menu "Debug" -> "Start Debugging" - Application
> has been launched, but debugger seems to be dead, no stop on breakpoints.
>
> My asconfig [1], launch.json [2]. I'm using JS only Nighly build of Royale
> - I have just tested with build number #926.
>
> VSCode version: Version 1.23.1
> AS3 & MXML Engine: 0.12.0
>
> Anyone experience the same ? Or can check whether have the same problem?
>
> [1] https://paste.apache.org/ulBB
> [2] https://paste.apache.org/g8I5
>
> Thanks,
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>

Re: Incorrect descendent CSS output

[Alex Harui]

If the namespace prefixes are stored in the selector, then when deciding 
whether to keepRules, we should check the prefix and if it is null and the 
default namespace is xhtml, then we can use a fully qualified name in the 
comparison.

HTH,
-Alex

On 6/5/18, 3:09 PM, "Harbs"  wrote:

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: 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: 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: Incorrect descendent CSS output

[Alex Harui]

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

[Alex Harui]

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]

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: How to replace Flex Path in Royale

[Piotr Zarzycki]

Ok! I will look into it!

Thanks!

On Tue, Jun 5, 2018, 11:15 PM Harbs  wrote:

> 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 .
> >
> > Thanks,
> > Piotr
> >
> > wt., 5 cze 2018 o 22:45 Harbs  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
> >>> *
> >>
> >>
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki <
> https://www.patreon.com/piotrzarzycki>
> >  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 .
> 
> Thanks,
> Piotr
> 
> wt., 5 cze 2018 o 22:45 Harbs  > 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 
>> >
>> 
>>> 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
>>> *
>> 
>> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki 
> 
>  >*

Re: Incorrect descendent CSS output

[Alex Harui]

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: How to replace Flex Path in Royale

[Piotr Zarzycki]

Unfortunately link doesn't work for me. Can you post code in
paste.apache.org.

Thanks,
Piotr

wt., 5 cze 2018 o 22:45 Harbs  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>
>
> > 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
> > *
>
>

-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

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

[Alex Harui]

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: 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%7C636638038403206781=
 INLNGTTuYDwM%2FRtYV8LQ4pY5S4%2FOdmOs6JWzsYxAQZA%3D=0>>
>> 
>> 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 

Re: Last class selectors

[Carlos Rovira]

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%7C636638038403206781=
> >> INLNGTTuYDwM%2FRtYV8LQ4pY5S4%2FOdmOs6JWzsYxAQZA%3D=0>>
> 
>  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: 

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

How to replace Flex Path in Royale

[Piotr Zarzycki]

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
*

Problem with Debugger in VSCode

[Piotr Zarzycki]

Hi Guys,

Does anyone who is using VSCode has problem with debugging app? I've
created Hello World app and tried to debug it but debugger cannot connect
with app at all. When I hit Menu "Debug" -> "Start Debugging" - Application
has been launched, but debugger seems to be dead, no stop on breakpoints.

My asconfig [1], launch.json [2]. I'm using JS only Nighly build of Royale
- I have just tested with build number #926.

VSCode version: Version 1.23.1
AS3 & MXML Engine: 0.12.0

Anyone experience the same ? Or can check whether have the same problem?

[1] https://paste.apache.org/ulBB
[2] https://paste.apache.org/g8I5

Thanks,
-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

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: 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
>  
> 
>  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;
>border-radius: 5px 5px 0 0;
>}
>.tabs > li:hover:before {
>-webkit-transform: translateY(70%);
>transform: translateY(70%);
>}
>.tabs > li.active 

Re: Last class selectors

[Carlos Rovira]

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%7C636638038403206781=
> INLNGTTuYDwM%2FRtYV8LQ4pY5S4%2FOdmOs6JWzsYxAQZA%3D=0>>
> >>
> >> 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
> >>> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C684ff80e790aac1708d5caec404f%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636638038403206781=EzFOoWovI%
> 

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

[Carlos Rovira]

Hi Alex,


2018-06-05 18:31 GMT+02:00 Alex Harui :

> They might be connected.  I think the problem we've been discussing is
> "how should the DOM be set up for absolute positioning?".


in Jewel I'm trying to use only flexbox, and that's part of Jewel. So both,
classes and css rules are defined in Jewel SWC. So themes not handle layout
and positioning only drawings, borders, backgrounds, colors, fonts...


> I don't think there is a perfect solution, but using '.Application *' may
> be good enough for now.
>

yes I think so the base of all of this is:

.layout
display: flex

.layout.absolute
position: relative
//justify-content: flex-start // align main axis (this is the default
not need to specify it)
> *
position: absolute

.layout.horizontal
flex-flow: row nowrap
//justify-content: flex-start // align main axis (this is the default
not need to specify it)
align-items: flex-start

.layout.vertical
flex-flow: column nowrap
//justify-content: flex-start // align main axis (this is the default
not need to specify it)
align-items: flex-start


In this way we get layouts working flawlessly for IE11, Chrome, Firefox,
Safari, Opera ...
(since Grid is still not so widely supported).


> I think you may be describing a different issue which is "how should
> layouts find out about the need to run layout again?".  I don't think there
> is a right answer here either, but PAYG says we shouldn't bake in watching
> every child in the DOM like Flex did.  That's just wasteful.  We could
> create some bead that does that for the general case, or for Express and
> maybe even Jewel to cut down on configuration/debugging, but we should make
> sure other strategies work, like beads that watch a single property on a
> component (LayoutChangeNotifier).  The idea is that someone should only
> have to pay for watching the things that truly matter in layout.
>

Right, I think I still need to remove the sizeChange event in BasicLayout
and maybe do a bead for basic layout bead... for example a
"NotifySizeChange" bead that will loop over child items and dispatch the
event
thoughts?


>
> My 2 cents,
> -Alex
>
> On 6/5/18, 4:15 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> Hi,
>
> just let you know that the problem seems a bit close to the one I
> reported
> about using view states for a new blog example post.
> If I change View layout from Basic to for example VerticalLayout, that
> fixes the issue.
> So in Jewel BasicLayout, that now is based on CSS, I added a loop like
> in
> the rest of layouts so each chid dispatch "sizeChanged" event
> This fixes the problem.
> So maybe this is not the right fix, but seems that basic layout needs
> its
> children to "prepare" itself for a change.
>
> Just to let you know since it seems both problems are connected.
>
> Thanks
>
>
> 2018-06-05 8:53 GMT+02:00 yishayw :
>
> > 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%7C7544e7d51bcd4246635e08d5cad5
> a966%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636637941374916636=rt9%2BTvmMTxoONKGPs28eeW7BBjZ85Fic
> saMk7ygxno0%3D=0
> >
>
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C7544e7d51bcd4246635e08d5cad5a966%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636637941374916636=y%2BAUMUakdOYIoVnc1NOYB96AbqgIuz
> BUoGzQXE6XCLA%3D=0
>
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Last class selectors

[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 mailto: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
 
>
>> 
>> 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
>>> 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C684ff80e790aac1708d5caec404f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636638038403206781=EzFOoWovI%2BOluTHQodvEWUTNfaJgRYEaQJX1BnAkN9k%3D=0
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C684ff80e790aac1708d5caec404f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636638038403206781=EzFOoWovI%2BOluTHQodvEWUTNfaJgRYEaQJX1BnAkN9k%3D=0
 

Re: Incorrect descendent CSS output

[Alex Harui]

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
 

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

[Alex Harui]

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?

[Alex Harui]

They might be connected.  I think the problem we've been discussing is "how 
should the DOM be set up for absolute positioning?".  I don't think there is a 
perfect solution, but using '.Application *' may be good enough for now.

I think you may be describing a different issue which is "how should layouts 
find out about the need to run layout again?".  I don't think there is a right 
answer here either, but PAYG says we shouldn't bake in watching every child in 
the DOM like Flex did.  That's just wasteful.  We could create some bead that 
does that for the general case, or for Express and maybe even Jewel to cut down 
on configuration/debugging, but we should make sure other strategies work, like 
beads that watch a single property on a component (LayoutChangeNotifier).  The 
idea is that someone should only have to pay for watching the things that truly 
matter in layout.

My 2 cents,
-Alex

On 6/5/18, 4:15 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi,

just let you know that the problem seems a bit close to the one I reported
about using view states for a new blog example post.
If I change View layout from Basic to for example VerticalLayout, that
fixes the issue.
So in Jewel BasicLayout, that now is based on CSS, I added a loop like in
the rest of layouts so each chid dispatch "sizeChanged" event
This fixes the problem.
So maybe this is not the right fix, but seems that basic layout needs its
children to "prepare" itself for a change.

Just to let you know since it seems both problems are connected.

Thanks


2018-06-05 8:53 GMT+02:00 yishayw :

> 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%7C7544e7d51bcd4246635e08d5cad5a966%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637941374916636=rt9%2BTvmMTxoONKGPs28eeW7BBjZ85FicsaMk7ygxno0%3D=0
>



-- 
Carlos Rovira

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C7544e7d51bcd4246635e08d5cad5a966%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636637941374916636=y%2BAUMUakdOYIoVnc1NOYB96AbqgIuzBUoGzQXE6XCLA%3D=0

Re: Last class selectors

[Carlos Rovira]

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 :

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


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Last class selectors

[Harbs]

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

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: Last class selectors

[Carlos Rovira]

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: [Discussion] Package change names (was Re: 0.9.3 Release)

[Carlos Rovira]

Hi Alex,

2018-06-04 20:15 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> At this point, I think I've addressed all of the compiler issues that
> result in unnecessary output or processing.  If Harbs is finished with the
> framework changes, then I think we can try building Jewel with and without
> Basic and see if there are still issues.
>

I'll give it a try and see. But If we get things working ok, I still expect
we can move things from what we call currently Basic to it's own SWC (TLCs,
CSS and direct related beads)
I still have to make a small list example like Harbs requested me for this.


> I have to say that my understanding of your responses seem counter to how
> the main patterns in Royale's composition-based frameworks are supposed to
> work.  Here are some of the disconnects as I see them.
>

I think we really have the same goals in mind and there's only one point
that I'm not like (make Jewel extend a library with Basic TLCs, direct
beads and CSS).


>
> 1. Jewel Views, Models, Controllers and other beads should not be tied to
> Jewel TLCs.  TLCs are intended to be example compositions of beads.  See
> the "Exploded Component" section of "Terminology and Concepts".
>

Right, I still need to get to this point and check this along with SWF
version. This days I was concentrating in get IE11 work. Right now is
almost done, and only need to solve 2 problems (Slider and SVG colors) to
get that part complete.


> 2. Jewel Views should not be tied to Jewel Models.   Jewel may not even
> need its own Models for many controls.  The default TextButton model just
> has text and html properties.  There shouldn't be anything
> component-set-specific about such a model.
>

Right. You said that because you saw some incorrect relationship in the
actual code? if so we need to fix that.


> 3. Folks are encouraged to create compositions from beads at all levels of
> the framework, from all component sets, in order to maximize code reuse.
> So, if you want to split Basic beads into a separate SWC from Basic TLCs,
> you must also agree to split Jewel beads into a separate SWC away from
> Jewel TLCs.


Yes, I don't want beads in Jewel of general purpose. If I find someone I'll
move to the shared lib. This days I removed some that was copied temporal
(i.e MultilineLabel), and modified other beads that was just copied until
now (layout beads, now has a different code with CSS handling, and still
need more work). But I have still more code that should be moved as we
finishing this discussion or even removed.


>That way, folks who compose Jewel beads into another component set will
> enjoy the same benefits you are claiming will happen if we split Basic
> beads from Basic TLCs.
>

Right


> 4. Because there are different levels of complexity, it does not make
> sense to try to make one universal library of re-usable pieces.  Also,
> because we want third-parties to have a viable ecosystem for their
> components, we want to make sure that composition works well in a
> decentralized organizational model.
>

Right


> 5. Everything in Royale, even the TLCs need to be reusable.  The MXML
> Component model requires it, especially of TLCs.
>
> I noticed just now that Jewel does not yet have any "composite" components
> (meaning, components composed of other components).  You may want to work
> on Jewel DataGrid, for example, and have it use the Express type-agnostic
> DataGridModel.  It might help illustrate how different levels of bead
> complexity should work.
>

Maybe Jewel List is the only composite component in Jewel right now right?

I need to finish some few things and then will handle this ok?

Thanks


>
> My 2 cents,
> -Alex
>
> On 6/1/18, 1:26 AM, "carlos.rov...@gmail.com on behalf of 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 

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

[Carlos Rovira]

Hi,

just let you know that the problem seems a bit close to the one I reported
about using view states for a new blog example post.
If I change View layout from Basic to for example VerticalLayout, that
fixes the issue.
So in Jewel BasicLayout, that now is based on CSS, I added a loop like in
the rest of layouts so each chid dispatch "sizeChanged" event
This fixes the problem.
So maybe this is not the right fix, but seems that basic layout needs its
children to "prepare" itself for a change.

Just to let you know since it seems both problems are connected.

Thanks


2018-06-05 8:53 GMT+02:00 yishayw :

> 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: http://apache-royale-development.20373.n8.nabble.com/
>



-- 
Carlos Rovira
http://about.me/carlosrovira

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

[yishayw]

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: http://apache-royale-development.20373.n8.nabble.com/

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/ 

[2]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:
>> 
>> 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,