Trees | Index | Help |
|
---|
Module gtkindiclient :: Class _comboboxentryhandler |
|
indi_vector_identifier
--+ |_blocking_indi_object_handler
--+ | | |gui_indi_object_handler
--+ | | |_gtkindi_widgetlist_handler
--+ | | |_gtkindi_widget_handler
--+ |_gtkindi_widget_vector_handler
--+ | _comboboxentryhandler
indiswitchvector
object (with rule
OneOfMany
) connected to a GTK.ComboBoxEntry object. The
labels of indiswitch
objects will be fed into the
popdown menu of the ComboBox, the label of the active switch will be
visable in the entry of .
Method Summary | |
---|---|
| |
configure(self,
vector)
| |
NoneType |
The method _blocking_on_gui_changed is called by the
GUI, in order to inform us, that a widget has changed. |
on_indiobject_changed(self,
vector)
| |
NoneType |
Called when the widget has changed and the INDI vector needs to be updated |
Inherited from _gtkindi_widget_vector_handler | |
indivector
|
Returns the indivector this handler is associated
with. |
| |
Inherited from _gtkindi_widgetlist_handler | |
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) |
Inherited from gui_indi_object_handler | |
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 activates the block, calls the method on_indiobject_changed (It is called by bigindiclient.process_events each time an
INDI object has been received) |
Instance Variable Summary | |
---|---|
Inherited from _gtkindi_widget_vector_handler | |
GTK.Widget | widget : The GTK widget |
Inherited from _gtkindi_widgetlist_handler | |
list of GTK.Widget | widgetlist : The list GTK widgets to be connected |
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 |
Inherited from indi_vector_identifier | |
StringType | devicename : The name of the device contaning the vector to be uniquely identifyed
by this object |
StringType | vectorname : The name of the indivector to be uniquely identifyed by
this object |
Method Details |
---|
__init__(self,
devicename,
vectorname,
widget)
|
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.
|
update_indi_vector(self, vector)Called when the widget has changed and the INDI vector needs to be updated
|
Trees | Index | Help |
|
---|
Generated by Epydoc 2.1 on Sat Sep 10 10:26:04 2005 | http://epydoc.sf.net |