Forums : UI composer, next generation
This page last changed on Jun 09, 2009 by marcf.
It probably is a little early but I wanted to start a thread on UI composer.
As we release the software, we need to focus on the next generation of the composer. I personally think that it is one of the most important focus points, because it will be the entry point to most users of OR.
There are 2 roles within the composer
1/ The installer.
Within composer, an installer defines devices. For example the X10 dialog, or the IR Beehive dialog, or the KNX group address dialog allow for definition of devices.The device is associated with a set of buttons. For example in IR, declaring a remote to the beehive device database returns a panel of buttons. The programmer will use these buttons.
2/ The programmer.
The programmer and the installer are usually one and the same. But the programmer's role is to program panels for the iphone from a palette of buttons. Today, programming in OR means to drag and drop buttons on different panels. We also support macro's as a set of buttons represented by one.
The integration of a device in this framework means to make available a set of buttons representing commands with associated images. That is the what the programmer will need to assemble panels. Then for the runtime BOSS support. These commands map to a native bus and the routing is taking care of in the controller. How to integrate is specified today, we focus here on the software side for composer.
From the java world JMX is Java Management Extensions. Juha and I wrote books and specs on the subject It's main idea is that random components or devices will be deployed and will advertise their functionality. Think about a device with an IR remote. Take a picture of the IR remote, image-map it and you have a declaration of buttons, or APIs as it were to the system. From a programmatic layer, they can be invoked, or called. Of course these would be the one-way only commands. A device exports its API through its IR remote. Mapping this to a visual assembly tool for buttons is straightforward. Programmatic self description is the feature we gain. As an industry we are a long way from this goal. The BOSS helps with this goal.
Implementing these ideas in composer depends on previous infrastructure work such as the notion of "accounts" where you can declare your devices.
On the panel generation side, we already support panel swiping and custom images for background and buttons. Per Juha this needs to be tightened up before we release something but fairly advanced panels can be created this way (see amsterdam demo).
1/ Get rid of the current grid to allow for absolute positioning.
2/ Support for mask on images. With transparent zones you can either replace icon or create visual effect on iphone surface like "magnify" which does not require the upload of buttons to signify changed state. This will allow for graphics designers to do their thing and then for programmers to generate the panels from single images.
3/ advanced navigation. Navigation right now means panels of x by y that one can swipe through. This is probably enough for now. At least we should allow for long panels that we can scroll. Clicking on a floorplan would require a level of software navigation, for example, click on room, see remotes available, select remote available, then display corresponding panel(s).
|Document generated by Confluence on Jun 05, 2016 09:32|