| Trees | Index | Help |
|
|---|
| Module indiclient :: Class gui_indi_object_handler |
|
_blocking_indi_object_handler --+
|
gui_indi_object_handler
indi_custom_element_handler,
indi_custom_vector_handler,
_gtkindi_widgetlist_handleron_gui_changed. And another one on_indiobject_changed to handle changes of
INDIobjects received from the INDI server. It allows to detect if the
method on_gui_changed is in asked to be called,
while the method on_indiobject_changed is running. This
situation has to be take special care of, as loopbacks or data losses are
likely to happen if one does not take care. In order to allow this
mechanism to work every function must not call on_gui_changed
directly, but any function may call _blocking_on_gui_changed instead. So if you
are writing a custom handler please link the callback of your GUI to _blocking_on_gui_changed and implement it
in on_gui_changed
| Method Summary | |
|---|---|
| NoneType | The method _blocking_on_gui_changed is called by the
GUI, in order to inform us, that a widget has changed. |
| NoneType | Important: Implement your GUI callback here but link you GUI callback signal to {_blocking_on_gui_changed} (see on_blocked if you want to know why) |
| NoneType | installs callbacks of the GUI that will call the function _blocking_on_gui_changed if the user
changes the the GUI object associated with this gui_indi_object_handler . |
| NoneType | uninstalls the GUI callback installed with set_bidirectional (see set_bidirectional for details) |
| NoneType | Called by the GUI whenever the widget associated with this handler has changed. |
| Inherited from _blocking_indi_object_handler | |
| |
| NoneType | activates the block. |
| BooleanType | Return True if blocked , False otherwise |
| NoneType | releases the block. |
| NoneType | This method will be called at least once by indiclient. |
| NoneType | This method activates the block, calls the method on_indiobject_changed (It is called by bigindiclient.process_events each time an
INDI object has been received) |
| NoneType | While this function is called the block is active. |
| Instance Variable Summary | |
|---|---|
| Inherited from _blocking_indi_object_handler | |
| IntType | _blocked: A counter incremented each time the _block method is called and decremented by
_unblock, >0 means blocked, ==0 mean
unblocked |
| Method Details |
|---|
on_blocked(self, *args)The method_blocking_on_gui_changed is called by the
GUI, in order to inform us, that a widget has changed. If the blocked
property is True, when _blocking_on_gui_changed is called by the
GUI. This method (on_blocked) is called and nothing else
done. The blocked property is True while the on_indiobject_changed function is
running, so and indiobject has been received from the server and on_indiobject_changed is currently
changing the widget associated with it. So there is a question: Was _blocking_on_gui_changed called by the
GUI? because on_indiobject_changed changed the widget
or was it called because the user changed something? Well, we don't
know! And this is bad. Because if on_indiobject_changed did it and we send
the new state to the server, the server will reply, which will in turn
trigger on_indiobject_changed which will cause
the GUI to emit another _blocking_on_gui_changed signal and
finally call on_blocked. This way we have generated a
nasty loopback. But if we don't send the new state to the server and
the change was caused by the user, the user will see the widget in the
new state, but the server will not know about it, so the user has got
another idea of the status of the system than the server and this is
also quite dangerous. For the moment we print a warning and send the
signal to the server, so we use the solution that might cause a
loopback, but we make sure that the GUI and the server have got the
same information about the status of the devices. One possible solution
to this problem that causes neither of the problems is implemented in
the gtkindiclient._comboboxentryhandler
class. We do no send the new state to the server. But we load the
latest state we received from the server and set the gui to this state.
So the user might have clicked at a GUI element, and it might not have
changed in the proper way. We tested this for the combobox and the
togglebutton and it worked.
|
on_gui_changed(self, *args)Important: Implement your GUI callback here but link you GUI callback signal to {_blocking_on_gui_changed} (seeon_blocked if you want to know why)
|
set_bidirectional(self)installs callbacks of the GUI that will call the function_blocking_on_gui_changed if the user
changes the the GUI object associated with this gui_indi_object_handler . The function _blocking_on_gui_changed will usually
call the function on_gui_changed. The function on_gui_changed has to update and send the
INDI object associated with this gui_indi_object_handler.
|
unset_bidirectional(self)uninstalls the GUI callback installed withset_bidirectional (see set_bidirectional for details)
|
_blocking_on_gui_changed(self, *args)Called by the GUI whenever the widget associated with this handler has changed. If the method on_indiobject_changed is currently active, the methodon_blocked is called otherwise (which is
the far more usual case) the method on_gui_changed is called.
Important: link your GUI callback signal to this function but
implement it in on_gui_changed (see on_blocked if you want to know why)
|
| Trees | Index | Help |
|
|---|
| Generated by Epydoc 2.1 on Sat Sep 10 10:26:06 2005 | http://epydoc.sf.net |