Anubis / Anubis

Commit f3112e03a404bcbab1bb773e4fc14c1047242d56

Authored by Alain Prouté
1 parent 344585a8

*** empty log message ***

Showing 1 changed file with 20 additions and 15 deletions   Show diff stats
Inline Side-by-side
anubis_dev/library/widgets4/widget.anubis
  Show/Hide comments   View file @f3112e0
... ... @@ -91,24 +91,29 @@
91 91  
92 92 Despite the fact that widgets are objects, their position in the host window is not
93 93 part of their internal state. When a widget needs to redraw a child widget, it calls a
94   - method which takes the relative position of the child widget (relative to its father
95   - widget) as an argument. The same is true for the transmission of events. Hence, a
96   - widget has the responsability to know the positions of its childs relative to
97   - itself. If getting these positions require heavy computation, the widget may store them
98   - into dynamic variables, but in this case, the widget also has the responsability of
99   - keeping these variables up to date.
  94 + method which takes the relative position of the child widget (relative to itself) as an
  95 + argument. The same is true for the transmission of events. Hence, a widget has the
  96 + responsability to know the positions of its childs relative to itself. If getting these
  97 + positions require heavy computation, the widget may store them into dynamic variables,
  98 + but in this case, the widget also has the responsability of keeping these variables up
  99 + to date.
  100 +
  101 + Another consequence of the fact that the position of a widget is not part of its
  102 + internal state, is that widgets are 'ubiquitous'. This means that the same widget may
  103 + appear at several different positions in a host window or even in distinct host
  104 + windows. In order to preserve this property, you should never violate the rules
  105 + explained below, in particular concerning absolute and relative coordinates.
100 106  
101 107 An important feature is the possibility of capturing either the mouse or the
102 108 keyboard. For example, when a 'text input' widget is clicked upon, it should capture
103   - the keyboard. To that end, the widget uses a function which creates a 'capture ticket'
104   - and returns an appropriate 'keyboard capture' answer, containing this ticket. The
105   - widget must also keep the ticket. Later, when a keyboard event arrives, the widget
106   - system transmits this event in the form of a function taking this ticket as an
107   - argument. Each widget which is supposed to be able to capture the keyboard, should
108   - apply this function to the ticket it has created. The function returns either 'failure'
109   - if then ticket is invalid, or 'success(e)' if it is valid, where 'e' is the actual
110   - captured event. This event must be handled, and an answer must be returned, which will
111   - eventually induce a redrawing.
  109 + the keyboard. To that end, the widget creates a 'capture ticket' and returns an
  110 + appropriate 'keyboard capture' answer, containing this ticket. The widget must also
  111 + keep the ticket. Later, when a keyboard event arrives, the widget system transmits
  112 + this event in the form of a function taking this ticket as an argument. Each widget
  113 + which is supposed to be able to capture the keyboard, should apply this function to the
  114 + ticket it has created. The function returns either 'failure' if the ticket is invalid,
  115 + or 'success(e)' if it is valid, where 'e' is the actual captured event. This event must
  116 + be handled, and an answer must be returned, which will eventually induce a redrawing.
112 117  
113 118  
114 119  
... ...