You are welcome, Max.

Thanks for your comment, Tucker. I understand what you mean, but I
think it's more complex than it initially seems to be.

What about browser APIs? If the browser has orientation information,
what would be the proposed way by the OpenLaszlo team to retrieve that
information in both Flash and DHTML runtime?

Google is already working on adding orientation to Webkit: A patch to
bring orientation support to Chromium and eventually Chrome has been
introduced to the WebKit code. This would enable the browser to get
orientation data from the device it is running on, things like
rotation, acceleration and related data. The functionality is being
built straight into WebKit, the rendering engine powering Chrome but
also Safari and countless other mobile or desktop browsers.
http://news.softpedia.com/news/Support-for-Device-Orientation-Coming-to-Google-Chrome-146573.shtml

Firefox: “One new feature that we’re including as part of Firefox 3.6
is support for web pages to access machine orientation information if
it’s available,” Mozilla evangelist Christopher Blizzard wrote.
“Originally built as something that we would include for our upcoming
mobile browser release, we’ve made it available on desktop systems as
well. Many modern Macbooks and Thinkpads contain devices and drivers
that expose this information. We’ve added support for Linux, Macs and
some Thinkpads where drivers and devices are available.”
JS event: window.addEventListener("MozOrientation", handleOrientation, true);
Docs: https://developer.mozilla.org/en/Detecting_device_orientation

@Tucker: Regarding your question "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."
There are quite a few applications which don't autorotate the whole
app but content within the app. Here's a blog post of a developer
describing that:
http://blog.sallarp.com/shouldautorotatetointerfaceorientation/

Square displays and portrait/landscape mode: If you an Android based
phone, the OS is relevant, and Android generally supports portrait and
landscape modes. Within Android apps, you can have different views
with different behavior regarding autorotation of content for each
view. If such an application will be launched on a device with a
square display, the views will rendered based on the setting for
orientation for the app, or pars of the app.

I just have a lot of questions, based on the research/testing I've done.

On Mon, Jul 12, 2010 at 11:10 PM, Max Carlson <[email protected]> wrote:
> Thanks for filing that improvement Raju!  It seems like we want both - an
> event that tells the actual orientation when you need it, and canvas
> onwidth/height events (provided the app doesn't have a fixed canvas size).
>
> Regards,
> Max Carlson
> OpenLaszlo.org
>
> On 7/12/10 1:08 PM, 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
>>>>>
>>>
>>>
>>
>

Reply via email to