Class v.c.g.c.Controller(Observer):

Part of vmc.contrib.gtkmvc.controller View In Hierarchy

We put all of our gtk signal handlers into a class. This lets us bind all of them at once, because their names are in the class dict. This class automatically register its instances as observers into the corresponding model. Also, when a view is created, the view calls method register_view, which can be oveloaded in order to connect signals and perform other specific operation. A controller possibly handles and contains also a set of adapters that makes easier to connect widgets and observable properties into the model.

parameter spurious controls the way spurious value change notifications are handled. If True, assignments to observable properties that do not actually change the value are notified anyway.
Method __init__ When parameter spurious is set to False
Method register_view This method is called by the framework when registering a
Method register_adapters This method is called by register_view during view
Method adapt Adapts a set of (observable) properties and a set of
Method __create_adapters__ Private service that looks at property and widgets types,

Inherited from Observer:

Method register_model Undocumented
Method accepts_spurious_change Returns True if this observer is interested in receiving
Method unregister_model Undocumented
Method __del__ Undocumented
Method get_model Undocumented
def __init__(self, model, spurious=False):

When parameter spurious is set to False (default value) the observer declares that it is not interested in receiving value-change notifications when property's value does not really change. This happens when a property got assigned to a value that is the same it had before being assigned.

A notification was used to be sent to the observer even in this particular condition, because spurious (non-changing) assignments were used as signals when signals were not supported by early version of the framework. The observer was in charge of deciding what to do with spurious assignments, by checking if the old and new values were different at the beginning of the notification code. With latest version providing new notification types like signals, this requirement seems to be no longer needed, and delivering a notification is no longer a sensible behaviour.

This is the reason for providing parameter spurious that changes the previous behaviour but keeps availability of a possible backward compatible feature.
def register_view(self, view):
This method is called by the framework when registering a view. Derived classes can exploit this call to connect signals manually, create and connect treeview, textview, etc.
def register_adapters(self):
This method is called by register_view during view registration process, when it is time to possibly create all adapters. model and view can safely be taken from self.model and self.view. Derived classes can specilize this method. In this implementation the method does nothing.
def adapt(self, *args):
Adapts a set of (observable) properties and a set of
widgets, by connecting them.

This method can be used to simplify the creation of one or
more adapters, by letting the framework do most of the work
needed to connect ('adapt') properties from one hand, and
widgets on the other.

This method is provided in three flavours:

1. An instance of an Adapter class can be created by the
   caller and passed as a unique argument. The adapter must
   be already fully configured.

2. The name of a model's property is passed as a unique
   argument.  A correponding widget name is searched and if
   found, an adapter is created. Name matching is performed
   by searching into view's widget names for words that end
   with the given property name. Matching is case
   insensitive and words can be separated by spaces,
   underscore (_) and CapitalizedWords. For example property
   'prop' will match widget 'cb_prop'. If no matches or
   multiple matches are found, a ValueError will be raised.
   The way names are matched can be customized by deriving
   method match_prop_name.

3. Two strings can be passed, respectively containing the
   name of an observable property in the model, and the name
   of a widget in the view.

Flavour 1 allows for a full control, but flavour 2 and 3
make easier to create adpaters with basic (default)
behaviour.

This method can be called into the method register_adapters
which derived classes can specialise.
def __match_prop_name(self, prop_name, wid_name):
Used internally when searching for a suitable widget. To customize its behaviour, re-implement this method into derived classes
def __create_adapters__(self, prop_name, wid_name):
Private service that looks at property and widgets types, and possibly creates one or more (best) fitting adapters that are returned as a list.
API Documentation for vodafone-mobile-connect-card-driver-for-linux, generated by pydoctor at 2008-01-10 13:06:31.