Re: Mobile vs Desktop diferences in components (Was: Re: Restarting contributions)

[Carlos Rovira]

Hi Alex,

that sounds very good to me and is where Apache Royale *magic* is. So, I
think it would be great to make our CSS to handle devices and/or OS in
order to have all possible flavors and be able to compile targeting some
device or OS

Thanks!




2017-11-03 18:06 GMT+01:00 Alex Harui :

> Hi Carlos,
>
> I agree, which is why I mentioned potentially extending media query, which
> is what Flex did, IIRC.
>
> The way Royale handles CSS today is that the compiler generates a .CSS
> file that is meant to be CSS compliant.  If you look at our CSS source
> files, they contain non-compliant things like ClassReference() and
> ILayoutBead that the browser doesn't handle.  So these things are removed
> by the compiler.  But the CSS is also encoded into a data structure (for
> both SWF and JS) that is understood by framework code, and that's where
> the ILayoutBead references a class since it is only framework code that
> cares.
>
> I think it is possible for us to allow certain new media query rules if
> they only affect the data structure and not the final CSS file.  I think
> you could then use that to load a bead that has a specific classname that
> the complaint CSS affects.
>
> Of course, that will take some work to make it happen.
> -Alex
>
> On 11/3/17, 8:00 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> 
> wrote:
>
> >Hi Alex,
> >
> >ok, I wasn't thinking about CSS beads, so I think we have the technical
> >solution already in place.
> >I think CSS with media queries is very interesting since we can plug one
> >bead or another regarding size of the screen
> >We should as well think if this is all what we want to do. I mean that a
> >very stretched browser could mean we are on mobile, but as well that
> >user on desktop resize the browser to some minimun. So, for example I
> >don't
> >know if we could decide if use touch vs mouse based on media queries
> >maybe would be better based on platform code...
> >
> >Thanks!
> >
> >
> >2017-11-03 3:00 GMT+01:00 Alex Harui :
> >
> >> Hi Carlos,
> >>
> >> Because we use CSS to choose beads, I think it might be possible to
> >>choose
> >> different views, layouts, etc based on media query.
> >> If there is some other popular way of reconfiguring layouts in JS we can
> >> certainly try to leverage that as well or instead.
> >>
> >> Of course, I could be wrong...
> >> -Alex
> >>
> >> On 11/2/17, 4:43 PM, "carlos.rov...@gmail.com on behalf of Carlos
> >>Rovira"
> >>  wrote:
> >>
> >> >Alex,
> >> >
> >> >for sizing and look and feel, yes, I propose media queries, I think
> >>this
> >> >is
> >> >what makes usable to use the same button component (or checkbox, radio,
> >> >tooglebutton,)
> >> >In the other hand there are other issues that should be managed with
> >>other
> >> >techniques. For example would tooltips be in desktop but no on mobile?
> >>Or
> >> >dateField would have a layout for desktop and other completly different
> >> >with some kind of spinner on mobile? For this kind of different
> >>behaviours
> >> >I think we would need (far beyond CSS media queries) logic and
> >>conditional
> >> >compilation.
> >> >
> >> >That's my idea, but maybe other have other point of view
> >> >
> >> >Thanks
> >> >
> >> >
> >> >2017-11-03 0:07 GMT+01:00 Piotr Zarzycki :
> >> >
> >> >> One thought which come up to my mind reading Harbs is - Maybe if
> >>adding
> >> >> touch  events natively its to hard or a lot of sacrifacies we should
> >> >> consider to find solid library for that purpose, but licensed under
> >> >>Apache
> >> >> License. Make it part of our effort.
> >> >>
> >> >> Piotr
> >> >>
> >> >> On Thu, Nov 2, 2017, 23:58 Harbs  wrote:
> >> >>
> >> >> > FYI, My PrintUI app supports touch events.
> >> >> >
> >> >> > Eventually, we’re going to change the UI (i.e. simplify some
> >>things)
> >> >>for
> >> >> > phones, but right now, the UI works fine for both desktop and
> >>tablets.
> >> >> >
> >> >> > The touch support was added by using hammer.js.[1]
> >> >> >
> >> >> > The basics for adding that support was basically:
> >> >> >
> >> >> > #1 detect whether the browser supports touch. (Non-touch displays
> >>are
> >> >> > simpler and I’m enabling a couple of extra features):
> >> >> > if (('ontouchstart' in window) ||
> >> >>window["navigator"]["maxTouchPoints"]
> >> >> ||
> >> >> > window["navigator"]["msMaxTouchPoints"]) {
> >> >> > getHammer(background);
> >> >> > } else {
> >> >> > window.addEventListener('mouseup', handleMouseUp, false);
> >> >> > background.addEventListener(MouseEvent.MOUSE_MOVE,handleMove);
> >> >> >
> >> >> > background.addEventListener(MouseEvent.MOUSE_DOWN,
> >> >> handleBackgroundMouseDown);
> >> >> > background.addEventListener(MouseEvent.DOUBLE_CLICK,
> >> >> handleDoubleClick);

Re: Working on UI Controls styling

[Carlos Rovira]

HI Alex,


2017-11-03 17:52 GMT+01:00 Alex Harui :

> Hi Carlos,
>
> I skimmed through https://material.io/guidelines/# last night.
>
> My impression is that there were two parts to it.  First was the
> environment/principles section which talked about physical objects and
> light (and motion), and then there were choices of widgets.  For example,
> I didn't see anything in the first part that said that a text input had to
> be a single line and couldn't be a box.
>

Material guidelines could be a great way to start, but trying to give
something different.
I think that we need to get something that looks great while be clearly
different to google material,
bootstrap, and others so people could see us as an alternative. That could
make people copying us
or adopting the whole Apache Royale SDK that is what we want in the end



>
> That made me think that we could use our widget set and apply Material
> environment and principles to it.  If we decide not to, I would think you
> would want to have some sort of similar environment/principles document
> which seems like a fair amount of work.  I think we'd end up looking
> different because we have different widgets and maybe some different
> colors.  I'm pretty sure that we don't want to be different so much that
> we don't create things that folks want to use.  The priority to me is just
> to prove that you can alter every pixel in every widget we have so that
> others can provide custom skins as well.  So starting with Material
> principles seems like it would save us time, we can get something
> released, and can innovate more later.
>

I think as you that we need a way to make the "presentation" of each
component highly customizable.
And we need to be different in visualization (art, colors, ...) but not in
usability that is what people
needs to be consistently



>
> Maybe a good question for our users is:  How many of you used the default
> Flex skins vs a whole new set of skins?  If most folks completely
> re-skinned to match their corporate branding, it matters less what our
> default is, and more that we can allow folks to customize every pixel.
>
>
We need both: a skin that will be highly customizable and to change skins
to look very very different.
People with lees money or time in their Apps will choose the first. People
that has more resources will go with the second.
Apache Royale needs to support both


> The wireframe can be black and white, IMO.  I was thinking that "vivid"
> would have parameterized colors.
>
>
I started to think that wireframe could end having lots of customization
controls. For example:

-2-3 main colors as we talked , and the same MDL does
-possibilitiy to be solid colors, or gradients
-possibility to have backgrounds more or less opaque

if we see a concrete component like button:

- configurable corners, square to round corners
- more blocky (relief) or more flat
...

So wireframe could be a concrete configuration of the main theme



> Since Bootstrap was mentioned, I want to point out that the Flat.swc is a
> rough approximation of the Flat theme which is a Bootstrap theme.  It is a
> rough approximation because I could not use the Flat CSS file directly
> since it contains much more advanced CSS than we currently support on the
> SWF side.  But it presumed that the Checkbox was a Label with a Span that
> hides in front of or behind the  in order to allow
> customizing every pixel.  Looks like MDL uses the same Span trick but
> maybe without a symbol font.
>
> Basic is, IMO, truly meant to be Basic.  I think the Basic Checkbox should
> not have that extra Span.  But it looks to me that a SkinnableCheckbox can
> add that extra Span and you either give it the same class name that
> BootStrap or MDL uses or create our own set of classnames and the CSS that
> goes with it.
>
>
The problem with Basic could be that if is very very basic and looks with a
very basic look (as it is very poorly stylizable), I think
People will not use it at all, in this case, I'll don't understand the goal
with basic. It's intend ended as a base
but to not use in production? For this reason is what I want to know if you
think this theme feature could be plugged in basic or not.




> Of course, I could be wrong.  This is not my area of expertise at all.
>

Hi Alex, maybe UX is not your expertise area, but your help here is very
needed since we can get to great ideas in this field, but
maybe don't know how to bring it to implementation in Apache Royale. I
think that you, Peter, Harbs,... are needed in order to
make this happen in the pure arquitecture side or this feature.

Thanks

-Alex
>
>
> On 11/3/17, 1:35 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> 
> wrote:
>
> >Hi Alex,
> >
> >2017-11-03 7:39 GMT+01:00 Alex Harui :
> >
> >> Hi Carlos,
> >>
> >> Looks good to me.  Thanks for doing this.
> >>
> >
> >Thanks 

Re: Working on UI Controls styling

[Piotr Zarzycki]

Carlos,

I just wanted to point to your last sentences. I think we don't know for
sure what can we do with Basic. Let's go and try if we came up that
something is not achievable let's discuss what need to be done.

Piotr

On Sat, Nov 4, 2017, 16:19 Carlos Rovira  wrote:

> HI Alex,
>
>
> 2017-11-03 17:52 GMT+01:00 Alex Harui :
>
> > Hi Carlos,
> >
> > I skimmed through https://material.io/guidelines/# last night.
> >
> > My impression is that there were two parts to it.  First was the
> > environment/principles section which talked about physical objects and
> > light (and motion), and then there were choices of widgets.  For example,
> > I didn't see anything in the first part that said that a text input had
> to
> > be a single line and couldn't be a box.
> >
>
> Material guidelines could be a great way to start, but trying to give
> something different.
> I think that we need to get something that looks great while be clearly
> different to google material,
> bootstrap, and others so people could see us as an alternative. That could
> make people copying us
> or adopting the whole Apache Royale SDK that is what we want in the end
>
>
>
> >
> > That made me think that we could use our widget set and apply Material
> > environment and principles to it.  If we decide not to, I would think you
> > would want to have some sort of similar environment/principles document
> > which seems like a fair amount of work.  I think we'd end up looking
> > different because we have different widgets and maybe some different
> > colors.  I'm pretty sure that we don't want to be different so much that
> > we don't create things that folks want to use.  The priority to me is
> just
> > to prove that you can alter every pixel in every widget we have so that
> > others can provide custom skins as well.  So starting with Material
> > principles seems like it would save us time, we can get something
> > released, and can innovate more later.
> >
>
> I think as you that we need a way to make the "presentation" of each
> component highly customizable.
> And we need to be different in visualization (art, colors, ...) but not in
> usability that is what people
> needs to be consistently
>
>
>
> >
> > Maybe a good question for our users is:  How many of you used the default
> > Flex skins vs a whole new set of skins?  If most folks completely
> > re-skinned to match their corporate branding, it matters less what our
> > default is, and more that we can allow folks to customize every pixel.
> >
> >
> We need both: a skin that will be highly customizable and to change skins
> to look very very different.
> People with lees money or time in their Apps will choose the first. People
> that has more resources will go with the second.
> Apache Royale needs to support both
>
>
> > The wireframe can be black and white, IMO.  I was thinking that "vivid"
> > would have parameterized colors.
> >
> >
> I started to think that wireframe could end having lots of customization
> controls. For example:
>
> -2-3 main colors as we talked , and the same MDL does
> -possibilitiy to be solid colors, or gradients
> -possibility to have backgrounds more or less opaque
>
> if we see a concrete component like button:
>
> - configurable corners, square to round corners
> - more blocky (relief) or more flat
> ...
>
> So wireframe could be a concrete configuration of the main theme
>
>
>
> > Since Bootstrap was mentioned, I want to point out that the Flat.swc is a
> > rough approximation of the Flat theme which is a Bootstrap theme.  It is
> a
> > rough approximation because I could not use the Flat CSS file directly
> > since it contains much more advanced CSS than we currently support on the
> > SWF side.  But it presumed that the Checkbox was a Label with a Span that
> > hides in front of or behind the  in order to allow
> > customizing every pixel.  Looks like MDL uses the same Span trick but
> > maybe without a symbol font.
> >
> > Basic is, IMO, truly meant to be Basic.  I think the Basic Checkbox
> should
> > not have that extra Span.  But it looks to me that a SkinnableCheckbox
> can
> > add that extra Span and you either give it the same class name that
> > BootStrap or MDL uses or create our own set of classnames and the CSS
> that
> > goes with it.
> >
> >
> The problem with Basic could be that if is very very basic and looks with a
> very basic look (as it is very poorly stylizable), I think
> People will not use it at all, in this case, I'll don't understand the goal
> with basic. It's intend ended as a base
> but to not use in production? For this reason is what I want to know if you
> think this theme feature could be plugged in basic or not.
>
>
>
>
> > Of course, I could be wrong.  This is not my area of expertise at all.
> >
>
> Hi Alex, maybe UX is not your expertise area, but your help here is very
> needed since we can get to great ideas in this field, but
> maybe don't know how to bring 

Re: Mobile vs Desktop diferences in components (Was: Re: Restarting contributions)

[Carlos Rovira]

Hi, for me states are something very concrete and I don't see too much
relation with what we want to get about discriminate layout for different
kind of devices
states seems to me more widely uses to handle application states that are
not dependent on how the app is visualized. For that reason I see better
that all this kind of things go to CSS

that's my 2ctn


2017-11-04 8:21 GMT+01:00 Alex Harui :

> Hmm.  That looks more like States than media query.  It brings up the
> question of how much of the visuals should be in CSS vs in MXML.  Royale
> should someday be able to do this same sort of thing via CSS Media Query.
> I think it would look something like:
>
> MXML:
>   
>
> CSS:
>
>   @media (max-width: 500px) {
>  .rowOrColumnDiv {
> ILayoutBead : ClassReferences(ColumnLayout);
>  }
>   }
>
>   .rowOrColumnDiv {
> ILayoutBead : ClassReferences(RowLayout);
>   }
>
> And thus, more of the visuals are dictated in CSS.
>
>
> I have been wondering if there is some way to extend States to do
> something like this though.  One problem with States is the combinations.
> States are supposed to represent the workflow states, not display states.
> So you might have:
>
> 
> 
>
> But it gets messy when you add another "dimension" like display size:
>
> 
> 
> 
> 
>
> And also want to add, for example, Android vs IOS states.
>
>
>
> 
> 
> 
>
> 
> 
> 
>
> There are things like StateGroups, but it still seems messy.  So one
> option that someone could investigate is adding another property like
> "displayState" and when it changes, look up the StateDescriptors and apply
> them.  Then you could have MXML like:
>
>
>
> Of course, I could be wrong...
> -Alex
>
> On 11/3/17, 2:58 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala"
>  wrote:
>
> >We might need to extend or wrap around css-media-queries.
> >
> >For example Angular Material does this for layouts [1]:
> >
> >  
> >  
> >  
> >
> >
> >This causes a vertical layout on screens less than xs (i.e. width < 600px)
> >and a horizontal layout on screens bigger than 600px.  By using two
> >attributes, we have made this component responsive.
> >
> >From what Alex mentioned, it seems like we can add this kind of
> >funtionality to Royale?  How exactly would that work here?
> >
> >Thanks,
> >Om
> >
> >[1]
> >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaterial
> .
> >angularjs.org%2Flatest%2Flayout%2Fcontainer=02%
> 7C01%7C%7Cb954fc85de8d
> >4bacf85908d523060d98%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C63645343
> >1260275371=r%2B7Qq%2FihOJkm35aZUr26flh0PHNKMtC1v4
> RuVXUGNMw%3D
> >ed=0
> >
> >
> >On Fri, Nov 3, 2017 at 10:06 AM, Alex Harui 
> >wrote:
> >
> >> Hi Carlos,
> >>
> >> I agree, which is why I mentioned potentially extending media query,
> >>which
> >> is what Flex did, IIRC.
> >>
> >> The way Royale handles CSS today is that the compiler generates a .CSS
> >> file that is meant to be CSS compliant.  If you look at our CSS source
> >> files, they contain non-compliant things like ClassReference() and
> >> ILayoutBead that the browser doesn't handle.  So these things are
> >>removed
> >> by the compiler.  But the CSS is also encoded into a data structure (for
> >> both SWF and JS) that is understood by framework code, and that's where
> >> the ILayoutBead references a class since it is only framework code that
> >> cares.
> >>
> >> I think it is possible for us to allow certain new media query rules if
> >> they only affect the data structure and not the final CSS file.  I think
> >> you could then use that to load a bead that has a specific classname
> >>that
> >> the complaint CSS affects.
> >>
> >> Of course, that will take some work to make it happen.
> >> -Alex
> >>
> >> On 11/3/17, 8:00 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >>Rovira"
> >> 
> >> wrote:
> >>
> >> >Hi Alex,
> >> >
> >> >ok, I wasn't thinking about CSS beads, so I think we have the technical
> >> >solution already in place.
> >> >I think CSS with media queries is very interesting since we can plug
> >>one
> >> >bead or another regarding size of the screen
> >> >We should as well think if this is all what we want to do. I mean that
> >>a
> >> >very stretched browser could mean we are on mobile, but as well that
> >> >user on desktop resize the browser to some minimun. So, for example I
> >> >don't
> >> >know if we could decide if use touch vs mouse based on media queries
> >> >maybe would be better based on platform code...
> >> >
> >> >Thanks!
> >> >
> >> >
> >> >2017-11-03 3:00 GMT+01:00 Alex Harui :
> >> >
> >> >> Hi Carlos,
> >> >>
> >> >> Because we use CSS to choose beads, I think it might be possible to
> >> >>choose
> >> >> different views, layouts, etc based on media query.
> >> >> If there is some other popular way 

Re: Unit Tests et. al.

[Greg Dove]

Harbs, I don't know if it still works since changes to Royale, but I had
something rudimentary for cross-target unit testing quite shortly after
working on the reflection support last year, in fact that was my primary
reason for choosing to focus on reflection at the time.

It was visual output only (i.e. just to look at the test results output in
the browser) and the goal was to get some compatibility with flexunit (so
that the same swf-based flexunit tests that were running in the build -e..g
BinaryData tests- could be run visually side by side between swf and js).
I also added a new TestVariance metadata to account for known (expected?)
variation between swf and js. This was needed to cover (for example) things
like testing Reflection classes themselves, where the results can be
different between the targets based on the 'native' base classes (e..g
EventDispatcher inheritance chain).

Some of that code might also be useful to harvest for what you are doing,
I'm not sure...

It's here:
https://github.com/apache/royale-asjs/tree/develop/manualtests/UnitTests



On Sun, Nov 5, 2017 at 7:30 AM, Harbs  wrote:

> Awesome!
>
> I assume that this means I can code the code to the Royale repo under
> Apache 2. Right?
>
> Harbs
>
> > On Nov 3, 2017, at 5:37 PM, Josh Tynjala  wrote:
> >
> > Please feel free to use my test runner. I'm happy to commit it somewhere
> to make it official Apache code, if necessary.
> >
> > - Josh
> >
> > On 2017-11-03 04:19, Harbs  wrote:
> >> One topic which keeps coming up is better test coverage for Royale.
> >>
> >> I think this is becoming a critical issue for a few reasons:
> >> 1. As we get close to version 1.0 it’s necessary to have good test
> coverage for confidence of quality and confidence that we don’t introduce
> recessive bugs.
> >> 2. It’s really hard to accept Github pull requests without examining
> the code VERY well that it does not introduce recessive bugs. CI which runs
> automated tests could give a preliminary test on pull requests to ensure
> that they don’t break anything. If the pull requests do break something,
> it allows the requester to fix the problem with confidence without taking
> others’ time.
> >>
> >> I think we need to break up testing into pieces and figure out a
> strategy to implement automated tests in a way that they are maintainable.
> >>
> >> Some points:
> >> 1. I think integration into something like Travis would be very helpful.
> >> 2. I think there’s a Jenkins plugin for building pull requests. Not
> sure how useful it is.[1]
> >> 3. Josh has created a Node.js-compatible test-runner architecture which
> could be useful for unit tests on parts of the framework which don’t rely
> on browser features. (i.e. models and the like) He mentioned the
> possibility of donating it, and I think that would be a very useful feature.
> >> 4. For UI and integration tests, there seem to be some pretty cool
> integrations using Selenium.[2][3]
> >> 5. I think the main testing effort needs to be using JS and something
> like Josh’s testing framework for non-UI pieces and some easy-to-use
> Selenium integration for visual pieces and integration tests.
> >> 6. We probably also want some API endpoints we can test off of for
> integration testing.
> >>
> >> I’m willing to invest time into this.
> >>
> >> It’s going to be a lot of work building out the tests and I think we
> need a plan for that. My thoughts:
> >>
> >> 1. Step one is to make it easy to write meaningful automated tests and
> establish a clear pattern.
> >> 2. Step two is to start writing tests starting from the
> most-used/easiest to beak pieces and work out from there.
> >> 3. Once the pattern is established, any new pieces MUST have testing
> coverage.
> >> 4. When fixing bugs, attention should be paid to adding testing for
> that component.
> >> 5. When a pull request comes in on a piece which does not have unit
> test, a test must be written before accepting the pull request. The test
> does not need to be written by the requester. Before examining the request,
> the test should be written to pass for expected behavior and fail for the
> bug that the pull request is attempting to fix (assuming the pull request
> is to fix a bug).
> >>
> >> Thoughts?
> >> Harbs
> >>
> >> P.S. I’m thinking of coming to the US in late December/early January.
> I would be interested in getting together for a hacking session with folks
> who are available.
> >>
> >> [1]https://wiki.jenkins.io/display/JENKINS/GitHub+pull+
> request+builder+plugin  display/JENKINS/GitHub+pull+request+builder+plugin>
> >> [2]https://docs.travis-ci.com/user/gui-and-headless-browsers/ <
> https://docs.travis-ci.com/user/gui-and-headless-browsers/>
> >> [3]https://saucelabs.com/products/integrations  products/integrations>
>
>

Re: Unit Tests et. al.

[Harbs]

Thanks! That looks very useful.

I started work on a feature/testing branch. I’ll try to merge what you did into 
what Josh did. I’m going to try to get the existing Core and/or Basic tests 
working in both swf and node js output tomorrow. We’ll see how well I do… ;-)

We might need different configs for different testing environments, but I’ll 
see if we can keep the divergence of the environs is minimal as possible.

Once I get the basics worked out, I’ll likely have an idea what others can help 
with. Let’s see if we can whip the Royale tests into shape. :-)

Harbs

> On Nov 4, 2017, at 10:30 PM, Greg Dove  wrote:
> 
> Harbs, I don't know if it still works since changes to Royale, but I had
> something rudimentary for cross-target unit testing quite shortly after
> working on the reflection support last year, in fact that was my primary
> reason for choosing to focus on reflection at the time.
> 
> It was visual output only (i.e. just to look at the test results output in
> the browser) and the goal was to get some compatibility with flexunit (so
> that the same swf-based flexunit tests that were running in the build -e..g
> BinaryData tests- could be run visually side by side between swf and js).
> I also added a new TestVariance metadata to account for known (expected?)
> variation between swf and js. This was needed to cover (for example) things
> like testing Reflection classes themselves, where the results can be
> different between the targets based on the 'native' base classes (e..g
> EventDispatcher inheritance chain).
> 
> Some of that code might also be useful to harvest for what you are doing,
> I'm not sure...
> 
> It's here:
> https://github.com/apache/royale-asjs/tree/develop/manualtests/UnitTests
> 
> 
> 
> On Sun, Nov 5, 2017 at 7:30 AM, Harbs  wrote:
> 
>> Awesome!
>> 
>> I assume that this means I can code the code to the Royale repo under
>> Apache 2. Right?
>> 
>> Harbs
>> 
>>> On Nov 3, 2017, at 5:37 PM, Josh Tynjala  wrote:
>>> 
>>> Please feel free to use my test runner. I'm happy to commit it somewhere
>> to make it official Apache code, if necessary.
>>> 
>>> - Josh
>>> 
>>> On 2017-11-03 04:19, Harbs  wrote:
 One topic which keeps coming up is better test coverage for Royale.
 
 I think this is becoming a critical issue for a few reasons:
 1. As we get close to version 1.0 it’s necessary to have good test
>> coverage for confidence of quality and confidence that we don’t introduce
>> recessive bugs.
 2. It’s really hard to accept Github pull requests without examining
>> the code VERY well that it does not introduce recessive bugs. CI which runs
>> automated tests could give a preliminary test on pull requests to ensure
>> that they don’t break anything. If the pull requests do break something,
>> it allows the requester to fix the problem with confidence without taking
>> others’ time.
 
 I think we need to break up testing into pieces and figure out a
>> strategy to implement automated tests in a way that they are maintainable.
 
 Some points:
 1. I think integration into something like Travis would be very helpful.
 2. I think there’s a Jenkins plugin for building pull requests. Not
>> sure how useful it is.[1]
 3. Josh has created a Node.js-compatible test-runner architecture which
>> could be useful for unit tests on parts of the framework which don’t rely
>> on browser features. (i.e. models and the like) He mentioned the
>> possibility of donating it, and I think that would be a very useful feature.
 4. For UI and integration tests, there seem to be some pretty cool
>> integrations using Selenium.[2][3]
 5. I think the main testing effort needs to be using JS and something
>> like Josh’s testing framework for non-UI pieces and some easy-to-use
>> Selenium integration for visual pieces and integration tests.
 6. We probably also want some API endpoints we can test off of for
>> integration testing.
 
 I’m willing to invest time into this.
 
 It’s going to be a lot of work building out the tests and I think we
>> need a plan for that. My thoughts:
 
 1. Step one is to make it easy to write meaningful automated tests and
>> establish a clear pattern.
 2. Step two is to start writing tests starting from the
>> most-used/easiest to beak pieces and work out from there.
 3. Once the pattern is established, any new pieces MUST have testing
>> coverage.
 4. When fixing bugs, attention should be paid to adding testing for
>> that component.
 5. When a pull request comes in on a piece which does not have unit
>> test, a test must be written before accepting the pull request. The test
>> does not need to be written by the requester. Before examining the request,
>> the test should be written to pass for expected behavior and fail for the
>> bug that the pull request is 

Re: Unit Tests et. al.

[Harbs]

FYI, It compiled and worked on the first try. :-)

The test view is very cool. I’m not sure if I missed it when you mentioned 
this, but I like. :-)

Harbs

> On Nov 4, 2017, at 10:30 PM, Greg Dove  wrote:
> 
> Harbs, I don't know if it still works since changes to Royale, but I had
> something rudimentary for cross-target unit testing quite shortly after
> working on the reflection support last year, in fact that was my primary
> reason for choosing to focus on reflection at the time.

Re: Unit Tests et. al.

[Harbs]

Wow. I don’t think I ever noticed the tutorial for FlexUnit on the Flex site:
https://flex.apache.org/flexunit/tutorial/ 


Who put that together? Looks like a lot of work went into that.

Harbs

> On Nov 4, 2017, at 6:59 PM, Harbs  wrote:
> 
> By “Unit Tests”, I really meant tests which are UI agnostic. I’m not 
> concerned by size of “Unit” tests, I’m more concerned about feature coverage. 
> When I think of unit tests in this context I mean FlexUnit-type tests. The 
> problem with FlexUnit, is that it only tests in Flash. Josh’s work solves 
> that problem. Ideally, we’d have tests which are run on both platforms. I 
> think We can use FlexUnit on Flash and Josh’s implementation to run the exact 
> same tests in node.
> 
> To me, it’s easier to tackle this problem if we first get “unit” tests 
> working that are platform independent.
> 
> Once that’s working, we can figure out how much the Unit-type tests can be 
> extended to test UI features and/or Mustella can be used. Mustella is a big 
> mystery to me.
> 
> Whatever the strategy, the tests need to be easy to write. Maybe it already 
> is easy to write mustella tests, but we need more documentation. I don’t know.
> 
> Either way, I will try to add Josh’s code and write some tests and see how it 
> goes.
> 
> Harbs
> 
>> On Nov 3, 2017, at 6:26 PM, Alex Harui  wrote:
>> 
>> I was unable to tell what it is Josh has from that link.
>> 
>> Right now, we have 3 test subsystems:
>> 1) Java-based tests using Selenium that Chris Dutz wrote
>> 2) FlexUnit tests (written in AS3) that only work in Flash (in the Basic
>> project)
>> 3) Mustella tests that are written in MXML that run on both Flash and in
>> the browser using Selenium.
>> 
>> This thread is titled "Unit Tests"  Do we have agreement on what the size
>> of the unit is?
>> 
>> Is there any advantage to trying to get FlexUnit to work without Flash?
>> For example, would folks migrating have old FlexUnit tests they want to
>> run?
>> 
>> I agree with Piotr that it would be better if tests didn't have to be
>> written in Java.  Using a declarative language like MXML makes you more
>> output-language agnostic.  Mustella works by having each Mustella command
>> implemented in Java for Selenium.  It constrains what your test can do to
>> things we know we can do on all platforms, and is agnostic about when the
>> next command run, which is helpful when there are differences in the way
>> the runtimes execute code and make results available.  I'd have to dig
>> into it again, but I think there are some issues in failure reporting in
>> Selenium of Selenium thinks there is only one test step which is Java code
>> that shoved a pile of JS into the browser to be executed.
>> 
>> It would be nice if we can leverage what we have instead of building a
>> whole new test system, but maybe Josh has something that is closer to what
>> we are looking for.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 11/3/17, 8:37 AM, "Josh Tynjala"  wrote:
>> 
>>> Please feel free to use my test runner. I'm happy to commit it somewhere
>>> to make it official Apache code, if necessary.
>>> 
>>> - Josh
>>> 
>>> On 2017-11-03 04:19, Harbs  wrote:
 One topic which keeps coming up is better test coverage for Royale.
 
 I think this is becoming a critical issue for a few reasons:
 1. As we get close to version 1.0 it’s necessary to have good test
 coverage for confidence of quality and confidence that we don’t
 introduce recessive bugs.
 2. It’s really hard to accept Github pull requests without examining
 the code VERY well that it does not introduce recessive bugs. CI which
 runs automated tests could give a preliminary test on pull requests to
 ensure that they don’t break anything. If the pull requests do break
 something, it allows the requester to fix the problem with confidence
 without taking others’ time.
 
 I think we need to break up testing into pieces and figure out a
 strategy to implement automated tests in a way that they are
 maintainable.
 
 Some points:
 1. I think integration into something like Travis would be very helpful.
 2. I think there’s a Jenkins plugin for building pull requests. Not
 sure how useful it is.[1]
 3. Josh has created a Node.js-compatible test-runner architecture which
 could be useful for unit tests on parts of the framework which don’t
 rely on browser features. (i.e. models and the like) He mentioned the
 possibility of donating it, and I think that would be a very useful
 feature.
 4. For UI and integration tests, there seem to be some pretty cool
 integrations using Selenium.[2][3]
 5. I think the main testing effort needs to be using JS and something
 like Josh’s testing framework for non-UI pieces and some easy-to-use
 

Re: Unit Tests et. al.

[Harbs]

Reading the FlexUnit docs, I see that there’s a lot of advanced features (that 
I never even knew about).

I’m going to start with just the metadata tags that Josh wrote support for 
(i.e. Before, Text and After).

Maybe I’ll add Ignore, BeforeClass and AfterClass as well.

A question I have for those who have used FlexUnit is how extensively these 
advanced features are used?

I have to figure out the best way to run tests on both node and Flash. It might 
be simplest to have two separate runner classes…

Harbs

> On Nov 4, 2017, at 7:20 PM, Harbs  wrote:
> 
> Wow. I don’t think I ever noticed the tutorial for FlexUnit on the Flex site:
> https://flex.apache.org/flexunit/tutorial/ 
> 
> 
> Who put that together? Looks like a lot of work went into that.
> 
> Harbs
> 
>> On Nov 4, 2017, at 6:59 PM, Harbs > > wrote:
>> 
>> By “Unit Tests”, I really meant tests which are UI agnostic. I’m not 
>> concerned by size of “Unit” tests, I’m more concerned about feature 
>> coverage. When I think of unit tests in this context I mean FlexUnit-type 
>> tests. The problem with FlexUnit, is that it only tests in Flash. Josh’s 
>> work solves that problem. Ideally, we’d have tests which are run on both 
>> platforms. I think We can use FlexUnit on Flash and Josh’s implementation to 
>> run the exact same tests in node.
>> 
>> To me, it’s easier to tackle this problem if we first get “unit” tests 
>> working that are platform independent.
>> 
>> Once that’s working, we can figure out how much the Unit-type tests can be 
>> extended to test UI features and/or Mustella can be used. Mustella is a big 
>> mystery to me.
>> 
>> Whatever the strategy, the tests need to be easy to write. Maybe it already 
>> is easy to write mustella tests, but we need more documentation. I don’t 
>> know.
>> 
>> Either way, I will try to add Josh’s code and write some tests and see how 
>> it goes.
>> 
>> Harbs
>> 
>>> On Nov 3, 2017, at 6:26 PM, Alex Harui >> > wrote:
>>> 
>>> I was unable to tell what it is Josh has from that link.
>>> 
>>> Right now, we have 3 test subsystems:
>>> 1) Java-based tests using Selenium that Chris Dutz wrote
>>> 2) FlexUnit tests (written in AS3) that only work in Flash (in the Basic
>>> project)
>>> 3) Mustella tests that are written in MXML that run on both Flash and in
>>> the browser using Selenium.
>>> 
>>> This thread is titled "Unit Tests"  Do we have agreement on what the size
>>> of the unit is?
>>> 
>>> Is there any advantage to trying to get FlexUnit to work without Flash?
>>> For example, would folks migrating have old FlexUnit tests they want to
>>> run?
>>> 
>>> I agree with Piotr that it would be better if tests didn't have to be
>>> written in Java.  Using a declarative language like MXML makes you more
>>> output-language agnostic.  Mustella works by having each Mustella command
>>> implemented in Java for Selenium.  It constrains what your test can do to
>>> things we know we can do on all platforms, and is agnostic about when the
>>> next command run, which is helpful when there are differences in the way
>>> the runtimes execute code and make results available.  I'd have to dig
>>> into it again, but I think there are some issues in failure reporting in
>>> Selenium of Selenium thinks there is only one test step which is Java code
>>> that shoved a pile of JS into the browser to be executed.
>>> 
>>> It would be nice if we can leverage what we have instead of building a
>>> whole new test system, but maybe Josh has something that is closer to what
>>> we are looking for.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 11/3/17, 8:37 AM, "Josh Tynjala" >> > wrote:
>>> 
 Please feel free to use my test runner. I'm happy to commit it somewhere
 to make it official Apache code, if necessary.
 
 - Josh
 
 On 2017-11-03 04:19, Harbs > wrote:
> One topic which keeps coming up is better test coverage for Royale.
> 
> I think this is becoming a critical issue for a few reasons:
> 1. As we get close to version 1.0 it’s necessary to have good test
> coverage for confidence of quality and confidence that we don’t
> introduce recessive bugs.
> 2. It’s really hard to accept Github pull requests without examining
> the code VERY well that it does not introduce recessive bugs. CI which
> runs automated tests could give a preliminary test on pull requests to
> ensure that they don’t break anything. If the pull requests do break
> something, it allows the requester to fix the problem with confidence
> without taking others’ time.
> 
> I think we need to break up testing into pieces and figure out a
> strategy to implement automated 

RE: FB : Strange side effects of -js-output argument

[Idylog - Nicolas Granon]

It's not such a big issue for now : what I have done is, I have a small eclipse 
plug-in that can copy files from workspace to another destination after compile.

Since we have other (non Royale) files to copy to the http server anyway...

Your suggestion (adding the js-output argument in flex-config.xml) is 
interesting, but what is the proper syntax ???

I have tried :


/myoutputdir


But it does not work. Should there be a  subtag ? Or maybe it 
should have another name ? (or no subtag at all ?)...

Nicolas Granon




> -Message d'origine-
> De : Alex Harui [mailto:aha...@adobe.com]
> Envoyé : samedi 4 novembre 2017 15:26
> À : dev@royale.apache.org; ngra...@idylog.com
> Objet : Re: FB : Strange side effects of -js-output argument
> 
> Piotr, Nicolas,
> 
> As I said a few posts ago, I will look into it next week (probably
> Thursday), when I can try to set up a debug environment with the FB
> source code.  I'm not able to do it now.  The code-hinting system seems
> to not care that the default flex-config.xml has these new options, so
> you might be able to add your new options there as a workaround for
> now.
> 
> Thanks,
> -Alex
> 
> On 11/4/17, 1:12 AM, "Idylog - Nicolas Granon" 
> wrote:
> 
> >Nope. It is not a casing problem.
> >
> >I can confirm that any additional "royale" argument in the "flex
> >compiler" panel breaks code-assist (it also triggers the realtime
> >processor error when you "apply" the settings).
> >
> >I also tried to use an additional config file (using -load-config
> >argument with the += syntax) but if the additional config file
> contains
> >a Royale argument (js-output, for example) it triggers an "uncaught
> >compiler exception".
> >
> >Nicolas Granon
> >
> >
> >
> >> -Message d'origine-
> >> De : Piotr Zarzycki [mailto:piotrzarzyck...@gmail.com]
> >> Envoyé : samedi 4 novembre 2017 03:32 À : dev@royale.apache.org;
> >> ngra...@idylog.com Objet : Re: FB : Strange side effects of
> >> -js-output argument
> >>
> >> Nicolas,
> >>
> >> Try to write exactly as I provide you -targets=JSRoyale or -
> >> compiler.targets=JSRoyale
> >>
> >> Piotr
> >>
> >> On Fri, Nov 3, 2017, 23:34 Idylog - Nicolas Granon
> >> 
> >> wrote:
> >>
> >> > Even more :
> >> >
> >> > When you add *any* royale argument to the "compiler arguments"
> >> dialog,
> >> > it breaks code-assist !!
> >> >
> >> > I just added -targets=jsroyale to the compiler arguments (no
> >> > -js-output
> >> > argument) and it also breaks code-assist !!!
> >> > (moreover, it does not seem to work : the swf is output as well..)
> >> >
> >> > Something out there really needs a fix...
> >> >
> >> > Nicolas Granon
> >> >
> >> >
> >> >
> >> > > -Message d'origine-
> >> > > De : Alex Harui [mailto:aha...@adobe.com.INVALID] Envoyé :
> >> > > vendredi
> >> > > 3 novembre 2017 18:01 À : dev@royale.apache.org;
> >> > > ngra...@idylog.com Objet : Re: FB : Strange side effects of
> >> > > -js-output argument
> >> > >
> >> > > Yeah, I noticed that too.  I think FB is running its own
> compiler
> >> > > for code-assist and new compiler options break that internal
> >> > > compiler.  I'm planning to dig into it more next week.  It might
> >> > > be that some compiler options have to be specified inside
> >> > > -config.xml
> >> files.
> >> > >
> >> > > -Alex
> >> > >
> >> > > On 11/3/17, 7:59 AM, "Idylog - Nicolas Granon"
> >> > > 
> >> > > wrote:
> >> > >
> >> > > >Ok, thanks.
> >> > > >
> >> > > >Nicolas Granon
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >> -Message d'origine-
> >> > > >> De : Piotr Zarzycki [mailto:piotrzarzyck...@gmail.com]
> >> > > >> Envoyé : vendredi 3 novembre 2017 15:40 À :
> >> dev@royale.apache.org
> >> > > >> Objet : Re: FB : Strange side effects of -js-output argument
> >> > > >>
> >> > > >> Hi Nicolas,
> >> > > >>
> >> > > >> Current compiler targets is "JSRoyale" for JS only output.
> >> > > >>
> >> > > >> Piotr
> >> > > >>
> >> > > >>
> >> > > >> 2017-11-03 15:30 GMT+01:00 Idylog - Nicolas Granon
> >> > > >> :
> >> > > >>
> >> > > >> > (my setup : FlashBuilder 4.7, Windows, Apache Royale 0.9
> >> > > >> > binaries)
> >> > > >> >
> >> > > >> > In some of my previous posts, I have tried to explain how
> to
> >> > > >> > setup FB and also the problems I got with code-assist
> >> > > >> > (auto-complete)
> >> > > not
> >> > > >> > working properly.
> >> > > >> > I also suggested a "working" setup of FB.
> >> > > >> >
> >> > > >> > Now, I have a *very* strange issue :
> >> > > >> >
> >> > > >> > If I add "-js-output=somepath" to the compiler arguments
> >> > > >> > (from "Project > Properties > Flex compiler" tab),
> >> > > >> > code-assist is lost
> >> > > 
> >> > > >> > (almost entirely). (side note : the project compiles
> without
> >> > > >> > errors, and output is in fact directed to (somepath)).
> >> > > >> >
> >> > > >> > If I remove the argument, code-assist 

Re: Unit Tests et. al.

[Harbs]

Awesome!

I assume that this means I can code the code to the Royale repo under Apache 2. 
Right?

Harbs

> On Nov 3, 2017, at 5:37 PM, Josh Tynjala  wrote:
> 
> Please feel free to use my test runner. I'm happy to commit it somewhere to 
> make it official Apache code, if necessary.
> 
> - Josh
> 
> On 2017-11-03 04:19, Harbs  wrote: 
>> One topic which keeps coming up is better test coverage for Royale.
>> 
>> I think this is becoming a critical issue for a few reasons:
>> 1. As we get close to version 1.0 it’s necessary to have good test 
>> coverage for confidence of quality and confidence that we don’t introduce 
>> recessive bugs.
>> 2. It’s really hard to accept Github pull requests without examining the 
>> code VERY well that it does not introduce recessive bugs. CI which runs 
>> automated tests could give a preliminary test on pull requests to ensure 
>> that they don’t break anything. If the pull requests do break something, 
>> it allows the requester to fix the problem with confidence without taking 
>> others’ time.
>> 
>> I think we need to break up testing into pieces and figure out a strategy to 
>> implement automated tests in a way that they are maintainable.
>> 
>> Some points:
>> 1. I think integration into something like Travis would be very helpful.
>> 2. I think there’s a Jenkins plugin for building pull requests. Not sure 
>> how useful it is.[1]
>> 3. Josh has created a Node.js-compatible test-runner architecture which 
>> could be useful for unit tests on parts of the framework which don’t rely 
>> on browser features. (i.e. models and the like) He mentioned the possibility 
>> of donating it, and I think that would be a very useful feature.
>> 4. For UI and integration tests, there seem to be some pretty cool 
>> integrations using Selenium.[2][3]
>> 5. I think the main testing effort needs to be using JS and something like 
>> Josh’s testing framework for non-UI pieces and some easy-to-use Selenium 
>> integration for visual pieces and integration tests.
>> 6. We probably also want some API endpoints we can test off of for 
>> integration testing.
>> 
>> I’m willing to invest time into this.
>> 
>> It’s going to be a lot of work building out the tests and I think we need 
>> a plan for that. My thoughts:
>> 
>> 1. Step one is to make it easy to write meaningful automated tests and 
>> establish a clear pattern.
>> 2. Step two is to start writing tests starting from the most-used/easiest to 
>> beak pieces and work out from there.
>> 3. Once the pattern is established, any new pieces MUST have testing 
>> coverage.
>> 4. When fixing bugs, attention should be paid to adding testing for that 
>> component.
>> 5. When a pull request comes in on a piece which does not have unit test, a 
>> test must be written before accepting the pull request. The test does not 
>> need to be written by the requester. Before examining the request, the test 
>> should be written to pass for expected behavior and fail for the bug that 
>> the pull request is attempting to fix (assuming the pull request is to fix a 
>> bug).
>> 
>> Thoughts?
>> Harbs
>> 
>> P.S. I’m thinking of coming to the US in late December/early January. I 
>> would be interested in getting together for a hacking session with folks who 
>> are available.
>> 
>> [1]https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin
>>  
>> [2]https://docs.travis-ci.com/user/gui-and-headless-browsers/ 
>> 
>> [3]https://saucelabs.com/products/integrations 
>> 

Re: Mobile vs Desktop diferences in components (Was: Re: Restarting contributions)

[Alex Harui]

Hmm.  That looks more like States than media query.  It brings up the
question of how much of the visuals should be in CSS vs in MXML.  Royale
should someday be able to do this same sort of thing via CSS Media Query.
I think it would look something like:

MXML:
  

CSS:

  @media (max-width: 500px) {
 .rowOrColumnDiv {
ILayoutBead : ClassReferences(ColumnLayout);
 }
  }

  .rowOrColumnDiv {
ILayoutBead : ClassReferences(RowLayout);
  }

And thus, more of the visuals are dictated in CSS.


I have been wondering if there is some way to extend States to do
something like this though.  One problem with States is the combinations.
States are supposed to represent the workflow states, not display states.
So you might have:




But it gets messy when you add another "dimension" like display size:






And also want to add, for example, Android vs IOS states.











There are things like StateGroups, but it still seems messy.  So one
option that someone could investigate is adding another property like
"displayState" and when it changes, look up the StateDescriptors and apply
them.  Then you could have MXML like:

   
  
Of course, I could be wrong...
-Alex

On 11/3/17, 2:58 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala"
 wrote:

>We might need to extend or wrap around css-media-queries.
>
>For example Angular Material does this for layouts [1]:
>
>  
>  
>  
>
>
>This causes a vertical layout on screens less than xs (i.e. width < 600px)
>and a horizontal layout on screens bigger than 600px.  By using two
>attributes, we have made this component responsive.
>
>From what Alex mentioned, it seems like we can add this kind of
>funtionality to Royale?  How exactly would that work here?
>
>Thanks,
>Om
>
>[1] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaterial.
>angularjs.org%2Flatest%2Flayout%2Fcontainer=02%7C01%7C%7Cb954fc85de8d
>4bacf85908d523060d98%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63645343
>1260275371=r%2B7Qq%2FihOJkm35aZUr26flh0PHNKMtC1v4RuVXUGNMw%3D
>ed=0
>
>
>On Fri, Nov 3, 2017 at 10:06 AM, Alex Harui 
>wrote:
>
>> Hi Carlos,
>>
>> I agree, which is why I mentioned potentially extending media query,
>>which
>> is what Flex did, IIRC.
>>
>> The way Royale handles CSS today is that the compiler generates a .CSS
>> file that is meant to be CSS compliant.  If you look at our CSS source
>> files, they contain non-compliant things like ClassReference() and
>> ILayoutBead that the browser doesn't handle.  So these things are
>>removed
>> by the compiler.  But the CSS is also encoded into a data structure (for
>> both SWF and JS) that is understood by framework code, and that's where
>> the ILayoutBead references a class since it is only framework code that
>> cares.
>>
>> I think it is possible for us to allow certain new media query rules if
>> they only affect the data structure and not the final CSS file.  I think
>> you could then use that to load a bead that has a specific classname
>>that
>> the complaint CSS affects.
>>
>> Of course, that will take some work to make it happen.
>> -Alex
>>
>> On 11/3/17, 8:00 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>> 
>> wrote:
>>
>> >Hi Alex,
>> >
>> >ok, I wasn't thinking about CSS beads, so I think we have the technical
>> >solution already in place.
>> >I think CSS with media queries is very interesting since we can plug
>>one
>> >bead or another regarding size of the screen
>> >We should as well think if this is all what we want to do. I mean that
>>a
>> >very stretched browser could mean we are on mobile, but as well that
>> >user on desktop resize the browser to some minimun. So, for example I
>> >don't
>> >know if we could decide if use touch vs mouse based on media queries
>> >maybe would be better based on platform code...
>> >
>> >Thanks!
>> >
>> >
>> >2017-11-03 3:00 GMT+01:00 Alex Harui :
>> >
>> >> Hi Carlos,
>> >>
>> >> Because we use CSS to choose beads, I think it might be possible to
>> >>choose
>> >> different views, layouts, etc based on media query.
>> >> If there is some other popular way of reconfiguring layouts in JS we
>>can
>> >> certainly try to leverage that as well or instead.
>> >>
>> >> Of course, I could be wrong...
>> >> -Alex
>> >>
>> >> On 11/2/17, 4:43 PM, "carlos.rov...@gmail.com on behalf of Carlos
>> >>Rovira"
>> >>  wrote:
>> >>
>> >> >Alex,
>> >> >
>> >> >for sizing and look and feel, yes, I propose media queries, I think
>> >>this
>> >> >is
>> >> >what makes usable to use the same button component (or checkbox,
>>radio,
>> >> >tooglebutton,)
>> >> >In the other hand there are other issues that should be managed with
>> >>other
>> >> >techniques. For example would tooltips be in desktop but no on
>>mobile?
>> 

Re: Unit Tests et. al.

[Harbs]

It looks like FlexUnit is currently broken.

I’m getting the following output when trying to run the FlexUnit tests on Core 
and Basic:

[mxmlc] 
/Users/harbs/Documents/ApacheRoyale/flex-flexunit/FlexUnit4/target/flexunit-4.3.0-20140410-as3_4.12.0.swc
 Warning: The definition mx.utils.ObjectUtil depended on by 
org.flexunit.runner.Description in the SWC 
/Users/harbs/Documents/ApacheRoyale/flex-flexunit/FlexUnit4/target/flexunit-4.3.0-20140410-as3_4.12.0.swc
 could not be found
[mxmlc] 
[mxmlc] 
[mxmlc] 
/Users/harbs/Documents/ApacheRoyale/flex-flexunit/FlexUnit4/target/flexunit-4.3.0-20140410-as3_4.12.0.swc
 Warning: The definition mx.utils.StringUtil depended on by 
flexunit.framework.AsyncTestHelper in the SWC 
/Users/harbs/Documents/ApacheRoyale/flex-flexunit/FlexUnit4/target/flexunit-4.3.0-20140410-as3_4.12.0.swc
 could not be found

Has anyone looked at this yet?

Harbs

> On Nov 4, 2017, at 10:45 PM, Harbs  wrote:
> 
> Thanks! That looks very useful.
> 
> I started work on a feature/testing branch. I’ll try to merge what you did 
> into what Josh did. I’m going to try to get the existing Core and/or Basic 
> tests working in both swf and node js output tomorrow. We’ll see how well I 
> do… ;-)
> 
> We might need different configs for different testing environments, but I’ll 
> see if we can keep the divergence of the environs is minimal as possible.
> 
> Once I get the basics worked out, I’ll likely have an idea what others can 
> help with. Let’s see if we can whip the Royale tests into shape. :-)
> 
> Harbs
> 
>> On Nov 4, 2017, at 10:30 PM, Greg Dove  wrote:
>> 
>> Harbs, I don't know if it still works since changes to Royale, but I had
>> something rudimentary for cross-target unit testing quite shortly after
>> working on the reflection support last year, in fact that was my primary
>> reason for choosing to focus on reflection at the time.
>> 
>> It was visual output only (i.e. just to look at the test results output in
>> the browser) and the goal was to get some compatibility with flexunit (so
>> that the same swf-based flexunit tests that were running in the build -e..g
>> BinaryData tests- could be run visually side by side between swf and js).
>> I also added a new TestVariance metadata to account for known (expected?)
>> variation between swf and js. This was needed to cover (for example) things
>> like testing Reflection classes themselves, where the results can be
>> different between the targets based on the 'native' base classes (e..g
>> EventDispatcher inheritance chain).
>> 
>> Some of that code might also be useful to harvest for what you are doing,
>> I'm not sure...
>> 
>> It's here:
>> https://github.com/apache/royale-asjs/tree/develop/manualtests/UnitTests
>> 
>> 
>> 
>> On Sun, Nov 5, 2017 at 7:30 AM, Harbs  wrote:
>> 
>>> Awesome!
>>> 
>>> I assume that this means I can code the code to the Royale repo under
>>> Apache 2. Right?
>>> 
>>> Harbs
>>> 
 On Nov 3, 2017, at 5:37 PM, Josh Tynjala  wrote:
 
 Please feel free to use my test runner. I'm happy to commit it somewhere
>>> to make it official Apache code, if necessary.
 
 - Josh
 
 On 2017-11-03 04:19, Harbs  wrote:
> One topic which keeps coming up is better test coverage for Royale.
> 
> I think this is becoming a critical issue for a few reasons:
> 1. As we get close to version 1.0 it’s necessary to have good test
>>> coverage for confidence of quality and confidence that we don’t introduce
>>> recessive bugs.
> 2. It’s really hard to accept Github pull requests without examining
>>> the code VERY well that it does not introduce recessive bugs. CI which runs
>>> automated tests could give a preliminary test on pull requests to ensure
>>> that they don’t break anything. If the pull requests do break something,
>>> it allows the requester to fix the problem with confidence without taking
>>> others’ time.
> 
> I think we need to break up testing into pieces and figure out a
>>> strategy to implement automated tests in a way that they are maintainable.
> 
> Some points:
> 1. I think integration into something like Travis would be very helpful.
> 2. I think there’s a Jenkins plugin for building pull requests. Not
>>> sure how useful it is.[1]
> 3. Josh has created a Node.js-compatible test-runner architecture which
>>> could be useful for unit tests on parts of the framework which don’t rely
>>> on browser features. (i.e. models and the like) He mentioned the
>>> possibility of donating it, and I think that would be a very useful feature.
> 4. For UI and integration tests, there seem to be some pretty cool
>>> integrations using Selenium.[2][3]
> 5. I think the main testing effort needs to be using JS and something
>>> like Josh’s testing framework for non-UI pieces and some easy-to-use
>>>