Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Carlos Rovira]

Great Josh!, this sounds like a solution! Hope Harbs or Piotr can try this
and report if is working! :)

2018-05-19 0:38 GMT+02:00 Josh Tynjala :

> Please forgive me if I'm missing some context because I'm just skimming
> through here. However, I think I may be able to offer a suggestion.
>
> Is the absolute path a location inside the the Royale SDK? If so, then you
> can use the ${royalelib} token to refer to the path relative to the SDK's
> *frameworks* directory. The Royale compiler knows how to resolve a path
> based on this token.
>
> For other SDKs, there's a similar ${flexlib} token. For the example themes
> included with the Feathers SDK, I've successfully used ${flexlib} to add a
> SWC to my project in *asconfig.json* without needing an absolute path:
>
> "library-path": ["${flexlib}/themes/MetalWorksDesktopTheme/
> MetalWorksDesktopTheme.swc"]
>
> A while back, I made sure that the ${royalelib} and ${flexlib} tokens both
> work in VSCode.
>
> - Josh
>
> On 2018/05/18 13:05:34, Harbs  wrote:
> > No. Specifying the themes seems to be a major problem.
> >
> > It’s possible to specify a theme using additional compiler options in
> asconfig, but I’m not prepared to specify an absolute path. This needs a
> solution…
> >
> > Harbs
> >
> > > On May 18, 2018, at 3:56 PM, Piotr Zarzycki 
> wrote:
> > >
> > > Hi Harbs,
> > >
> > > Were you able to setup project in IDE ?
> > >
> > > Thanks,
> > > Piotr
> > >
> > > 2018-05-17 15:13 GMT+02:00 Carlos Rovira :
> > >
> > >> Look foro "Inject a Font"
> > >>
> > >> 2018-05-17 15:12 GMT+02:00 Harbs :
> > >>
> > >>> What was the subject?
> > >>>
> >  On May 17, 2018, at 4:08 PM, Carlos Rovira  >
> > >>> wrote:
> > 
> >  Hi,
> > 
> >  I think seems something valid, maybe we should think more about
> > >> possible
> >  colateral issue of that method. You should look as well at a thread
> > >> where
> >  Alex proposed as well some valid options
> > 
> >  2018-05-17 15:04 GMT+02:00 Harbs :
> > 
> > > I just had another thought which might be even more flexible:
> > >
> > > Maybe the compile could parse @includes from CSS and insert them as
> > >>> links
> > > in the header HTML automatically.
> > >
> > > Thanks,
> > > Harbs
> > >
> > >> On May 17, 2018, at 3:52 PM, Carlos Rovira <
> carlosrov...@apache.org>
> > > wrote:
> > >>
> > >>>
> > >>> Another angle on this problem might be to allow adding links via
> the
> > >>> compiler automatically. Not sure exactly what form that might
> take
> > > though.
> > >>>
> > >>>
> > >> This was something Alex propose, something in the line of @media
> > >> -royale-swf, but with fonts, I think that is the right way.
> > >> For now we can stick with the html template but that should be
> > >>> temporal.
> > >
> > >
> > 
> > 
> >  --
> >  Carlos Rovira
> >  http://about.me/carlosrovira
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >> Carlos Rovira
> > >> http://about.me/carlosrovira
> > >>
> > >
> > >
> > >
> > > --
> > >
> > > Piotr Zarzycki
> > >
> > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > *
> >
> >
>



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

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

[Alex Harui]

On 5/18/18, 2:50 AM, "Harbs"  wrote:
And basic.css has:
RadioButton
{
font-size: 12px;
font-family: sans-serif;
}

RadioButton is a Royale Type Selector as it should be. No discussion on 
that front (with the exception that the styling should be removed from the 
defaults.css).

Te whole question is what happens in MyApp.css which is compiled standard 
HTML CSS.

Currently we get:

.RadioButton {
font-family: sans-serif;
font-size: 12px;
}

This CSS comes from the Type Selector in basic.css. This seems to be 
included in the app.css even if RadioButton is not included. But putting that 
point aside at the moment, the question is what the class selector (in app.css) 
should be *produced* from the type selector.
   
It is not obvious why RadioButton is in the app.css.  This might be a new bug 
from the theme handling I did recently.  I will investigate more.
 
I think we agree that “.RadioButton" is not right because there can be 
RadioButton from more than one component set.

One option is to fully qualify the *compiled* class selector so it’s named 
“.org_apache_royale_html_RadioButton”. I’m pretty sure this is what you are 
proposing. The primary objection to that is that it’s a rather long string and 
kind of “ugly”.

You can choose other string transformations, but the key point is that they 
should be derived from the unique QName.  Any other scheme just means that the 
developer has to solve the unique name problem twice which increases the chance 
of collision.

Another option is “.basic.Button”. The advantage of this approach is mostly 
aesthetics. It also has the advantage of being theoretically more flexible 
because CSS can be applied to “basic" and “Button” separately. Of course that 
goes both ways and if there’s css applied to “.Button” by mistake, it can 
effect the “basic” Button where it’s not supposed to.

I'm not clear how the compiler or the ValuesManager (at runtime) can 
efficiently associate .basic.Button with org.apache.royale.basic.Button.  
Metadata lookups can be expensive.


> If one problem is with Type Selectors in Royale inheriting styles from 
Base Classes, we should discuss ways to manage that.  Metadata is possible, but 
metadata is expensive at runtime.

Good point about extra code from meta tags. Maybe the compiler could strip 
these out?

My point is that ValuesManager will need this information at runtime.

My suggestion with meta-data was a way to enable the second option. It does 
not need to be specifically meta-tags. It could be something like this as well:

/**
* royaleclassselector RadioButton
* royaleclassprefix basic
* royaleinheritsbaseselector
*/

These ASDoc directives are definitely not available at runtime.


> There are two parts to how Type Selectors work.  The main concern appears 
to be the ClassReferences kind of CSS, which is not handled by the Browser.  
The IValuesImpl has to decide whether to look up the base class and it would 
have to fetch and parse metadata at runtime to do that.  And, as I mentioned 
earlier, I'm not sure the compiler can know whether the base class is in the 
output because it was directly instantiated or not.

I’m not sure how the IValuesImpl actually works, so I have no thoughts on 
this front. I’m not clear on whether there is currently an issue with that. 
I’ve been discussing plain CSS which *is* handled by the browser.

> Historically, the only reason Type Selectors inherit from Base Classes in 
Flex is because of app developer subclassing.  For sure, we the framework 
developers can always take the time to fill out the Type Selectors such that 
the lookup never goes to the Base Class.  But the app devs just want to use a 
component as the top tag in an MXMLComponent or do a cheap "MyButton extends 
Button" in AS.  And without inheritance, you don't get any defaults and things 
blow up.
> 
> We could say to the app devs::  "too bad, in Royale you gotta copy the 
base class type selector".   I would imagine non-Royale folks have to copy HTML 
Type Selectors in some cases already.
> 
> We could try to find all subclasses of classes that have Type Selectors 
that don't have their own Type Selector and have the compiler auto-copy that 
base class Type Selector (or add the subclass to the list of classes for that 
selector.

I think we *should* have inheritance (like we have today) unless a subclass 
specifically disables it using metadata or what-have-you.


Let's try some example code:


  

 
 
   
  


Button will be linked in because ComboBox composites a Button.  It will also be 
linked in because RadioButton subclasses Button.  There is code in IValuesImpls 
that loop through the base classes to resolve Type Selector inheritance.  
Roughly:

Var 

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Josh Tynjala]

Please forgive me if I'm missing some context because I'm just skimming through 
here. However, I think I may be able to offer a suggestion.

Is the absolute path a location inside the the Royale SDK? If so, then you can 
use the ${royalelib} token to refer to the path relative to the SDK's 
*frameworks* directory. The Royale compiler knows how to resolve a path based 
on this token.

For other SDKs, there's a similar ${flexlib} token. For the example themes 
included with the Feathers SDK, I've successfully used ${flexlib} to add a SWC 
to my project in *asconfig.json* without needing an absolute path: 

"library-path": 
["${flexlib}/themes/MetalWorksDesktopTheme/MetalWorksDesktopTheme.swc"]

A while back, I made sure that the ${royalelib} and ${flexlib} tokens both work 
in VSCode.

- Josh

On 2018/05/18 13:05:34, Harbs  wrote: 
> No. Specifying the themes seems to be a major problem.
> 
> It’s possible to specify a theme using additional compiler options in 
> asconfig, but I’m not prepared to specify an absolute path. This needs a 
> solution…
> 
> Harbs
> 
> > On May 18, 2018, at 3:56 PM, Piotr Zarzycki  
> > wrote:
> > 
> > Hi Harbs,
> > 
> > Were you able to setup project in IDE ?
> > 
> > Thanks,
> > Piotr
> > 
> > 2018-05-17 15:13 GMT+02:00 Carlos Rovira :
> > 
> >> Look foro "Inject a Font"
> >> 
> >> 2018-05-17 15:12 GMT+02:00 Harbs :
> >> 
> >>> What was the subject?
> >>> 
>  On May 17, 2018, at 4:08 PM, Carlos Rovira 
> >>> wrote:
>  
>  Hi,
>  
>  I think seems something valid, maybe we should think more about
> >> possible
>  colateral issue of that method. You should look as well at a thread
> >> where
>  Alex proposed as well some valid options
>  
>  2018-05-17 15:04 GMT+02:00 Harbs :
>  
> > I just had another thought which might be even more flexible:
> > 
> > Maybe the compile could parse @includes from CSS and insert them as
> >>> links
> > in the header HTML automatically.
> > 
> > Thanks,
> > Harbs
> > 
> >> On May 17, 2018, at 3:52 PM, Carlos Rovira 
> > wrote:
> >> 
> >>> 
> >>> Another angle on this problem might be to allow adding links via the
> >>> compiler automatically. Not sure exactly what form that might take
> > though.
> >>> 
> >>> 
> >> This was something Alex propose, something in the line of @media
> >> -royale-swf, but with fonts, I think that is the right way.
> >> For now we can stick with the html template but that should be
> >>> temporal.
> > 
> > 
>  
>  
>  --
>  Carlos Rovira
>  http://about.me/carlosrovira
> >>> 
> >>> 
> >> 
> >> 
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >> 
> > 
> > 
> > 
> > -- 
> > 
> > Piotr Zarzycki
> > 
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > *
> 
> 

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Carlos Rovira]

what was the way FlashBuilder or IntelliJ work about this?
I assume that if Maven is using this is since the compiler supports it, so
-theme should work, and IDEs should leverage that compiler argument.
Hope Alex could throw some light on this, I remember he tries Jewel some
weeks ago successfully (I think with ANT)

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

> No. Specifying the themes seems to be a major problem.
>
> It’s possible to specify a theme using additional compiler options in
> asconfig, but I’m not prepared to specify an absolute path. This needs a
> solution…
>
> Harbs
>
> > On May 18, 2018, at 3:56 PM, Piotr Zarzycki 
> wrote:
> >
> > Hi Harbs,
> >
> > Were you able to setup project in IDE ?
> >
> > Thanks,
> > Piotr
> >
> > 2018-05-17 15:13 GMT+02:00 Carlos Rovira :
> >
> >> Look foro "Inject a Font"
> >>
> >> 2018-05-17 15:12 GMT+02:00 Harbs :
> >>
> >>> What was the subject?
> >>>
>  On May 17, 2018, at 4:08 PM, Carlos Rovira 
> >>> wrote:
> 
>  Hi,
> 
>  I think seems something valid, maybe we should think more about
> >> possible
>  colateral issue of that method. You should look as well at a thread
> >> where
>  Alex proposed as well some valid options
> 
>  2018-05-17 15:04 GMT+02:00 Harbs :
> 
> > I just had another thought which might be even more flexible:
> >
> > Maybe the compile could parse @includes from CSS and insert them as
> >>> links
> > in the header HTML automatically.
> >
> > Thanks,
> > Harbs
> >
> >> On May 17, 2018, at 3:52 PM, Carlos Rovira  >
> > wrote:
> >>
> >>>
> >>> Another angle on this problem might be to allow adding links via
> the
> >>> compiler automatically. Not sure exactly what form that might take
> > though.
> >>>
> >>>
> >> This was something Alex propose, something in the line of @media
> >> -royale-swf, but with fonts, I think that is the right way.
> >> For now we can stick with the html template but that should be
> >>> temporal.
> >
> >
> 
> 
>  --
>  Carlos Rovira
>  http://about.me/carlosrovira
> >>>
> >>>
> >>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >>
> >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > *
>
>


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

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Harbs]

No. Specifying the themes seems to be a major problem.

It’s possible to specify a theme using additional compiler options in asconfig, 
but I’m not prepared to specify an absolute path. This needs a solution…

Harbs

> On May 18, 2018, at 3:56 PM, Piotr Zarzycki  wrote:
> 
> Hi Harbs,
> 
> Were you able to setup project in IDE ?
> 
> Thanks,
> Piotr
> 
> 2018-05-17 15:13 GMT+02:00 Carlos Rovira :
> 
>> Look foro "Inject a Font"
>> 
>> 2018-05-17 15:12 GMT+02:00 Harbs :
>> 
>>> What was the subject?
>>> 
 On May 17, 2018, at 4:08 PM, Carlos Rovira 
>>> wrote:
 
 Hi,
 
 I think seems something valid, maybe we should think more about
>> possible
 colateral issue of that method. You should look as well at a thread
>> where
 Alex proposed as well some valid options
 
 2018-05-17 15:04 GMT+02:00 Harbs :
 
> I just had another thought which might be even more flexible:
> 
> Maybe the compile could parse @includes from CSS and insert them as
>>> links
> in the header HTML automatically.
> 
> Thanks,
> Harbs
> 
>> On May 17, 2018, at 3:52 PM, Carlos Rovira 
> wrote:
>> 
>>> 
>>> Another angle on this problem might be to allow adding links via the
>>> compiler automatically. Not sure exactly what form that might take
> though.
>>> 
>>> 
>> This was something Alex propose, something in the line of @media
>> -royale-swf, but with fonts, I think that is the right way.
>> For now we can stick with the html template but that should be
>>> temporal.
> 
> 
 
 
 --
 Carlos Rovira
 http://about.me/carlosrovira
>>> 
>>> 
>> 
>> 
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>> 
> 
> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> *

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Piotr Zarzycki]

Hi Harbs,

Were you able to setup project in IDE ?

Thanks,
Piotr

2018-05-17 15:13 GMT+02:00 Carlos Rovira :

> Look foro "Inject a Font"
>
> 2018-05-17 15:12 GMT+02:00 Harbs :
>
> > What was the subject?
> >
> > > On May 17, 2018, at 4:08 PM, Carlos Rovira 
> > wrote:
> > >
> > > Hi,
> > >
> > > I think seems something valid, maybe we should think more about
> possible
> > > colateral issue of that method. You should look as well at a thread
> where
> > > Alex proposed as well some valid options
> > >
> > > 2018-05-17 15:04 GMT+02:00 Harbs :
> > >
> > >> I just had another thought which might be even more flexible:
> > >>
> > >> Maybe the compile could parse @includes from CSS and insert them as
> > links
> > >> in the header HTML automatically.
> > >>
> > >> Thanks,
> > >> Harbs
> > >>
> > >>> On May 17, 2018, at 3:52 PM, Carlos Rovira 
> > >> wrote:
> > >>>
> > 
> >  Another angle on this problem might be to allow adding links via the
> >  compiler automatically. Not sure exactly what form that might take
> > >> though.
> > 
> > 
> > >>> This was something Alex propose, something in the line of @media
> > >>> -royale-swf, but with fonts, I think that is the right way.
> > >>> For now we can stick with the html template but that should be
> > temporal.
> > >>
> > >>
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Harbs]

PathBuilder was designed to be drawing agnostic and the Graphics package is 
mostly interfaces. Theoretically, anything in Graphics should be usable with 
both SVG and Canvas implementations.

The org.apache.royale.svg classes are SVG implementations and can be used 
within any Royale components.

I wanted to do a canvas implementation as well, but it’s something I never got 
to. AFAIK, the only Canvas implementation in Royale is the CreateJS package.

For code with PathBuilder in use, take a look at the following TLF classes:
TextFlowLine
AdonrmentUtils
BackgroundManager

FYI, there is also logic for Transforms which work in conjunction with the 
Graphics classes.

HTH,
Harbs

> On May 18, 2018, at 3:01 PM, Carlos Rovira  wrote:
> 
> Thanks Harbs,
> 
> to understand better about the code you said, this is done creating a
> Canvas where the drawing is done? If so what is the canvas component in
> Royale?
> I'll want to try that, if there's some example code in same place, please
> let me know.
> thanks!
> 
> 2018-05-18 13:19 GMT+02:00 Harbs :
> 
>> Take a look at the Graphics package.
>> 
>> Specifically, PathBuilder lets you use commands very similar to Flash
>> drawing commands.
>> 
>> Also, CompoundGraphic in Basic offers a number of drawing commands.
>> 
>> org.apache.royale.svg (in Basic) has many basic shape types which simplify
>> drawing of those.
>> 
>> I’ve used these classes extensively, and they work very well.
>> 
>> Thanks,
>> Harbs
>> 
>>> On May 18, 2018, at 2:09 PM, Carlos Rovira 
>> wrote:
>>> 
>>> I talk about "drawing things" that was something
>>> more related to the Flash API.
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

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

[Carlos Rovira]

Hi Harbs,

2018-05-18 13:23 GMT+02:00 Harbs :

> A couple of questions/comments:
>
> > On May 18, 2018, at 1:57 PM, Carlos Rovira 
> wrote:
> >
> > One more important technical thing about that way is "verbosity" since
> each
> > time you reference that kind of class you are introducing a name that use
> > to be 2-3 time longer, each time.
>
> Are you suggesting this has performance implications? I would not have
> thought that class name length effects performance. If you have a source
> that it does, I’d be interested in hearing details.
>

No, in that point I'm talking exclusively about size, not performance here.

>
> > "My suggestion with meta-data was a way to enable the second option. It
> > does not need to be specifically meta-tags. It could be something like
> this
> > as well:
> >
> > /**
> > * royaleclassselector RadioButton
> > * royaleclassprefix basic
> > * royaleinheritsbaseselector
> > */
> > "
> > I still prefers the [] format since is more concise and I think is more
> > suited for this particular purpose.
>
> I agree that the bracketed format is “prettier”, but I could live with
> either.
>

Right, since I was talking that Metadata in this concrete use will not have
performance problems like Alex suggested, and you propose this other way
due to the possible performance problems, I think is better to return to
normal metadata discussion.

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

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Carlos Rovira]

Thanks Harbs,

to understand better about the code you said, this is done creating a
Canvas where the drawing is done? If so what is the canvas component in
Royale?
I'll want to try that, if there's some example code in same place, please
let me know.
thanks!

2018-05-18 13:19 GMT+02:00 Harbs :

> Take a look at the Graphics package.
>
> Specifically, PathBuilder lets you use commands very similar to Flash
> drawing commands.
>
> Also, CompoundGraphic in Basic offers a number of drawing commands.
>
> org.apache.royale.svg (in Basic) has many basic shape types which simplify
> drawing of those.
>
> I’ve used these classes extensively, and they work very well.
>
> Thanks,
> Harbs
>
> > On May 18, 2018, at 2:09 PM, Carlos Rovira 
> wrote:
> >
> > I talk about "drawing things" that was something
> > more related to the Flash API.
>
>


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

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

[Harbs]

A couple of questions/comments:

> On May 18, 2018, at 1:57 PM, Carlos Rovira  wrote:
> 
> One more important technical thing about that way is "verbosity" since each
> time you reference that kind of class you are introducing a name that use
> to be 2-3 time longer, each time.

Are you suggesting this has performance implications? I would not have thought 
that class name length effects performance. If you have a source that it does, 
I’d be interested in hearing details.

> "My suggestion with meta-data was a way to enable the second option. It
> does not need to be specifically meta-tags. It could be something like this
> as well:
> 
> /**
> * royaleclassselector RadioButton
> * royaleclassprefix basic
> * royaleinheritsbaseselector
> */
> "
> I still prefers the [] format since is more concise and I think is more
> suited for this particular purpose.

I agree that the bracketed format is “prettier”, but I could live with either.

> In General, I think we should get something that will be the "default" way,
> and then if we have a metadata, that should override the default way. That
> will make possible the most flexible way of handling this an a solution
> that since to fit all visions.

Agreed. I was suggesting that the default remains as it is today, and we be 
careful about including metadata in Framework classes.

Thanks,
Harbs

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Harbs]

Take a look at the Graphics package.

Specifically, PathBuilder lets you use commands very similar to Flash drawing 
commands.

Also, CompoundGraphic in Basic offers a number of drawing commands.

org.apache.royale.svg (in Basic) has many basic shape types which simplify 
drawing of those.

I’ve used these classes extensively, and they work very well.

Thanks,
Harbs

> On May 18, 2018, at 2:09 PM, Carlos Rovira  wrote:
> 
> I talk about "drawing things" that was something
> more related to the Flash API.

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Carlos Rovira]

I think this is all very interesting. We have still a part of what we could
make with Flex uncovered. I talk about "drawing things" that was something
more related to the Flash API.
There's some efforts like spriteflexjs, but I think the problem with that
project is that is "isolated" and seems difficult to use as a piece of the
global puzzle. Don't know too much about openfl, and seems that some great
things are happening integrating with apache royale compiler. But I'd
really want to know more about all of this since there's almost no
information and in order to imagine what we could do with all of this, we
should have some kind of articles, post or whatever that could let us know
about what things we can do, technologies implied, actual integrations, how
to build those libraries, some example out there of royale and openfl using
at the same time?

If we had some of the proposed information we could help on that

just my 2 :)

Thanks!

Carlos


2018-05-18 2:56 GMT+02:00 Alex Harui :

> Hi Greg,
>
> I think I understand your point.  I want to point out, though, that the
> current plan for the emulation set is to make Basic beads the fundamental
> workhorse of this emulation set.  What we are doing is taking, say, the
> beads used in Basic ImageButton and re-using those beads with no or little
> modification in Spark ImageButton.  So that means to me that if there is an
> API parameter of flash.display.BitmapData, that we are going to first
> choose to rename it to something like royale.display.BitmapData and have it
> subclass the class that is used to represent bitmap data in Basic.  I'm not
> sure how OpenFL implements flash.display.BitmapData, but it may or may not
> be compatible with Basic because Basic is going to shove the data into an
> IMG tag and it appears that to do that the data would be base64 encoded and
> look like:
>
> "data:image/png;base64,
> iVBORw0KGgoNSUhEUgoKCAYAAACNMs+9BGdBTUEAALGP
> C/xhBQlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9YGARc5KB0XV+IA
> AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
> REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
> ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
> vr4MkhoXe0rZigBJRU5ErkJggg=="
>
> Similarly, I think some Basic beads use BinaryData so our ByteArray might
> get renamed to royale.utils.ByteArray and subclass our BinaryData so it can
> be passed into the Basic beads.  But we will keep your suggestion in mind.
> Thanks for bringing it up,
> -Alex
>
> On 5/17/18, 5:19 PM, "Greg Dove"  wrote:
>
> Alex, your comment about a full-blown emulation component set built on
> openfl display objects could perhaps be a different (and interesting)
> approach or 'parallel' option in time. But I wasn't really meaning
> that at
> this point.
> I wasn't thinking so much on the 'displaylist' side of things.
>
> I was only intending to suggest that for some of the flash dependencies
> inside the emulation classes (e.g. use of ByteArray, for example), it
> might
> be a quick solution to use whatever emulation code openfl has for those
> already - even if that is only temporary or transitional.
> For ByteArray we do have alternate approaches as discussed, but perhaps
> using the openfl code could mean less initial work getting things
> working
> where-ever it is used, because there might be very little change
> required
> from the original code.  Perhaps something like BitmapData might be
> useful
> from openfl, for example (I don't think we have 'emulation' for this
> yet,
> right?). If this works, it could speed things up in emulation efforts
> perhaps by focusing more on migrating the 'Flex' specific code and not
> on
> the lower level flash player classes that are not yet emulated but
> necessary for some things.
> As I said, I only noticed the activity for openfl, and have not
> investigated what Joshua is doing there, so just wanted to float the
> idea... which is done now, so I will leave it to others to figure out
> if it
> makes sense or not!
>
>
> On Fri, May 18, 2018 at 10:36 AM, Alex Harui  >
> wrote:
>
> > Hi Greg,
> >
> > That's an interesting idea.  My inclination is to recommend that
> migrators
> > get rid of their flash*.* dependencies for two reasons:
> >
> > 1) I think in many cases there are other JS implementations that
> will work
> > better.  Having a Button be an HTMLButtonElement should be better
> than it
> > being implemented on OpenFL's Sprite.
> > 2) Not having code rely on flash*.* makes it easier for us to
> provide a
> > third target someday (WebAsm, Native).
> >
> > But if folks want to pursue an emulation component set that uses
> OpenFL
> > for flash*.*, it could become a viable solution.  Especially for
> apps that
> > had a lot of custom 

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

[Carlos Rovira]

Hi just responding some few things I saw:

"Metadata is possible, but metadata is expensive at runtime."

Depend if is a Metadata to use at compile time or at run time. In this case
we're talking about a compile time metadata. Even at runtime, a metadata
can be or not expensive depending on the scope (running some code inside a
class is as efficient as run a method but apply a behavior that cross all
instances of same type can be expensive."

"One option is to fully qualify the *compiled* class selector so it’s named
“.org_apache_royale_html_RadioButton”. I’m pretty sure this is what you are
proposing. The primary objection to that is that it’s a rather long string
and kind of “ugly”."

One more important technical thing about that way is "verbosity" since each
time you reference that kind of class you are introducing a name that use
to be 2-3 time longer, each time.

"My suggestion with meta-data was a way to enable the second option. It
does not need to be specifically meta-tags. It could be something like this
as well:

/**
* royaleclassselector RadioButton
* royaleclassprefix basic
* royaleinheritsbaseselector
*/
"
I still prefers the [] format since is more concise and I think is more
suited for this particular purpose.

In General, I think we should get something that will be the "default" way,
and then if we have a metadata, that should override the default way. That
will make possible the most flexible way of handling this an a solution
that since to fit all visions.

Thanks


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

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

[Harbs]

> 
> It is a bug.  In the framework.  The defaults.css for Basic has a 
> .DynamicDataGrid in it.  It shouldn't have that.  (There might be another 
> framework bug where a ClassReference in .DynamicDataGrid referenced DataGrid 
> which bring in DataGridButtonBar which brings in ButtonBar)   That's an 
> example of Class Selectors being used instead of Type Selectors.  If we 
> created an actual subclass of DataGrid called DynamicDataGrid then the CSS 
> could use a Type Selector instead of a Class Selector and the problem goes 
> away.   IMO, we need to decide on some good ways to stop using class 
> selectors or prune class selectors.
> 

OK. Great. I assumed the bug was in the compiler. Great to hear it’s not. Yes. 
We definitely need to get rid of those class selectors from framework CSS. I 
can work on that.

> 
>I don’t understand why the compiler cannot build a list of used classes 
> and drop any CSS references not used.
> 
> It does have that depending on what you mean by "used".  If "used" means 
> referenced by the code, it appears to be working correctly.  If you are 
> suggesting that the compiler tracks whether a class is actually instantiated, 
> that's a bit harder mainly because we would need to retain that information 
> in the SWC somewhere and we don't currently store compile-time information 
> elsewhere in the SWC.  We could try to prune more in post-processing for JS 
> only.  We could search every JS file for "new Button", but even then, I think 
> you'd miss where a className was stored in a variable and then instantiated 
> which is what ValuesManager does.  So I'm not sure the compiler can truly 
> know what classes got directly instantiated.

I think including code from class selectors is an acceptable limitation. 
(feature?) My comment was because of my erroneous assumption that the bug was 
in the compiler.

>I’m not sure we’re talking the same language. The class selector for 
> ImageButton will always be (in HTML css) .ImageButton. So if you have a basic 
> ImageButton and a Jewel ImageButton, there will be CSS conflicts in the 
> compiled HTML CSS.
> 
> The above statement isn't true.  I already mentioned upthread that the HTML 
> css could be .org_apache_royale_basic_ImageButton.
> 
> I think there is a fundamental disagreement here.  I think we should be 
> approximating how Type Selectors work.  That is because fully qualified type 
> names are essentially already guaranteed to be unique.  The compiler will 
> catch duplicates.  IMO, we want to leverage strong typing.  It is Royale's 
> technical advantage over all of the manual conventions I see folks having to 
> use in other JS frameworks.  I think you want to propose some scheme to use 
> class selectors and not use Type Selectors.  This is doable, but requires a 
> manual convention.  The component developer theoretically already decided on 
> how to make the fully qualified component name unique by selecting a unique 
> package name.  Now you want the component developer to have to identify 
> another unique name to ensure the class selector names don't collide.  And 
> those names are going to want to be "friendly" names like "Basic" and 
> "Jewel".  I don't get why using QNames is not sufficient.  If it is too 
> verbose in the output, maybe we can find a way to shorten it.  IMO, 
> uniqueness is probably better handled by tooling instead of manual 
> conventions.
> 
> Let's make sure we can't use Type Selectors before discussion a scheme for 
> using Class Selectors.  Uniqueness is built in to Type Selectors.

I think we are in agreement but the wires are being crossed on terminology.

I am in total agreement that framework CSS should always use Type Selectors. In 
other words, defaults.css should include:

RadioButton
{
IBeadModel: 
ClassReference("org.apache.royale.html.beads.models.ValueToggleButtonModel");
IBeadView:  
ClassReference("org.apache.royale.html.beads.RadioButtonView"); 

font-size: 11px;
font-family: Arial;
}
And basic.css has:
RadioButton
{
font-size: 12px;
font-family: sans-serif;
}

RadioButton is a Royale Type Selector as it should be. No discussion on that 
front (with the exception that the styling should be removed from the 
defaults.css).

Te whole question is what happens in MyApp.css which is compiled standard HTML 
CSS.

Currently we get:

.RadioButton {
font-family: sans-serif;
font-size: 12px;
}

This CSS comes from the Type Selector in basic.css. This seems to be included 
in the app.css even if RadioButton is not included. But putting that point 
aside at the moment, the question is what the class selector (in app.css) 
should be *produced* from the type selector.

I think we agree that “.RadioButton" is not right because there can be 
RadioButton from more than one component set.

One option is to fully qualify the *compiled* class