[Openicc] Dynamic options for Oyranos

[Kai-Uwe Behrmann]

This email starts with some reflection about the existing approach in 
Oyranos and the reasoning for a more generic one.
In the bottom end I hope for your brainstorming help about the toppic.


Current Oyranos options system:
The last version featured already a slightly dynamic options system. 
This means there exists one API to provide GUI informations, like 
widget labels, choices content and so on. Other API's expect
settings from these widgets to be feed in, according to their data type.

Why this at all?
This works to that state that settings can be added without touching any 
GUI code. 
For example, imagine we decide here on this list, that something should be 
named differently or a choice should move from one place to an other, we 
change something in Oyranos and all GUI's build upon the above scetched 
system show the corrections after restart. Coherent naming and 
translations are an other pro argument.
Well one might reply, this is soo much of work to set this all up, and  
in five minutes it is all conveniently done in a simple layout file.
Beside all the GUI's for the various toolkits or applications 
would need all these changes, below are more reasons to not keep options
static.



Dynamic GUI's:
Why?
With Oyranos providing a CMM framework, we see options coming from the 
CMM's not even Oyranos must know. It is up to the CMM to decide what to 
implement and what to support and what to show as optional.
As an example,
Chris, Bob and Hal discussed about HDR features. This is one case there a 
old inflexible application can not know, how to come up with the 
appropriate GUI.
With the proposed system in Oyranos, there should be toolkit dependent 
implementations and then the application would be able to use various 
CMM's, which are providing new capabilities. I hope it 
is clear that each and every application would have more trouble to 
implement such stuff themself.

What's needed for that?
The GUI and the options API's must be merged to work dynamic. A 
application asks for a widget layout and renders this into its own GUI or 
builds a separate window, as it feels appropriate. It is 
responsible to keep the actual widgets and the layout in sync, and 
registers one or two callbacks. Thats all to let Oyranos decide on what 
GUI is to been shown for a certain function and give the results back to 
Oyranos.

To illustrate the current path of a 8-bit image editor:
o first implement lcms for colour conversion
o implement options
o upgrade options to keep in sync with the remainder of the world
o implement 16-bit + HDR
o exchange against a CMM framework to support as well floating points
  or fork lcms
o implement some additional options for special CMM's other than lcms
o finally adopt to a dynamic GUI to support allmost all CMM's
I hope if the options are done rigth, we might have quite some time to not 
touch it further. As well it makes CM easier for new applications.



Now some technical questions:
My guess id, we would like to see a mapping of the Oyranos options to the 
command line, various toolkits and probably HTML. This means creating, 
rendering, updating and interpreting of options.
Choices, sliders, boolean buttons (check box), frames for layouting and 
probably a drawing based widget would provide enough.
The logical widgets must be easily to read and write by CMM's.

Predecessors, which came to my mind, where:
o Steinbergs VST
o Mozilla's XUL
o SuSE's Yast mapps its GUI to ncurses and Qt
Are there other projects to look at?

What further ideas and requirement come to mind to see solved?


Sorry for the first two part beeing so long. But I had the feeling, it was 
not clear to some people, why I think we need more than some simple static 
widgets.


kind regards
Kai-Uwe Behrmann
--
developing for colour management 
www.behrmann.name + www.oyranos.org