FAQ
From eyeOS Developers Wiki
Contents |
[edit] Abstract and real files
An abstract (or virtual) file is a group of two special files. Each one of the user's files inside eyeOS is an abstract file.
One part of the abstract file is expressed with the '.eyeInfo' extension (according to the default configuration), and consists of an XML document that contains the file's general data: its real name, the user that owns the file, its creation date and the application that created the file.
The other part of the abstract file is represented by a file with the '.eyeFile' extension (according to the default configuration) that contains the very same contents of the file.
A real file is simply a non-abstract file: it is a normal file, represented by its name and its extension, without the need to be represented by two parts. In other words, it is a file in the form we can find normally in an OS's file system.
It must be noted that this system is only an implementation of the idea behind the VFS service: to separate the users' personal files inside their file root directory and the other special files (configurations, code, etc).
From eyeOS 1.2 and newer versions, the VFS service uses modules. A module is an internal change of the implementation of the service that does not change the service's API. With this system, you can change the service's module without noticeable difference for the users.
This system of using abstract files that use two files to separate the content and the information about the file is the implementation used by the default module that VFS. It can change depending of the module chosen and its internal implementation.
[edit] Available eyeOS global variables in an application
When creating an eyeOS application, there are many variables available to the developers that help use some of the basic functionality provided by the system:
- myPid: unique integer number describing the Process ID assigned to the application.
- checknum: unique integer number describing to a running process. This number is used to make the messages sent by an application to the server reach their destiny.
- currentUser: string containing the name of the user that launches the application.
- procInfo: associative array that contains general information about the current process:
- appName: name of the application running in the process.
- checknum: see the checknum explanation above.
- time: Unix timestamp specifying when the process was started.
- currentUser: see the currentUser explanation above.
- pid: see the myPid explanation above.
[edit] What is serializing?
When a Widget is serialized, it is stored in the session so it can be accessed from any part of the application. Let's see an example of how we can use this serialization mechanism:
This code should be created in a file called 'app.eyecode', inside a directory of the application 'myApp':
//Initializing function that all eyeOS applications must have
function myApp_run($params=null) {
$myWindow = new Window(array(
'name' => 'myAppWND',
'father' => 'eyeApps',
'title' => ,
'width' => 200,
'height' => 200
));
$myWindow->show();
$myTextbox = new Textbox(array(
'name' => 'myTextbox',
'father' => 'myAppWND_Content',
'x' => 10,
'y' => 10,
'text' => 'Click the button to change the text'
));
$myTextbox->show(); //This function serializes the textbox
$myButton = new Button(array(
'name' => 'myButton',
'father' => 'myAppWND_Content',
'x' => 10,
'y' => 40,
'caption' => 'Change',
'signal' => 'Change'
));
}
This code must be in the events.eyecode file of the same application:
function myApp_on_Change($params=null) {
$myTextbox->setText('Hello, world!');
}
As you can see, we can access the Textbox in events.eyecode and use its class methods thanks to the fact that it was serialized.
Most of the widgets can be serialized passing the number 0 as the argument of their show() method. Not all widgets can be serialized with this method, but you can always serialize any widget using the serialize() function of the eyeWidgets library.
[edit] What is a process inside eyeOS?
Every time an application is executed, an entry in the process table of a user is created. This entry is an array that contains information about the name, Process ID (pid), checknum, currentUser (the name of the user who launched the process) and the time it was launched.
By default, an eyeOS application can have multiple instances of itself running flawlessly. Every instance has its own entry on the Process Table and uses its own information independently from the others. Despite that behavior, a programmer can make an application to avoid having multiple instances very easily thanks to the process managing API the PROC service provides.
