Re: [widgets] A proposal on widget modes

On Tue, 20 Jan 2009 20:58:41 +0100, Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com> wrote:

>
> Hi All,
>In the current Widgets 1.0: Packaging and Configuration specification
> [1], the window modes feature is identified as being at risk. Vodafone
> believes that window modes are an important feature and should be
> supported in Widgets 1.0. This email provides a proposal for how modes
> could be specified and why we think this would be of value. Our proposal
> is based on our experiences with current and prototype widget
> implementations, however, we welcome any suggestions on how this
> proposal could be improved.

Mostly, this proposal is in line with what Opera wants, but a few specific comments follow.

> Vodafone has identified the need for floating, fullscreen and docked
> modes. We have not identified a need for an application mode, although
> we recognise that this may not be aimed at mobile devices. We would
> therefore support the addition of the following attribute definition to
> [1]:

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)

> A keyword attribute whose value is one of the following valid modes:
> floating, fullscreen, docked. The default value, which is used when the
> attribute is omitted or has a value other than one of the valid modes,
> is floating.

See above regarding 'application'.  'floating' is equivalent to what we have in the past named 'widget', but frankly, I think 'floating' might be a better choice of word

Also, there is some different in expected behavior between these modes -- I'll dig up the specific text Opera has for supporting view states, and how it interacts with the initial viewport size, and behavior of CSS.

> The mode Element
>
> The mode element represents the modes that a widget has been designed to
> operate in.

I am a bit unsure about whether an attribute, or an element is the right choice here. Either way, if an element is the preferred choice, I would prefer something that would remain unambigous for a foreseeable future.  'viewmode'?

> default
>
> Optional. A mode attribute that indicates the default mode of operation
> for a widget.

Depends on whether this should be an element or attribute.

> 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?

> b.)getMode - an API that returns the current mode of the widget,
> alternatively this could be a property of the widget object;

ECMAScript bindings have little tradition for using getters this way. What about

interface Widget {
  /* ...  */
  readonly attribute DOMString currentMode;
}

(Alternatively, replace DOMString with an unsigned integer)


> c.)onBlur - an event triggered when the widget loses focus;
> d.)onFocus - an event triggered when the widget gets focus;

Blur and focus events are already de facto part of the window object, and as such is out of scope here, but should perhaps be mentioned as part of HTML

> e.)resize(height, width) - an API for changing the size of a floating
> widget;
> f.)onResize - an event triggered when the widget is re-sized in floating
> mode;

Also part of Window:

resizeTo(in int width, in int height);
resizeBy(in int delta_x, in int delta_y);

> g.)getDockSize() - an API that returns the size of the dock(s) supported
> by the widget user agent.

Dock size is tricky as an implementation may want to support simultaneous display of the dock and of the widget. This is essentially an unsolved problem, and I would rather we drop docking features for now.

(There are also situations where the dock might have a fixed width, but no fixed height -- the Vista sidebar gadgets work as an example of this)

> -------------------------------
> Floating mode
>
> It is expected that all widget user agents will support floating mode.

Is it? (The answer is "no", fwiw -- there are implementations that essentially only support fullscreen)

> 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.

> b.) Widgets in floating mode can overlap each other;

This is not the case for tiled window managers, such as dwm, ion, awesomewm.

Further, I don't think there is a direct need to specify this behavior.

> @media all and (widget-mode:docked) {
>    #myDockedView {
>      display: block;      /* shows the docked mode content */
>    }
>    #myFullscreenView {
>      display: none;
>    }
> }

Yes, from my standpoint, this seems to be a good proposal, but we might want to clear it with the CSS working group.  

-- 
Arve Bersvendsen

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

Received on Tuesday, 20 January 2009 20:53:44 UTC