General phylosophy ------------------ 0. Execution code [EC] ====================== It is not a apart of OVE, this is any FC valid object (AM, OVE itselfs services, ...) 1. Enviroment scripts [ES] ========================== Ant scritps which are creating application itselfs. Creates functions, connects low level objects (such as AM services) and creates user actions (such as 'click' on button). Its main purpose is to prive 'data sources'. What it creates/do: Data sources (have own file) Functions Setup for components What it doesn't create/do: UI layout - windows or visual objects Execution code (such as effects) 2. User interface [UI] ------------------------- Creates physical visual objects and puts on right positions inside windows. Initializes their properties, connects datas and sets events. It communicates with ES by data sources or function if necessary. This is 'script' language like HTML and similar. At all, it is not real script, just 'list' of all visual objects, and similar things. It can execute valid Ant lines - but base only (such as property set and similar). Main functionallyty of US to: 1. create 'windows' (or desktop) 2. creates visual objects (and set properties - connect to datas, etc.) 3. set all visual events and process them (for ex. call 'Play' when OnClick of play button is executed What it creates/do: Physical visual objects Physical windows/desktop Sets properties/data sources/events of these objetcs All menus What it doesn't create/do: Any implementation of any data source or any direct cooperation with EC layer UI can require 'more' features than VL currently have. See UI->VL commuication. UI is fully secure and can't directly user any EC things. Only ES related. So, if ES are secure, UI are also secure. 3. Visual Library [VL] ---------------------- VL is template for visual objects. It sets it's possible sizes, and similar. It also sets graphics sources, etc. It communicates with VLD. What it creates/do: Template for physical visual objects [one template can create unlimited numbers of objects on screen] 'Skins' - such as 'colored' / 'LCD' / 'B&W' / ... What it doesn't create/do: Animations or physical datas Nothing to do with any action/event/data source It is based on name wich have general form: type[.attribute[.attribute2..]] Can be given one or more attributes. If VL doesn't support given object (it is same like something different) it can redirect to something else. If VL doesn't redirect to different, the most nearer will be used. VL sets 'format' of VLD because it reference physical file names with pixels. UI can be inherited from some else VL (cascaded). Searching VL item: 1. try match exact item (type.style1.style2) <----| 2. found ? -> ok | 3. is here 'default' instead of LAST style ? -> ok | 4. REMOVE last style --------------------------------------| Default style is defined normally by 'default' - of not defined, first is used. Inside VL deffinition can be used | operator for glue more styles: type.style1.small | big -> it will match 'type.style1.small' _AND_ 'type.style1.big' Gfxer can redirects some demands to different. On VL/VLD layer can be created pretty variable layout and good 'library', 4. Visual library data [VLD] ---------------------------- Physical pixels, nothing soo much interested. Milions of files :) What it creates/do: Animations - user interactions (such as 'focus' and similar) What it doesn't create/do: Physical visual objects properties - sizes, positions, ... On VLD layer can be PRETTY simple made 'skins'. Gfxer only need to keep filenames (only name, extension (format) can be changed). If gfxer want, he can use 'dictionary' and use 100% own filenames if needed. Communication | ------------- *------> application independend | FC | OVE | physical gfx files | | +----+ | +----+ +----+ | +----+ +-----+ | EC | <=====|====> | ES | <-----> | UI | --|---> | VL | -----> | VLD | +----+ | +----+ +----+ | +----+ +-----+ | | | | | ^ | | |- part is application indepenend (Fc, Am, Ove), parts (such as 'pattern visual objects' are done for exact application) 1. EC <-> ES ------------- Communication based on FC interfaces, which Ant reads directly from H files. ES can do anything. So, ES is 'security risc' if someone want to use 'own'. Can be simple to crash system, create infinite loops etc. We don't support any kind of 'user' ES. 2. ES -> UI ------------ ES calls UI if needs to create some visual object. ES export sets of function and data sources which UI can use while assigning properties. Exmaple: we are swhoing 2 check boxes, where second can be selected ONLY if first is selected. Checkbox1: 'Use file paths' and Checkbox2: 'Remove file name' ES: For this purposes, ES exports '2' data sources. These data sources have one line in its database which can be 0 or 1. Datasource1: Name='Use file paths', .. Datasource2: Name='Remove file name', .. ES implement event 'OnDatasource1Change' and enable/disable Datasource2. UI: create '2' checkboxes, on position 10,10 and 40,50, and connects both to relevant Datasource. It will have size 100x12 pixels max. Use for them template 'small' So, it fully communicates on 'text' layer where every function/event/datasource have some inteligent name (not Datasource1 and 2 :) UI is ___fully___ dependend on ES version. If ES implement new feature and UI doesn't 'show' then user don't have any way how to access this feature. It can be useful in some cases (such novice/expert mode, where novice doesn't see button 'advanced features' and similar). On the second side: we can't allow mass creating UI files. All UI we will ever do in future should be maintaned by us or some dependable parthner. 3. UI -> VL ----------- UI calls VL for place some physical visual objects. It doesn't sets size/position, only visual object properties itselfs (such as combo box have 'show list' button on left / right, and similar). VL & VLD are indepenend on application itsefls, any anyone using OVE can use some standard. Some of them can look as 'target' OS - so, app can look like normal windoze app under windoze, etc. Example: UI: reference for 'button.small.green' VL: defines button.small [marked as default] button.big -> button.small 4. VL -> VLD ------------ Simple filename based stuff. There is NOT important EXTENSION - only 'filename'. Filename can also reference 'directory' if gfxer want to divide frames to X files (output of 3D thingy). There is nothing special.