[Openicc] Dynamic options for Oyranos

[Kai-Uwe Behrmann]

Am 13.02.08, 18:53 -0800 schrieb Jon A. Cruz:
> On Feb 13, 2008, at 2:22 AM, Kai-Uwe Behrmann wrote:
> 
> 
> > 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.
> > 
> 
> [SNIP]
> > 
> > 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?
 
> If you are looking to solve the problem in a manner to gain most support for
> end users, I think you're looking at the wrong UI approach.

I'd have to guess this sentence. Do you mean, the GUI can not be 
expressive enough? Or do you refere to my examples above?

> XUL especially is going in the exact wrong direction.

Agreed, XUL is much like VST a too heavy system for Oyranos.

> To be most useful the presentation and information should be separated. Also,
> the core API should probably avoid any specific toolkit.

Toolkit independence was alwas my intention.
 
> XUL solves the Mozilla problem of being able to pixel-tweak things for their
> specific application's UI. However, to edit abstract information in a generic
> way something like XForms is far more appropriate.
> 
> http: //www.w3.org/MarkUp/Forms/
> http: //xformsinstitute.com/essentials/

Ah, thanks.
 
> Then the core API could use that abstract information, and intermediate levels
> could add very thin platform-specific glue layers (Qt, GTK, ncurses...)

Yes, abstraction is the key.

> This has been an approach I've discussed with the Scribus team in regards to
> support for generic plugin mechanisms including settings, and has many
> advantages.

I'd probably be happy to use the mentioned plug-in mechanism. How far 
did you come with that. Is there more to read about beside the Create wiki 
page?

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