Re: [widgets] A proposal on widget modes

Hi Mark, Arve,

I've renamed currentMode to viewMode in the API spec. viewMode
represents the current view mode of the widget.

I would like to hear more use cases for the <modes> element before
adding it to the spec.

Kind regards,
Marcos



2009/1/22 Arve Bersvendsen <arveb@opera.com>:
>
> 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/
>
>
>
>



-- 
Marcos Caceres
http://datadriven.com.au

Received on Thursday, 12 February 2009 14:06:53 UTC