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)