[Openicc] Dynamic options for Oyranos

Jon A. Cruz jon at joncruz.org
Wed Feb 13 18:53:33 PST 2008


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?
>
>
> 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.

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.

XUL especially is going in the exact wrong direction.

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

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/

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


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.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/openicc/attachments/20080213/498362a7/attachment-0001.html 


More information about the openicc mailing list