incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: [PROPOSAL] Orientation Interface
Date Mon, 24 Oct 2011 22:28:07 GMT
pseudo xui code ... a simple case

// image view should be freely oriented
function showImageView() {
    x$("#listView").css({display:'none'});
    CB.supportedOrientations = [0,90,-90,180];
    x$("#imageView").css({display:'block'});
    x$("#imageView .closeBtn").click(showListView);
}

// list view always wants to display in portrait or portrait upsidedown
function showListView() {
    x$("#imageView").css({display:'none'});
    CB.supportedOrientations = [0,180];
    x$("#listView").css({display:'block'});

    x$("#listView li").click(function(e){
       // assume some DOM modification based on selected item.
       showImageView();
    });
}

On Mon, Oct 24, 2011 at 3:11 PM, Brian LeRoux <brian.leroux@nitobi.com>wrote:

> k, so imp semantics aside for a second. can you futz up a quick
> example of how you would call the code? (rather than how you'd impl
> it)
>
> want to understand use cases here..
>
>
>
> On Mon, Oct 24, 2011 at 3:00 PM, Jesse <purplecabbage@gmail.com> wrote:
> > Storing values in an object IMHO adds little or no value.
> > The Array has the additional benefit of providing a preferential order as
> > well, for the case where the requested 'supportedOrientations' does not
> > contain the physical current orientation.
> >
> > I do see a benefit to have defined type values, but deviating from the
> > numeric values only makes things more difficult to understand.  The
> numeric
> > values were chosen because these ARE the values passed to listeners of
> the
> > 'orientationchange' event
> > On most platforms, window.orientation already contains an integer value
> > which is one of : 0,90,-90,180
> >
> > north|south| .. imply that we are talking about the compass direction
> that
> > the device is facing, which absolutely not the case.
> >
> > We could make it absolutely understandable to all by providing a static
> > human-readable version of the values. Like this:
> >
> > // This definitely SHOULD be namespaced
> > OrientationType = {
> >  PORTRAIT:0,
> >  LANDSCAPE:90,
> >  LANDSCAPE_LEFT:90,
> >  LANDSCAPE_RIGHT:-90,
> >  PORTRAIT_RIGHTSIDEUP:0,
> >  PORTRAIT_UPSIDEDOWN:180
> > };
> >
> > // RE:  I can see more orientation
> > // settings emerging in the future. For example, future devices may have
> a
> > // fluid orientation ....
> >
> > This should not be confused with the devicemotion or accelerometer apis
> > which provide much more granular control when needed. Orientation values
> are
> > intended to be discrete values and not a continuous series.  The only
> other
> > orientations I foresee are possible additions of FACEUP and FACEDOWN,
> > although they are primarily just modifiers in another dimension to the
> > existing values.
> >
> >
> >
> >
> >
> >
> > On Mon, Oct 24, 2011 at 2:17 PM, Brian LeRoux <b@brian.io> wrote:
> >
> >> Good suggestions mr. brooks. Also, we might as we get used to this, it
> >> will be spaced under CB. Also, I think we could be more colloquial:
> >>
> >> CB.orientation.supports = {
> >>  north:true,
> >>  south:false,
> >>  east:false,
> >>  west:true
> >> }
> >>
> >> if (CB.orientation.supports.north) {
> >>  // ...etc
> >> }
> >>
> >> Is there API utility in the absolute #'s in an array that we're
> >> missing here Jesse? How are ppl using orientation?
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message