Caine
Hardcore Member
Yes dbus is a very likely candidate. It's still in an early stage, but let me just share some of my notes on it so far:
The different user interface environments provided currently and in the future on the Pandora have very different interaction styles. XFCE is strongly mouse (nub or stylus) oriented and makes use of a rich variety of widgets, mini-menu is based around the gaming controls, menus and icon grids. XBMC is based on gaming controls, keyboard and hierarchical menus but has rich widget functionality available for plugins.
As a consequence of this diverse running environment no emulator or application ever feels native to the user as they all implement their own user interface. The Pandora camp is split into two types of users: those who regard it ss a portable computer and those who regard it as a handheld gaming console. Especially the later category struggles with the lack of interface/look and feel uniformity on their Pandora console.
This protocol would allow applications to declare the logical structure of their interfaces and it would allow launchers and/or desktop environments to present these options in an as native as possible manner.
Two scenarios are of particular importance:
This approach is not without its downsides. Not in the least, each application would need to add support for this interface (most likely dbus based). Many developers will refuse to do so, causing their application to feel unnative in some environments (though still usable).On a related note, if it becomes popular it might cause a psychological barrier to porting applications as it requires actual development to integrate this.
Typical flow of control:
Advantages:
Disadvantages:
Initial proposal:
@image: optional image to display for entry
Idea: options could be split further into widget hints:
radiobuttons, editbox, pulldown menu, listbox, etc.
Each GUI is free to override the presentation
Callable functions, needs more work:
Todo:
As a consequence of this diverse running environment no emulator or application ever feels native to the user as they all implement their own user interface. The Pandora camp is split into two types of users: those who regard it ss a portable computer and those who regard it as a handheld gaming console. Especially the later category struggles with the lack of interface/look and feel uniformity on their Pandora console.
This protocol would allow applications to declare the logical structure of their interfaces and it would allow launchers and/or desktop environments to present these options in an as native as possible manner.
Two scenarios are of particular importance:
- Configuration of the application or emulator.
- Opening/saving of files/roms
This approach is not without its downsides. Not in the least, each application would need to add support for this interface (most likely dbus based). Many developers will refuse to do so, causing their application to feel unnative in some environments (though still usable).On a related note, if it becomes popular it might cause a psychological barrier to porting applications as it requires actual development to integrate this.
Typical flow of control:
Code:
[launcher interface] [application] [dbus intf.thread]
| | |
| start app. --intf | |
+------------------->| |
| | |
| +----+ |
| | | menu opened |
| menu url |<---+ |
|<-------------------+------------------->|
| | listen for cmds |
| | |
| query(url) | |
+--------------------.------------------->|
| gui description | |
|<........................................|
| | |
| change_option(url, key, val) |
+--------------------.------------------->|
| ok | |
|<........................................|
| | |
| action("resume") |
+--------------------.------------------->|
| suspend | |
|<-------------------.--------------------+
| | resume |
| |<-------------------+
|Advantages:
- Uniform look & feel across applications, easier for non technical users
- If guis provide rich navigation or config profile features then the individual apps don't need to
- Framework for app. menu development can simplify new applications
Disadvantages:
- Needs to be supported per application, likely to face developer resistance
- Less flexible as entirely hand-coded GUI
- Overhead
Initial proposal:
- menu oriented. Each menu can contain menus, options and actions
- each menu element is a tuple: (id, type, name, data, image?)
- @id: reference to pass to call
@type: menu, action, option (widget type hint)
@name: text to display on screen
@data: case type of
menu: submenu url
- action: ?
- option: possible values or regexp
@image: optional image to display for entry
Idea: options could be split further into widget hints:
radiobuttons, editbox, pulldown menu, listbox, etc.
Each GUI is free to override the presentation
Callable functions, needs more work:
- getMenuContent(path) -> description
- setOption(path, id, value) -> success/reload/path ?
- doAction(path, id) -> success/reload/path ?
Todo:
- check interfaces of existing emus for missing reqs.
- validate validity of interaction & control flow for at least:
minimenu, XFCE (generic emulator frontend?), Panorama, XBMC
- Carefully design the API
- Provide library support for at least C/C++ and python
probably based on dbus
