T & C
Terms and Conditions of Use:
DISCLAIMER: The content provided in this app is available in public domain.
In order to use the free App/Service, you must firstly agree to the Terms. You may not use the Service if you do not accept the Terms.
This app / Service is only an aggregator of the content from freely available videos on public domain e.g. YouTube.
This App / Service does not claim ownership of the content it publishes and uses.
If you beleive your copyright is being infringed, please contact the source/host of the content and request necessary action.
You can accept the Terms by simply using the App/Service. You understand and agree that "This app / creator of This app" will treat your use of the Service as acceptance of the Terms from that point onwards.
You may not use the Service and may not accept the Terms if (a) you are not of legal age to form a binding contract with "This app / creator of This app", or (b) you are a person who is either barred or otherwise legally prohibited from receiving or using the Service under the laws of the country in which you are resident or from which you access or use the Service.
This app and free Service may include hyperlinks to other web sites that are not owned or controlled by "This app / creator of This app".
This "This app / creator of This app" has no control over, and assumes no responsibility for, the content, privacy policies, or practices of any third party websites.
You acknowledge and agree that "This app / creator of This app" is not responsible for the availability of any such external sites or resources, and does not endorse any advertising, products or other materials on or available from such web sites or resources.
You acknowledge and agree that "This app / creator of This app" is not liable for any loss or damage which may be incurred by you as a result of the availability of those external sites or resources, or as a result of any reliance placed by you on the completeness, accuracy or existence of any advertising, products or other materials on, or available from, such web sites or resources.
"This app / creator of This app" encourages you to be aware when you leave the Service and to read the terms and conditions and privacy policy of each other website that you visit.


Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document surveys a group of market-leading widget user agents with the aim to inform the requirements of the Widgets 1.0: Requirements document. The survey exposes commonalities and fragmentation across widget user agents, and discusses how fragmentation currently affects, amongst other things, authoring, security, distribution and deployment, internationalisation and the device-independence of widgets. The document concludes by making a set of recommendations on what aspects of widgets require standardization to reduce fragmentation to ultimately standardize a cross-platform widget solution.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the W3C First Public Working Draft of the Widgets 1.0: Landscape. Once all the comments about this document will have been addressed, the Working Group intends to publish a final version of this document as a W3C Working Group Note.
The W3C Membership and other interested parties are invited to send comments to<EMAIL_ADDRESS>the W3C's public email list for issues related to Web Application Formats. Archives of the list are available.
This document is produced by the Web Application Formats WG, part of the Rich Web Clients Activity in the W3C Interaction Domain. It is expected that this document will become a Working Group Note. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document surveys the widget landscape by examining how market-leading widget user agents address issues around:
The market-leading widget user agents that are included in the survey are listed below. The widget user agents were subjectively chosen because of their perceived prevalence in the market place. This survey was conducted independently of any vendor and no vendor explicitly requested they be included in the survey.
| Widget User Agent | Vendor | Version | Platform |
|---|---|---|---|
| Widget User Agent | Vendor | Version | Platform |
| Konfabulator | Yahoo! | 4.5 | Windows XP, Windows Vista, MacOS |
| Windows Sidebar | Microsoft | 1.0 | Windows Vista |
| Google Desktop Gadgets | 1.x | Windows XP, Windows Vista | |
| Opera Widgets | Opera | 9.5 Beta | Mac OS 10.5, Windows XP, Windows Vista |
| Dashboard | Apple | 1.1 | Mac OS 10.5 |
| Web-Runtime | Nokia | 1.0 Beta | S60 3rd Edition, Feature Pack 2 (emulator) |
| Joost Widgets | Joost | 1.0 Beta | Mac OS 10.5, Windows XP, Windows Vista |
The inclusion of the widget user agents in this survey does not indicate endorsement of the standardization process by any particular vendor (in other words, just because a widget user agent appears should not be taken to mean that they will implement any part of the Widgets 1.0 specifications).
The purpose of this document is to provide a holistic overview of the widget space and provide information to aid in standardization process of widgets by the Web Application Formats Working Group. As such, this document provides:
This section defines some of the key terms related to widgets.
application/vnd.joost.joda-archive
media type.config.xml
resource bundled with an Opera widget.Since around 2003, a relatively new kind of application has seen significant
proliferation onto desktop computers and, more recently, web-enabled portable devices
like mobile phones. This kind of application is generally referred to by developers as a
widget engine: a piece of software that is able to run other smaller
applications known as widgets or gadgets. On the user's desktop,
widgets have gradually taken the place of some traditional single-purpose applications.
Typical examples of widgets range from simple clocks, CPU gauges, post-it notes, games,
battery-life indicators, to more sophisticated web-enabled widgets like weather
forecasters, news readers, email checkers, photo albums and currency converters.
There are literally thousands of unique widgets available for download on the web, which
users generally collect to create personal widget inventories. These widget inventories
provide users with access to online services that they commonly use. This means that, in
a lot of instances, users don't need to open up a web browser to get the information that
they want (eg. to check the weather). This is an aspect of widgets that makes them
particularly attractive on mobile devices, where the monetary cost of downloading web
pages is currently an issue for many users.
For developers, some widgets differ from traditional binary applications in that they are created using the same open technologies used to create web pages. Widget engines mimic, in many ways, the behavior of web browsers: an increasing number are actually built directly on top of web browsers so they are able to render web pages, while others incorporate web browser components such as ECMAScript interpreters. To developers and vendors, this means that most widgets are significantly easier to create than applications developed with lower-level programming languages such as Java and C#.
Amidst the popular rise of widgets and widget engines lay a number of issues for users, developers, current vendors and new vendors wanting to enter the market. By surveying various aspects that pertain to widget user agents, this document discusses these issues so they may be resolved through the W3C standardization process.
As shown in figure 1, a widget is instantiated on a widget user agent and can make use of a number of technologies that serve a different role (eg. distribution and deployment, etc). However, some of those technologies have not yet been formally standardized (items marked with an asterisk), which has contributed to fragmentation across the widget space.
Figure 1. A typical widget technology stack and aspects that have require standardization. Please note that this technology stack is intended as a guide, and does not represent the technology stack of any particular user agent.
Web widgets (also known as modules or badges) are fragments of HTML, CSS, and ECMAScript (or possibly an Adobe Flash movie) that are either declaratively or dynamically included into a Web document. A common example of Web widgets is one that downloads a set of icon-sized images from a photo-sharing Web site and displays those images as a slide-show based on a set of user preferences (eg. the images tagged 'vacation Italy'); such Web widgets are commonly seen embedded into social networking Web sites and blogs. Popular providers of Web widgets include:
Unlike widgets, Web widgets a hosted on the server-side and are embedded into HTML documents prior to being served to the client. The creation of a Web widget usually involves having an author specify, in XML or some other format (eg. PHP), what the widget does and which APIs the Web widget depends on. This document is then uploaded to a server, where when it is served to a client, it is transformed into HTML, CSS, and ECMAScript. For example, the input column of the table below shows a typical iGoogle gadget specification:
| Input | Output |
|---|---|
| Input | Output |
<?xml version="1.0" encoding="UTF-8"?> |
Hello World! |
After being processed on the server-side, the code in the input column is transformed
to HTML, CSS, and ECMAScript and inserted into the served document as either an
iframe
or as HTML elements (see the the Output column above). The actual
code that Google generates from the example is too large to be included in this
document.
Because Web widgets and a widget have a reliance of Web technologies, their offer much of the same functionality. However, differences exist in:
In relation to the packaging format , Web widgets are generally not packaged or downloaded as a single file (except in the case of Adobe Flash movies). Instead, Web widgets are commonly dynamically instantiated through a mix of ECMAScript, HTML elements, and CSS. However, similar to a widget as described in this document, some Web widgets make use of a dynamically loaded RSS file or JSON as a configuration document format.
In relation to security models, unlike a widget, Web widgets are generally part of a HTML document's DOM and so are bound to all the security constraints imposed by Web browsers.This means that Web widgets cannot make cross-domain requests, cannot autonomously access resources on an end-user's device, access system-level properties like the make, model, or usage percentage of the CPU, or execute system level commands like creating or deleting files, while widgets that run on most market-leading widget user agents generally can. In other words, some widget user agents provide a more relaxed security model than the one afforded to Web widgets by Web browsers.
The ability for a widget to perform actions beyond the security scope of Web widgets
is partially afforded by widget-specific APIs. For example, on Windows Vista's Sidebar, a
widget can be scripted to create a new folder on the end-user's hard drive by calling
'System.Shell.Folder.newFolder(strNewFolderName)'
. See Microsoft's
Sidebar Reference or Konfabulator Reference for more examples of API functionality
that is beyond the scope of Web widgets.
Another difference is how widget user agents handle internationalization when compared
to Web widgets (Web Browsers). On the Web, internationalization is sometimes handled
through HTTP's Accept-Language
header: this
works by allowing the Web Browser to send the end-user's preferred language to a server
(eg. Accept-Language: en-us
). If the server contains a version of the
desired resource in the end-user's language of choice, then the localized resource may be
returned to the end-user. A widget, on the other hand, may sometimes contained all
localized resources inside the widget resource in folders named using the common
language-region pattern (eg. /en-us/). When the widget is instantiated, the widget user
agent attempts to match one of these specially named folders to user's language
preferences. See the Internationalization and Localization section
for more information.
Widgets and Java applets share many commonalities. For instance, both widgets and applets rely on a pre-installed runtime engine for execution: java applets rely on the presence of the Java Runtime Environment (JRE), while widgets rely on the presence of their target widget engine. Widget and Java applets also share many similar functional aspects, like being able to do asynchronous HTTP requests to download resources from the Web.
It is argued that the most notable difference between them is that widgets are easier for authors to create than Java applets. This argument is made because widgets are created using HTML, CSS, and ECMAScript, which have very forgiving error handling and a short learning curve compared to Java. Another difference is that Java Applets are intended to run inside Web pages, while widgets as described in this document generally serve the purpose of stand-alone applications that run outside of a Web browser.
Packaging refers to encapsulating all the necessary resources and metadata required by the widget into a single file for the purpose of distribution and deployment. Distribution and deployment refers to getting a widget from the Web to run on an user's device as easily as possible.
The de facto standard for packaging widgets is the Zip file format, but with vendors requesting that their developers use a vendor specified file extension (ie. not .zip, but .widget, or .gadget, etc) when packaging their widgets.
Once a widget has been packaged for distribution, it is put onto a web server and
served with an appropriate media type. The purpose of a media type is to allow a browser,
for instance, to automatically associate a widget resource with the appropriate widget
user agent. For example, widgets served for Operas widget engine are served with the
application/x-opera-widgets
media type and associated with the Opera
browser. If a widget engine has correctly registered itself with the operatig system to
be the program of choice to deal with a particular media type media type and/or file
extension with, the web browser should automatically pass widgets to the widget engine
without the end-user having to select the widget resource manually.
End-users generally acquire widget resources directly from vendors (eg. Apple, Yahoo!) who often host dedicated online galleries where users can search for widgets and where developers can submit or update widgets they have created. However, authors are free to distribute their widgets from their own web sites.
| Widget User Agent | Packaging Format | Compression | File Extension | Media type |
|---|---|---|---|---|
| Widget User Agent | Packaging Format | Compression | File Extension | Media type |
| Konfabulator | Proprietary flat-file, Zip | Deflate (Zip) | .widget (not enforced) | application/vnd.yahoo.widget |
| Windows Sidebar | Zip, Cab, directory | Deflate | .gadget | application/x-windows-gadget |
| Google Desktop | Zip | Deflate | .gg | app/gg |
| Opera Browser | Zip | Deflate | .zip | application/x-opera-widgets |
| Apple Dashboard | Zip | Deflate | .wdgt or .zip | application/x-macbinary |
| Nokia Web-Runtime | Zip | Deflate | .wgz | application/x-nokia-widgets |
| Joost Widgets | Zip | Deflate | .joda (not enforced) | application/vnd.joost.joda-archive |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authoritative information about any particular widget user agent, please visit the vendor's web site.
A widget resource will typically include a configuration document, in which an author declares metadata and/or some configuration parameters that a widget user agent may use to configure a widget upon instantiation. All market leading widget engines use XML as the preferred format for storing metadata.
| Widget User Agent | XML vocabulary | File Name | Required? | Uses XMLNS? | Conforming Parser? |
|---|---|---|---|---|---|
| Widget User Agent | XML vocabulary | File Name | Required? | Uses XMLNS? | |
| Konfabulator | Konfabulator Reference | widget.xml | no | no | |
| Windows Sidebar | Microsoft Gadgets | gadget.xml | yes | no | |
| Google Desktop | Google Gadgets | gadget.gmanifest | no | ||
| Opera Widgets | Opera Spec | config.xml | yes | yes, but not required. If a bogus namespace is given, the widget will not work. | |
| Apple Dashboard | Apple plist | Info.plist | Yes | no | |
| Nokia Web-Runtime | Apple plist | Info.plist | Yes | no | |
| Joost Widgets | Joost Joda | config.xml | yes | yes, but not required (will work with any given namespace). |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authorities information about any particular widget user agent, please visit the vendor's web site.
Metadata refers to how authors store information about their widget inside the widget, and how that data is made accessible to people or machines.
In practice, the inclusion of any metadata elements is generally considered optional but is nonetheless recommended by vendors. Widget user agents generally make use of metadata elements in different application contexts such as menus, lists, and about-boxes. The most common metadata elements captured in configuration documents include:
| Widget User Agent | Root Element | Name | Unique Identifier | Version Identifier |
|---|---|---|---|---|
| Widget User Agent | Root Element | Name | Unique Identifier | Version Identifier |
| Konfabulator |
|
<name>text</name> |
<identifier>UUID or
RD</identifier> |
<version>text</version> |
| Windows Vista Sidebar |
|
<name>text</name> |
Uses <name> and <version> . |
<version>text(n.n.n.n)</version> |
| Google Desktop | <gadget> |
<name>text</name> |
<id>UUID</id> |
<version>text(n.n.n.n)</version> |
| Opera Widgets | <widget> |
<widgetname>text</widgetname> |
<id><host>URI</host>
<name>text</name><id> |
<id><revised>W3CDTF</revised></id> |
| Apple Dashboard | <plist version="1.0"> |
<key>CFBundleDisplayName</key>
<string>text</string> |
<key>CFBundleIdentifier</key> |
<key>CFBundleVersion</key><string>string</string> |
| Nokia Web-Runtime | <plist version="1.0"> |
<key>CFBundleDisplayName</key>
<string>text</string> |
<key>Identifier</key> |
<key>Version</key><string>string</string> |
| Joost Widgets | <widget-manifest> |
<name>text</name> |
<id>URI</id> |
none. |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authoritative information about any particular widget user agent, please visit the vendor's web site.
| Widget User Agent | Description | Authorship | Copyright |
|---|---|---|---|
| Widget User Agent | Description | Authorship | Copyright |
| Konfabulator | <description>Text</description> |
<author name="" organization="" href=""/> |
<copyright>text</copyright> |
| Windows Vista Sidebar | <description>Text</description> |
<author name=""> <info url="URL"/> <logo src="rel-path"/>
</author> |
<copyright>text</copyright> |
| Google Desktop | <description>Text</description> |
<author>text</author> <authorEmail>text</authorEmai>
<authorWebsite>URL </authorWebsite> |
<copyright>text</copyright> |
| Opera Widgets | <description>Text</description> |
<author> <name>text</name> <email>text</email>
<link>text</link> <organization>text</organization>
</author> |
none. |
| Apple Dashboard | none. | none. | none. |
| Nokia Web-Runtime | none. | none. | none. |
| Joost Widgets | none. | <web site.>URI</web site.> |
none. Often included as an xml comment inside the configuration document. |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authoritative information about any particular widget user agent, please visit the vendor's web site.
The most common configuration parameters include:
Please note that some configuration parameters have a close relationship to the security model of widgets.
| Widget User Agent | Bootstrap | Width and Height | Network | Plugins | Platform |
|---|---|---|---|---|---|
| Widget User Agent | Bootstrap | Width and Height | |||
| Konfabulator | Not declared. First *.kon file encountered is treated as the start file. | none. | <security> |
none. | <platform minVersion="n.n" os="macintosh|windows"/> |
| Windows Sidebar | <host> <base type="HTML" src="rel-path/file" />
</host> |
none. | none. Allowed by default. | none. Allowed by default. | <host name="sidebar"> <platform minPlatformVersion ="n.n"
/></host> |
| Google Desktop | Not declared. Root of container must have a "main.xml" file which serves as the start file. | none. | none. Allowed by default. | none. | <gadget minimumGoogleDesktopVersion="n.n.n.n"> |
| Opera Widgets | None. The start file must be called "index.html" and must be at the root of the archive. | <width>n</width> <height>n</height> |
<security> <access><protocol>http|ftp</protocol>
<host>IP Address|domain name</host> <port>integer|integer-range(eg
1200-1500)</port></access> </security> |
<content><plugins>yes|no</plugins>
<java>yes|no</java></content> |
|
| Apple Dashboard | <key>MainHTML</key>
<string>rel-path/any.html</string> |
When not present, the width and height of Default.png is used. |
<key>AllowFullAccess</key> <true|false/> |
||
| Nokia Web-Runtime | <key>MainHTML</key>
<string>rel-path/any.html</string> |
<key>AllowNetworkAccess</key> <true|false/>
<key>AllowFullAccess</key> <true|false/> |
none. | ||
| Joost Widgets | <main-file>rel-path/a.[jwl,html,svg]</main-file> |
<key>AllowNetworkAccess</key> <true|false/> |
<key>AllowInternetPlugins</key> <true|false/> |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authoritative information about any particular widget user agent, please visit the vendor's web site.
TBW
TBW
Authoring refers to how widgets are created, marked-up and scripted. In terms of authoring, there is a fairly congruent set of commonalities that most widget user agents share, and which authors exploit when authoring a widget: mainly their reliance on Web standards and protocols, and a strong focus on rapid development. Most widget user agents will typically support HTTP, IRIs, and Unicode, as well as ECMAScript, the DOM, and the ability to render markup languages, like HTML and CSS. Widget user agents also generally support multimedia resources, such as images, sounds, and some even video.
To make authoring of widgets possible, widget user agents provide authors with Application Programming Interfaces (APIs) that are mostly identical to those found in Web browsers, as well as APIs that provide functionality that is specific to widgets. Also, because of the rise in popularity of Ajax-style development, many widget user agents now implement the XMLHttpRequest object or some similar mechanism for making asynchronous data requests over HTTP.
| Widget User Agent | png | gif87 | gif89 | jpeg | png | svg | mp3 | wav | swf | css | js | html4 | canvas | XHR |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Widget User Agent | png | gif87 | gif89 | jpeg | png | svg | mp3 | wav | swf | css | js | html4 | canvas | XHR |
| Konfabulator | yes | yes | yes | yes | yes | no | yes | yes | yes | yes | yes | yes | yes | yes |
| Windows Vista Sidebar | yes | yes | yes | yes | yes | no | yes | yes | yes | yes | no | yes | ||
| Google Desktop | yes | yes | yes | yes | yes | no | yes | no | no | yes | no | no | yes | |
| Opera Widgets | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | ||
| Apple Dashboard | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | yes | ||
| Nokia Web Runtime | yes | yes | yes | yes | yes | no | no | yes | yes | yes | no | yes | ||
| Joost Widgets | yes | yes | yes | yes | yes | yes | ? | yes | yes | yes | yes | yes |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authoritative information about any particular widget user agent, please visit the vendor's web site.
explain functionality exclusively available to widgets (run programs, cross domain requests)
TBW
| Widget User Agent | Open page in browser | Preferences | Close widget |
|---|---|---|---|
| Widget User Agent | |||
| Konfabulator | void openURL(url) |
|
|
| Windows Vista Sidebar | no method, use <a href=""> element, or using javascript within the document: window.open(url) |
System.Gadget.Settings.write(String name, Object Value) |
System.Gadget.close() |
| Google Desktop | no method, use <a href=""> element | ||
| Opera Widgets | openURL(String url) |
widget.setPreferenceForKey(preference, key) |
|
| Apple Dashboard | openURL(String url) |
widget.setPreferenceForKey(preference, key) |
|
| Nokia Web Runtime | openURL(String url) |
|
|
| Joost Widgets | navigate(String url); |
widget.setString(String name, String vlaue); |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authoritative information about any particular widget user agent, please visit the vendor's web site.
TBW
TBW
| Property | Konfabulator | Windows Sidebar | Google Desktop | Opera Widgets | Apple Dashboard | Nokia Web-Runtime | Joost Widgets |
|---|---|---|---|---|---|---|---|
| locale information | locale | window.navigator.language | window.navigator.language | ||||
| Engine version needed to run | requiredEngineVersion | System.Gadget.platformVersion | |||||
| If the widget is visible | visible | System.Gadget.visible | |||||
| The version of the widget as specified in the configuration document | version | System.Gadget.version | |||||
| The name of the widget as specified in the configuration document | name | System.Gadget.name | |||||
| The details of the author as specified in the configuration document |
widget.author widget.company |
||||||
| The copyright declaration as in the configuration document | widget.copyright | ||||||
| Access the unique identifier for the widget |
String widget.identifier This read-only property contains a string value that is unique among all of the instances of a single widget. This value is assigned by Dashboard and persists between instantiations of each widget instance. |
string widget.identifier;
|
|||||
| requiredPlatform | Document, opacity, path, settingsUI, docked, background |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authoritative information about any particular widget user agent, please visit the vendor's web site.
TBW
| Event | Konfabulator | Windows Sidebar | Google Desktop | Opera Widgets | Apple Dashboard | Nokia Web-Runtime | Joost Widgets |
|---|---|---|---|---|---|---|---|
| Widget has loaded | widget.onLoad | ||||||
| WUA has focus | widget.onshow | ||||||
| WUA lost focus | widget.onhide | ||||||
| Widget focus | widget.onGainFocus | window.onfocus | |||||
| Widget lost focus | widget.onLoseFocus | window.onblur | |||||
| Widget drag start | widget.onMouseDrag | widget.ondragstart | |||||
| Widget is being dragged | |||||||
| Widget drag end | widget.ondragend | ||||||
| Widget is removed from WUA | widget.onUnload | widget.onremove | |||||
| Cross widget communication | widget.onTellWidget = function(){ } | ||||||
| Other | dockOpen onDockClosed onDockOpened onPreferencesChanged onRunCommandInBgComplete onScreenChanged onTellWidget onWakeFromSleep onWillChangePreferences |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authoritative information about any particular widget user agent, please visit the vendor's web site.
TBW
Execute system level commands or open applications.
//If no callbackHandler is present, the command is executed synchronously.
//If callbackHandler is present, command is executed asynchronously. callbackHandler needs to except an argument.
CommandObject widget.system(String command, [Function callbackHandler])
interface CommandObject{
String property outputString; //the standard out
String errorString; //any error that was thrown
String status. //the command's exit status
// allows handler to receive incremental output (eg ping.)
EventListener onreadoutput(function handler);
function cancel(); // cancel the command
function write(String value); //write a string to standard in
function close(); //send (EOF) to standard in
}
void widget.openApplication(HexNum Uid, String param)
opens an S60 application in stand-alone mode. Values cannot passed back from the opened application to the widget. A widget cannot open another widget using this method.
TBW
TBW
Accessibility refers to how end-users, and those with special needs, can access the content and use the interactive elements of an instantiated widget. Most market-leading widget user agents allow widgets to be authored using HTML, CSS, and ECMAScript. HTML, when authored with care, is generally regarded to be an accessible technology whose structure and semantics are generally well understood and correctly implemented by most market-leading widget user agents. To extend It is also therefore theoretically possible for authors to make their widgets fairly accessible by applying, for example, the relevant sections of the Web Content Accessibility Guidelines (WCAG).
| Widget User Agent | UI Markup | HTML Renderer |
|---|---|---|
| Widget User Agent | UI Markup | |
| Konfabulator | HTML + CSS (through Webkit), Proprietary XML | webkit |
| Windows Vista Sidebar | HTML + CSS + Proprietary XML | Internet Explorer |
| Google Desktop | Proprietary XML | none |
| Opera Widgets | (X)HTML + CSS + SVG | Opera |
| Apple Dashboard | HTML + CSS + SVG | Webkit/safari |
| Nokia Web Runtime | HTML + CSS | Webkit |
| Joost Widgets | XHTML + CSS + SVG + Proprietary XML | Gecko |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authoritative information about any particular widget user agent, please visit the vendor's web site.
TBW
TBW
What addressing mechanism does the widget user agent support at runtime to get to resources inside the package? (ie. how does a developer address and include things like images or sounds in their widget?)
| Widget User Agent | Other expected files |
|---|---|
| Widget User Agent | Other expected files |
| Konfabulator | at least one *.kon somewhere in the archive |
| Windows Sidebar | at least one html file somewhere in the archive |
| Google Desktop | |
| Opera Widgets | (any folder)* index.html. The folder is selected in alphabetical order, not by the order in which it appears physically in the archive. |
| Apple Dashboard | some [name].html file identified as the start file by the MainHTML key
in the Info.plist file. Icon.png and Default.png. Icon.png is used in the Dashboard bar.
Default.png is shown while the widget loads and used to set the render context of the
widget if width and height keys were not set in Info.plist. |
| Nokia Web-Runtime | some [name].html file identified as the start file by the MainHTML key
in the Info.plist file. Icon.png is optional. |
| Joost Widgets |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authoritative information about any particular widget user agent, please visit the vendor's web site.
TBW: discusses different ways that the start file of widget is located: 1. having a preset name (eg. index.html ala Opera Widgets). Having it declared in the configuration document (ala Joost), Having it match a search pattern (ala Konfabulator)
TBW
TBW
internationalization refers to the technical
aspects that allow a widget to work in multilingual contexts without requiring an
author to make significant engineering changes to a widget.
Localization is the processes where by a widget is adapted to use
the local conventions of particular end-users (eg. using a particular dialect).
To
allow authors to distribute a widget to multiple locales, the majority of vendors provide
guidelines explain to authors how to make effective use of internationalization
mechanisms built into widget user agents. When authors follow localization guidelines, a
widget user agent can use automated mechanisms to select the appropriate localized
resources for a widget based on a system's locale information; thus making it easier for
authors to create localized widgets.
In the widget space, internationalization is commonly achieved in one of two ways:
/en-au/
" for English Australian)
of localized content. If the widget user agent can identify the end-user's locale, and
the widget package contains matching localized content, then a localized widget will be
presented to the end-user./en-au/Localizable.strings
"). Inside the text file, localized strings are
identified by an unique identifier and must be formatted using a special syntax. For
instance, Konfabulator uses a special syntax for localizing strings, for example:"greeting" = "g'day mate!";
"greeting_gfx" = "/en-au/images/greet.png";
Note that this method only localizes textual content, but can be used to also identify the path or URI to localized resources. At runtime, the widget user agent makes those localized strings available via a scripting interface:
//would set the button's label to "g'day mate!" myButton.label = widget.getLocalizedString("greeting");
myButton.style.background = widget.getLocalizedString("greeting_gfx");
When automated internationalization is not provided by a widget user agent, authors usually result to using arbitrary solutions to achieve localization. Such is the case for Opera widgets.
| Widget User Agent | Localization Strategy | Automatic | Convention followed | Example | Comments |
|---|---|---|---|---|---|
| Konfabulator | Directory-based + JS | yes | /en-au/Localizable.strings |
||
| Windows Sidebar | Directory-based + JS | yes | |||
| Google Desktop | Directory-based + JS | yes | |||
| Opera Widgets | none | no | none | Does not support any automated localization strategies. | |
| Apple Dashboard | Directory-based + JS | yes | /en-au/ | ||
| Widget User Agent | Localization Strategy | Automatic | Convention followed | Example | Comments |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authoritative information about any particular widget user agent, please visit the vendor's web site.
TBW
TBW
A digital signature is the product of applying a secret numeric key (known as a private key) and an encryption algorithm over some data to produce a unique hash value. The only way to validate a digital signature is to use a corresponding public key in a process known as asymmetric cryptography.
Although not widely supported by market-leading widget user agents, some widget user agents allow an author to digitally sign a widget resource. Digitally signing a widget resource involves calculating the hash values of all the resources inside the widget resource and encrypting those values using a unique private key that is known only to the author. The resulting data is bundled inside the widget resource with a digital certificate, which an author can obtain from a certification authority (such as VeriSign) for a charge.
A digital certificate is therefore a trust mechanism intended to verify to a user that an author really did sign the widget resource. A widget user agent can use the digital certificate to verify the authenticity and data integrity of the widget resource. In the rare case where a widget damages the end-user's device, the digital certificate provides a user with a legal means to prove that a widget resource was signed by a particular author or publisher.
Because digital certificates can come from untrusted sources, widget user agents will include root certificates from sources that it trusts. Root certificates are explicitly trusted and are considered impossible to forge. For example, the Konfabulator is bundled with the Yahoo! root certificate which it uses to verify widgets signed by Yahoo! Inc. are in fact signed by Yahoo! Inc.
| Widget User Agent | Signature | Certificate Format |
|---|---|---|
| Konfabulator | yes | x509 |
| Windows Sidebar | yes | x509 |
| Google Desktop | no | - |
| Opera Widgets | no | - |
| Apple Dashboard | no | - |
| Nokia Web Runtime | Planned | - |
| Joost | Planned | - |
| Widget User Agent | Signature | Certificate Format |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authoritative information about any particular widget user agent, please visit the vendor's web site.
Automatic updates refers to a service that allows a widget
user agent to automatically check if a new or different version of an installed widget
resource has become available, and somehow acquire the new version and install it.
Automatic updates models work by allowing authors to assign a unique identifier and
version identifier to a widget resource (eg. id="http://example.com/my.wdgt"
version="1.2"
).
To keep a widget resource up to date, the widget user agent periodically checks if a different version of a widget resource has become available on a remote server. In the case of the Konfabulator, it does this by sending an XML document that identifies the widget via an unique identifier, and what version the end-user currently has installed. If a new version of the widget resource is available on the server, the server sends back an XML file that contains a URL from where the widget user agent can acquire the latest version. The widget user agent then informs the end-user that an update to a widget has become available and if they want to perform the update. If the end-user agrees, then the widget user agent downloads the latest version of the widget resource, archives the old version, installs the new one in its place. The updated widget is re-instantiated with its preexisting preferences (eg. an updated weather forecaster widget will generally not require the end-user to re-input their preferred city after an update).
TBW
Need to read up on how Nokia Web Runtime recommends authors deal with migration of Dashboard widgets, etc.
TBW
TBW
Security model refers to the security policies under which a widget user agent operates that either prevents or allows an instantiated widget from performing particular actions (eg. accessing the network or reading/writing files). When compared to Web browsers, some market-leading widget user agents have a comparatively relaxed security model that allows an instantiated widget to read, write, modify, and/or delete files, automatically upload files, automatically download files, execute local applications, and even perform cross-domain request to "mash-up" data from multiple different sources. All without the end-user having any indication that their privacy and security might be at risk.
The ability to perform most of the aforementioned actions is strictly forbidden in documents running in Web Browsers. Such a relaxed security model has been generally positive in the widget space with very useful and powerful widgets being developed. However, this has created an environment where users are left extremely vulnerable to malicious attacks, and serious security risks have been demonstrated. Some market-leading widget user agents, such as Opera Widgets, have a much tighter security model that adheres more closely to the security model of a Web Browser; as such, they may be less prone to serious security issues.
Need to discuss how security declarations are made using pInfo list or Opera's security element.
TBW
TBW
| Widget User Agent | Element in configuration file | Supported Types | Preferred | Comments |
|---|---|---|---|---|
| Widget User Agent | Element | Supported Types | Comments | |
| Konfabulator | <image usage="dock|security" src="images/some.png"/> |
GIF, PNG. |
Two images may be declared, depending on the |
|
| Windows Vista Sidebar |
<icons> <icon src="rel-path" [width="" height=""]> </icons> <hosts> <host> <defaultImage src=""/> </host> |
any GDI+ 1.0 supported format. |
Having multiple icon elements allows the engine to select the icon most appropriate for communication based on size. Preferred size is 64px*64px, but any size is ok. The documentation contradicts itself in regards to icon and defaultImage. Need to verify which one is actually used! |
|
| Google Desktop |
<small-icon>rel-path/some.png<small-icon> <icon>rel-path/some.png<small-icon> |
PNG | PNG |
Need to test other formats |
| Opera Widgets |
<icon>relative-path/some.png</icon>
|
GIF, PNG. | ||
| Apple Dashboard | none. | PNG |
Not declared. An optional icon must appear in the root of the archive and must be called icon.png. If the icon is missing, then the runtime will use a default icon. |
|
| Nokia Web-Runtime | none. | PNG | PNG | include an "icon.png" file at the root of the widget. |
| Joost Widgets |
<icon>relative-path/some.svg</icon>
|
SVG, PNG, JPEG, GIF | SVG or PNG are preferred. |
*Although care has been take to ensure the accuracy of the information contained in this table, there is no guarantee that the information is complete, correct, or up-to-date. To obtain authoritative information about any particular widget user agent, please visit the vendor's web site.
This section will describe how icons are used by different widget engines. It will discuss static icons (images, pngs), and dynamic icons, such as Yahoo!'s icons. Might also talk briefly about iPod/Phone icons here too, as they are dynamic.
PNG, GIF87/89
TBW
TBW
The following list represents the aspects of a widget that members of the working group have identified as requiring standardization to reduce fragmentation in the widget space. Aspects that are currently outside the scope of the working group charter are proceeded by the text "out of scope". To address aspects beyond the scope of the working group, the working group will require liaison with other working groups at the W3C and possibly other related consortia such as the OMA and the OAA.
Standardizable aspects of widgets include:
Standardizable aspects of widget engines include:
TBW
The editor would particularly like to thank Corin Edwards for his help on improving the design on of figure 1.
The editor would like to thank to the following people who have contributed to this document (ordered by first name):


Global Objective Administration Instructions
-
New Global Objectives may be created or existing Global
Objectives may be modified.
-
To create a new global objective, select Create Global
Objectives, fill in the necessary information, and
click Submit.
-
To view or modify an existing global objective, click
"View or modify an existing global objective."
Choose the user whose global objectives you would
like to view or modify, and click Submit.
-
Select the course whose Global Objectives you would like
to view. All objectives not associated with a
course may also be viewed. If you choose a course and no
global objectives are associated with that course, all
global objectives that are not associated with any course
will be displayed.
-
Click Submit.
-
To modify global objectives, select the objectives to
delete or reset individually or use the Select All option
to select all of the objectives. Choosing Clear Selection
allows you to deselect objectives that were already selected.
-
Click Submit.
|


Inclusionomics™ is a collective think tank born out of the desire to see positive change in the advancement of women, professionals of color and other underrepresented and marginalized professionals. We can no longer attempt to tackle the issues of diversity, equality and discrimination one at a time. These issues need to be addressed simultaneously and for that, we need engagement on many levels – from CEO’s to activists to educators to researchers – Inclusionomics is igniting the conversations necessary to effect change.
Women make up 50% of the workforce yet they are paid less than men. As the main, or sole source of income in many households, women are retiring after working their entire lives and are living below the poverty level. We cannot hope to change economic outcomes without tackling this issue.
We believe in working to create workplaces that prevent sexual harassment and discrimination rather than managing workplaces that need to continually address the issues after it happens. Now is the time for change. Work with us to maintain a respectful workplace for all employees.
Gender, race, ethnicity, age, socioeconomic background and ability are all aspects of our lives that affect how we’re treated. You can be a catalyst for change within your organization, community or within yourself. Diversity is not just a buzzword, inclusion is intentional and both are a way of life.


-
Hi! My name is Jola and I study Computer Science at Jagiellonian University in Cracow.
-
My family town is placed in beautiful mountains called Beskid Wyspowy.
-
I have an artistic soul, I like to design and create new things. I love playing the guitar and singing karaoke with friends or taking many, many photos.
-
My hobby is also handicraft - I'm keen on doing handmade jewelry, salt dough figures and crocheting.
-
I love to travel and meet new people. I have many amazing memories from every trip and also I take crazy amount of photos.
-
Hi! My name is Jola and I study Computer Science at Jagiellonian University in Cracow.
-
My family town is placed in beautiful mountains called Beskid Wyspowy.
-
I have an artistic soul, I like to design and create new things. I love playing the guitar and singing karaoke with friends or taking many, many photos.
-
My hobby is also handicraft - I'm keen on doing handmade jewelry, salt dough figures and crocheting.
-
I love to travel and meet new people. I have many amazing memories from every trip and also I take crazy amount of photos.