you will basically have 2 kind of graphical systems :
- those where the draw/handle code is at the CLIENT side (x-window), which means any operation involves the emission of a request to a remote object (Obj_id = 12345, event = REDRAW) that will be handled by the application which replies with a list of commands sent to the server (SET_PEN black,white), (CLEAR_BOX top_left, bottom_right) (DRAW_HLINE, top, left, right) (DRAW_HLINE bottom, left, right) (VLINE) (VLINE) (SET_FONT arial) (CENTER_TEXT center, "Hello World")
This approach can be heavy and gives poor responsiveness, but it can offer virtually any object you like
. The other drawback is that it requires a LOT of events if you want to do something that is highly dynamic (each mouse move could need to be reported !)
- those where the object behaviour is known by the server itself, so you just send a construction event (create_text_button (center, arial, "Hello World") and the server will know what it is, how it should be redrawn, how it respond to basic events such as MOUSE_BUTTON_DOWN, FOCUS_LOST, FOCUSED, MOUSE_BUTTON_UP, ... : only a "clicked" event need to be reported to the application ...
Now the major drawback is that the server needs to know EVERY object that you'll have to draw on screen
. Plug-ins will be your friends around here ...
And now my own idea about how it should work:
the server only knows about METALANGUAGES for widgets definitions. Those languages should be added as plug-in, but they could express a wide range of objects, combining primitives, etc.
for instance you could send at the construction
Code: Select all
object textbutton (
properties: (string: text; boolean down, focused )
content: (
background: fillbox (color <= grey) @center, #expandxy
corner_a: (
hline (color<=lightgrey) @north, #expandx
vline (color<=lightgrey) @east, #expandy
)
corner_b: (
hline (color<=darkgrey) @south, #expandx
vline (color<=darkgrey) @west, #expandy
)
txt: flattext (str<=text, color<=black) @center
)
on GET_FOCUS: background.color<=grey80;
on MOUSE_DOWN: do {
corner_a.color<=darkgrey;
corner_b.color<=lightgrey;
down=true;
}
on MOUSE_UP: do {
corner_a.color<=lightgrey;
corner_b.color<=darkgrey;
down=false;
if (focused) emit "clicked";
}
on GET_FOCUS: if (down) do {
// colors = down colors.
focused = true;
}
on FOCUS_LOST: if (down) do {
// colors = up colors.
focused = false;
}
)
a small system in the display server could compile this into a small description (bytecoded ?) of what is to be repainted and actions to be carried out when something occurs (basically maths expressions, affectations to local state and event emissions). This is done only once when the object is described. then when the FOCUS_LOST event is received, the server only finds back the executor for that object (GUiDL virtual machines) which will execute some small bytecode (draw_lines with the proper color, set a new value to *focused* local variable) and we're done.