date:20180606

In the case of the controlsPallette, how did it get its size? I could
certainly understand that if you didn't have position!=static, that setting top
on the dockAndOuterContainer would have no effect, but you shouldn't have had
to set y or top in the first place. IIRC, you couldn't use x,y in Flex layouts
like VerticalLayout/HorizontalLayout so migrating code shouldn't be using it.
It is fine to create other layouts that support x,y as exceptions.

In general, for a framework, we want to make sure we understand and fix the
fundamental problem before we address any hacks/exceptions. IMO, the
fundamental problem in the scenarios you've provided so far is that the layout
did not do what was expected so someone tried using x,y to fix it. First we
need that layout do what is expected, then worry about how folks might resolve
other issues, if any.

In ProductsView in RoyaleStore, the grip is an image loaded later, so there
might have been an issue there, especially on the SWF side, but I would expect
the browser to automatically re-layout once the grip image loaded. I dug
through Git history and found that I was the one who hacked in the x,y. It
could be that early on, the layout did not use FlexBox so we had a similar
problem of responding to the grip image loading late. But we should remove the
x,y and see if there is still a problem and ponder the right fix for that.
ProductsView should not need to be setting x,y.

So, IMO, it would be nice to do a similar investigation of controlsPallette.
IMO, if you examine that div, it's offsetHeight should be 40 and if it is then
you shouldn't need to set style.top=40 on docAndOuterContainer which means that
it shouldn't matter what style.position is.

My 2 cents,
-Alex

On 6/6/18, 2:12 PM, "Harbs" wrote:

> On Jun 6, 2018, at 11:05 PM, Harbs wrote:
>
>text="{locStr.UPLOAD_YOUR_IMAGE}"/>
>

It actually, looks like the x and y values no longer have an effect on this
particular component, but there was clearly a reason they were needed to be
specified at some point…

Another one. I have an image which needs to stick to the bottom right of
the app. To do that I needed to following:

top: calc(100% - 21px);
left: calc(100% - 187px);
position: fixed;

With a default of position: relative, I’m able to do this:

top: -21px;
float: right;
right: 10px;

This being said, it actually looks like I’m wrong about the way to set the
defaults being .Application *{}. This actually has a *higher* specificity than
.foo{}.[1]

I think the only way to guarantee that it’ll have a lower specificity than
other selectors is to use:

*{
position: relative;
}

I’m less happy about this option than ."Application *” because it’ll effect
elements outside the Royale app if it’s not in an iframe.

Harbs

[1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.smashingmagazine.com%2F2007%2F07%2Fcss-specificity-things-you-should-know%2F=02%7C01%7Caharui%40adobe.com%7C36c2eb99bf2e4b45c44d08d5cbf2422f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636639163710627765=1YPJLfmzcaeFlh%2Bu2FTmbTHgvIvS6n%2BhVQiZhiucJqs%3D=0

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

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

Which produces:

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

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

Here’s another one:

UPLOAD YOUR IMAGE

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

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

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

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

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

I could certainly not be understanding how pervasive this problem is.  I don't 
remember the x and y properties always being in ProductsView.  In fact, it is 
not in the original FlexStore demo.  I wonder if was added later?

I would hope that I could just bring up an HTML editor and use display:flex to 
layout 4 widgets horizontally and get one to stretch to fill the remaining 
space without setting position or the left and top styles.  I think that would 
be the minimal implementation.  Then offsetParent should be needed either.   We 
should remove the x and y from this demo and make sure we understand how to get 
this to work and generate that minimal DOM+CSS.  IMO, a framework should not 
implement wide-ranging defaults because someone hacked something in.

Then, if we need to compensate for migrating users having hacked x and y values 
then we can create PAYG beads/layouts for that.

Can you provide more details where you needed to set x,y in your app?  We have 
to remember to get out of the Flex mindset that there is only one Application 
or Layout.  It might turn out to be more efficient in some cases to have an 
AbsolutePositioningApplication if folks did find that they had to use x,y a lot 
in Flex.  But I think Carlos has achieved good results in his demos without 
setting x,y and just using display:flex.  He reported that there is no impact 
by adding that universal selector, but that also implies that it was 
just-in-case for him.

My 2 cents,
-Alex

On 6/6/18, 11:25 AM, "Harbs"  wrote:

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

Let’s take a piece of ProductsView in RoyaleStore:

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

 x="{filterGrip.width}”

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

I was forced to add similar code in my app.

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

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

My $0.02,
Harbs

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

Re: Problem with Debugger in VSCode

Hi,

this was in my TODO, since I didn't use debug since many months ago. I
remember this was working when I tried it...I think when I started to work
in making MDL, but I left totally (bad for me). I was trying and get the
breakpoint marked as red, so the breakpoint is recognized, but debugger
doesn't stop at all :(

2018-06-06 20:09 GMT+02:00 Alex Harui :

> Short of making it work in both SWF and JS, couldn't we just make it work
> in JS by adding a "debugger" global variable to the JS typedefs?  Then it
> could be wrapped in COMPILE::JS blocks and used in Royale without changing
> the compiler.
>
> Just wondering,
> -Alex
>
> On 6/6/18, 11:02 AM, "Josh Tynjala"  wrote:
>
> No, you can't use the debugger statement in ActionScript. I as
> documented, you can use a custom HTML template with your Royale app and add
> it in a

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

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

Let’s take a piece of ProductsView in RoyaleStore:

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

 x="{filterGrip.width}”

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

I was forced to add similar code in my app.

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

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

My $0.02,
Harbs

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

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

IMO, if we all pitched in on emulation, we would have many more migrating users 
at the end of the year claiming that the UI is still a bit ugly.  If we leave 
emulation to fewer people, then at the end of the year, we may not have gotten 
all of the emulation components up and running and so fewer people will try 
them.  IMO, every day we don't make migration easier, we lose more potential 
users to other frameworks.

I have proposed workarounds that will let us avoid Type Selector name 
collisions that won't take nearly as much of my time to assist with.  
Perfection can be the enemy of success.  Sorry to be so selfish, but I am just 
trying to keep my job.  You are not wrong to pursue new users who don't have 
apps to migrate.  But I'm more certain that there are likely to be important 
Adobe customers in the group with apps to migrate than the group that will be 
new to Royale this year.

My 2 cents,
-Alex

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

Hi Alex,

And I think that approach is perfectly valid. But we tend to think the rest
of us are wrong, and I think that's not the case. Don't you think that if
we solve this king of problems (let's call it "styling problems"), we can
get a more visual Royale to put material online in website and social
networks, and as well new example apps that looks beautiful and that will
bring more active users on board?

I think we are pursuing the same, I think as well we need the actual
strategy we are following, some people in emulation effort, some others, in
theming, some others in tools...and so on. People will not come if you get
emulation working but it looks ugly, and as well not come if we get Jewel
working but they don't have the emulation strategy solved, and will not
come if we have the other points, but they can't use IntelliJ (for example)
in a huge team that use that tool...and so on...

so for me all is important, and although I thing I'll not a emulation user,
I see the huge benefits it can bring to royale. You can look at it in other
way, I don't see Harbs and me (for example) investing time in emulation, so
better to work in other parts that needs improvement as well right?

thanks

2018-06-06 19:20 GMT+02:00 Alex Harui :

> IMO, the thing that will have the greatest impact on whether Adobe will
> continue to pay me to work full time on Royale is how many active users we
> have at the end of the year, not whether we have a really cool way of
> avoiding type selector name collisions.  So I am asking folks to consider
> that we may be better off just getting things to work for more users
> instead of taking longer to make them perfect for one.  And that's why
> emulation components are my highest priority.
>
> My 2 more cents,
> -Alex
>
> On 6/6/18, 9:37 AM, "Carlos Rovira"  wrote:
>
> I think as well this is important. Very important. We must notice that
> we
> are a multidisciplinar team and we must take advantage of that making
> each
> one work in the areas where they get the most of it. I think if Harbs
> wants
> to make this happen, I think he should do that. For needs, I think MX
> emulation is important, but not more or less than get this solve as
> well.
> Think that, for example, in my case or in Harbs case, probably will
> not use
> MX emulation at all, while others will use it. In the other part, 
we'll
> make heavy use of that feature.
>
> I already said this, I thought as well on "typeNames" problem of
> hardcode
> in a class, as when I see in a class hardcoded styles...I see many
> problems
> in those kind of things, so taking the time and energy to solve it, I
> think
> is a time well invested.
>
> My 2...
>
> Thanks
>
>
>
> 2018-06-06 18:26 GMT+02:00 Harbs :
>
> > > This just seems like too much work for the hopefully seldom case 
of
> > mixing TLC's from various component sets.
> >
> > Well, I am already doing that… Maybe I’m the exception, but it’s not
> a
> > theoretical need. ;-)
> >
> > It also would enable us to use Basic and Express TLCs in Jewel —
> without
> > subclassing at all.
> >
> > There’s a bigger picture aspect of this as well which is probably
> most
> > important. It would enable component sets to declare how their
> typenames
> > should be written in CSS. Right now, Carlos is forced to write his
> Jewel
> > CSS using class selectors. I would really like to be able to change
> that to
> > type selectors and declaring the selectors in the manifest would
> enable
> > that.
> >
> >

Re: Problem with Debugger in VSCode

Short of making it work in both SWF and JS, couldn't we just make it work in JS 
by adding a "debugger" global variable to the JS typedefs?  Then it could be 
wrapped in COMPILE::JS blocks and used in Royale without changing the compiler.

Just wondering,
-Alex

On 6/6/18, 11:02 AM, "Josh Tynjala"  wrote:

No, you can't use the debugger statement in ActionScript. I as documented, 
you can use a custom HTML template with your Royale app and add it in a

Re: Problem with Debugger in VSCode

2018-06-06 Thread Josh Tynjala

No, you can't use the debugger statement in ActionScript. I as documented, you 
can use a custom HTML template with your Royale app and add it in a

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

Hi Alex,

And I think that approach is perfectly valid. But we tend to think the rest
of us are wrong, and I think that's not the case. Don't you think that if
we solve this king of problems (let's call it "styling problems"), we can
get a more visual Royale to put material online in website and social
networks, and as well new example apps that looks beautiful and that will
bring more active users on board?

I think we are pursuing the same, I think as well we need the actual
strategy we are following, some people in emulation effort, some others, in
theming, some others in tools...and so on. People will not come if you get
emulation working but it looks ugly, and as well not come if we get Jewel
working but they don't have the emulation strategy solved, and will not
come if we have the other points, but they can't use IntelliJ (for example)
in a huge team that use that tool...and so on...

so for me all is important, and although I thing I'll not a emulation user,
I see the huge benefits it can bring to royale. You can look at it in other
way, I don't see Harbs and me (for example) investing time in emulation, so
better to work in other parts that needs improvement as well right?

thanks


2018-06-06 19:20 GMT+02:00 Alex Harui :

> IMO, the thing that will have the greatest impact on whether Adobe will
> continue to pay me to work full time on Royale is how many active users we
> have at the end of the year, not whether we have a really cool way of
> avoiding type selector name collisions.  So I am asking folks to consider
> that we may be better off just getting things to work for more users
> instead of taking longer to make them perfect for one.  And that's why
> emulation components are my highest priority.
>
> My 2 more cents,
> -Alex
>
> On 6/6/18, 9:37 AM, "Carlos Rovira"  wrote:
>
> I think as well this is important. Very important. We must notice that
> we
> are a multidisciplinar team and we must take advantage of that making
> each
> one work in the areas where they get the most of it. I think if Harbs
> wants
> to make this happen, I think he should do that. For needs, I think MX
> emulation is important, but not more or less than get this solve as
> well.
> Think that, for example, in my case or in Harbs case, probably will
> not use
> MX emulation at all, while others will use it. In the other part, we'll
> make heavy use of that feature.
>
> I already said this, I thought as well on "typeNames" problem of
> hardcode
> in a class, as when I see in a class hardcoded styles...I see many
> problems
> in those kind of things, so taking the time and energy to solve it, I
> think
> is a time well invested.
>
> My 2...
>
> Thanks
>
>
>
> 2018-06-06 18:26 GMT+02:00 Harbs :
>
> > > This just seems like too much work for the hopefully seldom case of
> > mixing TLC's from various component sets.
> >
> > Well, I am already doing that… Maybe I’m the exception, but it’s not
> a
> > theoretical need. ;-)
> >
> > It also would enable us to use Basic and Express TLCs in Jewel —
> without
> > subclassing at all.
> >
> > There’s a bigger picture aspect of this as well which is probably
> most
> > important. It would enable component sets to declare how their
> typenames
> > should be written in CSS. Right now, Carlos is forced to write his
> Jewel
> > CSS using class selectors. I would really like to be able to change
> that to
> > type selectors and declaring the selectors in the manifest would
> enable
> > that.
> >
> > This might be something I could work on, but I’d likely need
> direction.
> >
> > Thanks,
> > Harbs
> >
> > > On Jun 6, 2018, at 6:33 PM, Alex Harui 
> wrote:
> > >
> > > This just seems like too much work for the hopefully seldom case of
> > mixing TLC's from various component sets.  Remember that in
> "Terminology
> > and Concepts", the TLC's are just collections of beads.  There
> should be
> > little dependencies of the beads on the host strand.  Folks should
> be able
> > to break any TLC into its "exploded component".
> > >
> > > There should be so little code in a TLC, that there really
> shouldn't be
> > much advantage to having a TLC in one component set subclass a TLC in
> > another component.  The big re-use of code should come from
> subclassing and
> > aggregating beads and reusing utility functions.
> > >
> > > Any manually controlled naming scheme just sets up another place
> for
> > mistakes and collisions.  I think there are many more important
> things for
> > us to work on, like getting the emulation components to run.
> > >
> > > My 2 cents,
> > > -Alex
> > >
> > > On 6/6/18, 12:28 AM, "Harbs"  wrote:
> > >
> > >While I was trying to figure out how the compiler handles CSS,
> a new
> > idea came to me which I think is better than

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

IMO, the thing that will have the greatest impact on whether Adobe will 
continue to pay me to work full time on Royale is how many active users we have 
at the end of the year, not whether we have a really cool way of avoiding type 
selector name collisions.  So I am asking folks to consider that we may be 
better off just getting things to work for more users instead of taking longer 
to make them perfect for one.  And that's why emulation components are my 
highest priority.

My 2 more cents,
-Alex

On 6/6/18, 9:37 AM, "Carlos Rovira"  wrote:

I think as well this is important. Very important. We must notice that we
are a multidisciplinar team and we must take advantage of that making each
one work in the areas where they get the most of it. I think if Harbs wants
to make this happen, I think he should do that. For needs, I think MX
emulation is important, but not more or less than get this solve as well.
Think that, for example, in my case or in Harbs case, probably will not use
MX emulation at all, while others will use it. In the other part, we'll
make heavy use of that feature.

I already said this, I thought as well on "typeNames" problem of hardcode
in a class, as when I see in a class hardcoded styles...I see many problems
in those kind of things, so taking the time and energy to solve it, I think
is a time well invested.

My 2...

Thanks



2018-06-06 18:26 GMT+02:00 Harbs :

> > This just seems like too much work for the hopefully seldom case of
> mixing TLC's from various component sets.
>
> Well, I am already doing that… Maybe I’m the exception, but it’s not a
> theoretical need. ;-)
>
> It also would enable us to use Basic and Express TLCs in Jewel — without
> subclassing at all.
>
> There’s a bigger picture aspect of this as well which is probably most
> important. It would enable component sets to declare how their typenames
> should be written in CSS. Right now, Carlos is forced to write his Jewel
> CSS using class selectors. I would really like to be able to change that 
to
> type selectors and declaring the selectors in the manifest would enable
> that.
>
> This might be something I could work on, but I’d likely need direction.
>
> Thanks,
> Harbs
>
> > On Jun 6, 2018, at 6:33 PM, Alex Harui  wrote:
> >
> > This just seems like too much work for the hopefully seldom case of
> mixing TLC's from various component sets.  Remember that in "Terminology
> and Concepts", the TLC's are just collections of beads.  There should be
> little dependencies of the beads on the host strand.  Folks should be able
> to break any TLC into its "exploded component".
> >
> > There should be so little code in a TLC, that there really shouldn't be
> much advantage to having a TLC in one component set subclass a TLC in
> another component.  The big re-use of code should come from subclassing 
and
> aggregating beads and reusing utility functions.
> >
> > Any manually controlled naming scheme just sets up another place for
> mistakes and collisions.  I think there are many more important things for
> us to work on, like getting the emulation components to run.
> >
> > My 2 cents,
> > -Alex
> >
> > On 6/6/18, 12:28 AM, "Harbs"  wrote:
> >
> >While I was trying to figure out how the compiler handles CSS, a new
> idea came to me which I think is better than any of the ideas we had until
> now (if I might say so myself). ;-p
> >
> >Basically, we can just use the component manifest file.
> >
> >One of the issues I was struggling with is that if the type selector
> is defined and hard-coded in the component class, that very much limits 
how
> other component sets can use the component. I think this is part of what
> was bothering Carlos as well.
> >
> >By adding a new attribute to components, I think we can solve this
> problem very nicely. For example in express-manifest:
> > lookupOnly="true" typeNames=".express.Button”/>
> >
> >Would define that any express|Button (used in an express namespace)
> should be written with a selector of “.express.Button”. That is even if 
the
> class is the same as one used by a different component set.
> >
> >Of course, of that to work, the correct typeNames need to be assigned
> to the classes. I think that could be defined in the CSS:
> >
> >Button{
> >   TypeNames: “.express.Button”;
> >}
> >
> >Of course, this would require using ValuesManager to look up the
> classNames for the component (i.e. this.typeNames =
> ValuesManager.valuesImpl.getValue(this, "typeNames") as String), so it’s
> not completely PAYG.
> >
> >I would suggest for this one of a few

Re: Problem with Debugger in VSCode

2018-06-06 Thread Josh Tynjala

You might be running into this issue (Debugger will not stop at breakpoints on 
startup with Apache Royale):

https://github.com/BowlerHatLLC/vscode-nextgenas/wiki/Common-issues#debugger-will-not-stop-at-breakpoints-on-startup-with-apache-royale

It seems like VSCode can't connect with the browser's debugger protocol fast 
enough to register the breakpoint before the startup code has already finished 
running.

A good way to check if you're running into this issue is to add some kind of 
click listener with a breakpoint. By the time you can interact with the app, 
the debugger should be fully connected.

- Josh

On 2018/06/05 19:50:40, 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: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

FTR, in the other thread about package names, I do not agree that Jewel must 
re-use or subclass Basic or Express TLCs.  The main point of code re-use is in 
the beads.  Express can certainly subclass Basic TLCs as its goal is to 
pre-aggregate Basic beads.  But, IMO, Jewel doesn't have to subclass Basic 
TLCs.  That decision should be factor in code reuse, but also complexity of the 
CSS.

On 6/6/18, 9:27 AM, "Harbs"  wrote:

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

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

How did you work around the collision problem?

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

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

I guess I don't understand why Carlos has to use class selectors and not type 
selectors in Jewel.

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

IMO, I would much rather everyone devote time to getting the emulation 
components up and running and seeing if we can get the Starling folks to use 
Royale.  I think we have simple solutions to Type Selector name collisions that 
won't be as hard to implement, like a simple shortname map of package names to 
something shorter.

My 2 cents,
-Alex

Thanks,
Harbs

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

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

I think as well this is important. Very important. We must notice that we
are a multidisciplinar team and we must take advantage of that making each
one work in the areas where they get the most of it. I think if Harbs wants
to make this happen, I think he should do that. For needs, I think MX
emulation is important, but not more or less than get this solve as well.
Think that, for example, in my case or in Harbs case, probably will not use
MX emulation at all, while others will use it. In the other part, we'll
make heavy use of that feature.

I already said this, I thought as well on "typeNames" problem of hardcode
in a class, as when I see in a class hardcoded styles...I see many problems
in those kind of things, so taking the time and energy to solve it, I think
is a time well invested.

My 2...

Thanks



2018-06-06 18:26 GMT+02:00 Harbs :

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

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

Harbs is proposing that, like border-box, we apply position:relative to all 
elements in the DOM.  My understanding is that you can do that via:

.Application * {
position: relative;
   }

If it has zero impact on Jewel's use of flexbox then I think it is safe to use. 
 I just want to make sure folks won't be wanting to turn that off at some point.

Another area of concern is in encapsulating existing DOM patterns.  When folks 
want to make existing JS frameworks work in Royale, they may want to copy code 
from those JS frameworks and wrap them in Royale classes.  But if the code they 
borrow did not assume that all elements had position:relative, the copied code 
may not work correctly.  That's why the application of PAYG principles, IMO, is 
to only apply it to the parent containers that need it, even though that runs a 
bit more code to do that.  Setting position:relative "just-in-case" someone 
needs to use x,y is not PAYG, IMO.

My 2 cents,
-Alex

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

Hi Alex

2018-06-06 17:23 GMT+02:00 Alex Harui :

> This sounds scary to me because it affects the entire DOM, and not very
> PAYG.  Maybe Carlos should try it on his Jewel layouts and see if anything
> breaks.
>

What you refer exactly to try? let me know to do it .

-- 
Carlos Rovira

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C29273bf16fa1457dc71a08d5cbc777a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636638979924029830=77fNpWL%2FJwcjHJCRD4a%2BZARrUeHPTLSnLABXoGcS1I8%3D=0

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

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

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

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

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

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

Thanks,
Harbs

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

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

I'm all for this kind of changes. Things should be as easy and straight
forward as possible, so if we can simplify something to get the same, this
is better. And we are still on 0.9.x so is not something we *can* do, is
something we *must* do if it enhances the overall solution and is possible.
I think the proposed branch is the best way to go to know exactly what is
needed. But in theory sounds good to me.

thanks


2018-06-06 18:05 GMT+02:00 Harbs :

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

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

Hi Alex

2018-06-06 17:23 GMT+02:00 Alex Harui :

> This sounds scary to me because it affects the entire DOM, and not very
> PAYG.  Maybe Carlos should try it on his Jewel layouts and see if anything
> breaks.
>

What you refer exactly to try? let me know to do it .


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

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

> ... and not very PAYG.

On the contrary.

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

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

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

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

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

This just seems like too much work for the hopefully seldom case of mixing 
TLC's from various component sets.  Remember that in "Terminology and 
Concepts", the TLC's are just collections of beads.  There should be little 
dependencies of the beads on the host strand.  Folks should be able to break 
any TLC into its "exploded component".

There should be so little code in a TLC, that there really shouldn't be much 
advantage to having a TLC in one component set subclass a TLC in another 
component.  The big re-use of code should come from subclassing and aggregating 
beads and reusing utility functions.

Any manually controlled naming scheme just sets up another place for mistakes 
and collisions.  I think there are many more important things for us to work 
on, like getting the emulation components to run.

My 2 cents,
-Alex

On 6/6/18, 12:28 AM, "Harbs"  wrote:

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

Basically, we can just use the component manifest file.

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

By adding a new attribute to components, I think we can solve this problem 
very nicely. For example in express-manifest:
 On Jun 1, 2018, at 9:25 AM, Alex Harui  wrote:
> 
> OK, then I think we are on roughly the same page.  Earlier I proposed a 
map of package names to short names.  However, I just realized that it needs to 
be a map of MXML namespaces to short names, and metadata won't work because I 
think the rules get chosen by MXML namespace instead of package names because 
you can map the same class into different MXML namespaces.  If you want to map 
"library://ns.apache.org/jewel " to ".jewel." it 
would have the desired result.
> 
> My 2 cents,
> -Alex
> 
> On 5/30/18, 11:58 PM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
> 
>I’m not talking about solving subclassing here.
> 
>I’m talking about one thing: How to determine what classnames the 
compiler writes to HTML CSS files for specific types.
> 
>Carlos and I would both like for the compiler to compile:
>j|Button{
>   background-color: #fff;
>}
> 
>To: 
>.jewel.Button{
>   background-color: #fff;
>}
> 
>Rather than:
>org_apache_royale_jewel_Button{
>   background-color: #fff;
>}
> 
>And we all agree that we don’t want:
>.Button{
>   background-color: #fff;
>}
> 
>The question is how to accomplish that. We’re suggesting to include 
some kind of meta tag or comment in the Button class source which acts as a 
compiler directive to specify exactly what to output. If you have another 
suggestion on how we can achieve that goal, that’s fine too.
> 
>Makes sense?
>Harbs
> 
>> On May 31, 2018, at 12:30 AM, Alex Harui  
wrote:
>> 
>> There has always been an option to keep/strip metadata in the output.  
It is -compiler.keep-as3-metadata.
>> 
>> I don't think I understand what you are proposing with metadata.  I 
thought I'd shown that there was no easy way to solve what the runtime 
(ValuesManager) should do. I thought we'd agreed upthread that metadata was not 
required, and we would decide on some short-name abbreviations based on the 
fully qualified names (package and class name).   The abbreviation scheme 
doesn't have to be perfect, as long as it reduces likelihood of collision at 
very low cost.  An example might be that you can register abbreviation mappings 
so we say that "oarh" is short for "org.apache.royale.html".
>> 
>> Thoughts?
>> -Alex
>> 
>> On 5/29/18, 5:47 AM, "Harbs" mailto:harbs.li...@gmail.com> >> 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.
>>

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

This sounds scary to me because it affects the entire DOM, and not very PAYG.  
Maybe Carlos should try it on his Jewel layouts and see if anything breaks.

Some other implementation options would be to:

-Have the x,y setters set position on the parent.  I think we used to do this 
and decided to not do it anymore
-Have the x,y setters add a class selector to the parent.
-Have a bead, like we've discussed for UnselectableElement, that brings in the 
selector.
-Have the layouts that allow for absolute positioning set the right styles or 
selector on the parent.

My 2 cents,
-Alex

On 6/5/18, 11:44 PM, "Harbs"  wrote:

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

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

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

Harbs

> On Jun 5, 2018, at 8:00 AM, Alex Harui  wrote:
> 
> Ah, ok.  How would a user disable that selector in case it did something 
undesirable?
> 
> -Alex
> 
> On 6/4/18, 1:56 PM, "Harbs"  wrote:
> 
>Sorry I was a bit confused. The selector that works is:
> 
>.Application * {
>   position: relative;
>}
> 
>> On Jun 4, 2018, at 11:32 PM, Harbs  wrote:
>> 
>> Yes. But it cascades down.
>> 
>> I manually made this change to the TreeExample project, and it fixed the 
bug.
>> 
>>> On Jun 4, 2018, at 7:22 PM, Alex Harui  wrote:
>>> 
>>> I'm still not understanding.  Style.position is not inheriting so how 
would it cascade down?  Isn't .Application only applied to the ?
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 6/4/18, 9:15 AM, "Harbs"  wrote:
>>> 
>>>  I’m suggesting that we change defaults.css
>>> 
>>>  from:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>>  }
>>> 
>>>  to:
>>>  Application
>>>  {
>>> padding: 0px;
>>> margin: 0px;
>>> position: relative;
>>>  }
>>> 
>>>  I believe this will resolve this issue as the default would cascade 
down to all sub-elements. The default would be relative, but beads would be 
free to change that to whatever they want.
>>> 
>>>  Of course, that would dictate that UIBase belongs in Basic and not 
Core… ;-)
>>> 
>>>  Harbs
>>> 
 On Jun 4, 2018, at 7:10 PM, Alex Harui  
wrote:

 I’m not sure exactly what change you are proposing, but UIBase used to 
set position=relative on all positioners.  We took that away so that the "flex" 
and other display/layout styles would not have to deal with the excess clutter 
and overhead of having set position on so many elements in the DOM.  Via PAYG, 
only the elements that need to have a style.position should have it set.

 My 2 cents,
 -Alex

 On 6/4/18, 8:44 AM, "Harbs"  wrote:

 It just occurred to me that the 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.
>

Re: Incorrect descendent CSS output

I must say I don't remember exactly. I did many test and research and
compare with what others trying to solve the same in the internet without
using a concrete library that at that time I think we want to avoid. So you
can try to compile with and without and use a compare tool to see what you
get and maybe that show the intention of the regex . Maybe it make some
little improvement, but if it remove something, better remove it.

2018-06-06 14:48 GMT+02:00 Harbs :

> I understand, but I’m trying to understand what the logic of that line of
> code was. What was it trying to do?
>
> I could simply remove the line, but if it’s serving a function, we should
> probably fix the RegEx instead.
>
> Thanks,
> Harbs
>
> > On Jun 6, 2018, at 3:36 PM, Carlos Rovira 
> wrote:
> >
> > Hi Harbs,
> >
> > that was a simple attempt to minify css code, if that line is not working
> > you can comment it, and we'll be improving the minifying method.
> >
> > thanks
> >
> >
> >
> > 2018-06-06 14:27 GMT+02:00 Harbs :
> >
> >> It’s this code in minifyCSSString:
> >>cssString = cssString.replaceAll("[a-zA-Z]+#", "#");
> >>
> >> Why is that code there?
> >>
> >> Harbs
>
>

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

Re: Incorrect descendent CSS output

I understand, but I’m trying to understand what the logic of that line of code 
was. What was it trying to do?

I could simply remove the line, but if it’s serving a function, we should 
probably fix the RegEx instead.

Thanks,
Harbs

> On Jun 6, 2018, at 3:36 PM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> that was a simple attempt to minify css code, if that line is not working
> you can comment it, and we'll be improving the minifying method.
> 
> thanks
> 
> 
> 
> 2018-06-06 14:27 GMT+02:00 Harbs :
> 
>> It’s this code in minifyCSSString:
>>cssString = cssString.replaceAll("[a-zA-Z]+#", "#");
>> 
>> Why is that code there?
>> 
>> Harbs

Re: Incorrect descendent CSS output

Hi Harbs,

that was a simple attempt to minify css code, if that line is not working
you can comment it, and we'll be improving the minifying method.

thanks



2018-06-06 14:27 GMT+02:00 Harbs :

> It’s this code in minifyCSSString:
> cssString = cssString.replaceAll("[a-zA-Z]+#", "#");
>
> Why is that code there?
>
> Harbs
>
> > On Jun 6, 2018, at 3:21 PM, Harbs  wrote:
> >
> > I found another problem.
> >
> > The following CSS is the correct compiled results in the debug css:
> >
> >
> > .toggleTextButton.selected#subscriptButton {
> >cursor: pointer;
> >background-color: transparent;
> >outline: none;
> >background-image: url("assets/images/icons/
> subscript_selected.svg");
> >border-style: hidden;
> > }
> >
> >
> > .toggleTextButton#subscriptButton {
> >cursor: pointer;
> >background-color: transparent;
> >outline: none;
> >background-image: url("assets/images/icons/subscript.svg");
> >border-style: hidden;
> > }
> >
> > Somehow in the release version, the CSS becomes the following: The class
> selector before the subscriptButton id selector gets lost after the dot.
> Any idea what might be causing it?
> >
> > .toggleTextButton.#subscriptButton{cursor:pointer;background-color:
> transparent;outline:none;background-image:url("assets/
> images/icons/subscript_selected.svg");border-style:
> hidden;}.#subscriptButton{cursor:pointer;background-
> color:transparent;outline:none;background-image:url("
> assets/images/icons/subscript.svg");border-style:hidden;}
> >
> >> On Jun 6, 2018, at 2:24 AM, Alex Harui 
> wrote:
> >>
> >> 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
> >
> >
> 
> 
> 
> >>>
> >>
> >>
> >>
> >
>
>


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

Re: Incorrect descendent CSS output

It’s this code in minifyCSSString:
cssString = cssString.replaceAll("[a-zA-Z]+#", "#");

Why is that code there?

Harbs

> On Jun 6, 2018, at 3:21 PM, Harbs  wrote:
> 
> I found another problem.
> 
> The following CSS is the correct compiled results in the debug css:
> 
> 
> .toggleTextButton.selected#subscriptButton {
>cursor: pointer;
>background-color: transparent;
>outline: none;
>background-image: url("assets/images/icons/subscript_selected.svg");
>border-style: hidden;
> }
> 
> 
> .toggleTextButton#subscriptButton {
>cursor: pointer;
>background-color: transparent;
>outline: none;
>background-image: url("assets/images/icons/subscript.svg");
>border-style: hidden;
> }
> 
> Somehow in the release version, the CSS becomes the following: The class 
> selector before the subscriptButton id selector gets lost after the dot. Any 
> idea what might be causing it?
> 
> .toggleTextButton.#subscriptButton{cursor:pointer;background-color:transparent;outline:none;background-image:url("assets/images/icons/subscript_selected.svg");border-style:hidden;}.#subscriptButton{cursor:pointer;background-color:transparent;outline:none;background-image:url("assets/images/icons/subscript.svg");border-style:hidden;}
> 
>> On Jun 6, 2018, at 2:24 AM, Alex Harui  wrote:
>> 
>> 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

I found another problem.

The following CSS is the correct compiled results in the debug css:


.toggleTextButton.selected#subscriptButton {
cursor: pointer;
background-color: transparent;
outline: none;
background-image: url("assets/images/icons/subscript_selected.svg");
border-style: hidden;
}


.toggleTextButton#subscriptButton {
cursor: pointer;
background-color: transparent;
outline: none;
background-image: url("assets/images/icons/subscript.svg");
border-style: hidden;
}

Somehow in the release version, the CSS becomes the following: The class 
selector before the subscriptButton id selector gets lost after the dot. Any 
idea what might be causing it?

.toggleTextButton.#subscriptButton{cursor:pointer;background-color:transparent;outline:none;background-image:url("assets/images/icons/subscript_selected.svg");border-style:hidden;}.#subscriptButton{cursor:pointer;background-color:transparent;outline:none;background-image:url("assets/images/icons/subscript.svg");border-style:hidden;}

> On Jun 6, 2018, at 2:24 AM, Alex Harui  wrote:
> 
> 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
 
 
>>> 
>>> 
>>> 
>> 
> 
> 
>

Promoting Apache Royale on Facebook

Hi,

just let you know that we're promoting Apache Royale on Facebook:

https://www.facebook.com/ApacheRoyaleSDK/videos/360747917782110/

Please join us there and share your love! :)

Thanks!

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

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

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

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

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

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

HTH,
Harbs

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

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

Hi Harbs,

I reach to the same conclusion that "typeNames" set in the class code is
not the best way to go, and not PAYG. A rule to follow should be that TLCs
and other classes should never hardcode anything about layout, positioning,
styles or classNames. So I think your strategy is good in concept, and
maybe in the planned inmplementation, I'm seeing some things that maybe
could not work:

Button{
   TypeNames: “.jewel.button”;
}

should not be?

Button{
   TypeNames: “jewel button”;
}

For implementation, I think #3 should be better, since is more PAYG, and we
should have probably an extension of UIBase (somewhat "StyledUIBase" or
whatever), so Basic should continue using UIBase, but Jewel is using some
variables and methods in *all* components that should go to and
intermediate class  UIBase -> StyledUIBase -> Button (Jewel), and in
StyledUIBase we can implement what you say. I was planning to make
StyledUIBase soon (is what we called JewelUIBase in other discussion some
months ago), and will have mainly the protected var classSelectorList the
override to setClassName that are things that are in all jewel controls and
components, so to this we can add the setTypeNames as well and I think it
would be ok that UI sets that will be more "Visual" attractive use this
instead of its UIBase superclass.

Thoughts?

Carlos

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



2018-06-06 9:28 GMT+02:00 Harbs :

> While I was trying to figure out how the compiler handles CSS, a new idea
> came to me which I think is better than any of the ideas we had until now
> (if I might say so myself). ;-p
>
> Basically, we can just use the component manifest file.
>
> One of the issues I was struggling with is that if the type selector is
> defined and hard-coded in the component class, that very much limits how
> other component sets can use the component. I think this is part of what
> was bothering Carlos as well.
>
> By adding a new attribute to components, I think we can solve this problem
> very nicely. For example in express-manifest:
>  lookupOnly="true" typeNames=".express.Button”/>
>
> Would define that any express|Button (used in an express namespace) should
> be written with a selector of “.express.Button”. That is even if the class
> is the same as one used by a different component set.
>
> Of course, of that to work, the correct typeNames need to be assigned to
> the classes. I think that could be defined in the CSS:
>
> Button{
>TypeNames: “.express.Button”;
> }
>
> Of course, this would require using ValuesManager to look up the
> classNames for the component (i.e. this.typeNames =
> ValuesManager.valuesImpl.getValue(this, "typeNames") as String), so it’s
> not completely PAYG.
>
> I would suggest for this one of a few of courses of action:
>
> 1. We could create a protected setTypeNames method in UIBase which would
> be virtual and overridden by subclasses to either write the typeNames
> directly or use the ValuesManager.
> 2. We could create a protected setTypeNames method in UIBase which uses
> the ValuesManager by default and the subclasses would only override the
> method if they want to set it directly.
> 3. We do nothing in UIBase, and each component decides whether to
> implement a protected setTypeNames method (or similar) which could work in
> one of the two aforementioned ways.
>
> #3 is the most PAYG.
> #2 is the least PAYG, but the most DRY. According to Royale principles, it
> would generally not be the way we’d go, but I would prefer it because it
> gives the most predictable behavior in terms of declarable CSS. TypeNames
> is also pretty “Core” to Royale component sets, so it’s somewhat
> appropriate. It also allows users to remove default CSS selectors from
> specific components should they choose to do so.
>
> Thoughts?
> Harbs
>
> > On Jun 1, 2018, at 9:25 AM, Alex Harui  wrote:
> >
> > OK, then I think we are on roughly the same page.  Earlier I proposed a
> map of package names to short names.  However, I just realized that it
> needs to be a map of MXML namespaces to short names, and metadata won't
> work because I think the rules get chosen by MXML namespace instead of
> package names because you can map the same class into different MXML
> namespaces.  If you want to map "library://ns.apache.org/jewel  ns.apache.org/jewel>" to ".jewel." it would have the desired result.
> >
> > My 2 cents,
> > -Alex
> >
> > On 5/30/18, 11:58 PM, "Harbs"  harbs.li...@gmail.com>> wrote:
> >
> >I’m not talking about solving subclassing here.
> >
> >I’m talking about one thing: How to determine what classnames the
> compiler writes to HTML CSS files for specific types.
> >
> >Carlos and I would both like for the compiler to compile:
> >j|Button{
> >   background-color: #fff;
> >}
> >
> >To:
> >.jewel.Button{
> >   background-color: #fff;
> >}
> >
> >Rather than:
> >

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

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

It prevents a lot of the reflowing problems.

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

Harbs

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

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

Hi Yishay,
maybe mixing topics, but I only showing how I'm solving in jewel layouts.
Why I'm creating new layouts? since I see many problems with mixing layout
types (display: block, in other cases flex...), and seems inconsistent, so
I'm trying to base all in Jewel in only one system. Flexbox is not the best
(I think Grid would be better), but is supported in IE11, so is the middle
point right now.
A secondary motive was to get rid of JS loops or processing when possible,
since layout and positioning nowadays is done completely in CSS, so Jewel
layout has (for now), SWF code like in basic (can change when I reach to
focus more on SWF part), but JS is turning to use only CSS class selectors,
so the browsers handle all positioning. The work is still in progress, for
now I get IE11 working again and things positioning right in all browsers,
that is by itself a huge improvement over the jewel layout classes that we
had some days ago. As Harbs said a collateral effect of all of this (but
not a main one) is that we should end with "styles" set in HTML, or at
least only use that if we want to make some dynamic change at runtime.

2018-06-06 7:52 GMT+02:00 Yishay Weiss :

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

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

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

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

Basically, we can just use the component manifest file.

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

By adding a new attribute to components, I think we can solve this problem very 
nicely. For example in express-manifest:
 On Jun 1, 2018, at 9:25 AM, Alex Harui  wrote:
> 
> OK, then I think we are on roughly the same page.  Earlier I proposed a map 
> of package names to short names.  However, I just realized that it needs to 
> be a map of MXML namespaces to short names, and metadata won't work because I 
> think the rules get chosen by MXML namespace instead of package names because 
> you can map the same class into different MXML namespaces.  If you want to 
> map "library://ns.apache.org/jewel " to 
> ".jewel." it would have the desired result.
> 
> My 2 cents,
> -Alex
> 
> On 5/30/18, 11:58 PM, "Harbs"  > 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" >  > >> 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

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