[Altosdev-kernel] GUI

[Alexey M. <tkt...@cs...>]

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