The Widgets module is responsible for drawing Widgets of various types and handling the various operations available for widgets. The rendering and widget construction technology may vary from platform to platform.

Core Widget Operations

 

Initialization: The initialization process is responsible for initiating widget resources and preparing widget view which is handled within a container provided by Glass. For example, Website Glass renders widgets by constructing widgets into Browser’s DOM related with currently presented page. The external control flow of rendering all widgets is controlled by Website Glass, and each widget is responsible for rendering its own graphics by adding elements into browser’s DOM of underlying HTML page.

Toolbar: A widget may or may not include a toolbar. The purpose of a toolbar is to provide easy tool buttons or menu or links for the user to perform core operations such as opening the Peers Group interface and more. 

Rendering: A widget includes its own rendering routine. Rendering routine is responsible for rendering the internal structure and any required graphics of a widget. Rendering routine is usually called after initialization but may also be invoked for the purpose of refreshing widget view after some change, so that new resources state will be reflected in the view.

Persist state: A widget usually has a persist state that holds both state of presentation and content. By state of presentation we mean for example the state of size, position, open/minimized and possibly other settings. By state of content we mean the actual content carried by the widget, for example some text, some picture, some video, some application resources state etc.

When a widget is loaded the content is combined with the widget view and the user sees the final result – for example textbox, profile capsule, html layout etc.

 Widget data may be stored either locally or remotely. In addition, some changes in stored state may result from personal preference while other are shared among all peers. The storage mechanism is quite complex and is described in details below.

Widget content: A widget is created for the purpose of presenting and/or sharing some content. The content may be textual or visual or any other type that can be digitized and stored in the form of binary or textual data. Widget’s content is editable by nature so that User or VPeer (virtual peer) can create or edit the initial content and then edit again if required. In some cases widgets may restrict future editing operations. The content is stored as part of the widget data sent to the storage mechanism, and is retrieved when the widget is rendered. The recommended approach for storage is that each change in widget content causes widget data to be saved and this save operation occurs in the background so that the user does not have to click a “Save” button. However, on some widgets the Save button may exist for providing a more intuitive user interface, and the presence of a “Save button” may be combined with automatic saving mechanism that works in the background.        

Open and Minimize: Widgets are presented on top of other external context. As such it is required to be able to present widgets either as Open or as Minimized. In the Open mode a widget is presented to the user so that its resources and content are presented in the view. For example, a toolbar is presented, and if a widget has text or video or image, these will be presented. In the Minimized mode widget is presented as small minimized box, usually in the same location where is will be presented when in the Open mode, but not necessarily. This allows widgets to be created in relation with context without interfering with the Context view itself, unless the user is interested in the widgets themselves. The Minimized/Open state of a widget is stored as part of the widget state and will be used next time the user loads the widget. Minimize/Open state is due to personal preference so that different peers may watch different states based on preferences.

Resize: Widgets may be resized. Having the resize trait is optional, so it may be restricted by some widgets, and allowed by others. Resizing is very practical when the resources and content presented by widgets require more space to render nicely than available by the default size set to the widgets. The new size is stored as part of the widget state and will be used next time the user loads the widget. The size state is due to personal preference so that different peers may watch different states based on preferences.

 Drag: Widget may be dragged on the screen, within the boundaries of the underlying context. For example, a widget that was assigned in relation with a Web page can be dragged to different positions on the browser window. Dragging should be optional and some widgets may choose to restrict dragging. Dragging is provided for the purpose of convenience of presentation so that widget view can be arranged nicely when presented on top of external context view. The Drag state is due to personal preference so that different peers may watch different states based on preferences.

Define peers group: A Widget can be shared by relating it with a peers group. A peers group is a group of friends or contacts account identifier, such as Email address, unique Ids etc. that is set in relation with a widget. Defining a peers group is essential for sharing a Widget and is handled using special peers-group management View.

Sharing scenario given Widget-W1 on Glass-G1:

1. Peer-A open peers-group management

2. Peer-A adds contact of Peer-B to the group and closes. Data will be saved

3. Peer-B signs-in with his/her account

4. Peer-B is in the same state in relation with the context identifier refered by Glass-G1. For example if Glass-G1 context is a web page then Peer-B is now watching the same web page where Widget-W1 was originally created.

5. System check for Widgets shared with Peer-B and loads Widget-W1

6. Widget-W1 is now presented to Peer-B

P2P Channel: A widget may use a peer to peer channel in order to communicate with the parallel instance of the same widget, as inspected by peers in the peers-group assigned to the user. Using P2P allows real-time collaboration with regards to widgets. P2P allows online streaming of data and events generated by Widget1 used by Peer-A “W1(p-a)”   to be perceived by the parallel instance of the widget as used by Peer-B  “W1(p-b)” given that Peer-A and Peer-B are both members in the peers group assigned to the widget. The stream is not limited to two peers only, but can be shared between multiple peers currently online.

This way we have two or more instances of the same widget: “W1(p-a)” and “W2(p-b)” communicate with each other. The communication may include exchange of data, exchange of events, and generally exchange of messages.

For example: FormConnector Widget  is a widget that knows how to bind with Web page forms, and once the binding with the form attachment is made on both sides, by two (or more) peers, then one peer can fill the form fields for other peers. 

Lifecycle events: A widget may have many events during its lifecycle. For example, when a peer is added, content changes, position is set, minimizing, maximizing etc. An external program may be interested in those events for the purpose of applying some level of control. Accordingly, a mechanism is required to register listeners and report events to listeners. Currently the recommended approach is to handle widgets event listeners via the container glass that can mediate events to listeners. 

Executing application logic: A widget is a software component. It includes settings, content, presentation view and can also include some logic. Hence any widget is like a small application. Basic widgets serve mainly for presenting specific type of content so their logic is basic and limited to content view. Application widgets are widgets with logic that serves some flow of usage across time. Yet both cases may be considered as mini applications.

Embedding / Floating modes: Depending on context type a widget may be embedded into context view or float on top of it. These are two modes of presentation that provide high flexibility and richer user experience.

Website context is an example where the two modes are possible. In the embedded mode a widget, say video viewer, can be located so it looks like embedded within website page. This is possible due to the nature of Web page DOM (data object model). In the floating view mode the same widget is located on top of the web page content, as if there was a transparent layer on top of the page and the widget can be positioned on top of it.

Binding with underlying context: Some widgets are designed to bind with underlying context so they can get events and context from context components and use these events for the purpose of application logic, view control or real time collaboration. For example, InputConnector Widget is a widget that is capable of binding with HTML input elements of the underlying context (HTML web page) and transfer input element events and element value to other peers in order to create the effect of the two or more peers filling the input field together. 

Linkage Graph: Linkage operation involves searching for related widgets by one or more semantic rules. See the Content Linkage section for more details.

 

Attaching Identification to Widgets: Attaching identification is required in glasses where a widget is related with a code. In such cases, when creating new widgets it is required to scan the code and attach it to the widget. Widgets that require to be attached with a code provide special UI for that where user is capable of scanning or entering the code for attaching with a widget.

Creating Custom Implementations: As with glass, widgets may have different implementations that share core behavior. Accordingly, an Abstract Widget class/prototype is usually defined by CG library that can be implemented for creating various types of widgets.