DOSPR

Back to the revision list Download file Permalink

<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V4.2//EN">

<title>Detailed design</title>

<sect1>

<title>System overview</title>

<sect2>

<title>Filesystem hierarchy</title>

<para>

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.

</para>

<para>

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.

</para>

<sect3>

<para>

It contains a sub-directory per applications group. In this sub-directory one man find the following directories:

</para>

<listitem><para>Binaries: the applications binaries</para></listitem>

<listitem><para>Engines: the applications' engines binaries</para></listitem>

<listitem><para>Libraries: the shared libraries</para></listitem>

<listitem><para>System: the applications administration binaries</para></listitem>

<listitem><para>Sources: the applications source code (a sub-directory per package)</para></listitem>

</itemizedlist>

</sect3>

<sect3>

<para>

Shared data: documentation, hosted files, ...

</para>

</sect3>

<sect3>

<title>/System</title>

<para>

System hierarchy. Contains the following sub-directories:

</para>

<listitem><para>Apps: system essential applications and libraries, containing a Apps/subdirectory like hierarchy.</para></listitem>

<listitem><para>Devices: equivalent to the /dev</para></listitem>

<listitem><para>Kernel: equivalent to the /proc on Linux</para></listitem>

<listitem><para>Sources: the associated source code (a sub-directory per entity)</para></listitem>

</itemizedlist>

</sect3>

<sect3>

<title>/Volumes</title>

<para>

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.

</para>

</sect3>

</sect2>

<sect2>

<title>Special files</title>

<sect3>

<title>Configuration files</title>

<para>

FIXME: think about a DTD for configuration files;

</para>

<para>

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.

</para>

#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

</screen>

</sect3>

</sect2>

</sect1>

<sect1>

<title>Programming interfaces</title>

<!--

- use a table, head with prefix, describe function

- prefix actually is a namespace, it should not be an abbreviation, but then it would be a pain to develop in C with it; else we could think of tricks to implement namespaces in C in a way, like:

{

namespace_set("GToolkit");

gt_win = window_new();

namespace_set("AppEngine");

ae_win = window_new();

}

which could ease the implementation of shared libraries, though this is ugly and can be a pain sometimes...

- detail every data type

-->

<sect2>

<title>Essential classes</title>

<sect3>

<title>Buffers</title>

<para>

Prefix is "Buffer".

</para>

new(): Buffer

new(Size size): Buffer

delete()

get_size(): Size

set_size(Size size): Bool

</programlisting>

</sect3>

<sect3>

<title>Config</title>

<para>

Prefix is "Config".

</para>

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

</programlisting>

</sect3>

<sect3>

<title>Files</title>

<para>

Prefix is "File".

</para>

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)

</programlisting>

</sect3>

<sect3>

<title>Lists</title>

<para>

Prefix is "List".

</para>

new(): List

new(ListType type): List

delete()

get_type(): ListType

set_type(ListType type)

</programlisting>

</sect3>

<sect3>

<title>Strings</title>

<para>

Prefix is "String".

</para>

<para>

A string can be stored in different encodings, possibly longer than the 7-bit ascii, or 8-bit ascii extensions ones (eg UTF-8).

</para>

<para>

Strings are always properly terminated when manipulated using this interface.

</para>

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`

</programlisting>

</sect3>

<sect3>

<title>Variables</title>

<para>

Prefix is "Variable".

</para>

<para>

This type is used for data conversions.

</para>

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`

</programlisting>

</sect3>

</sect2>

<sect2>

<title>Applications engines</title>

<para>

Prefix is "AppEngine".

</para>

new(): AppEngine

delete()

</programlisting>

</sect2>

<sect2>

<title>Applications interfaces</title>

<para>

Prefix is "AppIface".

</para>

new(): AppIface

delete()

</programlisting>

</sect2>

<sect2>

<title>Graphical toolkit</title>

<para>

Prefix is "G".

</para>

<sect3>

<title>Conception proposal</title>

<para>

A list of a possible implementation guidelines follows.

</para>

<listitem><para>a GCanvas is a surface, containing GCanvasItems</para></listitem>

<listitem><para>a GCanvasItem is a graphical primitive</para></listitem>

<listitem><para>GCanvasItems can be grouped inside GCanvasGroups</para></listitem>

<listitem><para>a GWindow contains a GCanvas</para></listitem>

<listitem><para>a GCanvas is a GWidget</para></listitem>

<listitem><para>every GWidget is a GCanvas</para></listitem>

</itemizedlist>

<para>

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.

</para>

<para>

A problem is, it doesn't handle resizing properly as is.

</para>

</sect3>

<sect3>

<title>Widgets</title>

<sect4>

<title>Canvas</title>

<para>

Prefix is "Canvas".

</para>

//FIXME functions applying to GCanvases, but not to GWidgets

</programlisting>

</sect4>

<sect4>

<title>CanvasItem</title>

<para>

Prefix is "CanvasItem".

</para>

delete() //deletes properly, whichever the type

show() //shows item

hide() //hides item

</programlisting>

</sect4>

<sect4>

<title>Label</title>

<para>

Prefix is "Label".

</para>

new(): GLabel

new(String string): GLabel

delete()

get_text(): String

set_text(String string)

</programlisting>

</sect4>

<sect4>

<title>Window</title>

<para>

Prefix is "Window".

</para>

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)

</programlisting>

</sect4>

</sect3>

</sect2>

</sect1>

<!--

- APIs

* C library:

. str*() => string_*() and buffer_*()

. C classes => String?, Buffer?, SList, DList, Hash, Config, ...

- sessions

* sessions manager/init => itself a session? => can log on it and set it up?

* system sessions/engines (services)

* user sessions

- inter process communications

- login process

* one can even login on a system service as if would join an existing session, and the setup and monitoring interfaces appear (make this possible generally from a user's session, and you've got the control panel)

-->

</chapter>