Re: No Touch support?

[Alex Harui]

Hi Carlos,

The "CSS" that handles which beads to load is not conforming CSS and is handled 
by custom code, similar to Apache Flex.  So we could extend media query similar 
to how Flex Mobile did it, or people will figure out queries that pretty much 
tell the same.  Some combination of screen size, resolution, etc.

What controller gets loaded is determined on a per-component basis, so Button 
may never have a touch controller, or it might have a controller and view that 
does not support "over" states on devices that don’t' support them.

The main goal, IMO, is always PAYG.  What interaction events do you need to 
handle on different devices/computers?  I claim that "over" events are worth 
handling on the computers that support them, and unnecessary code on my phone 
and tablet.  The Express components will probably have a universal mouse+touch 
controller that wastes code handling "over" on the phone just so folks don't 
have to do as much configuring.  Basic will keep them separate.  Code up into a 
bead what you think folks will need in Jewel.  If you don't get it right, no 
big deal, others can supply other combinations of event handling.  There may 
not be one size that fits all.

My 2 cents,
-Alex

On 7/5/18, 11:43 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Alex,

how this would be with media queries? FWIK, media queries gives you the
possibility to make for example changes depending on screen size, but
screen size does not say anything about if you are on Desktop or Mobile
right? or is another approach that I'm not aware.

For what I see seems mouse will be always needed, while touch only on
concrete cases. For example Button will always need Mouse controller and
that solves mouse and touch in all devices. Drawer will need as well mouse
controller in all normal cases like button, but in touch devices will need
to handle three listeners (touchbegin, touchmove and touchend) to solve
swipe gesture to close the drawer. This will be only on mobile/tablet and
not needed on desktop, since in desktop just clicking with the mouse
outside the drawer closes it. So with this example what do you think will
be the best approach in Royale?

thanks



2018-07-05 18:06 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> Of course you can combine a MouseController and a TouchController into one
> bead.  Aggregations are supported throughout Royale and probably never
> prohibited.
> Aggregations are often not PAYG so that's why the current plan is to
> support runtime loading of the mouse or touch controller based on media
> query.  It isn't PAYG to be looking for mouseOver events on a touch device
> that has no ability to detect "over".  You might even load a different 
View
> that doesn't bring in code to display "over" states.
>
> The key point is that the controller for a component is replaceable.  I
> don't think we want a pattern where you load more than both a mouse and
> touch  controller.  What goes in the one controller can be tweaked for the
> users needs.
>
> My 2 cents,
> -Alex
>
> On 7/5/18, 1:30 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> Hi Alex,
>
> as I said, maybe the solution is not turn off the actual controller
> and put
>  a touch one. Mouse controller does many things already. I must to
> investigate more over this since I see this more like to "add"
> controllers
> than to switch one for other. Can we configure more than 1controller
> bead
> per component? So people can use "mouse" only or "touch" only or
> "mouse" +
> "touch" at the same time? then mouse handle "click" and "basic" touch
> like
> it does actually and we can have some touch controllers separated for
> things like swipes and other touch needs?
>
>
>
>
> 2018-07-04 18:34 GMT+02:00 Alex Harui :
>
> > Harbs,
> >
> > Can we wrap Hammer.js into more easily reusable TouchControllers in
> Royale?
> >
> > IMO, it doesn't matter if it is a can of worms.  Royale hopefully
> makes it
> > easy to replace TouchControllers.  So you can write one that mostly
> works
> > and if someone offers a better one at some point, you can switch to
> that.
> > We won't bake one into the components and make the user wait for a
> next
> > release to get improvements.
> >
> > My 2 cents,
> > -Alex
> >
> > On 7/4/18, 9:26 AM, "Harbs"  wrote:
> >
> > Hi Carlos,
> >
> > Touch support is a can of worms.
> >
> > Basic touch support comes for free from Mouse Events. Anything
> more
> > than that, gets very complex 

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

[Carlos Rovira]

ok, I can revert this changes in the next few days, so you don't have to
deal with this.

2018-07-06 11:39 GMT+02:00 Harbs :

> > but don't you think we can save time and
> > resources and left this for 0.9.4 with more refactors we already planned?
>
> My motivation is to not release undocumented breaking changes — especially
> since they might be changed further or reverted in the next release. I’d
> like to keep the breaking releases to a minimum.
>
> I’m willing to make these changes and deal with the extra work.
>
> Thanks,
> Harbs
>
> > On Jul 6, 2018, at 12:22 PM, Carlos Rovira 
> wrote:
> >
> > Hi Harbs
> >
> > 2018-07-06 10:27 GMT+02:00 Harbs :
> >
> >> Here’s what I’d like to do so we could just get out a release:
> >>
> >> * Postpone any final decision on package and project refactoring until
> >> after the release.
> >>
> >
> > Ok for me, although I think this was one of the things we all agree. But
> I
> > think you refer that is better to make refactors after 0.9.3 what I think
> > is a good idea.
> >
> >
> >> * Make sure (for the current release only) that the package names match
> >> the previous release (even if they could use changing).
> >>
> >
> > the list fo changed package names I posted was not final, so this
> packages
> > can be reverted. The only problem I see is that is a work to give an step
> > backwards instead to go forward. That could be done, but just seems to me
> > we're giving that part a level of importance that does not match a 0.9.x
> > release. If this kind of things was done after 1.x, this would be clear
> to
> > change it and do it ASAP, but don't you think we can save time and
> > resources and left this for 0.9.4 with more refactors we already planned?
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

[Harbs]

> but don't you think we can save time and
> resources and left this for 0.9.4 with more refactors we already planned?

My motivation is to not release undocumented breaking changes — especially 
since they might be changed further or reverted in the next release. I’d like 
to keep the breaking releases to a minimum.

I’m willing to make these changes and deal with the extra work.

Thanks,
Harbs

> On Jul 6, 2018, at 12:22 PM, Carlos Rovira  wrote:
> 
> Hi Harbs
> 
> 2018-07-06 10:27 GMT+02:00 Harbs :
> 
>> Here’s what I’d like to do so we could just get out a release:
>> 
>> * Postpone any final decision on package and project refactoring until
>> after the release.
>> 
> 
> Ok for me, although I think this was one of the things we all agree. But I
> think you refer that is better to make refactors after 0.9.3 what I think
> is a good idea.
> 
> 
>> * Make sure (for the current release only) that the package names match
>> the previous release (even if they could use changing).
>> 
> 
> the list fo changed package names I posted was not final, so this packages
> can be reverted. The only problem I see is that is a work to give an step
> backwards instead to go forward. That could be done, but just seems to me
> we're giving that part a level of importance that does not match a 0.9.x
> release. If this kind of things was done after 1.x, this would be clear to
> change it and do it ASAP, but don't you think we can save time and
> resources and left this for 0.9.4 with more refactors we already planned?
> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

[Carlos Rovira]

Hi Harbs

2018-07-06 10:27 GMT+02:00 Harbs :

> Here’s what I’d like to do so we could just get out a release:
>
> * Postpone any final decision on package and project refactoring until
> after the release.
>

Ok for me, although I think this was one of the things we all agree. But I
think you refer that is better to make refactors after 0.9.3 what I think
is a good idea.


> * Make sure (for the current release only) that the package names match
> the previous release (even if they could use changing).
>

the list fo changed package names I posted was not final, so this packages
can be reverted. The only problem I see is that is a work to give an step
backwards instead to go forward. That could be done, but just seems to me
we're giving that part a level of importance that does not match a 0.9.x
release. If this kind of things was done after 1.x, this would be clear to
change it and do it ASAP, but don't you think we can save time and
resources and left this for 0.9.4 with more refactors we already planned?



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

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

[Carlos Rovira]

Hi Olaf,

2018-07-06 10:19 GMT+02:00 Olaf Krueger :

>
> I am interested in two points:
> - If we decide to decouple Jewel from Basic and introduce a Core and/or
> Foundation package: Is there any volunteer out there who will do this work?
>

Yes, I said I'll work on that. Harbs said as well that wants to help


>
> - Is it impossible to evolve Jewel if the SDK architecture remains as it is
> or is it "just" inconvenient?
>

It's in fact evolving since I'm creating every day new code in Jewel.



>
> Thanks,
> Olaf
>
>
>
>
>
>
>
>
>
>
>
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>



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

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

[Harbs]

Here’s what I’d like to do so we could just get out a release:

* Postpone any final decision on package and project refactoring until after 
the release.
* Make sure (for the current release only) that the package names match the 
previous release (even if they could use changing).
* Leave the division of projects as they are today in the develop branch (for 
the time being).

Does this make sense?

Harbs

> On Jul 5, 2018, at 12:46 PM, Piotr Zarzycki  wrote:
> 
> I remember that Harbs asked your for list of files which should be part of
> Core yes ? You said that you will do this and discussion died in that
> place.
> 
> 
> czw., 5 lip 2018 o 11:39 Carlos Rovira  napisał(a):
> 
>> I think the discussion was mainly done and that we agree in almost all
>> things but one: Should Jewel link Basic? For me it's clear that no.
>> Should Jewel use code in basic, clearly yes. So that left us with only 3
>> options:
>> 
>> 1.- Make Jewel link Basic. But I against this solution due to many points I
>> exposed in lots of emails before.
>> 
>> 2.- Separate Basic in two: Foundation (that's beads, supportClasses, and so
>> on, no CSS here) and Basic (TLCs, CSS,...). I think this is the middle
>> point where we should go as a community that wants to hear all voices and
>> respect all visions. For DG case, Jewel will end taking the needed common
>> pieces from Foundation.
>> 
>> 3.- Duplicate code. I think the worst solution since no body wants it.
>> 
>> For me this discussion can't give us more, since we all know how others
>> think and is not about one think is better that the other, is clear as well
>> that all are valid solutions, but we need to take a path to continue our
>> way. The path should not be one fixed solution 100%, but a mixture of
>> various since we are community and fixed things could make people not be
>> happy at all with the solution, and end leaving. We have a huge historial
>> of leaves to make this happen again and some community things to talk about
>> yet that we said will do after closing this discussion.
>> 
>> IMHO, point 2 is the middle solution and for me the recommended to take.
>> 
>> Just my 2ctns
>> 
>> Carlos
>> 
>> 
>> 2018-07-05 11:14 GMT+02:00 Piotr Zarzycki :
>> 
>>> Hi,
>>> 
>>> Someone could start work on DataGrid, but the discussion about not using
>>> Basic/Express in Jewel has not been finished. I don't see how actually is
>>> create that sophisticated component without inheriting those one from
>>> Express.
>>> 
>>> Piotr
>>> 
>>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>> 
> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> *

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

[Olaf Krueger]

Hi Carlos,
you are right, the title "Jewel Refactoring" is misleading, sorry.
It should mean the SDK refactoring in favour of the Jewel development.

Anyway, I was absent the last few weeks and probably not up-to-date.
But it seems to me that you all are still searching for a solution?

So, even if anything is already said and discussed, it is maybe a good idea
to collect all the points (pros and cons) in order to get a decision.

I am interested in two points:
- If we decide to decouple Jewel from Basic and introduce a Core and/or
Foundation package: Is there any volunteer out there who will do this work?

- Is it impossible to evolve Jewel if the SDK architecture remains as it is
or is it "just" inconvenient?

Thanks,
Olaf











--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

[Carlos Rovira]

Hi Olaf,

I think the topic is no more "Jewel Refactoring", since many of the
refactors I think where ok, but "UI sets dependency on actual Basic", and
if we want to make that grid, the points to evaluate should be "Processing
of non used CSS " (or "non CSS default" as you posted, "have lots of unused
TLCs in class path for nothing", and many other points I put on other
emails. Since other like Less code duplication will not apply if we have
all beads and supportClasses in Core and/or Foundation.

Maybe other that want Jewel to depend on Basic should put the lines of why
we they want to depend on TLCs and CSS that will never be use on Jewel as
well to complete the matrix.

Thanks


2018-07-05 21:23 GMT+02:00 Olaf Krueger :

> Hi Carlos,
> I just saw post after posting the matrix example.
>
> I don't want to trigger another discussion but I am not sure if all others
> know about all the details which were discussed in the past.
> I am also not sure if it is possible to find a consensus by going the
> current path.
> So, having such a matrix would make it easy for anybody to understand the
> different goals and the pros and cons of different approaches.
> Moreover, I think it would be good if such an important decision would be
> documented.
> It also could help to convince others that the alternative which will be
> found (whatever it is) makes sense.
>
> However, just an idea ;-)
>
> Thanks,
> Olaf
>
>
>
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
> 
>
>

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

[Olaf Krueger]

Hi Carlos,
I just saw post after posting the matrix example.

I don't want to trigger another discussion but I am not sure if all others
know about all the details which were discussed in the past.
I am also not sure if it is possible to find a consensus by going the
current path.
So, having such a matrix would make it easy for anybody to understand the
different goals and the pros and cons of different approaches.
Moreover, I think it would be good if such an important decision would be
documented.
It also could help to convince others that the alternative which will be
found (whatever it is) makes sense.

However, just an idea ;-)

Thanks,
Olaf



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

[Olaf Krueger]

Hi,
I've just created an example of such an evaluation matrix [1].
Please notice that this is really just an example which could be a starting
point if you find it helpful.
The assumptions I've already done may be wrong.

Basically, the idea is to list goals/criteria and assign a weight/priority
to each of it.
Each goal has to be evaluated and the weight has to be considered.
In the best case, you find the alternative which fits the needs/requirements
best.

Of course, important criteria/goals are missing in the example and has to be
added.
Forgive me, but I've not enough knowledge about the code base in order to
think about those criteria.

The example is done by using google spreadsheet.
If somebody is interested in extending it please let me know, I guess I can
make it accessible for others.

HTH,
Olaf

[1]
https://snag.gy/EId7Hx.jpg



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

[Carlos Rovira]

Hi Olaf,
you're right. But what I'm trying to say is that we discussed long over
various things. That was very positive since we found many bugs and
problems, so discussion brings many positive things. Not the final thing
where I think we are stuck is in something that technically I think is
better (and I refer to lots of emails of points and thoughts), for me this
is important and spend many time to make all understand why I don't want a
UI set depends on another and depends on CSS and have TLCs that you normaly
would not use and can make people end taking the easy way just because you
have some code in your class path, and making problems more difficult to
detect. as I said we had a community problem still undiscussed and
unsolved, since we still didn't close this one. And other leave the project
because of that problem. So it's normal in this case talk about leave, just
because is something implied in the discussion. I think in other projects
things are managed more easily and discussed and things are not taken so
strictly giving way to the participation of all. We should get to that
place if we want to evolve as a community.

About the matrix you proposed I think we discussed way to long over it, and
for me that will be started it over again.
I think we have all data in the table and if I can recall right, the only
point to go forward is if we want UI sets depends on actual Basic or
separate Basic TLCs and CSS to it's own library, what I highly recommend,
since I don't see coding Jewel with actual Basic dependency.

thanks


2018-07-05 18:18 GMT+02:00 Olaf Krueger :

> Hi,
>
> >fixed things could make people not be happy at all with the solution, and
> end leaving
>
> I prefer to don't speak all the time about leaving.
> Anybody is free to leave at any time, same as in the real world.
> But leaving because of technical decisions is completely incomprehensible
> for me... as long as decisions are made in favor of the project and not to
> suit someones personal taste.
>
> However, this is a technical project here and I think it should be possible
> to find a decision based on technical facts.
>
> One way to get a decision could be to build something like an evaluation
> matrix.
> Criteria have to be listed and weighted and particular alternatives have to
> be evaluated.
> The goal is to get the best alternative/solution.
>
> I'll try to prepare an example tonight.
>
> HTH,
> Olaf
>
>
>
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>



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

Re: No Touch support?

[Carlos Rovira]

Hi Alex,

how this would be with media queries? FWIK, media queries gives you the
possibility to make for example changes depending on screen size, but
screen size does not say anything about if you are on Desktop or Mobile
right? or is another approach that I'm not aware.

For what I see seems mouse will be always needed, while touch only on
concrete cases. For example Button will always need Mouse controller and
that solves mouse and touch in all devices. Drawer will need as well mouse
controller in all normal cases like button, but in touch devices will need
to handle three listeners (touchbegin, touchmove and touchend) to solve
swipe gesture to close the drawer. This will be only on mobile/tablet and
not needed on desktop, since in desktop just clicking with the mouse
outside the drawer closes it. So with this example what do you think will
be the best approach in Royale?

thanks



2018-07-05 18:06 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> Of course you can combine a MouseController and a TouchController into one
> bead.  Aggregations are supported throughout Royale and probably never
> prohibited.
> Aggregations are often not PAYG so that's why the current plan is to
> support runtime loading of the mouse or touch controller based on media
> query.  It isn't PAYG to be looking for mouseOver events on a touch device
> that has no ability to detect "over".  You might even load a different View
> that doesn't bring in code to display "over" states.
>
> The key point is that the controller for a component is replaceable.  I
> don't think we want a pattern where you load more than both a mouse and
> touch  controller.  What goes in the one controller can be tweaked for the
> users needs.
>
> My 2 cents,
> -Alex
>
> On 7/5/18, 1:30 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> Hi Alex,
>
> as I said, maybe the solution is not turn off the actual controller
> and put
>  a touch one. Mouse controller does many things already. I must to
> investigate more over this since I see this more like to "add"
> controllers
> than to switch one for other. Can we configure more than 1controller
> bead
> per component? So people can use "mouse" only or "touch" only or
> "mouse" +
> "touch" at the same time? then mouse handle "click" and "basic" touch
> like
> it does actually and we can have some touch controllers separated for
> things like swipes and other touch needs?
>
>
>
>
> 2018-07-04 18:34 GMT+02:00 Alex Harui :
>
> > Harbs,
> >
> > Can we wrap Hammer.js into more easily reusable TouchControllers in
> Royale?
> >
> > IMO, it doesn't matter if it is a can of worms.  Royale hopefully
> makes it
> > easy to replace TouchControllers.  So you can write one that mostly
> works
> > and if someone offers a better one at some point, you can switch to
> that.
> > We won't bake one into the components and make the user wait for a
> next
> > release to get improvements.
> >
> > My 2 cents,
> > -Alex
> >
> > On 7/4/18, 9:26 AM, "Harbs"  wrote:
> >
> > Hi Carlos,
> >
> > Touch support is a can of worms.
> >
> > Basic touch support comes for free from Mouse Events. Anything
> more
> > than that, gets very complex very quickly.
> >
> > I use Hammer.js in my own app to handle touch, and it works very
> well.
> >
> > https://na01.safelinks.protection.outlook.com/?url=
> > https%3A%2F%2Fhammerjs.github.io%2F=02%7C01%7Caharui%40
> adobe.com%
> > 7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636663183877387695=8By2PeXtYHtWAy9%
> 2BwBFwvW3CdtAEx%
> > 2Fly80MJCO8oqtM%3D=0  protection.outlook.com/?url=https%3A%2F%2Fna01.safelinks&
> data=02%7C01%7Caharui%40adobe.com%7C050c62517e694c28fbb608d5e251a003%
> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636663762562128231=
> tkyHPnu28qJv9uMZVl6Hr9Y7k%2BmvOP99L%2FuUQE8KdXc%3D=0.
> > protection.outlook.com/?url=https%3A%2F%2Fhammerjs.github.
> > io%2F=02%7C01%7Caharui%40adobe.com%
> 7C69560100ba4747a4e52808d5e1ca
> > e3c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> > 7C636663183877387695=8By2PeXtYHtWAy9%2BwBFwvW3CdtAEx%
> > 2Fly80MJCO8oqtM%3D=0>
> >
> > Harbs
> >
> > > On Jul 4, 2018, at 4:47 PM, Carlos Rovira <
> carlosrov...@apache.org>
> > wrote:
> > >
> > > Hi,
> > >
> > > I'm looking how to provide touch support for Drawer so users
> can
> > slide out.
> > > Is a default behavior in this kind of components.
> > >
> > > I'm seeing there's no TouchEvent or something similar. I think
> this
> > is an
> > > important flaw, since not having this is like to say we are not
> > prepared
> > > for mobile and in the end we lost users.
> > >
> > >
> > >
> > > --
> > > 

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

[Olaf Krueger]

Hi,

>fixed things could make people not be happy at all with the solution, and
end leaving

I prefer to don't speak all the time about leaving.
Anybody is free to leave at any time, same as in the real world.
But leaving because of technical decisions is completely incomprehensible
for me... as long as decisions are made in favor of the project and not to
suit someones personal taste.

However, this is a technical project here and I think it should be possible
to find a decision based on technical facts.

One way to get a decision could be to build something like an evaluation
matrix.
Criteria have to be listed and weighted and particular alternatives have to
be evaluated.
The goal is to get the best alternative/solution.

I'll try to prepare an example tonight.

HTH,
Olaf



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: No Touch support?

[Alex Harui]

Hi Carlos,

Of course you can combine a MouseController and a TouchController into one 
bead.  Aggregations are supported throughout Royale and probably never 
prohibited.
Aggregations are often not PAYG so that's why the current plan is to support 
runtime loading of the mouse or touch controller based on media query.  It 
isn't PAYG to be looking for mouseOver events on a touch device that has no 
ability to detect "over".  You might even load a different View that doesn't 
bring in code to display "over" states.

The key point is that the controller for a component is replaceable.  I don't 
think we want a pattern where you load more than both a mouse and touch  
controller.  What goes in the one controller can be tweaked for the users needs.

My 2 cents,
-Alex

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

Hi Alex,

as I said, maybe the solution is not turn off the actual controller and put
 a touch one. Mouse controller does many things already. I must to
investigate more over this since I see this more like to "add" controllers
than to switch one for other. Can we configure more than 1controller bead
per component? So people can use "mouse" only or "touch" only or "mouse" +
"touch" at the same time? then mouse handle "click" and "basic" touch like
it does actually and we can have some touch controllers separated for
things like swipes and other touch needs?




2018-07-04 18:34 GMT+02:00 Alex Harui :

> Harbs,
>
> Can we wrap Hammer.js into more easily reusable TouchControllers in 
Royale?
>
> IMO, it doesn't matter if it is a can of worms.  Royale hopefully makes it
> easy to replace TouchControllers.  So you can write one that mostly works
> and if someone offers a better one at some point, you can switch to that.
> We won't bake one into the components and make the user wait for a next
> release to get improvements.
>
> My 2 cents,
> -Alex
>
> On 7/4/18, 9:26 AM, "Harbs"  wrote:
>
> Hi Carlos,
>
> Touch support is a can of worms.
>
> Basic touch support comes for free from Mouse Events. Anything more
> than that, gets very complex very quickly.
>
> I use Hammer.js in my own app to handle touch, and it works very well.
>
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fhammerjs.github.io%2F=02%7C01%7Caharui%40adobe.com%
> 7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636663183877387695=8By2PeXtYHtWAy9%2BwBFwvW3CdtAEx%
> 2Fly80MJCO8oqtM%3D=0 
 protection.outlook.com/?url=https%3A%2F%2Fhammerjs.github.
> io%2F=02%7C01%7Caharui%40adobe.com%7C69560100ba4747a4e52808d5e1ca
> e3c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636663183877387695=8By2PeXtYHtWAy9%2BwBFwvW3CdtAEx%
> 2Fly80MJCO8oqtM%3D=0>
>
> Harbs
>
> > On Jul 4, 2018, at 4:47 PM, Carlos Rovira 
> wrote:
> >
> > Hi,
> >
> > I'm looking how to provide touch support for Drawer so users can
> slide out.
> > Is a default behavior in this kind of components.
> >
> > I'm seeing there's no TouchEvent or something similar. I think this
> is an
> > important flaw, since not having this is like to say we are not
> prepared
> > for mobile and in the end we lost users.
> >
> >
> >
> > --
> > Carlos Rovira
> > https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636663183877387695=7j8FPbQ59eU0hMPOLfelshVI6DDqVC
> JtLrxGWpK4MVQ%3D=0
>
>
>
>


-- 
Carlos Rovira

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C050c62517e694c28fbb608d5e251a003%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636663762562128231=SyJ%2FO7tu4%2Fw2a%2Ba1JZv4aefMKCXhttWQ1QNSLonSmiQ%3D=0

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

[Carlos Rovira]

Hi Piotr,

I think Core or Core + Foundation should have all the reusable pieces for
the rest of UI sets (Basic, Jewel, Express, and more) and those combine
regarding their objectives.

Basicaly core classes, interfaces, supportClasses and beads. For example
almost all *Base.as classes should be common, and then final and TLC
implementations must go to the UI Set. For example Group and Container
start to evolve differently in Jewel that Basic as I told it will happen

Initially that was a copy/paste, but just to part from a working state,
then I'm changing it to become what Jewel requires.

For me is just to start working on that instead of writing more emails
about this.

Carlos



2018-07-05 11:46 GMT+02:00 Piotr Zarzycki :

> I remember that Harbs asked your for list of files which should be part of
> Core yes ? You said that you will do this and discussion died in that
> place.
>
>
> czw., 5 lip 2018 o 11:39 Carlos Rovira 
> napisał(a):
>
> > I think the discussion was mainly done and that we agree in almost all
> > things but one: Should Jewel link Basic? For me it's clear that no.
> > Should Jewel use code in basic, clearly yes. So that left us with only 3
> > options:
> >
> > 1.- Make Jewel link Basic. But I against this solution due to many
> points I
> > exposed in lots of emails before.
> >
> > 2.- Separate Basic in two: Foundation (that's beads, supportClasses, and
> so
> > on, no CSS here) and Basic (TLCs, CSS,...). I think this is the middle
> > point where we should go as a community that wants to hear all voices and
> > respect all visions. For DG case, Jewel will end taking the needed common
> > pieces from Foundation.
> >
> > 3.- Duplicate code. I think the worst solution since no body wants it.
> >
> > For me this discussion can't give us more, since we all know how others
> > think and is not about one think is better that the other, is clear as
> well
> > that all are valid solutions, but we need to take a path to continue our
> > way. The path should not be one fixed solution 100%, but a mixture of
> > various since we are community and fixed things could make people not be
> > happy at all with the solution, and end leaving. We have a huge historial
> > of leaves to make this happen again and some community things to talk
> about
> > yet that we said will do after closing this discussion.
> >
> > IMHO, point 2 is the middle solution and for me the recommended to take.
> >
> > Just my 2ctns
> >
> > Carlos
> >
> >
> > 2018-07-05 11:14 GMT+02:00 Piotr Zarzycki :
> >
> > > Hi,
> > >
> > > Someone could start work on DataGrid, but the discussion about not
> using
> > > Basic/Express in Jewel has not been finished. I don't see how actually
> is
> > > create that sophisticated component without inheriting those one from
> > > Express.
> > >
> > > Piotr
> > >
> > > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>



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

Re: Coming back to discussion over separating libs (Was Re: No Touch support?)

[Piotr Zarzycki]

I remember that Harbs asked your for list of files which should be part of
Core yes ? You said that you will do this and discussion died in that
place.


czw., 5 lip 2018 o 11:39 Carlos Rovira  napisał(a):

> I think the discussion was mainly done and that we agree in almost all
> things but one: Should Jewel link Basic? For me it's clear that no.
> Should Jewel use code in basic, clearly yes. So that left us with only 3
> options:
>
> 1.- Make Jewel link Basic. But I against this solution due to many points I
> exposed in lots of emails before.
>
> 2.- Separate Basic in two: Foundation (that's beads, supportClasses, and so
> on, no CSS here) and Basic (TLCs, CSS,...). I think this is the middle
> point where we should go as a community that wants to hear all voices and
> respect all visions. For DG case, Jewel will end taking the needed common
> pieces from Foundation.
>
> 3.- Duplicate code. I think the worst solution since no body wants it.
>
> For me this discussion can't give us more, since we all know how others
> think and is not about one think is better that the other, is clear as well
> that all are valid solutions, but we need to take a path to continue our
> way. The path should not be one fixed solution 100%, but a mixture of
> various since we are community and fixed things could make people not be
> happy at all with the solution, and end leaving. We have a huge historial
> of leaves to make this happen again and some community things to talk about
> yet that we said will do after closing this discussion.
>
> IMHO, point 2 is the middle solution and for me the recommended to take.
>
> Just my 2ctns
>
> Carlos
>
>
> 2018-07-05 11:14 GMT+02:00 Piotr Zarzycki :
>
> > Hi,
> >
> > Someone could start work on DataGrid, but the discussion about not using
> > Basic/Express in Jewel has not been finished. I don't see how actually is
> > create that sophisticated component without inheriting those one from
> > Express.
> >
> > Piotr
> >
> > --
> Carlos Rovira
> http://about.me/carlosrovira
>


-- 

Piotr Zarzycki

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

Coming back to discussion over separating libs (Was Re: No Touch support?)

[Carlos Rovira]

I think the discussion was mainly done and that we agree in almost all
things but one: Should Jewel link Basic? For me it's clear that no.
Should Jewel use code in basic, clearly yes. So that left us with only 3
options:

1.- Make Jewel link Basic. But I against this solution due to many points I
exposed in lots of emails before.

2.- Separate Basic in two: Foundation (that's beads, supportClasses, and so
on, no CSS here) and Basic (TLCs, CSS,...). I think this is the middle
point where we should go as a community that wants to hear all voices and
respect all visions. For DG case, Jewel will end taking the needed common
pieces from Foundation.

3.- Duplicate code. I think the worst solution since no body wants it.

For me this discussion can't give us more, since we all know how others
think and is not about one think is better that the other, is clear as well
that all are valid solutions, but we need to take a path to continue our
way. The path should not be one fixed solution 100%, but a mixture of
various since we are community and fixed things could make people not be
happy at all with the solution, and end leaving. We have a huge historial
of leaves to make this happen again and some community things to talk about
yet that we said will do after closing this discussion.

IMHO, point 2 is the middle solution and for me the recommended to take.

Just my 2ctns

Carlos


2018-07-05 11:14 GMT+02:00 Piotr Zarzycki :

> Hi,
>
> Someone could start work on DataGrid, but the discussion about not using
> Basic/Express in Jewel has not been finished. I don't see how actually is
> create that sophisticated component without inheriting those one from
> Express.
>
> Piotr
>
> --
Carlos Rovira
http://about.me/carlosrovira

Re: No Touch support?

[Piotr Zarzycki]

Hi,

Someone could start work on DataGrid, but the discussion about not using
Basic/Express in Jewel has not been finished. I don't see how actually is
create that sophisticated component without inheriting those one from
Express.

Piotr


czw., 5 lip 2018 o 10:30 Carlos Rovira  napisał(a):

> Hi Alex,
>
> as I said, maybe the solution is not turn off the actual controller and put
>  a touch one. Mouse controller does many things already. I must to
> investigate more over this since I see this more like to "add" controllers
> than to switch one for other. Can we configure more than 1controller bead
> per component? So people can use "mouse" only or "touch" only or "mouse" +
> "touch" at the same time? then mouse handle "click" and "basic" touch like
> it does actually and we can have some touch controllers separated for
> things like swipes and other touch needs?
>
>
>
>
> 2018-07-04 18:34 GMT+02:00 Alex Harui :
>
> > Harbs,
> >
> > Can we wrap Hammer.js into more easily reusable TouchControllers in
> Royale?
> >
> > IMO, it doesn't matter if it is a can of worms.  Royale hopefully makes
> it
> > easy to replace TouchControllers.  So you can write one that mostly works
> > and if someone offers a better one at some point, you can switch to that.
> > We won't bake one into the components and make the user wait for a next
> > release to get improvements.
> >
> > My 2 cents,
> > -Alex
> >
> > On 7/4/18, 9:26 AM, "Harbs"  wrote:
> >
> > Hi Carlos,
> >
> > Touch support is a can of worms.
> >
> > Basic touch support comes for free from Mouse Events. Anything more
> > than that, gets very complex very quickly.
> >
> > I use Hammer.js in my own app to handle touch, and it works very
> well.
> >
> > https://na01.safelinks.protection.outlook.com/?url=
> > https%3A%2F%2Fhammerjs.github.io%2F=02%7C01%7Caharui%40adobe.com%
> > 7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636663183877387695=8By2PeXtYHtWAy9%2BwBFwvW3CdtAEx%
> > 2Fly80MJCO8oqtM%3D=0  > protection.outlook.com/?url=https%3A%2F%2Fhammerjs.github.
> > io%2F=02%7C01%7Caharui%40adobe.com%7C69560100ba4747a4e52808d5e1ca
> > e3c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> > 7C636663183877387695=8By2PeXtYHtWAy9%2BwBFwvW3CdtAEx%
> > 2Fly80MJCO8oqtM%3D=0>
> >
> > Harbs
> >
> > > On Jul 4, 2018, at 4:47 PM, Carlos Rovira  >
> > wrote:
> > >
> > > Hi,
> > >
> > > I'm looking how to provide touch support for Drawer so users can
> > slide out.
> > > Is a default behavior in this kind of components.
> > >
> > > I'm seeing there's no TouchEvent or something similar. I think this
> > is an
> > > important flaw, since not having this is like to say we are not
> > prepared
> > > for mobile and in the end we lost users.
> > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> > 7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636663183877387695=7j8FPbQ59eU0hMPOLfelshVI6DDqVC
> > JtLrxGWpK4MVQ%3D=0
> >
> >
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


-- 

Piotr Zarzycki

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

Re: No Touch support?

[Carlos Rovira]

Hi Alex,

as I said, maybe the solution is not turn off the actual controller and put
 a touch one. Mouse controller does many things already. I must to
investigate more over this since I see this more like to "add" controllers
than to switch one for other. Can we configure more than 1controller bead
per component? So people can use "mouse" only or "touch" only or "mouse" +
"touch" at the same time? then mouse handle "click" and "basic" touch like
it does actually and we can have some touch controllers separated for
things like swipes and other touch needs?




2018-07-04 18:34 GMT+02:00 Alex Harui :

> Harbs,
>
> Can we wrap Hammer.js into more easily reusable TouchControllers in Royale?
>
> IMO, it doesn't matter if it is a can of worms.  Royale hopefully makes it
> easy to replace TouchControllers.  So you can write one that mostly works
> and if someone offers a better one at some point, you can switch to that.
> We won't bake one into the components and make the user wait for a next
> release to get improvements.
>
> My 2 cents,
> -Alex
>
> On 7/4/18, 9:26 AM, "Harbs"  wrote:
>
> Hi Carlos,
>
> Touch support is a can of worms.
>
> Basic touch support comes for free from Mouse Events. Anything more
> than that, gets very complex very quickly.
>
> I use Hammer.js in my own app to handle touch, and it works very well.
>
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fhammerjs.github.io%2F=02%7C01%7Caharui%40adobe.com%
> 7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636663183877387695=8By2PeXtYHtWAy9%2BwBFwvW3CdtAEx%
> 2Fly80MJCO8oqtM%3D=0  protection.outlook.com/?url=https%3A%2F%2Fhammerjs.github.
> io%2F=02%7C01%7Caharui%40adobe.com%7C69560100ba4747a4e52808d5e1ca
> e3c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636663183877387695=8By2PeXtYHtWAy9%2BwBFwvW3CdtAEx%
> 2Fly80MJCO8oqtM%3D=0>
>
> Harbs
>
> > On Jul 4, 2018, at 4:47 PM, Carlos Rovira 
> wrote:
> >
> > Hi,
> >
> > I'm looking how to provide touch support for Drawer so users can
> slide out.
> > Is a default behavior in this kind of components.
> >
> > I'm seeing there's no TouchEvent or something similar. I think this
> is an
> > important flaw, since not having this is like to say we are not
> prepared
> > for mobile and in the end we lost users.
> >
> >
> >
> > --
> > Carlos Rovira
> > https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636663183877387695=7j8FPbQ59eU0hMPOLfelshVI6DDqVC
> JtLrxGWpK4MVQ%3D=0
>
>
>
>


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

Re: No Touch support?

[Carlos Rovira]

Hi Harbs,

2018-07-04 18:26 GMT+02:00 Harbs :

> Hi Carlos,
>
> Touch support is a can of worms.
>

that's for sure, I think touch gestures can get complex quickly.


>
> Basic touch support comes for free from Mouse Events. Anything more than
> that, gets very complex very quickly.
>

Right, I love that mouse events are even valid for basic touch needs.
That's huge point.
I think we only need to handle some concrete use case. For example Drawer
need is just swipe the panel with the finger from right to left, that's all.
It's like the need of a combobox to show a list, is just a particularity of
that component. So maybe the right solution is just to handle that kind of
corner cases and that's all... I'd want to do this in a way that can be
valid for all platforms involved and not just JS. In Jewel things are still
not working in SWF, but I'm trying to make it room for this to happen some
day, this is the same, maybe it will not work yet in flash, but the
solution should make room for that to happen.


>
> I use Hammer.js in my own app to handle touch, and it works very well.
>
> https://hammerjs.github.io/ 
>

interesting I'll take a look

thanks :)

Carlos


>
> Harbs
>
> > On Jul 4, 2018, at 4:47 PM, Carlos Rovira 
> wrote:
> >
> > Hi,
> >
> > I'm looking how to provide touch support for Drawer so users can slide
> out.
> > Is a default behavior in this kind of components.
> >
> > I'm seeing there's no TouchEvent or something similar. I think this is an
> > important flaw, since not having this is like to say we are not prepared
> > for mobile and in the end we lost users.
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

Re: No Touch support?

[Carlos Rovira]

Hi Alex,

2018-07-04 18:19 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> You can use negative words like "flaw" if you want.  But really, the fact
> is that nobody has had time to work on Touch support.  Mainly because the
> folks interested in migrating to Royale from Flex have not required it yet.
>

I think that as much as we love what we are doing here, we must be
self-critical, and the word "flaw" is used to say "hey! this is something
we don't have and others coming will see it as a point to not use us or not
to talk good about us". I know each one here has its priorities and that's
ok, maybe nothing here see this as an importan point, but today the world
is mobile and finger slides are normal. We can think "people migrating to
Royale from Flex have not required it", or another way to see it is "People
migrating to Royale from Flex, don't find things like touch gestures and
goes React and Angular". Things can be seen from many points, but we
although we believe in what we do, we should not be blind to the actual
needs since if not we take the risk to think old school when is not right
decision to do so.



>
> Drawer is cool, and new, but I don't know that migrating folks will have a
> high demand for it.  They all seem to be using DataGrid.
>

I want to say here that maybe we're talking so many to migrating folks, but
that's not our only target, we want as well people coming from actual html
frameworks. As well, maybe you can be surprised about how many people use
today a Drawer against how many people uses a Datagrid.
For example, in our App, we don't use DataGrids, or at least, for now we
don't need all DG functionality and we can go with a List+ItemRenderer.
Many people out there use to overuse DG when really is not needed since
they don't need to reorder columns, edit cells, and other things


>
> The principles around Touch support in Royale is that interactions are
> handled by Controllers.  Search for *MouseController.as and there should be
> a controller for each interactive component.  The controllers are specified
> in CSS as the IBeadController.  You can replace the MouseController with a
> TouchController by specifying a TouchController as the IBeadController.
> This should even allow us to leverage CSS Media Query to specify
> MouseControllers for mouse runtime environments and TouchControllers for
> touch environments.
>

I'm thinking that although we can create a Touch controller similar to the
Mouse one, we should have as well a MouseAndTouchController since people
will want to use both.


>
> If you've got the time to work on the first TouchController, great, but I
> would much rather see a DataGrid and other composite, higher-level Flex
> components working in Jewel so we can try to close down the discussion of
> why dependencies on Basic and Express are not a bad thing and get another
> release out, and so that customers that are actively trying to migrate
> their apps can use Jewel for their visuals if they want.
>
>
As I said, I don't think DG in Jewel will come to soon. My roadmap are
finishing navigation, organization and layouts things first, I think this
is essential since without that to create an App is very difficult (here
Tabs is needed, but maybe I can left it for later). You can do it by
yourself, but is better that Royale has all of this out of the box. Then
I'll go with Date controls and DropDown/ComboBox, from here maybe DG...but
don't really know since as I say is not needed for me and will be more a
work for the project.

In opposite, I have two clients that wants to see a Royale Interface
Navigation example that adapt nicely from Desktop to Tablet and to Mobile,
with current navigation standards (top bar, drawer, responsiveness). So in
Desktop Drawer and right sidebar is fixed, in Tablet, Drawer hides in favor
of a button to show it, and in Mobile right side bar hides in favor of a
button to show it.

This for me is more interesting to bring new customers that DG, since will
make people be able to start a new Royale App with current navigation
paradigm very quickly while DG can be only a need for some of them.

In all of this touch is not crucial, and can come later, but will be vey
cool to show people the use of this components with all the features and
let them now that they can have the same in the browser or in a browser app
that going native.

Just my 2 cents.

thanks!

Carlos




> Thanks,
> -Alex
>
> On 7/4/18, 6:47 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> Hi,
>
> I'm looking how to provide touch support for Drawer so users can slide
> out.
> Is a default behavior in this kind of components.
>
> I'm seeing there's no TouchEvent or something similar. I think this is
> an
> important flaw, since not having this is like to say we are not
> prepared
> for mobile and in the end we lost users.
>
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> 

Re: No Touch support?

[Andrew Wetmore]

@harbs could that become a blog entry?

On Wed, Jul 4, 2018, 2:19 PM Harbs,  wrote:

> Possibly.
>
> The way Hammer.js works is that you attach it to an element and create an
> instance of it or a controller. The specific touch events need to be
> specified.
>
> > On Jul 4, 2018, at 7:34 PM, Alex Harui  wrote:
> >
> > Harbs,
> >
> > Can we wrap Hammer.js into more easily reusable TouchControllers in
> Royale?
> >
> > IMO, it doesn't matter if it is a can of worms.  Royale hopefully makes
> it easy to replace TouchControllers.  So you can write one that mostly
> works and if someone offers a better one at some point, you can switch to
> that.  We won't bake one into the components and make the user wait for a
> next release to get improvements.
> >
> > My 2 cents,
> > -Alex
> >
> > On 7/4/18, 9:26 AM, "Harbs"  wrote:
> >
> >Hi Carlos,
> >
> >Touch support is a can of worms.
> >
> >Basic touch support comes for free from Mouse Events. Anything more
> than that, gets very complex very quickly.
> >
> >I use Hammer.js in my own app to handle touch, and it works very well.
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhammerjs.github.io%2F=02%7C01%7Caharui%40adobe.com%7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636663183877387695=8By2PeXtYHtWAy9%2BwBFwvW3CdtAEx%2Fly80MJCO8oqtM%3D=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhammerjs.github.io%2F=02%7C01%7Caharui%40adobe.com%7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636663183877387695=8By2PeXtYHtWAy9%2BwBFwvW3CdtAEx%2Fly80MJCO8oqtM%3D=0
> >
> >
> >Harbs
> >
> >> On Jul 4, 2018, at 4:47 PM, Carlos Rovira 
> wrote:
> >>
> >> Hi,
> >>
> >> I'm looking how to provide touch support for Drawer so users can slide
> out.
> >> Is a default behavior in this kind of components.
> >>
> >> I'm seeing there's no TouchEvent or something similar. I think this is
> an
> >> important flaw, since not having this is like to say we are not prepared
> >> for mobile and in the end we lost users.
> >>
> >>
> >>
> >> --
> >> Carlos Rovira
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636663183877387695=7j8FPbQ59eU0hMPOLfelshVI6DDqVCJtLrxGWpK4MVQ%3D=0
> >
> >
> >
>
>

Re: No Touch support?

[Harbs]

Possibly.

The way Hammer.js works is that you attach it to an element and create an 
instance of it or a controller. The specific touch events need to be specified.

> On Jul 4, 2018, at 7:34 PM, Alex Harui  wrote:
> 
> Harbs,
> 
> Can we wrap Hammer.js into more easily reusable TouchControllers in Royale?
> 
> IMO, it doesn't matter if it is a can of worms.  Royale hopefully makes it 
> easy to replace TouchControllers.  So you can write one that mostly works and 
> if someone offers a better one at some point, you can switch to that.  We 
> won't bake one into the components and make the user wait for a next release 
> to get improvements.
> 
> My 2 cents,
> -Alex
> 
> On 7/4/18, 9:26 AM, "Harbs"  wrote:
> 
>Hi Carlos,
> 
>Touch support is a can of worms.
> 
>Basic touch support comes for free from Mouse Events. Anything more than 
> that, gets very complex very quickly.
> 
>I use Hammer.js in my own app to handle touch, and it works very well.
> 
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhammerjs.github.io%2F=02%7C01%7Caharui%40adobe.com%7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636663183877387695=8By2PeXtYHtWAy9%2BwBFwvW3CdtAEx%2Fly80MJCO8oqtM%3D=0
>  
> 
> 
>Harbs
> 
>> On Jul 4, 2018, at 4:47 PM, Carlos Rovira  wrote:
>> 
>> Hi,
>> 
>> I'm looking how to provide touch support for Drawer so users can slide out.
>> Is a default behavior in this kind of components.
>> 
>> I'm seeing there's no TouchEvent or something similar. I think this is an
>> important flaw, since not having this is like to say we are not prepared
>> for mobile and in the end we lost users.
>> 
>> 
>> 
>> -- 
>> Carlos Rovira
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636663183877387695=7j8FPbQ59eU0hMPOLfelshVI6DDqVCJtLrxGWpK4MVQ%3D=0
> 
> 
> 

Re: No Touch support?

[Alex Harui]

Harbs,

Can we wrap Hammer.js into more easily reusable TouchControllers in Royale?

IMO, it doesn't matter if it is a can of worms.  Royale hopefully makes it easy 
to replace TouchControllers.  So you can write one that mostly works and if 
someone offers a better one at some point, you can switch to that.  We won't 
bake one into the components and make the user wait for a next release to get 
improvements.

My 2 cents,
-Alex

On 7/4/18, 9:26 AM, "Harbs"  wrote:

Hi Carlos,

Touch support is a can of worms.

Basic touch support comes for free from Mouse Events. Anything more than 
that, gets very complex very quickly.

I use Hammer.js in my own app to handle touch, and it works very well.


https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhammerjs.github.io%2F=02%7C01%7Caharui%40adobe.com%7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636663183877387695=8By2PeXtYHtWAy9%2BwBFwvW3CdtAEx%2Fly80MJCO8oqtM%3D=0
 


Harbs

> On Jul 4, 2018, at 4:47 PM, Carlos Rovira  wrote:
> 
> Hi,
> 
> I'm looking how to provide touch support for Drawer so users can slide 
out.
> Is a default behavior in this kind of components.
> 
> I'm seeing there's no TouchEvent or something similar. I think this is an
> important flaw, since not having this is like to say we are not prepared
> for mobile and in the end we lost users.
> 
> 
> 
> -- 
> Carlos Rovira
> 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C69560100ba4747a4e52808d5e1cae3c3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636663183877387695=7j8FPbQ59eU0hMPOLfelshVI6DDqVCJtLrxGWpK4MVQ%3D=0

Re: No Touch support?

[Harbs]

Hi Carlos,

Touch support is a can of worms.

Basic touch support comes for free from Mouse Events. Anything more than that, 
gets very complex very quickly.

I use Hammer.js in my own app to handle touch, and it works very well.

https://hammerjs.github.io/ 

Harbs

> On Jul 4, 2018, at 4:47 PM, Carlos Rovira  wrote:
> 
> Hi,
> 
> I'm looking how to provide touch support for Drawer so users can slide out.
> Is a default behavior in this kind of components.
> 
> I'm seeing there's no TouchEvent or something similar. I think this is an
> important flaw, since not having this is like to say we are not prepared
> for mobile and in the end we lost users.
> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: No Touch support?

[Alex Harui]

Hi Carlos,

You can use negative words like "flaw" if you want.  But really, the fact is 
that nobody has had time to work on Touch support.  Mainly because the folks 
interested in migrating to Royale from Flex have not required it yet.

Drawer is cool, and new, but I don't know that migrating folks will have a high 
demand for it.  They all seem to be using DataGrid.

The principles around Touch support in Royale is that interactions are handled 
by Controllers.  Search for *MouseController.as and there should be a 
controller for each interactive component.  The controllers are specified in 
CSS as the IBeadController.  You can replace the MouseController with a 
TouchController by specifying a TouchController as the IBeadController.  This 
should even allow us to leverage CSS Media Query to specify MouseControllers 
for mouse runtime environments and TouchControllers for touch environments.

If you've got the time to work on the first TouchController, great, but I would 
much rather see a DataGrid and other composite, higher-level Flex components 
working in Jewel so we can try to close down the discussion of why dependencies 
on Basic and Express are not a bad thing and get another release out, and so 
that customers that are actively trying to migrate their apps can use Jewel for 
their visuals if they want.

Thanks,
-Alex

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

Hi,

I'm looking how to provide touch support for Drawer so users can slide out.
Is a default behavior in this kind of components.

I'm seeing there's no TouchEvent or something similar. I think this is an
important flaw, since not having this is like to say we are not prepared
for mobile and in the end we lost users.



-- 
Carlos Rovira

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7Cf19155725bd641c23c6e08d5e1b4b574%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636663088611258999sdata=9r8VBk%2BDvsIvWYdhBB8STvBQVh3CZkGOJ5P0oX1fdus%3Dreserved=0