I think we are talking past each other here. I understand that at some level you need to know "which way is up". I understand that there are physically configured bits on the phone (I gave the example of a physical button, which is visible to the user, you gave the example of the accelerometer, which has it's coordinate system physically aligned with the device) where orientation will be important. I understand that in certain applications, you will have a creative need to know the exact orientation of the device (you had better hope it has a gyroscope).
My point is that for a "normal" application, we should provide a virtual canvas where 0,0 is top-left, the x-coordinate system increases to the right and the y-coordinate system increases down. I should not have to have my app sense that the device has been turned upside down and set my canvas rotation to compensate. That approach will allow a legacy application to "just work" when you turn the device upside down, just as Mobile Safari synthesizing mouse gestures from touch gestures allows legacy DHTML applications to work. (Safari does not prevent applications from getting the touch gestures, but neither does it require it.) I'm not saying we prevent the app from seeing the low-level orientation information, just that we don't require it. I know there are devices with square displays. Presumably when you turn them sideways, they are still square. What UI state is used to represent which side of the square display is up? Surely not something with the word portrait or landscape? On 2010-07-12, at 16:08, Raju Bitter wrote: > No, Tucker, there's a reason for the need to know which side of the > phone is up. As soon as you start using the accelerometer in UI > interactions, it's of course relevant to know which side of the phone > is "up", or you'll get the wrong behavior for you app. And the "square > phone" is not a magical item, there have been phones with a square > display before (Palm), and Motorola is working on one: > http://pocketnow.com/tech-news/motorola-to-further-fragment-android-with-square-resolution-phone > > On Mon, Jul 12, 2010 at 9:56 PM, P T Withington <[email protected]> wrote: >> I think your :-) means you are not expecting me to answer, but just in case: >> >> I would _hope_ that the LZX platform kernel would deal with the orientation. >> That is, the naive LZX programmer shouldn't have to even _think_ about >> which way is up. His application should be displayed right side up by >> default. _If_ the programmer has an application that wants to know about >> the actual orientation, for some clever reason (e.g., to know that the >> physical home button is above his app instead of below it), we should not >> prevent him from getting at that information; but we should not require LZX >> programmers to know anything about that for their app to "just work". >> >> The LZX spirit is to try to think outside the platform box to see if we can >> discover a general principal that can be applied across all platforms. I'm >> willing to entertain serious objections to why you can't define portrait and >> landscape as being the ratio of height to width (that is what the dictionary >> says), but suggesting that a square display has a portrait and a landscape >> mode sounds like a punchline whose joke I am missing? >> >> If we are going to invent mythical devices, what about my roll-up tablet? >> Wouldn't you want your LZX application to notice that I have unrolled more >> diaplay and to automatically adapt to the amount of visible display, without >> having to wait for a new release of the application that knows about the >> UIInterfacePercentUnrolled API? >> >> On 2010-07-12, at 15:03, Raju Bitter wrote: >> >>> But then, how do you know the difference between these two states for >>> iOS, e.g. iPad: >>> 1) UIInterfaceOrientationPortrait >>> 2) UIInterfaceOrientationPortraitUpsideDown >>> >>> And how about devices with a square display, where the width and >>> height cannot be deduced from a numerical value? Like future devices >>> running Android... >>> >>> :-) >>> >>> On Mon, Jul 12, 2010 at 8:04 PM, P T Withington <[email protected]> wrote: >>>> I agree with what you are saying, but I am pointing out that the LZX event >>>> should be based on the display dimensions, not a device sensor. That way, >>>> even in a browser, I can have the benefit of landscape or portrait >>>> orientations. >>>> Another way of looking at it is that a mobile device kernel should >>>> virtualize changing the orientation of the device as a change in the screen >>>> dimensions (just as if I had resized a browser window). >>>> >>>> On Jul 12, 2010, at 10:26, Quirino Zagarese <[email protected]> >>>> wrote: >>>> >>>> I guess the point is runtime rotation of the device. >>>> If I rotate my device I would like to have some kind of event or callback >>>> in >>>> order to >>>> reorganize the UI. Of course I can benefit of constraints, but I need to >>>> know first the device >>>> has actually been rotated. If I had to build an Android LZX app, >>>> I would put a main view in the canvas that rotates accordingly to >>>> underlying >>>> device rotation >>>> events. Inside it I would use constraints to automatically re-dispose >>>> components. >>>> For this purpose, Laszlo is simply great! >>>> >>>> Quirino >>>> >>>> >>>> 2010/7/12 P T Withington <[email protected]> >>>>> >>>>> I think this is a place where OpenLaszlo could potentially really shine, >>>>> through the use of constraints. You don't _really_ need to know about >>>>> screen "orientation" since you should be able to deduce it from the canvas >>>>> dimesions: >>>>> >>>>> function screenOrientation () { >>>>> return canvas.width > canvas.height ? 'landscape' : 'portrait'; >>>>> } >>>>> >>>>> A careful OL app will use constraints to optimize itself to the canvas >>>>> dimensions and thus work in resizable browser windows, on platforms with >>>>> various screen dimensions, etc. If the app wants to present different >>>>> layouts based on landscape or portrait orientation, why should it base >>>>> that >>>>> on some hardware device sensor? I should be able to resize my browser >>>>> window and get the same layout. >>>>> >>>>> On 2010-07-12, at 08:19, Raju Bitter wrote: >>>>> >>>>>> After my first weeks of testing OpenLaszlo+PhoneGap on Android I think >>>>>> one of the first improvement the LFC needs would be support for screen >>>>>> orientation. Probably >>>>>> >>>>>> a) a canvas attribute storing the orientation value >>>>>> For the iOS possible values are: >>>>>> 1) UIInterfaceOrientationPortrait >>>>>> 2) UIInterfaceOrientationPortraitUpsideDown >>>>>> 4) UIInterfaceOrientationLandscapeLeft >>>>>> 5) UIInterfaceOrientationLandscapeRight >>>>>> >>>>>> Android default modes are portrait and landscape. >>>>>> >>>>>> b) a canvas event in case the screen orientation changes >>>>>> >>>>>> http://jira.openlaszlo.org/jira/browse/LPP-9048 >>>>>> >>>>>> For Android/PhoneGap we'd need to extend the DroidGap class to send an >>>>>> event into JavaScript/canvas in case of layout/orientation change, it >>>>>> doesn't seem to be supported through JavaScript, at least for 2.1. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mobile mailing list >>>>> [email protected] >>>>> http://www.openlaszlo.org/mailman/listinfo/mobile >>>> >>>> >>>> >>>> -- >>>> Quirino Zagarese >>>> >>>> PhD Student - Engineering Department - Università degli Studi del Sannio >>>> >>>> Italian OpenLaszlo Community - www.laszloitalia.org >>>> >>>> EU4RIA: Laszlo+Java, easily - eu4ria.googlecode.com >>>> >> >>
