RE: [Non-DoD Source] Quick check on Linting tools for Apache Royale
Greg, Currently we are still using v9.3 of SonarQube and v18 for the JDK. -Mark K -Original Message- From: Greg Dove Sent: Friday, May 20, 2022 01:56 To: us...@royale.apache.org Cc: Apache Royale Development Subject: Re: [Non-DoD Source] Quick check on Linting tools for Apache Royale Mark, would you mind sharing what version of SonarQube you are using? Our experience is that a recent version (needed for java 17) does not seem to work for actionscript files, so we'd be keen to hear what version you are using. Thanks, Greg On Thu, May 19, 2022 at 8:18 AM Greg Dove mailto:greg.d...@gmail.com> > wrote: Hi Mark, I appreciate you sharing your more recent experience - it sounds like SonarQube remains the most viable option for now... Thanks, Greg On Thu, May 19, 2022 at 5:20 AM Kessler CTR Mark J wrote: Greg, We actually still use SonarQube for AS file scanning as AS3 does not have a lot of actively developed utilities in this area. You do have to customize their rules list to be more appropriate, but it does give you a 70% solution. You are correct about it not working on any code structure inside of the MXML files themselves. Run the MXML files lean on code and rely on controllers/VO/utility in pure AS files to give you the most benefit from it. -Mark K -Original Message- From: Greg Dove mailto:greg.d...@gmail.com> > Sent: Wednesday, May 18, 2022 00:51 To: us...@royale.apache.org <mailto:us...@royale.apache.org> Cc: Apache Royale Development mailto:dev@royale.apache.org> > Subject: [Non-DoD Source] Quick check on Linting tools for Apache Royale Hi everyone, It's been a while since I used any code quality tools with Apache Royale. I'm keen for some updated suggestions if you have any... to be clear: this is about the actionscript/css/mxml, not about the generated javascript. I worked on a project some years ago (when it was still FlexJS) where we used SonarQube, and that was working at the time (as part of a maven build) and was useful (although I think it may have been limited to actionscript code blocks inside mxml and not working with mxml itself...). Has anyone used SonarQube or perhaps tried to use Flex PMD or anything else recently, with Apache Royale? Would be keen to hear your thoughts and/or recommendations! Thanks, Greg
RE: [Non-DoD Source] Quick check on Linting tools for Apache Royale
Greg, We actually still use SonarQube for AS file scanning as AS3 does not have a lot of actively developed utilities in this area. You do have to customize their rules list to be more appropriate, but it does give you a 70% solution. You are correct about it not working on any code structure inside of the MXML files themselves. Run the MXML files lean on code and rely on controllers/VO/utility in pure AS files to give you the most benefit from it. -Mark K -Original Message- From: Greg Dove Sent: Wednesday, May 18, 2022 00:51 To: us...@royale.apache.org Cc: Apache Royale Development Subject: [Non-DoD Source] Quick check on Linting tools for Apache Royale Hi everyone, It's been a while since I used any code quality tools with Apache Royale. I'm keen for some updated suggestions if you have any... to be clear: this is about the actionscript/css/mxml, not about the generated javascript. I worked on a project some years ago (when it was still FlexJS) where we used SonarQube, and that was working at the time (as part of a maven build) and was useful (although I think it may have been limited to actionscript code blocks inside mxml and not working with mxml itself...). Has anyone used SonarQube or perhaps tried to use Flex PMD or anything else recently, with Apache Royale? Would be keen to hear your thoughts and/or recommendations! Thanks, Greg
RE: [Non-DoD Source] Re: Sanitizing HTML (was Re: 0.9.9)
Sorry for my delay, the use cases is based on not allowing unsanitized input from either the user, a request property, or server response. Generally speaking XSS is an injection style exploitation. 2 main types of XSS: 1. Reflected: happens when information from a user or request property is not sanitized and used in things like popups or assigned to display elements like might occur when trying to return an error message to the end user with a portion of their input. Can also be DOM based. 2. Stored: This type is generally when a server has stored a value that contains the exploit and sends it clients later on. This one is more serious as it could affect multiple users at once. Imagine something more akin to blogging where one person posts an article and then all the people who visit it later to read the article that triggers the exploit. My compromise of a recommendation is that properties like the TEXT getters / setters or similar properties automatically use the sanitizer methods before assigning the new values to the element. I feel like that would still allow some manual formatting if designed, but we would have done our due diligence / due care. Thoughts? -Mark K -Original Message- From: Harbs Sent: Friday, December 10, 2021 05:26 To: dev@royale.apache.org Subject: [Non-DoD Source] Re: Sanitizing HTML (was Re: 0.9.9) Sanitizing what? And why? What is the use case which is “dangerous”? > On Dec 10, 2021, at 11:49 AM, Edward Stangler wrote: > > > My mistake. > > Definitely should be sanitizing. If you want PAYG, then make it default > (some global function) and something that can be overridden by those who > want to live dangerously. > > > On 12/10/2021 3:07 AM, Harbs wrote: >>> It looks to me that most uses of innerHTML in Royale are assigning text >>> to various labels (like Button). >> I’m not sure which case you’re referring to. >> >> Ignoring examples, ASDoc and RoyaleSite, here is every use of innerHTML in >> the framework with comments: >> >> HTMLText -- A component created specifically for applying innerHTML. It >> would generally be used in mxml where the content would be provided by the >> develper >> ImageAndTextButton -- Uses innerHTML to combine text and and img tag. I >> guess it could be safer if it would use Image and TextNode elements. >> Label -- has an html getter/setter which is clearly for markup so innerHTML >> is necessary. >> LoadIndicator -- uses innerHTML, but the markup is generated internally and >> not exposed, so not a risk. >> TextButton -- has an html getter/setter which is clearly for markup so >> innerHTML is necessary. It has a separate text getter/setter which *does >> not* use innerHTML >> UnselectableElementBead -- uses self-generated innerHTML for setting a >> style. Not a risk. >> addDynamicSelector -- uses innerHTML for setting a style but only the first >> time it's used. Should not be a risk. >> InspireTreeIconBead -- similar to UnselectableElementBead >> Flat DropDownList -- uses innerHTML in six places. I don't know why. >> Graphics -- uses innerHTML for self generated markup. Not a risk. >> TextNodeContainerBase has an innerHTML getter/setter because it's emulating >> the corresponding HTML elements. >> InnerHTML -- is (as its name suggests) a component for setting innerHTML. >> Jewel Button -- has an html getter/setter which is clearly for markup so >> innerHTML is necessary. It has a separate text getter/setter which *does >> not* use innerHTML >> Jewel Label -- has an html getter/setter which is clearly for markup so >> innerHTML is necessary. It has a separate text getter/setter which *does >> not* use innerHTML >> Jewel SnackbarView uses innerHTML for the "message". I don't know why. >> MX Button -- I found it used innerHTML which should have been textContent. >> Fixed. >> MX Label -- has htmlText getter/setter which is clearly for markup so >> innerHTML is necessary. >> MX TinyEditor -- has htmlText getter/setter which is clearly for markup so >> innerHTML is necessary. >> MX UITextField -- has htmlText getter/setter which is clearly for markup so >> innerHTML is necessary. >> MX UITextFormat -- uses innerHTML for measuring. Should be safe. >> Spark ButtonBase -- uses innerHTML. I don't know why. >> Spark DropDownListButton -- uses innerHTML to draw the skin. The label is >> part of that. It's possible that should be sanitized. >> TextLine -- uses innerHTML in two places where textContent could likely be >> used, but the string it's using came from textContent, so it should not be a >> risk. >> >> Summary: >> Ones which could use looking into: >> ImageAndTextButton >> Flat DropDownList >> Jewel SnackbarView >> Spark ButtonBase >> Spark DropDownListButton >> >> I’m not personally very familiar with either Jewel or the Spark components, >> so someone else should comment on those. >> >> The other risky area in HTML is setting “src” for Image tags and the like. >> >> We’re not sanitizing
RE: [Non-DoD Source] Re: 0.9.9
I like the fact that the Closure library has those, but those are optional. We have our own mechanisms already in our private libraries because the Royale SDK had no consideration for it. Security should not be an afterthought, and by not defaulting to having some form of security baked in by default we are contributing to the global problems of it. We cannot expect newer developers to follow things like OWASPs top [1], and they will not see a need for it until there is an incident. [1] https://owasp.org/www-project-top-ten/ -Mark K -Original Message- From: Harbs Sent: Thursday, December 9, 2021 11:13 To: dev@royale.apache.org Subject: [Non-DoD Source] Re: 0.9.9 I just went poking around and I found that Google Closure has a pretty extensive library for sanitizing HTML: https://github.com/google/closure-library/tree/master/closure/goog/html/sanitizer Considering we’re already using the goog libs for other things, it should be fairly straight-forward to wrap the functionality in Royale classes. Feel free to work on that… ;-) I do think that the sanitizing should be opt-in. Harbs > On Dec 9, 2021, at 5:03 PM, Kessler CTR Mark J > wrote: > >I am on the opposite spectrum of this opinion. We had to write our own > library on-top of the basic Royale for our applications that was more > security minded. All of our defaults are for innerText as it will not > interpret the contents or use new variants that already have security built > it such as a textarea's "value" has security considerations by default now. > This is important as cybersecurity teams or software tests can easily show > basic XSS in fields either reflected or stored. Remember the end users are > the ones that are directly affected by vulnerabilities built into a web > application and a developer that does not follow good sanitization practices > will surely allow easily preventable vulnerabilities in. > > We should always have secure defaults, but allow developers to violate good > security practices on their own as a conscious decision. > > > -Mark K
RE: [Non-DoD Source] Re: 0.9.9
No I was using the TextArea.value as an example of the web standards finally including some built in protection while as the older input styles still need to catch up. -Mark K -Original Message- From: Harbs Sent: Thursday, December 9, 2021 10:33 To: dev@royale.apache.org Subject: [Non-DoD Source] Re: 0.9.9 Not following. What concerns do you have with TextArea values? IFIK, there’s no possibility of XSS attacks there. Can you give me specific concerns you have? > On Dec 9, 2021, at 5:03 PM, Kessler CTR Mark J > wrote: > >I am on the opposite spectrum of this opinion. We had to write our own > library on-top of the basic Royale for our applications that was more > security minded. All of our defaults are for innerText as it will not > interpret the contents or use new variants that already have security built > it such as a textarea's "value" has security considerations by default now. > This is important as cybersecurity teams or software tests can easily show > basic XSS in fields either reflected or stored. Remember the end users are > the ones that are directly affected by vulnerabilities built into a web > application and a developer that does not follow good sanitization practices > will surely allow easily preventable vulnerabilities in. > > We should always have secure defaults, but allow developers to violate good > security practices on their own as a conscious decision. > > > -Mark K
RE: 0.9.9
I am on the opposite spectrum of this opinion. We had to write our own library on-top of the basic Royale for our applications that was more security minded. All of our defaults are for innerText as it will not interpret the contents or use new variants that already have security built it such as a textarea's "value" has security considerations by default now. This is important as cybersecurity teams or software tests can easily show basic XSS in fields either reflected or stored. Remember the end users are the ones that are directly affected by vulnerabilities built into a web application and a developer that does not follow good sanitization practices will surely allow easily preventable vulnerabilities in. We should always have secure defaults, but allow developers to violate good security practices on their own as a conscious decision. -Mark K
RE: Externs that returns a value instead of void method
Hugo,
If you are using the @externs in the class comments, use a native on
function and it will ignore its requirement to actually have a body. It can
remain just a declaration. The other thing that caused us problems in the
beginning is we needed a change to the release compilation properties to
optimize only the whitespace, because it was mangling our external namespaces
if not.
public native static function getDocumentAsPDF():Object;
r/s
-Mark K
-Original Message-
From: Maria Jose Esteve
Sent: Sunday, October 24, 2021 07:32
To: dev@royale.apache.org
Subject: [Non-DoD Source] RE: Externs that returns a value instead of void
method
If you want I have several projects with externs that you could look at to see
different wrappers.
Depending on how the JS library is set up you will have some problems or others
but in general they work very well.
- [1] royale-community-examples project: Here you have a wrapper for
VirtualSelect, JSCalendar, JsFullCalendar and we are finishing one for
InspireTree.
- [2] royale-echarts examples project: wrapper for the Apache Echarts incubator
graphics library.
[1] https://github.com/mjesteve/royale-examples-community/tree/develop
[2] https://github.com/mjesteve/Royale-ECharts/tree/develop
I hope they will help you.
Hiedra.
-Mensaje original-
De: Yishay Weiss
Enviado el: domingo, 24 de octubre de 2021 9:15
Para: dev@royale.apache.org
Asunto: Re: Externs that returns a value instead of void method
Are you compiling the PDF typdefs as a separate lib? If so, you need to make
sure the application compiler treats it as a js-external-library. If you do
that, as Josh pointed out, no js output from the lib will be included in your
application so it shouldn't matter what actual values you return, as long as it
compiles.
On 2021/10/23 22:35:33, Hugo Ferreira wrote:
> Hi,
>
> How to use a method in externs (
> https://apache.github.io/royale-docs/features/externs) that returns a value.
>
> I tried: public static function getDocumentAsPDF():Object { return null; }
>
> But of course that returns null (even the JS version returns a value)
>
smime.p7s
Description: S/MIME cryptographic signature
RE: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
As an example, here is how to access the version number in other languages.
Some easier to use than others. Looks like the easiest ones are just static
const strings.
Flex[1]: mx.core.FlexVersion.CURRENT_VERSION
Dotnet[2]: System.Environment.Version
Java[3]:System.getProperty("java.version");
React[4]: React.version
Angular[5]: import { VERSION } from '@angular/core'; VERSION.full
Groovy[6]: GroovySystem.getVersion();
Ruby[7]: RUBY_VERSION
Python[8]: sys.version
Node.Js[9]: process.version
PHP[10]: phpversion()
So I would like the SDK to provide something similar. It looks like we still
have a mechanism setup in the build.xml we are just missing the files it's
looking for (Version.as files). Let's add the following file and see if it
with a little tweak in pathing would turn it into a self-managing version file
when building the SDK for release. This looks like a smallest simplest
mechanism to implement this. Especially since it's regex pattern matching the
old version format, it doesn't matter how we layout the file.
File: Version.as
package org.apache.royale.core
{
public class Version
{
public static const CURRENT_VERSION:String = "0.9.6.0";
}
}
SDK Usage for developer:
Import org.apache.core.Version;
trace(Version.CURRENT_VERSION);
[1] https://flex.apache.org/asdoc/mx/core/FlexVersion.html
[2]
https://docs.microsoft.com/en-us/dotnet/api/system.environment.version?view=netframework-4.8
[3] https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
[4]
https://stackoverflow.com/questions/36994564/how-can-one-tell-the-version-of-react-running-at-runtime-in-the-browser
[5]
https://stackoverflow.com/questions/36456843/how-to-check-angular2-version-with-typescript
[6] http://docs.groovy-lang.org/latest/html/api/groovy/lang/GroovySystem.html
[7]
https://stackoverflow.com/questions/1589751/determine-ruby-version-from-within-rails
[8] https://docs.python.org/3/library/sys.html
[9] https://nodejs.org/api/process.html#process_process_version
[10] https://www.php.net/manual/en/function.phpversion.php
-Mark K
-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org]
Sent: Tuesday, April 30, 2019 10:37 AM
To: dev@royale.apache.org
Subject: Re: [Non-DoD Source] Re: Version property (was: Let's bump Royale
version to 1.0)
Hi Mark,
sorry but all you state can be solved with the solution I exposed to you.
There's no need to add an identifier to an SDK since you can add it
yourself from the SDK you downloaded or get by the multiple ways available.
In any of the cases the numbers are not baked into code, but are available
in different parts and you can use defines to bake it into your code and
use it in the same way you use to do in Flex. At least I don't see from
your response that your points will not be covered in that way
RE: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0)
Lol, I can't seem to explain it properly. Take maven/ant/config files out of
the equation it doesn't matter for this example. This has to do with getting
some identifying information into the official SDK releases. We don't want to
pass variables as an SDK user. We want the official SDK to already come
packaged with a version number or a build number or a build date...
Here's the scenario that I would love to see happen:
1. SDK user downloads official Royale SDK release and never modifies it.
2. SDK User compiles their app using official SDK and references an official
SDK property that contains the SDK identifier already built in it. Meaning I
should be able to code complete off of the SDK and find something that already
exists and could return me an official identifier.
-Mark K
-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org]
Sent: Monday, April 29, 2019 1:14 PM
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale version
to 1.0)
ok,
we do the following in maven for other needs so this will be valid for you
too:
in your maven properties.
0.9.6-OR-WHATEVER
org.apache.royale.compiler
royale-maven-plugin
true
...
BUILD::royaleVersion
'"${royale.framework.version}"'
...
...
defines can be done in ANT, asconfigc, config.xml
Then in AS3 or MXML
/**
* ROYALE VERSION NUMBER
*/
private static var _royaleVersion :String = BUILD::royaleVersion;
So now you can use in any place you want
HTH
Carlos
Re: Version property (was: Let's bump Royale version to 1.0)
Let me clarify. @Carlos, It's not a dependency issue, it's a matter of finding out what the SDK version or build number of the SDK or any form of uniquely identifying information about the SDK in code. So the apps we build using Flex we can just get the Flex version by referencing mx.core.FlexVersion in code. Then in our application logs when an app starts up we can see the message "Compiled with SDK v4.16.0.". So it allows us to more easily troubleshoot issues later. @Alex, Yes that would be great to have any important versions in there. How about we just keep it like a compile time constant / compiler "define" statement that has the version built it? -Mark K
RE: Version property (was: Let's bump Royale version to 1.0)
Yeah just concerned with an official build number, or date, or something with numbers we can use to identify a production app back to what SDK was used to compile it. Imagine having an app released on production and a user reports a problem. We would need to reproduce the problem in a test environment. This would include using the same SDK to compile the app. Currently in Flex, we can just access its version directly which makes things faster. If the SDK doesn't have anything like this at the moment and we did add that functionality in there, I would say let's just use a date field since it could be automated. Something like MMDD type format. -Mark K -Original Message- From: Alex Harui [mailto:aha...@adobe.com.INVALID] Sent: Friday, April 26, 2019 12:02 PM To: dev@royale.apache.org Subject: [Non-DoD Source] Re: Version property (was: Let's bump Royale version to 1.0) On 4/26/19, 4:29 AM, "Kessler CTR Mark J" wrote: > So far, we have not had the release scripts properly generate the right version number for the NPM artifacts. This spurred a question for me. Is there a way to find out what version number the SDK binaries are in code for Royale? Sort of like the Flex SDK mx.core.FlexVersion or at least a build date? Not at this time. IMO, runtime versioning wasn't worth the cost of all of those strings and code in the production app. Also, Royale was designed from the beginning to try to be "version-agnostic". By using loose-coupling via Beads/PAYG/ValuesManager and lots of interfaces instead of direct class references, there shouldn't be a need to deal with version incompatibilities at runtime like Flex did with the Marshall Plan and FlexVersion and more. Flex had to care about version incompatibilities because the fundamental base classes were not loosely-coupled. Flex HelloWorld was 128K not just because UIComponent was huge, but because UIComponent pulled in other classes as init-time strongly-coupled dependencies. A good thing to think about as you write Royale framework code is, "can every dependency be easily replaced"? After we hit 1.0 (and hopefully find some volunteers to write regression tests), then new APIs to existing classes will need to be considered carefully and implemented in extensions. So there will be some extension of IUIBase that has some new API instead of adding new APIs to IUIBase. I have a personal preference to use long names instead of numbers, so the extension will hopefully be called IUIBaseWithWhatever instead of IUIBase2. If you are asking about build-time versioning, we haven't done anything there either. As long as there is no impact on production apps I think it is fine for folks to contribute something if there is a need. My 2 cents, -Alex
RE: [Non-DoD Source] Re: Let's bump Royale version to 1.0
Well imagine a new user blindly walking into the site.They go to the root of the site [1] and see that nice orange "getting started" button. Clicking on that takes you to the getting started page [2]. It has a link to the download page and it has IDE links which is good. It would be nice if we added a few more links to things like examples and the ASDOC references. Then I would feel like it has a good start. Now the first thing that happens is we are sending people away from the main Royale site and onto GitHub to look up the IDE information. Are we using that as our main information sources now? I feel like we should keep everything on one place for information. Whether that is on apache or github doesn't matter as long as it's consistent. [1] https://royale.apache.org/ [2] https://royale.apache.org/getting-started/ -Mark K -Original Message- From: Carlos Rovira [mailto:carlosrov...@apache.org] Sent: Friday, April 26, 2019 4:52 AM To: dev@royale.apache.org Subject: [Non-DoD Source] Re: Let's bump Royale version to 1.0 Hi Mark, most of the points in your list should already done in the website, like download SDK, minimum requerimiento, IDE's available, examples of using components (this is blog examples and need more, but I'm the only one pushing this examples, this could be easy to solve if others want to commit blog post in the same way I did for new examples. The template is already done, or I can help in publishing it if people donates content. Other need more work: Starting a new App, ASDoc needs to be completed with new APIs, since right now is just a sub set and in this form is not useful for others. Latest point is complicated to have this days, since it implies people using Royale and sharing different techniques of integration.
Re: Let's bump Royale version to 1.0
To give a perspective on the references and examples part from our organization... When we started trying to convert one of our small apps we choose the Jewel set of components. This was because it had lots of visible content and examples [1] whereas the standard examples were more limited [2]. Carlos does a good job of advertising new features with pictures, short descriptions, and some examples. It would be nice to consolidate that information back into the Royale site. The Tour de Jewel examples being hosted on the Royale site is a good idea. This is why we used Jewel as our base to build our organizational library from. There might be other component sets that are fully functional, but without good references and examples they are basically unknown or gray boxes. The hosted ASDOCs on the Royale site [3] are a bit harder to read and are missing different component sets like jewel. We were not able to use it for finding most of the things we were looking for. Instead we used the SDK source and searched for class names / content. Then we could walk the class file source and their inheritance to find what we were looking for. Like hunting for premade beads. So if I were to order what a person might need to start (I know we have parts of this already): -How to download SDK binaries and get minimum requirements done. -What IDE's are available and how to set them up. -Starting a new app and getting it to compile for the first time. -Good reference (ASDOCs) being more complete. -Examples of using the components and how to use them. -Whole example applications showing a purpose and integration of multiple techniques. [1] https://royale.apache.org/tourdejewel/ [2] https://royale.apache.org/category/royale-examples/ [3] https://royale.apache.org/asdoc/ -Mark K
RE: Java newer licensing
I validated that it worked with Flex and Royale compilation. Overall it was an easy replacement. -Downloaded the OpenJDK from [1] and unzipped it into a folder. -Updated the JAVA_HOME environmental var. -The system path for the %JAVA_HOME%\bin folder stayed the same since it was already using a %var% name. I'm fine with choices, it turns out both the Oracle version and the Open version are mostly the same anyways. I just think we should update "Building Royale" docs like the README to include the download location for the Open version as well. Since the free Royale download should encourage a free Dependency download vice having the pay license version as the default. [1] https://jdk.java.net/12/ -Mark K -Original Message- From: Alex Harui [mailto:aha...@adobe.com.INVALID] Sent: Friday, April 19, 2019 12:07 AM To: dev@royale.apache.org Subject: [Non-DoD Source] Re: Java newer licensing IMO, it would be great for volunteers to validate that Royale compiles on Open JDK and later Java versions so users have a choice of those as well as Java 8 (for a little while longer), and fix any bugs to make it work on all 3. It would be best if we didn't have to pick one official version.
RE: Java newer licensing
Forgot to mention I'm bringing this up because of two points. 1. While the older versions Java will still be available, they are no longer will receive security updates. This causes future security risks and support for the older versions should be retired. 2. New versions of Java after January will require a license annually. So I was wondering if we move to the OpenJDK officially for the SDK instead of only requiring the paid licensing app? -Mark K -Original Message- From: Kessler CTR Mark J Sent: Thursday, April 18, 2019 8:23 AM To: dev@royale.apache.org Subject: Java newer licensing Our organization is in the process of figuring out how many licenses are needed for our clients and servers. This conversation however spilled over to our development environments as well. How is oracles new licensing [1][2] for Oracle Java SE / Oracle JDK going to affect us here for how we compile? Is it worth mentioning OpenJDK [3] since it is also maintained by Oracle folks and has a close parity of features to Oracles JDK? [1] https://www.oracle.com/technetwork/java/javase/overview/faqs-jsp-136696.html [2] https://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html [3] https://openjdk.java.net/ -Mark K
Java newer licensing
Our organization is in the process of figuring out how many licenses are needed for our clients and servers. This conversation however spilled over to our development environments as well. How is oracles new licensing [1][2] for Oracle Java SE / Oracle JDK going to affect us here for how we compile? Is it worth mentioning OpenJDK [3] since it is also maintained by Oracle folks and has a close parity of features to Oracles JDK? [1] https://www.oracle.com/technetwork/java/javase/overview/faqs-jsp-136696.html [2] https://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html [3] https://openjdk.java.net/ -Mark K
RE: includedInLayout
For the apps we create we use both cases. 1. Make something invisible, but not remove it's layout space. This matches Carlos's example, by allowed a static sized interface even when parts are not visible. 2. Make something invisible and remove it's layout space. Standard items, such as hiding interface / buttons / allowing things to collapse. We have used the "includeInLayout" and "visible" properties together to replace the states (includeIn and excludeFrom) in some use cases where we needed forms with fully created components on loading a popup. It was the only way to get our validation manager to work properly. For us, Flex states never really worked as intended for this scenario even when we tried the "creationPolicy='all '". It introduced quarks for component validation. But that doesn't seem to be a problem yet I'm ok with any method of doing these 2 (mean hidden and hidden without layout), just as long as we can do both. -Mark K
RE: text vs html
My guess is the bottom line would be, no matter what is chosen, do we allow them an easy way to get at the html properties directly. That would make a big difference to have to use a longer path to access for a less used property or have like 2 of every component. -Mark K
RE: text vs html
The "text" property is probably just for compatibility with the flex components if we are talking about things like "TextInput". Is the "text" property just syntax sugar / wrapping for the html property? -Mark K -Original Message- From: Carlos Rovira [mailto:carlosrov...@apache.org] Sent: Thursday, April 4, 2019 4:59 AM To: dev@royale.apache.org Subject: [Non-DoD Source] text vs html Hi in many components we have properties "text" and "html", and I was trying to figure what we need this duplicate currently. My bet is that just html (or text with html tags support) will be sufficient. Is there any need to have this double property, it seems to me not PAYG and html supports text with more things, so not reason for this, at least that I know thanks -- Carlos Rovira http://about.me/carlosrovira
RE: [Non-DoD Source] RE: Remote Object and Coldfusion
> How can I test this ? Is a way to replace this class and rebuild the sdk , > or I wait for tomorrow NB release ? At the bottom of the download page [1] there are links under the Nightly Builds section. This has the build packages that are close to what the officially released SDK has. The only change I had to do to get them working for me was to copy the packaged SWFs into the libs folder. [1] https://royale.apache.org/download/ -Mark K smime.p7s Description: S/MIME cryptographic signature
RE: CreationComplete event question
>That said, based on the code snippets provided, I'm not sure why >"initComplete" fired before addElement, which is what I think you are trying >to point out. I would expect it to be called in addElement, so further >investigation is needed there. Put a breakpoint in your "initComplete" >handler and see what the call stack is. addedToParent() should be on the call >stack. Correct I wasn't being clear enough. Yes the "initComplete" was firing before the addElement from our original problem. After setting up a new test application I couldn't produce it again. Manually deleted the debug folder of the other test app and rebuilt it, it was working fine. I think that quick compile/debug combo leaves debris sometimes. I checked the call stack anyways for the event handler "initComplete" and it had addedToParent in it. So well just blame the bin/output and the guy failing to manually cleaning it out (me) . Thank you for taking the time to respond. Sorry for the confusion. -Mark K -Original Message- From: Alex Harui [mailto:aha...@adobe.com.INVALID] Sent: Monday, April 1, 2019 12:29 PM To: dev@royale.apache.org Subject: [Non-DoD Source] Re: CreationComplete event question I haven't really followed this thread in detail so apologies if I'm missing the point. Hopefully, FlexJS/Royale has never promised 100% backward compatibility with Flex. That's because there are some fundamental differences in the runtimes/platforms. In Flash, if you change properties of a DisplayObject, the effects show up after all other code runs. In the browser, if you change properties on an HTMLElement, it shows up right away in many cases. So lifecycle events and invalidation are not being promised to work exactly as they did in Flex. It would add a lot of overhead to try to emulate the deferred rendering of Flash in the browser. "initComplete" in Royale isn't quite the exact same as "creationComplete" in Flex. Both give you a place to run some code as the component is initialized, but there may be subtle differences if you depended on deferred validation in Flex. That said, based on the code snippets provided, I'm not sure why "initComplete" fired before addElement, which is what I think you are trying to point out. I would expect it to be called in addElement, so further investigation is needed there. Put a breakpoint in your "initComplete" handler and see what the call stack is. addedToParent() should be on the call stack. HTH, -Alex
RE: [Non-DoD Source] Re: Plain public variables complain they don't have getters / setters (Was "CreationComplete event question")
smime.p7m Description: S/MIME encrypted message
RE: [Non-DoD Source] Re: CreationComplete event question
Carlos,
>my recommendation is not use such older version. Many many changes was done
>after 0.9.4.
Well for all of our official work, we can only use released SDK's, we
cannot use test / nightly SDK's to make stuff for production. So if I go to
our Royale download page [1], the latest version posted is 0.9.4. Which means
that's the only version we can make products with until a new version is
released.
>I think you should use a nightly build as a minimum (and if you plan to do
>Royale development seriously, my recommendation is you work with the latest
>develop branch, since we are improving and fixing in a day-by-day basic. Is
>strange the day we don't push new changes ;)
I know what you mean, I like the fact it's being updated all the time. But
to add extra complication (this is an internal organizational thing) GitHub
websites are blocked from work, so we cannot download anything from there while
at work. So if we wanted to just try out a nightly build I would have head out
to a third party network (Starbucks anyone?), download the nightly binaries,
and scan/authorized drive transfer to our isolated development area.
Could we get a new release cut sometime soon :P ?
>creationComplete does not exists. I think Alex could give more info about why
>is not.
>I must say that I *never* need that handler anymore, you can do almost all
with "initComplete". I think "this" is always available within a component,
so don't understand why a "initComplete" should not be valid for you. I
just needed in more complex scenarios to use "beadsAdded" handler, for
things in the life cycle of a component.
I agree, we've been very successful with the "initComplete" for everything else
so far, except having "this" the newly created object does not successfully
compare to a reference of itself ("this == storedReference"). Remember it
works with a button that is on the same card/group, so some sort of not fully
completed yet or timing issue. I might have to get a short example together
since it still happens on the nightly binaries.
Side notes:
-The nightly binaries do not have the SWC's in the "frameworks\libs" folder
they are under each project. Easy fix find *.swc and copy to the libs folder.
-VO's with plain public variables now complain they don't have getters /
setters. Not sure what to do about this. Disable warnings for this?
[1] https://royale.apache.org/download/
-Mark K
-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org]
Sent: Monday, March 25, 2019 5:54 PM
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: CreationComplete event question
Hi Mark,
going by parts:
El lun., 25 mar. 2019 a las 18:07, Kessler CTR Mark J
() escribió:
> Using Royal SDK 0.9.4 binaries with a Jewel Card / Basic Group
my recommendation is not use such older version. Many many changes was done
after 0.9.4.
I think you should use a nightly build as a minimum (and if you plan to do
Royale development seriously, my recommendation is you work with the latest
develop branch, since we are improving and fixing in a day-by-day basic. Is
strange the day we don't push new changes ;)
> and ran into an issue where the "this" reference is not ready / comparable
> while in an "initComplete" event handler. However after its full creation
> cycle it is available and can be compared. I tested with a button calling
> the same method as the initComplete did. Would have tried using a
> "creationComplete" handler, but the event doesn't seem to exist.
>
>
creationComplete does not exists. I think Alex could give more info about
why is not.
I must say that I *never* need that handler anymore, you can do almost all
with "initComplete". I think "this" is always available within a component,
so don't understand why a "initComplete" should not be valid for you. I
just needed in more complex scenarios to use "beadsAdded" handler, for
things in the life cycle of a component.
> Searched the email archive and found the thread "Where is the
> creationComplete in jewel ?", that states the init and completed events
> were combined. What is the new preferred way to get a creationComplete
> styled event or when it's 100% setup if the initComplete does not work or
> is that a bug?
>
if initComplete is not working for you I think that's a bug depending on
the scenario. Please describe the problem, the component that is
dispatching the initComplete and a simple handler so we can give more
details, if possible with a nightly build, since if not we can see
different things than you see.
>
>
> -Mark K
>
--
Carlos Rovira
http://about.me/carlosrovira
CreationComplete event question
Using Royal SDK 0.9.4 binaries with a Jewel Card / Basic Group and ran into an issue where the "this" reference is not ready / comparable while in an "initComplete" event handler. However after its full creation cycle it is available and can be compared. I tested with a button calling the same method as the initComplete did. Would have tried using a "creationComplete" handler, but the event doesn't seem to exist. Searched the email archive and found the thread "Where is the creationComplete in jewel ?", that states the init and completed events were combined. What is the new preferred way to get a creationComplete styled event or when it's 100% setup if the initComplete does not work or is that a bug? -Mark K
RE: PopUpManager question
Alex, I'll see if I can squeeze in sometime this week to make a basic one to contribute. I'm talking just the basic methods addPopUp, bringToFront, centerPopUp, createPopUp, removePopUp, and a few helper methods. That's the smallest amount of stuff to give the exact same methods as the Flex side and not be dependent on any of the old managers (like system manager). That should help support your less is more concept by not adding in all the extra weight we are adding to ours, but still be useful for migrations. So I image then you can do popups manually for small things with an general element adding / removing. However have the option to switch over to the basic PopUpManager for window ordering and modals with backdrops. -Mark K -Original Message- From: Alex Harui [mailto:aha...@adobe.com.INVALID] Sent: Thursday, March 21, 2019 9:01 PM To: dev@royale.apache.org Subject: [Non-DoD Source] Re: PopUpManager question HI Mark, If you want to contribute your PopUpManager to Royale or otherwise share it with others, that would be great. Royale will probably not have a single one-size-fits-all PopUpManager. Different implementations will hopefully become available as folks like you implement them. The Basic components have a Collection.swc that has an ArrayList that might serve as a starting point for your collection needs. HTH, -Alex
RE: PopUpManager question
Alex, > 1) It is hard to follow these threads without more context. I think Royale > is going to require that folks make it clear which components they are using. > Flex always had a primary set (MX then later, Spark) so we could make > assumptions about what components you are referencing. That makes sense, on our Flex side of the house we stayed as much as we could on the spark components. If you needed a complete listing of those we could produce one, but probably wouldn't be helpful in this thread since I was referencing Royale items and more specifically Jewel versions of them for the most part when I references the "Alert, PopUp, SnackBar, ToolTip" part. I was not being clear enough when talking about the Apache based projects vice our own corporate internal resources / libraries. I will work at being more clear between all of these but making references to Royale, Jewel, Flex, or Air for SDK clarity and can use terms like internal / organization for our end user requirements. > 2) The Basic components don't have a PopUpManager (yet) because nobody needed > one. Simple stacking and unstacking of popups doesn't require a > PopUpManager. In Basic you use org.apache.royale.utils.UIUtils. The > emulation (MXRoyale) set has a PopUpManager that tries to emulate the Flex > PopUpManager. I just saw it work. Jewel can have its own way of managing > popups. Our organizational popup management is more complicated than stacking and unstacking. We will require something that manages popups and layers / sets of popups. For issues we have seen internally such as having things like notifications appearing behind a modal popup because of the Flex PopUpManager opened the notification/popups at the same time. Or maybe there is a longer term notification showing file uploads / download status that needs to always be in the foreground. In the Flex side we added an additional manager which would correct layering issues by reordering items in the stack if it detected a problem, but that required something checking or updating after each popup or notification is created / removed. If we have to reinvent the wheel for our organization while using Royale we might create our own PopUpManager. We definitely will not use something that emulates the Flex PopUpManager since we could make one that handles all the different sets of layers we use to ensure certain types of popups are always on top regardless of the current stack. That would combine some of our managers and make it much more efficient for us internally. Array stacks like using zindexes in a way to keep certain items on top of each other. (Value ranges shown just for being descriptive of the concept) zIndex of 1000 - 1999 Standard popups and modal background layers. zIndex of 2000 - 2999 Notifications, toasts, and snackbar's layers. zIndex of 3000 - 4000 Critical application errors / complete stoppages / etc... > 3) mx.collections.ArrayList and mx.collections.ArrayCollection are emulations > of the Flex version. I'm not inclined to add new features to it. However, > there should be no hardcoding of those classes ?outside of the emulation > components, so folks not using the emulation set should be able to just use a > different collection implementation, and if they use the same classAlias, > Royale's AMF should be able to use it now that Greg got IExternalizable > working. So, if you want a different way of handling changes to the > collections, take a look at the Basic collections or write a new > implementation. In ?Royale, we want to try to make it such that there is no > one single implementation that everyone must use. Sounds like a good idea, we will just write our own organizational Collection class so we can add/remove functionality. We do not like the way Flex ListCollectionView did business with queued events in a giant pile (example being the private function handlePendingUpdates in ListCollectionView.as), we had to add special handling to some of our components that would ignore these events sent by a ListCollectionView and wait for a separate event to handle the changes. The only event that the ListCollectionView took into was the CollectionEventKind.UPDATE. It would create an array of those queued collection events and send out 1 event with all the changes in it. There are even comments in the ListCollectionView.as file describing a need to come back and optimize the way it handles events, because whom ever created that piece of code/sdk knew there could be times it would send out a large volume of events. I agree we don't need the Royale / SDK copy to be hard coded, it can stay the way it is now and is intended to be. Our internal organizational libraries will all be hard coded to standardize the features available. We chose to keep the bead strand usage because we liked the way the beads were encapsulating segments of code, so we hard
RE: PopUpManager question
>Take into account that Jewel already has most of the things you mention: >Alert, PopUp, SnackBar, ToolTip...maybe you just need to do some managers, >beads, or things that complete your needs. The Alert we cannot use at all because it uses a third party load (cloudflare) and is not baked in (we would like to not use pollyfill's anyways). We chose to intentionally build a new Alert because of that, which isn't a big deal, it's pretty much just a canned popup anyways. Our current test PopUpManager opens any UIBase component as a popup. We preferred this method to allow us a wider range of uses. Imagine clicking on a datagrid row item and it opens an image based buttonbar for options. Our notification system is more robust; it will queue / stack as needed while supporting hovering and delays. It uses an Interface to standardize handling the different types. Some notifications are simple success/warning/error/info/debug styled notifications that automatically disappear as needed. However some are persistent that manage complicated tasks for items like uploads / downloads / etc. and have user controls which are more like a snackbar which will only disappear once completed performing it's task or the user has performed an action with it. I liked the tooltip bead for controls, we will probably inherit it and make it center it's upper left (0,0 position) to make it appear where the mouse pointer was vice the current 4 corners + middle option. I will look into the Jewel.ToolTip for when we get to our charts (which will be a while from now) since we will still need to have multiple toolTips up at once. > We are about to share ArrayListView that is like ListCollectionView and > provides filtering and sorting using the MX classes (Sort, SortField) >Greg should share this today or tomorrow hopefully. > Just take into account. Remember that Jewel uses ArrayList instead of > ArrayCollection. And AMF is capable to use AL instead of AC > About addItem, removeItem, updateItem, remember as well that this is > implemented as beads. If you need the addItem functionality to add an item > to a List just add the bead. Good news! We will probably inherit it and hardcode all the beads in there (which we've done for quite a few controls already). That will help us standardize even if it goes against the PAYG philosophy. However the beads / strands make good code separation and replacement is easier when there is a base class inherited by new class adding permanent beads. BTW I would love a new feature in the collections. Just two methods or a getter / setter and a private variable. It would completely disable event dispatching. I'm not talking about the current event "pendingUpdates" feature in the ListCollectionView. I mean not call any event while it's disabled or process any queue after its re-enabled. If I perform a serious add/remove/update loop on a collection, I would like to manually call a reset event after the fact and not have an obscene amount of events trigger in a row. -Mark K -Original Message- From: Carlos Rovira [mailto:carlosrov...@apache.org] Sent: Wednesday, March 20, 2019 1:56 PM To: dev@royale.apache.org Subject: Re: [Non-DoD Source] Re: PopUpManager question Hi Mark, El mié., 20 mar. 2019 a las 17:52, Kessler CTR Mark J () escribió: > Carlos, > I did look into that. But it was too simplified for us as an > enterprise solution. We needed the holistic approach to all popup types; > it's the only way to keep the layers straight. Multi-level / layered > popups, alerts, notification handling / toasts / snackbar, and we will add > in a tooltip manager (for multiple active tooltips, imagine chart usage) to > it. This means several managed arrays for the different sets of layers; > would have preferred vectors over arrays. Whereas the flex side we only > had to add one additional manager for our notification / toast / snackbar > support and some side utils. > Take into account that Jewel already has most of the things you mention: Alert, PopUp, SnackBar, ToolTip...maybe you just need to do some managers, beads, or things that complete your needs. And if designed as a framework class/component you can submit as a Pull Request and propose to merge. Or better comment first here and propose additions. In that way we continue growing as a project and as a community > > BTW I do appreciate the work you've (and others) put into Jewel. It's > looking good. We actually use it as a base right now for testing and > modify it for our needs from there. Great to know others are already using Jewel! :) > Our goal at this point is get the basics done in the royale side and redo > some of our libraries so it can be used on either royale or the air / flex > side. We came to the realization that the layout from the CS
RE: [Non-DoD Source] Re: PopUpManager question
Carlos, I did look into that. But it was too simplified for us as an enterprise solution. We needed the holistic approach to all popup types; it's the only way to keep the layers straight. Multi-level / layered popups, alerts, notification handling / toasts / snackbar, and we will add in a tooltip manager (for multiple active tooltips, imagine chart usage) to it. This means several managed arrays for the different sets of layers; would have preferred vectors over arrays. Whereas the flex side we only had to add one additional manager for our notification / toast / snackbar support and some side utils. BTW I do appreciate the work you've (and others) put into Jewel. It's looking good. We actually use it as a base right now for testing and modify it for our needs from there. Our goal at this point is get the basics done in the royale side and redo some of our libraries so it can be used on either royale or the air / flex side. We came to the realization that the layout from the CSS side of things is too powerful to be held back by trying to use flex/air styled layout. So the views we have just will not work on both sides of the house. We will however work to keep the business logic the same, but it means creating things on the royale side that are missing to match previous features. Next up will work on Collections (ArrayCollection and VectorCollection) since we use those heavily. We use the events, sorting, filtering, addItem, contains, disable/enable autoupdate, getItemAt, itemUpdated, refresh, removeItemAt, setItemAt, and interface ICollecitonView references features. Well that's if we have some time left on it this week. I have to swap projects again next week and back on to main support for a few more weeks then I'll see if I can squeeze in more time here again. -Mark K -Original Message- From: Carlos Rovira [mailto:carlosrov...@apache.org] Sent: Wednesday, March 20, 2019 11:30 AM To: dev@royale.apache.org Subject: [Non-DoD Source] Re: PopUpManager question Hi Mark, In Jewel there's a PopUp component. You can see it working in Tour De Jewel here: http://royale.apache.org/tourdejewel/ (is one of the latest options in the drawer menu on the left) Carlos El mié., 20 mar. 2019 a las 15:50, Kessler CTR Mark J () escribió: > Never mind, Figured it out. I'll switch over to using this style. > > container.element.style.zIndex; > > > > -Mark K > > -Original Message----- > From: Kessler CTR Mark J > Sent: Wednesday, March 20, 2019 7:57 AM > To: dev@royale.apache.org > Subject: PopUpManager question > > I finally got a chance to get back to testing out a conversion of one of > small apps. I only have this week to work on it. We couldn't find a > working PopUpManager, so we created one. It works pretty good however we > tried to update the z-index on the popup directly using a style, but > something is stripping out our "z-index:" property. It is not stripping > any of our other CSS properties. > > What is the best way to change the CSS styles directly on a container? > > > -Mark K > -- Carlos Rovira http://about.me/carlosrovira
RE: PopUpManager question
Never mind, Figured it out. I'll switch over to using this style. container.element.style.zIndex; -Mark K -Original Message- From: Kessler CTR Mark J Sent: Wednesday, March 20, 2019 7:57 AM To: dev@royale.apache.org Subject: PopUpManager question I finally got a chance to get back to testing out a conversion of one of small apps. I only have this week to work on it. We couldn't find a working PopUpManager, so we created one. It works pretty good however we tried to update the z-index on the popup directly using a style, but something is stripping out our "z-index:" property. It is not stripping any of our other CSS properties. What is the best way to change the CSS styles directly on a container? -Mark K
PopUpManager question
I finally got a chance to get back to testing out a conversion of one of small apps. I only have this week to work on it. We couldn't find a working PopUpManager, so we created one. It works pretty good however we tried to update the z-index on the popup directly using a style, but something is stripping out our "z-index:" property. It is not stripping any of our other CSS properties. What is the best way to change the CSS styles directly on a container? -Mark K
RE: [Non-DoD Source] Re: Things that we still doesn't have and need in UIBase sizing
I'm slow getting to these emails, so if I've missed any, I apologize.
After this last two weeks I've come to the realization that the FlexBox CSS
style is greatly more flexible(no pun intended twice) than most of what we have
in AS. I could write a pile of examples for most common layouts if it had
enough interest. These were styles I ended up assigning using CSS selectors
assigned to MXML via the className property. I could even fix formatting
issues I was having in Jewel by overriding the styles this way.
If you really wanted to use a max width without adding coding overhead to the
SDK you could just add in CSS file selector to use max-width.
.MyStyle
{
Max:width: 200px;
}
It would cut off any overflow by default. If you'd prefer you could use the
"flex-wrap: wrap" to have it wrap the children in the cross axis direction.
I'll have to add more to the email later on, but this part can go out now.
Could make a very large wiki page on layout in MXML with the flexbox logic.
-Mark K
-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org]
Sent: Thursday, January 10, 2019 2:50 PM
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: Things that we still doesn't have and need in
UIBase sizing
Hi Mark,
thanks for joining to the discussion:
El jue., 10 ene. 2019 a las 20:31, Kessler CTR Mark J
() escribió:
>
> Back on topic, I was able to avoid using max size declarations by adding
> in CSS to utilize the flex-box CSS alignments to fill and distribute sizes.
>
Very interesting, could you provide some code example so I can understand
the concept? I'm interested in that technique
thanks
--
Carlos Rovira
http://about.me/carlosrovira
RE: Using em vs px (was. Re: Things that we still doesn't have and need in UIBase sizing)
In firefox you can change the setting by clicking on View -> Zoom -> Checking the Zoom Text Only feature. In Chrome I see there is an extension you can add to do this [1], but I could not find a native control in chrome. Then you can zoom in and out with your normal CTRL+MouseWheel but it will only be the text. This can also be a native feature with certain OS level text size settings that some browsers inherit that too via the OS text size percentage change or an accessibility feature change for text size. Below is a small app [2] to demonstrate the issue. When text zooming is enabled, you'll see the cards PX width stay static in size when the text is resized. However the em version scales with the text. I made a tiny function for this example to also demonstrate a programmatic way to convert from PX to EM as needed. Does this help explain better ? If not I could try some screen shots instead, not sure if they would get stripped. Thanks again! [1] https://chrome.google.com/webstore/detail/zoom-text-only/jamhfhbppcmkgghlkeieococonlbppjg?hl=en-US [2] http://ns.adobe.com/mxml/2009; xmlns:j="library://ns.apache.org/royale/jewel" applicationComplete="onApplicationComplete()" > -Mark K -Original Message- From: Carlos Rovira [mailto:carlosrov...@apache.org] Sent: Thursday, January 10, 2019 2:58 PM To: dev@royale.apache.org Subject: [Non-DoD Source] Using em vs px (was. Re: Things that we still doesn't have and need in UIBase sizing) Hi Mark, renaming this since I thing is very different topic. I must say that I don't understand completely what you are trying to share, But I'm completely open to make changes from px to em or viceversa if we get a better result. So first: El jue., 10 ene. 2019 a las 20:31, Kessler CTR Mark J () escribió: > I have a side question on this topic of size and size properties. I'm > just finishing up a 10 day test conversion of a small application interface > and was surprised to see us use PX a lot in the layout when it's on the JS > side of things. I was specifically using the jewel set to test with. When > I scaled the application it still looked acceptable, however if only the > font-size / text size was changed (via accessibility or browser setting) > then everything scaled poorly. I tried in Chrome (for example) to do CMD+ and CMD- to increase/decrease font size and things scale right for me. Maybe you are referring to another kind of size changes? > I overrode a good chunk of CSS by applying each new css file as a theme in > order I wanted them to override each other. What I changed was PX > references to EM. EM is based on the font-size by 1px font = 1/16 of EM. > So a font-size 16px would be a natural 1EM. Then the font-size scaling and > the regular scaling both worked. > I think you share your changes I can try in JewelTheme and if valid I can integrate it...maybe a PR? As I worked this latest months with Jewel I'm finding I need to do some adjustments to font, icon and some other sizes so different combinations play nice together. Is something I have in my TODO list, but since I'm finishing our first Royale App, I'm very busy for that now. Hope in few days/weeks do that... > > Would it be feasible to make the PX assignments on the JS side get run > through a static function to convert it to EM instead? > I think I need here that you share in some code example what you have in mind...can't figure just with that phrase, sorry. Thanks for sharing Mark! :) > > -Mark K > > -- Carlos Rovira http://about.me/carlosrovira
RE: [Non-DoD Source] Re: Jewel alert.as
Thanks for update. Can we have the file stored in the SDK instead hosting
outside on another domain. In our case the file never gets loaded because it's
pulling from an another a domain the client does not have access to [1]. But
if it were in the SDK it would get compiled with the app and it would always be
available.
[1] "Loading failed for the with source" ...
-Mark k
-Original Message-
From: Carlos Rovira [<a rel="nofollow" href="mailto:carlosrov...@apache.org">mailto:carlosrov...@apache.org</a>]
Sent: Thursday, January 10, 2019 3:02 PM
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: Jewel alert.as
You mean this:
/**
* constructor.
*
* <inject_html>
* <link rel="stylesheet" type="text/css" href="
<a rel="nofollow" href="https://cdnjs.cloudflare.com/ajax/libs/dialog-polyfill/0.4.9/dialog-polyfill.min.css">https://cdnjs.cloudflare.com/ajax/libs/dialog-polyfill/0.4.9/dialog-polyfill.min.css</a>
">
* <script src="
<a rel="nofollow" href="https://cdnjs.cloudflare.com/ajax/libs/dialog-polyfill/0.4.9/dialog-polyfill.min.js">https://cdnjs.cloudflare.com/ajax/libs/dialog-polyfill/0.4.9/dialog-polyfill.min.js</a>
">
*
*
* @langversion 3.0
* @playerversion Flash 10.2
* @playerversion AIR 2.6
* @productversion Royale 0.9.4
*/
public function Alert()
{
super();
typeNames = "jewel alert";
}
Alert component uses a polyfill of Dialog and that needs both the js and
the css of that pollyfill that we retrieve from cloud flare.
The inject_html makes that two lines be added to the index.html so it will
be available to use in the application.
thanks
El jue., 10 ene. 2019 a las 20:34, Kessler CTR Mark J
() escribió:
> The 0.9.4 release has a Alert.as [1] file on the ASDOC comment for the
> constructor has a cloudflare referenced CSS. Is a third party direct
> reference supposed to be in there?
>
>
> [1] projects/Jewel/src/main/royale/jewel/Alert.as
>
> -Mark K
>
--
Carlos Rovira
http://about.me/carlosrovira
Jewel alert.as
The 0.9.4 release has a Alert.as [1] file on the ASDOC comment for the constructor has a cloudflare referenced CSS. Is a third party direct reference supposed to be in there? [1] projects/Jewel/src/main/royale/jewel/Alert.as -Mark K
RE: Things that we still doesn't have and need in UIBase sizing
I have a side question on this topic of size and size properties. I'm just finishing up a 10 day test conversion of a small application interface and was surprised to see us use PX a lot in the layout when it's on the JS side of things. I was specifically using the jewel set to test with. When I scaled the application it still looked acceptable, however if only the font-size / text size was changed (via accessibility or browser setting) then everything scaled poorly. I overrode a good chunk of CSS by applying each new css file as a theme in order I wanted them to override each other. What I changed was PX references to EM. EM is based on the font-size by 1px font = 1/16 of EM. So a font-size 16px would be a natural 1EM. Then the font-size scaling and the regular scaling both worked. Would it be feasible to make the PX assignments on the JS side get run through a static function to convert it to EM instead? Back on topic, I was able to avoid using max size declarations by adding in CSS to utilize the flex-box CSS alignments to fill and distribute sizes. -Mark K
RE: Official Hack Proposal (was Re: [royale-asjs] branch develop updated: Fix implicit coercion error)
I'm all for strongly typed / static typed everything when available for compile and run times. However here is some side information on the ECMA (2015) typed arrays[1] and the ongoing discussion / notes for the full static type implementation [2] that was proposed by Sirisian's (pretty detailed). The intent being to just offer information of what years down the road might look like. [1] https://tc39.github.io/ecma262/#sec-typedarray-objects [2] https://github.com/sirisian/ecmascript-types -Mark K
