Detailed design System overview Filesystem hierarchy The filesystem is highly inspired from the UNIX one, but taking in consideration the user only needs to access his files, applications, volumes or shared files most of the time. Consequently, the following directories are available at top level: "Apps", "Data", "System" and "Volumes". The "System" directory could even have been called ".System" to only let the advanced users access it via the common interfaces. It could even be considered that the place of an executable in the filesystem hierarchy could determine its privileges; this can't be a security risk, since when one gains access to the filesystem, then he has already access to the full system. /Apps It contains a sub-directory per applications group. In this sub-directory one man find the following directories: Binaries: the applications binaries Engines: the applications' engines binaries Libraries: the shared libraries System: the applications administration binaries Sources: the applications source code (a sub-directory per package) /Data Shared data: documentation, hosted files, ... /System System hierarchy. Contains the following sub-directories: Apps: system essential applications and libraries, containing a Apps/subdirectory like hierarchy. Devices: equivalent to the /dev Kernel: equivalent to the /proc on Linux Sources: the associated source code (a sub-directory per entity) /Volumes Hard disks, CD-ROM and DVD-ROM drives, USB keys, etc, that get automatically mounted. To gain read and write access on them, one should have the necessary privileges though. Special files Configuration files FIXME: think about a DTD for configuration files; Configuration files contain variable names along with their values, nested inside sections. Default variables and values can be set in the global section, which name is "" (empty string). The global section is the default one. Comments are allowed on their own lines. #this is a comment #default section is global variable=value [section] variable=value [another section] #another comment variable=value another variable=value [] #this is global section again variable=value Programming interfaces Essential classes Buffers Prefix is "Buffer". new(): Buffer new(Size size): Buffer delete() get_size(): Size set_size(Size size): Bool Config Prefix is "Config". new(): Config delete() load(File file): Bool save(File file): Bool get(String section, String name): String set(String section, String name, Variable variable): Bool Files Prefix is "File". new(): File delete() open(String filename, FileOpenMode mode): Bool close() is_end(): Bool read(Buffer buffer): Size write(Buffer buffer): Size flush() set_position(Offset offset) set_position(Offset offset, FilePositionFrom) Lists Prefix is "List". new(): List new(ListType type): List delete() get_type(): ListType set_type(ListType type) Strings Prefix is "String". A string can be stored in different encodings, possibly longer than the 7-bit ascii, or 8-bit ascii extensions ones (eg UTF-8). Strings are always properly terminated when manipulated using this interface. new(): String //creates an empty string new(Buffer buffer): String //creates a string from `buffer` using //the default encoding new(Buffer buffer, StringEncoding encoding): String //creates a string from `buffer` encoded //as `encoding` delete() get_size(): Size //get string buffer size set_size(Size size) //set string buffer size to `size` get_length(): Size //get string length set_length(Size size) //set string length to `size` Variables Prefix is "Variable". This type is used for data conversions. new(VariableType type, Buffer data): Variable //creates a `type` variable from `data` delete() get(VariableType type): //get variable as `type` set(VariableType type) //set default type to `type` set(VariableType type, Buffer data) //set variable as `type` from `data` Applications engines Prefix is "AppEngine". new(): AppEngine delete() Applications interfaces Prefix is "AppIface". new(): AppIface delete() Graphical toolkit Prefix is "G". Conception proposal A list of a possible implementation guidelines follows. a GCanvas is a surface, containing GCanvasItems a GCanvasItem is a graphical primitive GCanvasItems can be grouped inside GCanvasGroups a GWindow contains a GCanvas a GCanvas is a GWidget every GWidget is a GCanvas Consequently, every graphical item on screen is a GCanvasItem, GWidgets are groups of GCanvasItems, and can contain other GWidgets, possibly being GCanvases. This is a big advantage for code reuse. A problem is, it doesn't handle resizing properly as is. Widgets Canvas Prefix is "Canvas". //FIXME functions applying to GCanvases, but not to GWidgets CanvasItem Prefix is "CanvasItem". delete() //deletes properly, whichever the type show() //shows item hide() //hides item Label Prefix is "Label". new(): GLabel new(String string): GLabel delete() get_text(): String set_text(String string) Window Prefix is "Window". new(): GWindow new(String title): GWindow new(GWindowType type): GWindow new(GWindowType type, String title): GWindow delete() get_type(): GWindowType set_type(GWindowType type) get_size(): Size set_size(Size x, Size y)