RE: [widgets] A proposal on widget modes

Hi Arve,

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

Thanks,

Mark 

>-----Original Message-----
>From: Arve Bersvendsen [mailto:arveb@opera.com] 
>Sent: 20 January 2009 20:53
>To: Priestley, Mark, VF-Group; public-webapps
>Subject: 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)
>

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

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

[MP] We agree

>Also, there is some different in expected behaviour 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'?
>

[MP] We feel that if there is more than one attribute related
to the display of the widget it makes sense to group them together in an
element. We agree "viewmode" is better than "mode"

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

[MP] We think that this should be a DOM event that takes place after the
switch of modes. Not 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)

[MP] We agree that this is a better approach and prefer the use of a
DOMString

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

[MP] Agreed

>
>> 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);
>
[MP] Agreed - although we want to make clear that this should only be
applicable
to floating (and application) modes

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

[MP] We understand the problem that you highlight but we feel strongly
that docked 
mode should be supported. 

As such we could propose something along the following lines:

"A widget instance may be displayed in docked mode and either fullscreen
mode or floating 
mode at the same time. A widget instance can not be displayed in
floating mode and fullscreen 
mode at the same time."

As long as widgets in docked mode can't have focus this shouldn't
present an issue as far as 
we can work out (although it could make mode transistions a bit more
complex) 

>
>(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)
>

[MP] Couldn't we just return null or some other value in the case that
height or 
width were not fixed?


>> -------------------------------
>> 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)
>
[MP] This may be true but I guess we were approaching this from the
point of view of having at 
least one default mode which a widget developer could rely on, and our
opinion was that floating mode 
was the ideal candidate for this (as defined it's the only mode in which
the developer can fully control 
the display of the widget).  

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

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

[MP] Agreed - no need to specify this, more us trying to explain what we
would expect...

>> @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.  
>
[MP} Sounds like a good plan

>--
>Arve Bersvendsen
>
>Developer, Opera Software ASA, http://www.opera.com/
>
>
>

Received on Thursday, 22 January 2009 13:28:03 UTC