The here described concepts are targeted until version 1.0 of Oyranos. They are intended to make the API consistent and its usage predictable. A additional page shall describe the behaviour of Oyranos, default settings and recommendations to developers who like to interact with the system.
- Oyranos is intended to work on at least Linux, osX and (hopefully) Windows
- On Linux the Elektra configuration library is used for managing and storing the configuration.
- If publically available Oyranos will sit on top of native Colour Management Systems like ColorSync© or ICM©.
- Paths are scanned secursively avoiding links for security reasons.
- Paths count allways, to aim consistency. There are no exceptions.
- Users configure their own settings, while administrators configure system wide settings.
- User settings have priority over system settings
- All settings, called policy as a whole, shall be saveable and recoverable.
- For strings, constant pointers to chars are the prefered form (utf8?)
- For the need of allocating unknown sizes of memory, a function is passed by the user allocating the memory. The returned block goes into the responsibility of the user.
- More complex library allocated memory blocks, like profile name lists, can be freed with a Oyranos provided function.
- Last but not least user allocated Oyranos objects, those allocated by Oyranos with a user provided function, are free'd by oyDeAllocFunc_t.
- As long as possible types are signaled by theyre kind of writing.
- all functions, types and enums start with a oy due to no namespace in C
- namespace in C++ is oyranos::
- functions: words starting upper case
- enums: all letters upper case, words are separated by underscore
- variables: are lower case and words are separated by underscore
- macros: are all upper case even the starting OY_
- typs: end with _t
- structs: end with a _s
- internals: end with _
- Functions are needed which show useful informations for GUIs, about the content in the Profiles and about possible errors.
- Some descriptors are provided as strings, and may help keeping the user interface consistent throughout toolkits. (translation?)
- A callback mechanism informs about changes regarding the configuration.
- Special informations like for instance about the display geometry are not planed so far. You query monitor profiles by screen name not by geometry.
- It should be easy to query Oyranos for certain informations contained in a profile like primaries, gamma or profile type.
- To some degree useablity checks for profiles should be included.
- The concept of parsing text files to register new capabilities and modules will help to build a flexible base for further extensions.
- Therefore the internal data must be kept dynamic.
- A text parser should allow to distinguish the same profile for multiple devices and vice versa.
Generated on Sat Jun 16 21:05:41 2007 for Oyranos by
1.5.1