[widgets] Focus & widgets management, was: RE: [widgets] A proposal on widget modes

Hi Arve, Mark,

ACCESS has a few FYI comments related to the widget modes and also corresponding to the widget management mentioned in this mail thread.

i) SCREEN SIZES / WIDGET MODES in NETFRONT WIDGETS
ii) OPEN IPTV FORUM SPECIFICATION: WIDGET/APPLICATION FOCUS MANAGEMENT

i) SCREEN SIZES / WIDGET MODES in NETFRONT WIDGETS
ACCESS' NetFront Widgets specification added the following functionality to the previous draft of the Widget 1.0 spec:
1. Display states:
a) Normal Display State (Floating state)
The normal display state is used to position more than one widget on the standby screen, etc. Widgets on the standby screen can be aligned, overlapped, or moved to any position. For this reason, the normal display state is sometimes called the float state.
When the state switches from another display state to the normal display state, the onrestore event handler of the widget object is called.
b) Maximized Display State
In the maximized display state, a widget is displayed within a wider area than the normal display state. The number of widgets that can be displayed at the same time in this state depends on the terminal. For example, it is possible to allow only one widget to be displayed in maximum display for an environment with a small display area such as a mobile terminal, and allow more than one widget to be displayed concurrently in maximum display for an environment with a large display area such as a TV.
When the state switches from another display state to the maximum display state, the onmaximize event handler of the Widget object is called.
c) Docked Display State
Docked display state displays more than one widget on the standby screen, etc. using small rectangular windows. This state is used to show the minimum amount of information desired to be updated regularly when displaying a widget.
When the state switches from another display state to the dock display state, the ondock event handler of the Widget object is called. The widget content creator can switch the display content to that of dock display state using the ondock event handler.

To sum up, we have the following event handlers:
- onrestore
- onmaximize
- ondock

The screen sizes in NetFront Widgets are specified as follows:
1. For Normal/Floating state: by width + height attributes of the <widget> element in config.xml
2. For Maximized state: by maximizedwidth + maximizedheight attributes of the <xwidget> element in config.xml
3. NetFront Widgets added <display> element to config.xml where the type attribute takes one of the following values: QWGA, WQVGA, VGA, WVGA that specify for which type of screen the widget was developed.

ii) OPEN IPTV FORUM SPECIFICATION: WIDGET/APPLICATION FOCUS MANAGEMENT

The Open IPTV Forum (OITF) specifications are located here:
http://www.openiptvforum.org/downloads.html

One of them
http://www.openiptvforum.org/docs/Release1/OIPF-R1_SPEC_Volume_5_V1_0.pdf
in its section 7.13 defines a model for applications/widgets that has been suggested by Mark, i.e. it is among others about widget focus management.

Among others, we have there the following methods:
- show()
- hide()
- activate()
- deactivate()
and the following events (copied directly from the OITF spec):
- ApplicationActivated: Issued when an application focus change occurs to inform the recipient of the event that the application is now focussed.
- ApplicationDeactivated: Issued when an application focus change occurs to inform the recipient of the event that the application is now no longer
focussed.
- ApplicationShown: Issued when an application has become visible.
- ApplicationHidden: Issued when an application has become hidden.
- ApplicationPrimaryReceiver: This event is issued to indicate that the target is now at the front of
the active application list.
- ApplicationNotPrimaryReceiver: This event is issued to indicate that the target is no longer at the
front of the active application list.
- ApplicationTopmost: This event is issued to indicate that the target is now the topmost (i.e. it has the highest Z-index and is not obscured by any other visible applications, for OITFs where multiple applications are
visible simultaneously.
- ApplicationNotTopmost: This event is issued to indicate that the target is no longer at the topmost application. For OITFs where only one application is visible at a time, this event indicates that the application is no longer visible to the user.

Probably this model could be adopted or something similar (i.e. covering the market needs) should be elaborated.
Also when focus-related specifications are being produced, ACCESS assumes that WICD is taken into account:
http://www.w3.org/TR/2007/CR-WICD-20070718/#focus-handling
to prepare a full model.

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Europe GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com
-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Arve Bersvendsen
Sent: Thursday, January 22, 2009 2:57 PM
To: Priestley, Mark, VF-Group; public-webapps
Subject: Re: [widgets] A proposal on widget modes


On Thu, 22 Jan 2009 14:25:02 +0100, Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com> wrote:

> Hi Arve,
>
> Thanks for your feedback - I'm glad our thinking is along similar lines.
> Some responses to your comments below.

Some responses below. Note that I have cut parts to which I have no direct answer yet.

>> Application mode is required outside of a mobile context, to
>> differentiate between chromeless (e.g. Opera
>> Widgets/Dashboard/etc) and widgets with OS Chrome (e.g. the
>> Adobe AIR view state model)
>>
>
> [MP] We are of course fine with an application mode being defined, we
> just
> don't have an opinion on what it should be... From your description we
> assume it will be as per the floating mode but with chrome?

There are some expected differences in behavior.

1. Floating widgets are expected to be draggable from any area of the widget, except where defined by [CSS] to not be draggable. 'Application' Widgets are not expected to exhibit this behavior.
2. Application widgets are expected to be user-resizable, and so authors cannot rely on the widget having any particular viewport size.

This makes them behave much more like 'fullscreen' in a mobile context, or like a regular web page in a browser.

>>> a.)onModeChange - an event triggered when the widget
>> transitions to a
>>> new mode;
>>
>> It needs to be specified _when_ this event is triggered. Is it
>> prior to the mode switch taking place?  Is it a DOM event, or
>> a callback.  Is it cancellable?
>
> [MP] We think that this should be a DOM event that takes place after the
> switch of modes. Not cancellable.

The downside to letting this happen after the mode switch, is that the widget might in this callback want to

>>> a.) Only one floating mode widget can have focus. The widget with
>>> focus must have the highest z-index;
>>
>> This is in direct conflict with Window behavior on Unix/Linux
>> system, where a window can have a lower z-index than other
>> windows, and still be focused. It is also in conflict with
>> Opera's current desktop widget implementation, where it is
>> possible to push widgets to stick to the desktop and as such
>> be overlaid by other windows.
>>
> [MP] Good points - so we could instead say something like the last
> widget that the user interacted with
> has focus? Would that work?

I'm not really sure there is a need to say anything really - because we'd be well into the domain of specifying interaction requirements and behavior of operating systems.

--
Arve Bersvendsen

Developer, Opera Software ASA, http://www.opera.com/




________________________________________

Access Systems Europe GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Friday, 23 January 2009 12:14:35 UTC