Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Mark Kessler]

Don't need every SWC with a version.  Just one for the whole SDK would
be fine.  I proposed just a single one stored in the core.  We can
modify the build file to just point to the single file instead of
doing a path search.  See the start of my example [1].


[1] 
https://github.com/KesslerConsulting/royale-asjs/commit/84262f3a2e56cc6b58ccdf283d039c94fb10cafb

-Mark K


On Tue, Apr 30, 2019 at 6:42 PM Alex Harui  wrote:
>
> To be more specific:
>
> Version.as in Flex was included into every class.  I do not recommend doing 
> that in Royale.  It didn't have enough value for the cost.
>
> FlexVersion.as in Flex was used for runtime versioning.  Code could use it to 
> take different paths.  I hope we don't need that in Royale.
>
> The Flex and Royale compilers will put the compiler version in SWFs but do 
> not put any string in JS output.  Someday, the Royale compiler may be 
> released separately from the SWCs.  Royale may stop releasing certain SWCs in 
> the future if there is no interest in maintaining them.  Then we will have to 
> decide whether to update the version of those SWCs after they are frozen.  
> Royale SWCs do not carry version information on a per-SWC basis.  But in some 
> future, you could be using some version of the Royale compiler to compile 
> with SWCs from different versions of the Royale SDKs.
>
> This version information is defined in the pom for folks using Maven.  It is 
> not defined at all for other build mechanisms (Ant, command-line, IDEs) 
> because the non-Maven artifacts do not have versions in the file names.  
> That's on purpose.  We want to make it easy for non-Maven users to swap 
> versions of SDKs.  Maven users prioritize explicit dependency information 
> over swapping of SDK versions.
>
> In summary, Royale may not be released like Flex where all SWCs are updated 
> for each release along with a compiler.  So I'm not exactly sure what problem 
> is trying to be solved, but it won't hurt to have a version bead or version 
> constant.  And if someone wants to propose a way to get the compiler to 
> inject a version string in JS output, that's fine too, but keep in mind that 
> all of these verions strings might get removed during minification so they 
> will probably need to be an exported public variable/constant.
>
> It would be great to have the version automatically updated for each release, 
> but I think the number of places we currently change are small so having one 
> more place probably is ok.  All it takes is a volunteer to create the PRs or 
> commit the code.
>
> My 2 cents,
> -Alex
>
>

Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Mark Kessler]

We can through an old mechanism that appears to be left from the
Apache Flex side that does just this.

Around line1192 of the root build.xml [1].  It specifically hunts down
files called "Version.as" and uses RegEx to update the version number
and build number.  So when the SDK is built for release, it will
automatically update the Version.as files using the "release.version"
property.  Meaning after we create the file(Version.as) having the
correct version format inside it it will be something that stays
up-to-date automatically.  Little tweaks needed it looks like, but it
should work.

build.xml lines look like this:















I won't have a chance to test the build.xml right now to finish it,
but here is what the rest of it would look like [2] (very short).

Usage for the end user:

import org.apache.royale.core.Version;

trace(Version.CURRENT_VERSION);


[1] https://github.com/apache/royale-asjs/blob/develop/build.xml
[2] 
https://github.com/KesslerConsulting/royale-asjs/commit/84262f3a2e56cc6b58ccdf283d039c94fb10cafb

-Mark K

On Tue, Apr 30, 2019 at 5:17 PM Carlos Rovira  wrote:
>
> Well,
> since others techs make that maybe it would be ok to have it baked. Right
> now I don't have a strong opinion about what to do maybe others could bring
> more light, but Version class seems ok to me, and hope we could have it get
> the version directly without manual modifications what will very cumbersome
> to manage for releases, niglhly builds, etc..
>

Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)

[Mark Kessler]

Well that would work in addition too, but not replace what I'm talking
about.  I'm talking about the SDK having a built in version.  A
version bead would be more building an app using the SDK and the app
having it's own version.


-Mark K

On Tue, Apr 30, 2019 at 2:39 PM Piotr Zarzycki
 wrote:
>
> +1 to Josh's idea that we provide bead with logic which serves version.
>
> Thanks,
> Piotr

Re: Should we change width/height to use EM instead PX?? (was: Re: Using em vs px)

[Mark Kessler]

As a comment on the helper functions, we could also just have
something that does on the fly conversion.  In other words if I say
300 pixels, I want it to translate that into EM / other unit in the
background. The reason I bring that up is to allow exact PX still be
used for the Flex / Air side and converted for the js/css side.

pixelTotal / fontSize = em

300 / 14 = 21.429 (rounded)

Soo 300px for flex and 21.429 for JS side.

-Mark K

Re: Using em vs px (was. Re: Things that we still doesn't have and need in UIBase sizing)

[Mark Kessler]

Carlos,
I can give it a shot when I'm at home.  However, what about the
direct width/height assignments.  Should they do EM assignment too or
should there be a new widthEM heightEM property added?


-Mark K

On Sun, Jan 13, 2019 at 6:58 AM Carlos Rovira  wrote:
>
> Hi Mark,
>
> thanks for the info. I finally could reproduce the issue, was not aware of
> that, since I thought there was only one way to increase/decrease.
> So good to know.
>
> To fix that we should go through all the components CSS rules to change px
> to em.
> I must say that I'm in a current point where I can't do this myself, so if
> you know clearly how to do this, do you want to do yourself and submit PRs
> so I can integrate in current codebase?
>
> let me know if that could be a plan. And many thanks for pointing this!  :)
>
> Carlos
>
>

Re: [DISCUSS] project vs. project name

[Mark Kessler]

An installer type thing?

-Mark K



> Maybe it is possible to have just one package, but different install scripts 
> ? (full, swf only, js only ?)
> For people like me (app developers) it makes sense.
> However, I'm not sure that a no-component install will be of interest for 
> much people...

> Nicolas Granon

Re: [DISCUSS] project vs. project name

[Mark Kessler]

Wouldn't we just release an SDK instead?  Like Royale SDK and skip the JS part?


-Mark K

On Mon, Oct 2, 2017 at 6:25 AM, Carlos Rovira
 wrote:
> Hi,
>
> my opinion on this regard is that having many sub names (aka product names)
> and packages will only confuse people coming to Royale.
> As well, I think we already manage outputs via compiler params to dictate
> if we want to target one or more outputs.
> So I'll be more happy with only one name and only one package that could
> output JS, WASM, SWF, )
>
> People coming from Flex will find us and will know we can be their solutions
> Meanwhile people that search for a frontend tech, will come to read about
> Angular, React, ...and hope in some time Royale. We don't
> want those people be contaminated for old Flash or Flex that could make
> them not choose us for something is not relevant to us.
>
> So I think we should always look forward and as we decided to remove "JS",
> we should as well not have a "FlexJS" version inside
>
> That's my 2ctn
>
> Thanks
>
> Carlos
>
>
> 2017-10-02 11:25 GMT+02:00 Erik de Bruin :
>
>> Hi,
>>
>> With the renaming effort planned to start right after the 'packaging'
>> branch lands, I think it makes sense to discuss and vote on the naming of
>> the product(s) of this project.
>>
>> Buried in another thread Alex remarked the following, which I think is an
>> excellent suggestion:
>>
>> "When we were discussing this earlier, we were discussing two
>> IDE-friendly release
>> artifacts, one designed for folks migrating from Apache Flex and another
>> for folks not interested in SWF.  In the packaging branch I have most of
>> that working.
>>
>> We were discussing calling the migration package 'FlexJS' and the other one
>> Royale or RoyaleJS.  The latter is considered by some folks to mean "Royale
>> for JS".  The package names would be apache-royale-flexjs- and
>> maybe apache-royale-royalejs-. The project name would definitely
>> be Royale but I think we want to have artifacts that denote target
>> markets."
>>
>> A strong case has been made to leave off the "JS" off all but the
>> legacy/migration package, which makes sense to me as well.
>>
>> I think there are plans to have this project create multiple product (e.g.
>> one that does AS3->WebAssembly), so I do not think that we should name the
>> current product 'Royale'. It will be increasingly confusing to have a
>> product with the same name as the project and then have other products from
>> the same project with totally different names. I suggest we come up with a
>> naming convention that will reflect the functionality of the various
>> products and their link to the project. E.g. (off the top of my head, just
>> to show what I mean): royale-as-js, royale-as-wasm, etc.
>>
>> What do you think?
>>
>> EdB
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>
>
>
>
> --
>
> 
>
> Carlos Rovira
>
> Director General
>
> M: +34 607 22 60 05
>
> http://www.codeoscopic.com
>
>
> Conocenos Avant2 en 1 minuto! 
>
>
> Este mensaje se dirige exclusivamente a su destinatario y puede contener
> información privilegiada o confidencial. Si ha recibido este mensaje por
> error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
> proceda a su destrucción.
>
> De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> servicio o información solicitados, teniendo usted derecho de acceso,
> rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> necesaria.