[Altosdev-kernel] GUI
Status: Planning
Brought to you by:
dozz
|
From: Alexey M. <tkt...@cs...> - 2002-03-08 14:00:37
|
Hei,
As i mentioned before, all communication between processes are performed
using signals and streams. About signals we talk later, let talk about
streams.
The stream is the form of inter process communication. Stream consist of 2
channels; one of them is using for commands transfering and second for
data transfering. Transfering commands should be faster than data transfering
in kernel realization (cuz commands transferring has less data than
data transferring, so we can implement it to work faster).
The communication between processes is implemented using streams. If one
process needs to open stream "/dev/gui/level1" it do it with appropriate
system call. Kernel transfers command to VFS, which knows that "/dev/gui"
is the mountpoint of device gui and requests it for stream named "level1"
Each process has special entry point for requests about stream
creation. The GUI receives this request and creates stream from his side.
As a fact, "/dev/gui/level1" is only a stream name, stream is a number of
internal kernel structure... The GUI receives request and creates the
thread which will perform communication with application through this
stream... It is common client-server architecture.
It can be described like that.
Process open stream "/dev/gui/level1" with system call
1. Kernel creates the new stream number and remember that on the one
side of stream is our process.
2. Kernel sends request to VFS in order to get the informaion who will
be on other side of stream..
2.1 VFS knows that "/dev/gui" is the mount point of gui module.
2.2 It calls the special entry point in module in order to know is it
possible for module to send and receive data through this stream.
2.2.1 GUI looking for his streams names,... yappi
2.2.2 He found that "level1" is a stream name and function level1
should perform the communication through this stream
2.2.3 GUI creates the thread for function level1 and passes to it
the number of stream.
2.2.4 GUI returns to VFS information that he accepts stream
creationg.
2.3 VFS returns to kernel the gui process id
3. Kernel remembers the information about the second side of stream
4. Kernel returns to the process the number of created stream.
What should do the thread in GUI? It should read from command channel of
stream for commands from process and sends through stream
information about events.
I suggest 3 level of GUI services:
1. Raw GUI service;
In this service we care about redrawing and other stuff. The GUI in
this case will only send us information about events and we redraw and
etc.
2. Component GUI service.
Like using X protocol we will send GUI through stream information
about compoments of window, their properties and GUI sends for us back
in stream information about events but we don't need to readraw
anything cuz using standart components.
3. Raw text service.
For console applications.. The was text output into stream will be
shown in window and user input will be sent to application through
stream.
Application can use any level... for example super modern MP3player can
use first level to get the strange window form and buttons. The text
editor can use second level to minimize code.. He sends the GUI level 2
his representation in some format and catches events that GUI sends to
him.. he can perform save and load when user selects save and load from
menu and etc... Simple console applications like super hacker utility or
common ping can use GUI level 3, to not be worried about application
graphical representation.
Level 1:
Application sends to GUI:
1. Bitmaps of window,
2. Mask of windows to know the window area,
3. The mask of events, that application wants to catch,
4. Or just a request to draw in window some graphics.
Application receive from GUI:
1. Event information (mouse event, keyboard event),
2. Request to redraw some area of window (event too).
Level 2:
Application sends to GUI:
1. The defenition of window and all elements it contains
2. Request to affect to specified element of window (insert text into
common text label element, for example).
Application receives from GUI:
1. Events, but specified for elements (for example, user selects "load"
from menu).
2. Request redraw some area IN some ELEMENT!
Level 3:
Application sends to GUI:
1. Raw text (GUI creates the window using service level 2 and creates
standart text edit element in it, when GUI receive the text, it
shows it in this element)
Application receives from GUI:
1. Raw key values, that user pressed.
--
See you later,
d.
+358 040 817 8540
|