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&data=02%
> 7C01%7C%7Cb954fc85de8d
> >4bacf85908d523060d98%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C63645343
> >1260275371&sdata=r%2B7Qq%2FihOJkm35aZUr26flh0PHNKMtC1v4
> RuVXUGNMw%3D&reserv
> >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

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);
> >> >> > }
> >> >> >
> >> >> > This sets up the touch events. “grubbyFingers” is to give the
> >>hammer
> >> >> > events more “play” because fingers are less precise than mice.
> >> >> >
> >> >> > private static function getHammer(

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&data=02%7C01%7C%7Cb954fc85de8d
>4bacf85908d523060d98%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63645343
>1260275371&sdata=r%2B7Qq%2FihOJkm35aZUr26flh0PHNKMtC1v4RuVXUGNMw%3D&reserv
>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?
>> >>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 m

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

[OmPrakash Muppirala]

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://material.angularjs.org/latest/layout/container


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?
> >>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(Mouse

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

[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);
>> >> > }
>> >> >
>> >> > This sets up the touch events. “grubbyFingers” is to give the
>>hammer
>> >> > events more “play” because fingers are less precise than mice.
>> >> >
>> >> > private static function getHammer(background:UIBase):void{
>> >> > background.element.addEventListener('touchstart',
>> >> > function(ev:Object):void {
>> >> > // the user touched the screen!
>> >> > trace(ev);
>> >> > grubbyFingers = true;
>> >> > ev["preventDefault"]();
>> >> > }, false);
>> >> > var hammer:Object = new window["Hammer"](background.element);
>> >> > var enable:Object = {"enable":true};
>> >> > hammer["get"]('pinch').set(enable);
>> >> > hammer["get"]('rotate').set(enable);
>> >> > hammer["get"]('pre

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

[Carlos Rovira]

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);
> >> > }
> >> >
> >> > This sets up the touch events. “grubbyFingers” is to give the hammer
> >> > events more “play” because fingers are less precise than mice.
> >> >
> >> > private static function getHammer(background:UIBase):void{
> >> > background.element.addEventListener('touchstart',
> >> > function(ev:Object):void {
> >> > // the user touched the screen!
> >> > trace(ev);
> >> > grubbyFingers = true;
> >> > ev["preventDefault"]();
> >> > }, false);
> >> > var hammer:Object = new window["Hammer"](background.element);
> >> > var enable:Object = {"enable":true};
> >> > hammer["get"]('pinch').set(enable);
> >> > hammer["get"]('rotate').set(enable);
> >> > hammer["get"]('press').set({"time": 0});
> >> > hammer["get"]('pan').set({"direction":30});//Hammer.DIRECTION_ALL
> >> >
> >> > hammer["on"]("pan", handlePan);
> >> > hammer["on"]("panstart", handlePanStart);
> >> > hammer["on"]("panend pancancel", handlePanEnd);
> >> > hammer["on"]("pinch", handlePinch);
> >> > hammer["on"]("rotate", handleRotate);
> >> > hammer["on"]("tap", handleTap);
> >> > hammer["on"]("press", handleTouchStart);
> >> > }
> >> >
> >> > That’s it. The rest is just handling the specific events.
> >> >
> >> > I was trying to consider how to add native touch events natively to
> >> > Royale, but it seemed like a really hard problem and the hammer.js
> >> library
> >> > solves it nicely.
> >> >
> >> >
> >> > Harbs
> >> >
> >>[1]https://na01.safelinks.protection.outlook.com/?url=http
> %3A%2F%2Fhammer
> >>js.github.io%2F&data=02%7C01%7C%7C973d42c862f248f8472308d5
> 224b909d%7Cfa7b
> >>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452630304478314&
> sdata=j5qU10z86
> >>J%2FqdEBGY4Y%2F9GVxJL7Kn5fLXTWDBlG%2FHE8%3D&reserved=0
> >> 3A%2F%2Fhamm

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

[Peter Ent]

What we don't want to do - I think - is to have say 
loaded with every possible bead and then, at runtime, unload the beads
that aren't needed for the platform.

The media query or building separate targets with source+CSS for the
target seems like a better, PAYG way.

—peter

On 11/2/17, 10:00 PM, "Alex Harui"  wrote:

>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);
>>> > }
>>> >
>>> > This sets up the touch events. “grubbyFingers” is to give the hammer
>>> > events more “play” because fingers are less precise than mice.
>>> >
>>> > private static function getHammer(background:UIBase):void{
>>> > background.element.addEventListener('touchstart',
>>> > function(ev:Object):void {
>>> > // the user touched the screen!
>>> > trace(ev);
>>> > grubbyFingers = true;
>>> > ev["preventDefault"]();
>>> > }, false);
>>> > var hammer:Object = new window["Hammer"](background.element);
>>> > var enable:Object = {"enable":true};
>>> > hammer["get"]('pinch').set(enable);
>>> > hammer["get"]('rotate').set(enable);
>>> > hammer["get"]('press').set({"time": 0});
>>> > hammer["get"]('pan').set({"direction":30});//Hammer.DIRECTION_ALL
>>> >
>>> > hammer["on"]("pan", handlePan);
>>> > hammer["on"]("panstart", handlePanStart);
>>> > hammer["on"]("panend pancancel", handlePanEnd);
>>> > hammer["on"]("pinch", handlePinch);
>>> > hammer["on"]("rotate", handleRotate);
>>> > hammer["on"]("tap", handleTap);
>>> > hammer["on"]("press", handleTouchStart);
>>> > }
>>> >
>>> > That’s it. The rest is just handling the specific events.
>>> >
>>> > I was trying to consider how to add native touch events natively to
>>> > Royale, but it seemed like a really hard problem and the hammer.js
>>> library
>>> > solves it nicely.
>>> >
>>> >
>>> > Harbs
>>> > 
>>>[1]https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhamme
>>>r
>>>js.github.io%2F&data=02%7C01%7C%7C973d42c862f248f8472308d5224b909d%7Cfa7
>>>b
>>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452630304478314&sdata=j5qU10z8
>>>6
>>>J%2FqdEBGY4Y%2F9GVxJL7Kn5fLXTWDBlG%2FHE8%3D&reserved=0
>>>>>s
>>>.github.io%2F&data=02%7C01%7C%7C973d42c862f248f8472308d5224b909d%7Cfa7b1
>>>b
>>>5a7b34438794aed2c178decee1%7C0%7C0%7C636452630304634559&sdata=%2BPUw7Bj4
>>>v
>>>CMpq5YgtSN9Wi5%2Fe5SwlRpXPwvvpZ%2BKBvs%3D&reserved=0>
>>> >
>>> > > On Nov 2, 2017, at 11:23 PM, Carlos Rovira
>>>
>>> > wrote:
>>> > >
>>> > > Hi Alex,
>>> > >
>>> > > my opinion here is different, since making dif

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

[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);
>> > }
>> >
>> > This sets up the touch events. “grubbyFingers” is to give the hammer
>> > events more “play” because fingers are less precise than mice.
>> >
>> > private static function getHammer(background:UIBase):void{
>> > background.element.addEventListener('touchstart',
>> > function(ev:Object):void {
>> > // the user touched the screen!
>> > trace(ev);
>> > grubbyFingers = true;
>> > ev["preventDefault"]();
>> > }, false);
>> > var hammer:Object = new window["Hammer"](background.element);
>> > var enable:Object = {"enable":true};
>> > hammer["get"]('pinch').set(enable);
>> > hammer["get"]('rotate').set(enable);
>> > hammer["get"]('press').set({"time": 0});
>> > hammer["get"]('pan').set({"direction":30});//Hammer.DIRECTION_ALL
>> >
>> > hammer["on"]("pan", handlePan);
>> > hammer["on"]("panstart", handlePanStart);
>> > hammer["on"]("panend pancancel", handlePanEnd);
>> > hammer["on"]("pinch", handlePinch);
>> > hammer["on"]("rotate", handleRotate);
>> > hammer["on"]("tap", handleTap);
>> > hammer["on"]("press", handleTouchStart);
>> > }
>> >
>> > That’s it. The rest is just handling the specific events.
>> >
>> > I was trying to consider how to add native touch events natively to
>> > Royale, but it seemed like a really hard problem and the hammer.js
>> library
>> > solves it nicely.
>> >
>> >
>> > Harbs
>> > 
>>[1]https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhammer
>>js.github.io%2F&data=02%7C01%7C%7C973d42c862f248f8472308d5224b909d%7Cfa7b
>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452630304478314&sdata=j5qU10z86
>>J%2FqdEBGY4Y%2F9GVxJL7Kn5fLXTWDBlG%2FHE8%3D&reserved=0
>>>.github.io%2F&data=02%7C01%7C%7C973d42c862f248f8472308d5224b909d%7Cfa7b1b
>>5a7b34438794aed2c178decee1%7C0%7C0%7C636452630304634559&sdata=%2BPUw7Bj4v
>>CMpq5YgtSN9Wi5%2Fe5SwlRpXPwvvpZ%2BKBvs%3D&reserved=0>
>> >
>> > > On Nov 2, 2017, at 11:23 PM, Carlos Rovira 
>> > wrote:
>> > >
>> > > Hi Alex,
>> > >
>> > > my opinion here is different, since making different libraries for
>>the
>> > same
>> > > purpose make the user task more complicated.
>> > > For example, for the case commented of touch vs mouse we could have
>> only
>> > > one button component that will use conditional compilation to get
>>mouse
>> > for
>> > > desktop and gestures for mobile. If not users ends with the need to
>> > create
>> > > different applications for each platform, and is in our hands to
>>avoid
>> > that.
>> > >
>> > > Some cases are easy, the b

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

[Carlos Rovira]

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);
> > }
> >
> > This sets up the touch events. “grubbyFingers” is to give the hammer
> > events more “play” because fingers are less precise than mice.
> >
> > private static function getHammer(background:UIBase):void{
> > background.element.addEventListener('touchstart',
> > function(ev:Object):void {
> > // the user touched the screen!
> > trace(ev);
> > grubbyFingers = true;
> > ev["preventDefault"]();
> > }, false);
> > var hammer:Object = new window["Hammer"](background.element);
> > var enable:Object = {"enable":true};
> > hammer["get"]('pinch').set(enable);
> > hammer["get"]('rotate').set(enable);
> > hammer["get"]('press').set({"time": 0});
> > hammer["get"]('pan').set({"direction":30});//Hammer.DIRECTION_ALL
> >
> > hammer["on"]("pan", handlePan);
> > hammer["on"]("panstart", handlePanStart);
> > hammer["on"]("panend pancancel", handlePanEnd);
> > hammer["on"]("pinch", handlePinch);
> > hammer["on"]("rotate", handleRotate);
> > hammer["on"]("tap", handleTap);
> > hammer["on"]("press", handleTouchStart);
> > }
> >
> > That’s it. The rest is just handling the specific events.
> >
> > I was trying to consider how to add native touch events natively to
> > Royale, but it seemed like a really hard problem and the hammer.js
> library
> > solves it nicely.
> >
> >
> > Harbs
> > [1]http://hammerjs.github.io/ 
> >
> > > On Nov 2, 2017, at 11:23 PM, Carlos Rovira 
> > wrote:
> > >
> > > Hi Alex,
> > >
> > > my opinion here is different, since making different libraries for the
> > same
> > > purpose make the user task more complicated.
> > > For example, for the case commented of touch vs mouse we could have
> only
> > > one button component that will use conditional compilation to get mouse
> > for
> > > desktop and gestures for mobile. If not users ends with the need to
> > create
> > > different applications for each platform, and is in our hands to avoid
> > that.
> > >
> > > Some cases are easy, the button case could have different
> representations
> > > in size thanks to CSS, but others are more complicated. Is the case of
> > > DateChooser vs DateSpinner, but I think we should get a Date component
> > that
> > > could get both behaviours depending on what platform targets without
> the
> > > need for the user to have different applications or the need of declare
> > > different components.
> > >
> > > Nowadays, to make an application to target different platforms and
> > devices
> > > is a nightmare, and if we make people to follow the same path we have
> in
> > > Flex, we are not getting any improvement in that workflow. I think Flex
> > > choose that path due to the implications already in place, the mx and
> > spark
> > > components where made before the mobile era, and was not prepared for
> > that.
> > >
> > > We are planning the components in this days and we could change that.
> > >
> > > At least, for me this would be another key factor to choose Apache
> Royale
> > > over other solutions

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

[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);
> }
>
> This sets up the touch events. “grubbyFingers” is to give the hammer
> events more “play” because fingers are less precise than mice.
>
> private static function getHammer(background:UIBase):void{
> background.element.addEventListener('touchstart',
> function(ev:Object):void {
> // the user touched the screen!
> trace(ev);
> grubbyFingers = true;
> ev["preventDefault"]();
> }, false);
> var hammer:Object = new window["Hammer"](background.element);
> var enable:Object = {"enable":true};
> hammer["get"]('pinch').set(enable);
> hammer["get"]('rotate').set(enable);
> hammer["get"]('press').set({"time": 0});
> hammer["get"]('pan').set({"direction":30});//Hammer.DIRECTION_ALL
>
> hammer["on"]("pan", handlePan);
> hammer["on"]("panstart", handlePanStart);
> hammer["on"]("panend pancancel", handlePanEnd);
> hammer["on"]("pinch", handlePinch);
> hammer["on"]("rotate", handleRotate);
> hammer["on"]("tap", handleTap);
> hammer["on"]("press", handleTouchStart);
> }
>
> That’s it. The rest is just handling the specific events.
>
> I was trying to consider how to add native touch events natively to
> Royale, but it seemed like a really hard problem and the hammer.js library
> solves it nicely.
>
>
> Harbs
> [1]http://hammerjs.github.io/ 
>
> > On Nov 2, 2017, at 11:23 PM, Carlos Rovira 
> wrote:
> >
> > Hi Alex,
> >
> > my opinion here is different, since making different libraries for the
> same
> > purpose make the user task more complicated.
> > For example, for the case commented of touch vs mouse we could have only
> > one button component that will use conditional compilation to get mouse
> for
> > desktop and gestures for mobile. If not users ends with the need to
> create
> > different applications for each platform, and is in our hands to avoid
> that.
> >
> > Some cases are easy, the button case could have different representations
> > in size thanks to CSS, but others are more complicated. Is the case of
> > DateChooser vs DateSpinner, but I think we should get a Date component
> that
> > could get both behaviours depending on what platform targets without the
> > need for the user to have different applications or the need of declare
> > different components.
> >
> > Nowadays, to make an application to target different platforms and
> devices
> > is a nightmare, and if we make people to follow the same path we have in
> > Flex, we are not getting any improvement in that workflow. I think Flex
> > choose that path due to the implications already in place, the mx and
> spark
> > components where made before the mobile era, and was not prepared for
> that.
> >
> > We are planning the components in this days and we could change that.
> >
> > At least, for me this would be another key factor to choose Apache Royale
> > over other solutions.
> >
> > Just my 2cnts...
> >
> >
> > 2017-11-02 22:00 GMT+01:00 Alex Harui :
> >
> >> I agree that some components in Mobile.swc could be moved elsewhere and
> >> used on desktops, but I thought there would be library of mobile
> >> components that default to different interaction models (gesture vs
> >> mouse).   Flex had some mobile-specific components (ToggleSwitch,
> >> DateSpinner, etc).  I thought their swipe interactions wouldn't work
> for a
> >> desktop with a mouse.
> >>
> >> Of course, I could be wrong...
> >>
> >> -Alex
> >>
> >> On 11/2/17, 7:46 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira"
> >> 
> >> wrote:
> >>
> >>> Hi Peter,
> >>>
> >>> thanks, I think would be great to have that in mind to avoid extra
> efforts
> >>> for users.
> >>> As applications are wired nowadays it would be bad for us if we have
> >>> separate component libraries
> >>> to target 

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

[Harbs]

The one *MAJOR* gotcha on mobile is that Android does not support standard 
KeyboardEvents for soft keyboards (external keyboards work fine).

Working around this problem requires jumping through major hoops.

If your app does not need to deal with KeyboardEvents directly, this is not an 
issue.

This is a problem to some degree on all browsers and this is not specific to 
Royale. I do wonder if there’s some way to abstract the problem away (or 
minimize it) in Royale.

Harbs

> On Nov 3, 2017, at 12:58 AM, 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);
> }
> 
> This sets up the touch events. “grubbyFingers” is to give the hammer events 
> more “play” because fingers are less precise than mice.
> 
> private static function getHammer(background:UIBase):void{
> background.element.addEventListener('touchstart', 
> function(ev:Object):void {
> // the user touched the screen!
> trace(ev);
> grubbyFingers = true;
> ev["preventDefault"]();
> }, false);
> var hammer:Object = new window["Hammer"](background.element);
> var enable:Object = {"enable":true};
> hammer["get"]('pinch').set(enable);
> hammer["get"]('rotate').set(enable);
> hammer["get"]('press').set({"time": 0});
> hammer["get"]('pan').set({"direction":30});//Hammer.DIRECTION_ALL
> 
> hammer["on"]("pan", handlePan);
> hammer["on"]("panstart", handlePanStart);
> hammer["on"]("panend pancancel", handlePanEnd);
> hammer["on"]("pinch", handlePinch);
> hammer["on"]("rotate", handleRotate);
> hammer["on"]("tap", handleTap);
> hammer["on"]("press", handleTouchStart);
> }
> 
> That’s it. The rest is just handling the specific events.
> 
> I was trying to consider how to add native touch events natively to Royale, 
> but it seemed like a really hard problem and the hammer.js library solves it 
> nicely.
> 
> 
> Harbs
> [1]http://hammerjs.github.io/ 
> 
>> On Nov 2, 2017, at 11:23 PM, Carlos Rovira > > wrote:
>> 
>> Hi Alex,
>> 
>> my opinion here is different, since making different libraries for the same
>> purpose make the user task more complicated.
>> For example, for the case commented of touch vs mouse we could have only
>> one button component that will use conditional compilation to get mouse for
>> desktop and gestures for mobile. If not users ends with the need to create
>> different applications for each platform, and is in our hands to avoid that.
>> 
>> Some cases are easy, the button case could have different representations
>> in size thanks to CSS, but others are more complicated. Is the case of
>> DateChooser vs DateSpinner, but I think we should get a Date component that
>> could get both behaviours depending on what platform targets without the
>> need for the user to have different applications or the need of declare
>> different components.
>> 
>> Nowadays, to make an application to target different platforms and devices
>> is a nightmare, and if we make people to follow the same path we have in
>> Flex, we are not getting any improvement in that workflow. I think Flex
>> choose that path due to the implications already in place, the mx and spark
>> components where made before the mobile era, and was not prepared for that.
>> 
>> We are planning the components in this days and we could change that.
>> 
>> At least, for me this would be another key factor to choose Apache Royale
>> over other solutions.
>> 
>> Just my 2cnts...
>> 
>> 
>> 2017-11-02 22:00 GMT+01:00 Alex Harui > >:
>> 
>>> I agree that some components in Mobile.swc could be moved elsewhere and
>>> used on desktops, but I thought there would be library of mobile
>>> components that default to different interaction models (gesture vs
>>> mouse).   Flex had some mobile-specific components (ToggleSwitch,
>>> DateSpinner, etc).  I thought their swipe interactions wouldn't work for a
>>> desktop with a mouse.
>>> 
>>> Of course, I could be wrong...
>>> 
>>> -Alex
>>> 
>>> On 11/2/17, 7:46 AM, "carlos.rov...@gmail.com 
>>> 

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

[Harbs]

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);
}

This sets up the touch events. “grubbyFingers” is to give the hammer events 
more “play” because fingers are less precise than mice.

private static function getHammer(background:UIBase):void{
background.element.addEventListener('touchstart', function(ev:Object):void {
// the user touched the screen!
trace(ev);
grubbyFingers = true;
ev["preventDefault"]();
}, false);
var hammer:Object = new window["Hammer"](background.element);
var enable:Object = {"enable":true};
hammer["get"]('pinch').set(enable);
hammer["get"]('rotate').set(enable);
hammer["get"]('press').set({"time": 0});
hammer["get"]('pan').set({"direction":30});//Hammer.DIRECTION_ALL

hammer["on"]("pan", handlePan);
hammer["on"]("panstart", handlePanStart);
hammer["on"]("panend pancancel", handlePanEnd);
hammer["on"]("pinch", handlePinch);
hammer["on"]("rotate", handleRotate);
hammer["on"]("tap", handleTap);
hammer["on"]("press", handleTouchStart);
}

That’s it. The rest is just handling the specific events.

I was trying to consider how to add native touch events natively to Royale, but 
it seemed like a really hard problem and the hammer.js library solves it nicely.


Harbs
[1]http://hammerjs.github.io/ 

> On Nov 2, 2017, at 11:23 PM, Carlos Rovira  wrote:
> 
> Hi Alex,
> 
> my opinion here is different, since making different libraries for the same
> purpose make the user task more complicated.
> For example, for the case commented of touch vs mouse we could have only
> one button component that will use conditional compilation to get mouse for
> desktop and gestures for mobile. If not users ends with the need to create
> different applications for each platform, and is in our hands to avoid that.
> 
> Some cases are easy, the button case could have different representations
> in size thanks to CSS, but others are more complicated. Is the case of
> DateChooser vs DateSpinner, but I think we should get a Date component that
> could get both behaviours depending on what platform targets without the
> need for the user to have different applications or the need of declare
> different components.
> 
> Nowadays, to make an application to target different platforms and devices
> is a nightmare, and if we make people to follow the same path we have in
> Flex, we are not getting any improvement in that workflow. I think Flex
> choose that path due to the implications already in place, the mx and spark
> components where made before the mobile era, and was not prepared for that.
> 
> We are planning the components in this days and we could change that.
> 
> At least, for me this would be another key factor to choose Apache Royale
> over other solutions.
> 
> Just my 2cnts...
> 
> 
> 2017-11-02 22:00 GMT+01:00 Alex Harui :
> 
>> I agree that some components in Mobile.swc could be moved elsewhere and
>> used on desktops, but I thought there would be library of mobile
>> components that default to different interaction models (gesture vs
>> mouse).   Flex had some mobile-specific components (ToggleSwitch,
>> DateSpinner, etc).  I thought their swipe interactions wouldn't work for a
>> desktop with a mouse.
>> 
>> Of course, I could be wrong...
>> 
>> -Alex
>> 
>> On 11/2/17, 7:46 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>> 
>> wrote:
>> 
>>> Hi Peter,
>>> 
>>> thanks, I think would be great to have that in mind to avoid extra efforts
>>> for users.
>>> As applications are wired nowadays it would be bad for us if we have
>>> separate component libraries
>>> to target different devices. We should try to make differentiations in the
>>> components and we have
>>> varios tools here (CSS, AS3 logic, conditional compilation,...)
>>> 
>>> Thanks!
>>> 
>>> 2017-11-02 15:36 GMT+01:00 Peter Ent :
>>> 
 (copied from another email thread; this one seems more appropriate).
 
 I created the Mobile kit. I did it separately because it was supposed to
 mimic how UINavigationController, UIViewController, and UITabController
 work on iOS (which I'm more familiar with than And

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

[Alex Harui]

Hi Carlos,

I agree that a great goal would be to allow the development of an
application that can run anywhere.

You are welcome to build components that can look different and interact
differently in different environments.  Under the covers, I hope they are
compositions of beads.

Royale components are supposed to be MVC so a gesture controller could
replace a mouse controller for a Mobile app.  A Mobile SWC might use the
same View bead from Basic, but have CSS that dictates a gesture controller
instead of a mouse controller.  And that gesture controller would probably
be in the Mobile.swc.  A SWC is a good way of overriding defaults since it
adds new CSS selectors and rules.  Some other components might leverage
plugins from Cordova.

To have a single app change significantly from a desktop browser to a
mobile app, I think we would try to leverage CSS Media Query (and maybe
extend it if we need to).

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

On 11/2/17, 2:23 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>my opinion here is different, since making different libraries for the
>same
>purpose make the user task more complicated.
>For example, for the case commented of touch vs mouse we could have only
>one button component that will use conditional compilation to get mouse
>for
>desktop and gestures for mobile. If not users ends with the need to create
>different applications for each platform, and is in our hands to avoid
>that.
>
>Some cases are easy, the button case could have different representations
>in size thanks to CSS, but others are more complicated. Is the case of
>DateChooser vs DateSpinner, but I think we should get a Date component
>that
>could get both behaviours depending on what platform targets without the
>need for the user to have different applications or the need of declare
>different components.
>
>Nowadays, to make an application to target different platforms and devices
>is a nightmare, and if we make people to follow the same path we have in
>Flex, we are not getting any improvement in that workflow. I think Flex
>choose that path due to the implications already in place, the mx and
>spark
>components where made before the mobile era, and was not prepared for
>that.
>
>We are planning the components in this days and we could change that.
>
>At least, for me this would be another key factor to choose Apache Royale
>over other solutions.
>
>Just my 2cnts...
>
>
>2017-11-02 22:00 GMT+01:00 Alex Harui :
>
>> I agree that some components in Mobile.swc could be moved elsewhere and
>> used on desktops, but I thought there would be library of mobile
>> components that default to different interaction models (gesture vs
>> mouse).   Flex had some mobile-specific components (ToggleSwitch,
>> DateSpinner, etc).  I thought their swipe interactions wouldn't work
>>for a
>> desktop with a mouse.
>>
>> Of course, I could be wrong...
>>
>> -Alex
>>
>> On 11/2/17, 7:46 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>> 
>> wrote:
>>
>> >Hi Peter,
>> >
>> >thanks, I think would be great to have that in mind to avoid extra
>>efforts
>> >for users.
>> >As applications are wired nowadays it would be bad for us if we have
>> >separate component libraries
>> >to target different devices. We should try to make differentiations in
>>the
>> >components and we have
>> >varios tools here (CSS, AS3 logic, conditional compilation,...)
>> >
>> >Thanks!
>> >
>> >2017-11-02 15:36 GMT+01:00 Peter Ent :
>> >
>> >> (copied from another email thread; this one seems more appropriate).
>> >>
>> >> I created the Mobile kit. I did it separately because it was
>>supposed to
>> >> mimic how UINavigationController, UIViewController, and
>>UITabController
>> >> work on iOS (which I'm more familiar with than Android). But there is
>> >> nothing specific in that kit (that I remember) which ties it to a
>>mobile
>> >> device. That's opposed to Storage kit, which is dependent on AIR to
>> >> provide a file system on the SWF platform.
>> >>
>> >> I think once we look into refactoring the packages, a lot of Mobile
>> >>could
>> >> be moved out.
>> >>
>> >>
>> >> ‹peter
>> >>
>> >> On 11/2/17, 8:48 AM, "carlos.rov...@gmail.com on behalf of Carlos
>> >>Rovira"
>> >>  wrote:
>> >>
>> >> >Hi, I think we should not differentiate between desktop and mobile.
>>We
>> >> >should make components ready for both platforms and differentiate
>> >>desktop,
>> >> >web, mobile or tablets mainly with CSS for sizes and in some case
>>with
>> >> >code
>> >> >(i.e: DateChooser use to behave differently in desktop than mobile)
>> >> >
>> >> >2017-11-02 13:29 GMT+01:00 Yishay Weiss :
>> >> >
>> >> >>
>> >> >>
>> >> >> For now, we would like to have an Apache Royale "ViewStack"
>> >>equivalent
>> >> >>but
>> >> >> we do not know where to start.
>> >> >> What do you think the parent component should be ? Could you give
>>to
>> >>us
>> >> >> some cues ?
>> >> >>
>> >> >
>> >> >
>> >> >--
>> >> >Carlos Rovira
>> >> >h

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

[Carlos Rovira]

Hi Alex,

my opinion here is different, since making different libraries for the same
purpose make the user task more complicated.
For example, for the case commented of touch vs mouse we could have only
one button component that will use conditional compilation to get mouse for
desktop and gestures for mobile. If not users ends with the need to create
different applications for each platform, and is in our hands to avoid that.

Some cases are easy, the button case could have different representations
in size thanks to CSS, but others are more complicated. Is the case of
DateChooser vs DateSpinner, but I think we should get a Date component that
could get both behaviours depending on what platform targets without the
need for the user to have different applications or the need of declare
different components.

Nowadays, to make an application to target different platforms and devices
is a nightmare, and if we make people to follow the same path we have in
Flex, we are not getting any improvement in that workflow. I think Flex
choose that path due to the implications already in place, the mx and spark
components where made before the mobile era, and was not prepared for that.

We are planning the components in this days and we could change that.

At least, for me this would be another key factor to choose Apache Royale
over other solutions.

Just my 2cnts...


2017-11-02 22:00 GMT+01:00 Alex Harui :

> I agree that some components in Mobile.swc could be moved elsewhere and
> used on desktops, but I thought there would be library of mobile
> components that default to different interaction models (gesture vs
> mouse).   Flex had some mobile-specific components (ToggleSwitch,
> DateSpinner, etc).  I thought their swipe interactions wouldn't work for a
> desktop with a mouse.
>
> Of course, I could be wrong...
>
> -Alex
>
> On 11/2/17, 7:46 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> 
> wrote:
>
> >Hi Peter,
> >
> >thanks, I think would be great to have that in mind to avoid extra efforts
> >for users.
> >As applications are wired nowadays it would be bad for us if we have
> >separate component libraries
> >to target different devices. We should try to make differentiations in the
> >components and we have
> >varios tools here (CSS, AS3 logic, conditional compilation,...)
> >
> >Thanks!
> >
> >2017-11-02 15:36 GMT+01:00 Peter Ent :
> >
> >> (copied from another email thread; this one seems more appropriate).
> >>
> >> I created the Mobile kit. I did it separately because it was supposed to
> >> mimic how UINavigationController, UIViewController, and UITabController
> >> work on iOS (which I'm more familiar with than Android). But there is
> >> nothing specific in that kit (that I remember) which ties it to a mobile
> >> device. That's opposed to Storage kit, which is dependent on AIR to
> >> provide a file system on the SWF platform.
> >>
> >> I think once we look into refactoring the packages, a lot of Mobile
> >>could
> >> be moved out.
> >>
> >>
> >> ‹peter
> >>
> >> On 11/2/17, 8:48 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >>Rovira"
> >>  wrote:
> >>
> >> >Hi, I think we should not differentiate between desktop and mobile. We
> >> >should make components ready for both platforms and differentiate
> >>desktop,
> >> >web, mobile or tablets mainly with CSS for sizes and in some case with
> >> >code
> >> >(i.e: DateChooser use to behave differently in desktop than mobile)
> >> >
> >> >2017-11-02 13:29 GMT+01:00 Yishay Weiss :
> >> >
> >> >>
> >> >>
> >> >> For now, we would like to have an Apache Royale "ViewStack"
> >>equivalent
> >> >>but
> >> >> we do not know where to start.
> >> >> What do you think the parent component should be ? Could you give to
> >>us
> >> >> some cues ?
> >> >>
> >> >
> >> >
> >> >--
> >> >Carlos Rovira
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%2
> >> >Fcarlosrovira&data=02%7C01%7C%7Cf4ef6800329a4b7db4f608d521f0
> >> 21cc%7Cfa7b1b5
> >> >a7b34438794aed2c178decee1%7C0%7C0%7C636452237602199585&
> >> sdata=VJCP0F%2F%2BJ
> >> >Qg8fL0GOhl9VQNeocXe0y0flc2rpAYhgRI%3D&reserved=0
> >>
> >>
> >
> >
> >--
> >
> > http%3A%2F%2Fwww.codeo
> >scopic.com&data=02%7C01%7C%7Cbcb3ac6792ea438a74c208d52200
> 8a29%7Cfa7b1b5a7b
> >34438794aed2c178decee1%7C0%7C0%7C636452308073997718&
> sdata=AoQM%2FPoQcuzZB9
> >A8wnYhLM2zASMZJpD0%2BYrYgZt6Y44%3D&reserved=0>
> >
> >Carlos Rovira
> >
> >Director General
> >
> >M: +34 607 22 60 05
> >
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.codeos
> >copic.com&data=02%7C01%7C%7Cbcb3ac6792ea438a74c208d52200
> 8a29%7Cfa7b1b5a7b3
> >4438794aed2c178decee1%7C0%7C0%7C636452308073997718&
> sdata=AoQM%2FPoQcuzZB9A
> >8wnYhLM2zASMZJpD0%2BYrYgZt6Y44%3D&reserved=0
> >
> >
> >Conocenos Avant2 en 1 minuto!
> > https%3A%2F%2Favant2.e
> >s%2F%23video&data=02%7C01%7C%7Cbcb3ac6792ea438a7

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

[Alex Harui]

I agree that some components in Mobile.swc could be moved elsewhere and
used on desktops, but I thought there would be library of mobile
components that default to different interaction models (gesture vs
mouse).   Flex had some mobile-specific components (ToggleSwitch,
DateSpinner, etc).  I thought their swipe interactions wouldn't work for a
desktop with a mouse.

Of course, I could be wrong...

-Alex

On 11/2/17, 7:46 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Peter,
>
>thanks, I think would be great to have that in mind to avoid extra efforts
>for users.
>As applications are wired nowadays it would be bad for us if we have
>separate component libraries
>to target different devices. We should try to make differentiations in the
>components and we have
>varios tools here (CSS, AS3 logic, conditional compilation,...)
>
>Thanks!
>
>2017-11-02 15:36 GMT+01:00 Peter Ent :
>
>> (copied from another email thread; this one seems more appropriate).
>>
>> I created the Mobile kit. I did it separately because it was supposed to
>> mimic how UINavigationController, UIViewController, and UITabController
>> work on iOS (which I'm more familiar with than Android). But there is
>> nothing specific in that kit (that I remember) which ties it to a mobile
>> device. That's opposed to Storage kit, which is dependent on AIR to
>> provide a file system on the SWF platform.
>>
>> I think once we look into refactoring the packages, a lot of Mobile
>>could
>> be moved out.
>>
>>
>> ‹peter
>>
>> On 11/2/17, 8:48 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>  wrote:
>>
>> >Hi, I think we should not differentiate between desktop and mobile. We
>> >should make components ready for both platforms and differentiate
>>desktop,
>> >web, mobile or tablets mainly with CSS for sizes and in some case with
>> >code
>> >(i.e: DateChooser use to behave differently in desktop than mobile)
>> >
>> >2017-11-02 13:29 GMT+01:00 Yishay Weiss :
>> >
>> >>
>> >>
>> >> For now, we would like to have an Apache Royale "ViewStack"
>>equivalent
>> >>but
>> >> we do not know where to start.
>> >> What do you think the parent component should be ? Could you give to
>>us
>> >> some cues ?
>> >>
>> >
>> >
>> >--
>> >Carlos Rovira
>> >https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>> >Fcarlosrovira&data=02%7C01%7C%7Cf4ef6800329a4b7db4f608d521f0
>> 21cc%7Cfa7b1b5
>> >a7b34438794aed2c178decee1%7C0%7C0%7C636452237602199585&
>> sdata=VJCP0F%2F%2BJ
>> >Qg8fL0GOhl9VQNeocXe0y0flc2rpAYhgRI%3D&reserved=0
>>
>>
>
>
>-- 
>
>scopic.com&data=02%7C01%7C%7Cbcb3ac6792ea438a74c208d522008a29%7Cfa7b1b5a7b
>34438794aed2c178decee1%7C0%7C0%7C636452308073997718&sdata=AoQM%2FPoQcuzZB9
>A8wnYhLM2zASMZJpD0%2BYrYgZt6Y44%3D&reserved=0>
>
>Carlos Rovira
>
>Director General
>
>M: +34 607 22 60 05
>
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeos
>copic.com&data=02%7C01%7C%7Cbcb3ac6792ea438a74c208d522008a29%7Cfa7b1b5a7b3
>4438794aed2c178decee1%7C0%7C0%7C636452308073997718&sdata=AoQM%2FPoQcuzZB9A
>8wnYhLM2zASMZJpD0%2BYrYgZt6Y44%3D&reserved=0
>
>
>Conocenos Avant2 en 1 minuto!
>s%2F%23video&data=02%7C01%7C%7Cbcb3ac6792ea438a74c208d522008a29%7Cfa7b1b5a
>7b34438794aed2c178decee1%7C0%7C0%7C636452308073997718&sdata=GUD86EBdmMhJ9Y
>zcRriunwvdGrigIefR85kK2bydDx4%3D&reserved=0>
>
>
>Este mensaje se dirige exclusivamente a su destinatario y puede contener
>información privilegiada o confidencial. Si ha recibido este mensaje por
>error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
>proceda a su destrucción.
>
>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>comunicamos
>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>servicio o información solicitados, teniendo usted derecho de acceso,
>rectificación, cancelación y oposición de sus datos dirigiéndose a
>nuestras
>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>necesaria.

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

[Carlos Rovira]

Hi Peter,

thanks, I think would be great to have that in mind to avoid extra efforts
for users.
As applications are wired nowadays it would be bad for us if we have
separate component libraries
to target different devices. We should try to make differentiations in the
components and we have
varios tools here (CSS, AS3 logic, conditional compilation,...)

Thanks!

2017-11-02 15:36 GMT+01:00 Peter Ent :

> (copied from another email thread; this one seems more appropriate).
>
> I created the Mobile kit. I did it separately because it was supposed to
> mimic how UINavigationController, UIViewController, and UITabController
> work on iOS (which I'm more familiar with than Android). But there is
> nothing specific in that kit (that I remember) which ties it to a mobile
> device. That's opposed to Storage kit, which is dependent on AIR to
> provide a file system on the SWF platform.
>
> I think once we look into refactoring the packages, a lot of Mobile could
> be moved out.
>
>
> ‹peter
>
> On 11/2/17, 8:48 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi, I think we should not differentiate between desktop and mobile. We
> >should make components ready for both platforms and differentiate desktop,
> >web, mobile or tablets mainly with CSS for sizes and in some case with
> >code
> >(i.e: DateChooser use to behave differently in desktop than mobile)
> >
> >2017-11-02 13:29 GMT+01:00 Yishay Weiss :
> >
> >>
> >>
> >> For now, we would like to have an Apache Royale "ViewStack" equivalent
> >>but
> >> we do not know where to start.
> >> What do you think the parent component should be ? Could you give to us
> >> some cues ?
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7C%7Cf4ef6800329a4b7db4f608d521f0
> 21cc%7Cfa7b1b5
> >a7b34438794aed2c178decee1%7C0%7C0%7C636452237602199585&
> sdata=VJCP0F%2F%2BJ
> >Qg8fL0GOhl9VQNeocXe0y0flc2rpAYhgRI%3D&reserved=0
>
>


-- 



Carlos Rovira

Director General

M: +34 607 22 60 05

http://www.codeoscopic.com


Conocenos Avant2 en 1 minuto! 


Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

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

[Peter Ent]

(copied from another email thread; this one seems more appropriate).

I created the Mobile kit. I did it separately because it was supposed to
mimic how UINavigationController, UIViewController, and UITabController
work on iOS (which I'm more familiar with than Android). But there is
nothing specific in that kit (that I remember) which ties it to a mobile
device. That's opposed to Storage kit, which is dependent on AIR to
provide a file system on the SWF platform.

I think once we look into refactoring the packages, a lot of Mobile could
be moved out.


‹peter

On 11/2/17, 8:48 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi, I think we should not differentiate between desktop and mobile. We
>should make components ready for both platforms and differentiate desktop,
>web, mobile or tablets mainly with CSS for sizes and in some case with
>code
>(i.e: DateChooser use to behave differently in desktop than mobile)
>
>2017-11-02 13:29 GMT+01:00 Yishay Weiss :
>
>>
>>
>> For now, we would like to have an Apache Royale "ViewStack" equivalent
>>but
>> we do not know where to start.
>> What do you think the parent component should be ? Could you give to us
>> some cues ?
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7C%7Cf4ef6800329a4b7db4f608d521f021cc%7Cfa7b1b5
>a7b34438794aed2c178decee1%7C0%7C0%7C636452237602199585&sdata=VJCP0F%2F%2BJ
>Qg8fL0GOhl9VQNeocXe0y0flc2rpAYhgRI%3D&reserved=0

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

[Carlos Rovira]

Hi, I think we should not differentiate between desktop and mobile. We
should make components ready for both platforms and differentiate desktop,
web, mobile or tablets mainly with CSS for sizes and in some case with code
(i.e: DateChooser use to behave differently in desktop than mobile)

2017-11-02 13:29 GMT+01:00 Yishay Weiss :

>
>
> For now, we would like to have an Apache Royale "ViewStack" equivalent but
> we do not know where to start.
> What do you think the parent component should be ? Could you give to us
> some cues ?
>


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