source: orange/docs/extend-widgets/rst/settings.rst @ 11439:2a63a9963207

Revision 11439:2a63a9963207, 25.6 KB checked in by Ales Erjavec <ales.erjavec@…>, 12 months ago (diff)

Small fixes to widget development documentation.

Line 
1#####################
2Settings and Controls
3#####################
4
5In the :doc:`previous section <basics>` of our tutorial we
6have just built a simple sampling widget. Let us now make this widget
7a bit more useful, by allowing a user to set the proportion of data
8instances to be retained in the sample. Say we want to design a widget
9that looks something like this:
10
11.. image:: dataSamplerBWidget.png
12
13What we added is an Options box, with a spin entry box to set the
14sample size, and a check box and button to commit (send out) any
15change we made in setting. If the check box with "Commit data on
16selection change" is checked, than any change in the sample size will
17make the widget send out the sampled data set. If data sets are large
18(say of several thousands or more) instances, we may want to send out
19the sample data only after we are done setting the sample size, hence
20we left the commit check box unchecked and press "Commit" when we are
21ready for it.
22
23This is a very simple interface, but there is something more to
24it. We want the settings (the sample size and the state of the commit
25button) to be saved. That is, any setting we made, after closing our
26widget (or after going out of Orange application that includes this
27widget, or after closing Orange Canvas), we want to save so that the
28next time we open the widget the settings is there as we have left
29it. There is some complication to it, as widget can be part of an
30application, or part of some schema in the Canvas, and we would like
31to have the settings application- or schema-specific.
32
33****************
34Widgets Settings
35****************
36
37Luckily, since we use the base class :obj:`OWWidget`, the settings
38will be handled just fine. We only need to tell which variables we
39will use for the settings. For Python inspired readers: these
40variables can store any complex object, as long as it is
41picklable. In our widget, we will use two settings variables, and we
42declare this just after the widget class definition.
43
44::
45
46    class OWDataSamplerB(OWWidget):
47        settingsList = ['proportion', 'commitOnChange']
48        def __init__(self, parent=None, signalManager=None):
49
50Any setting has to be initialized, and then we need to call
51:obj:`loadSettings()` to override defaults in case we have used
52the widget before and the settings have been saved::
53
54    self.proportion = 50
55    self.commitOnChange = 0
56    self.loadSettings()
57
58Now anything we do with the two variables (:obj:`self.proportion` and
59:obj:`self.commitOnChange`) will be saved upon exiting our
60widget. In our widget, we won't be setting these variables directly,
61but will instead use them in conjunction with GUI controls.
62
63******************
64Controls and OWGUI
65******************
66
67Now we could tell you how to put different Qt controls on the
68widgets and write callback functions that set our settings
69appropriately. This is what we have done before we got bored with it,
70since the GUI part spanned over much of the widget's code. Instead, we
71wrote a library called OWGUI (I never liked the name, but could never
72come up with something better). With this library, the GUI definition
73part of the options box is a bit dense but rather very short::
74
75    box = OWGUI.widgetBox(self.controlArea, "Info")
76    self.infoa = OWGUI.widgetLabel(box, 'No data on input yet, waiting to get something.')
77    self.infob = OWGUI.widgetLabel(box, '')
78
79    OWGUI.separator(self.controlArea)
80    self.optionsBox = OWGUI.widgetBox(self.controlArea, "Options")
81    OWGUI.spin(self.optionsBox, self, 'proportion', min=10, max=90, step=10,
82               label='Sample Size [%]:', callback=[self.selection, self.checkCommit])
83    OWGUI.checkBox(self.optionsBox, self, 'commitOnChange', 'Commit data on selection change')
84    OWGUI.button(self.optionsBox, self, "Commit", callback=self.commit)
85    self.optionsBox.setDisabled(1)
86
87We are already familiar with the first part - the Info group
88box. To make widget nicer, we put a separator between this and Options
89box. After defining the option box, here is our first serious OWGUI
90control. Called a :obj:`spin`, we give it place where it is
91drawn (:obj:`self.optionsBox`), and we give it the widget object
92(:obj:`self`) so that it knows where the settings and some other
93variables of our widget are.
94
95Next, we tell the spin box to be
96associated with a variable called :obj:`proportion`. This simply
97means that any change in the value the spin box holds will be directly
98translated to a change of the variable
99:obj:`self.proportion`. No need for a callback! But there's
100more: any change in variable :obj:`self.proportion` will be
101reflected in the look of this GUI control. Say if there would be a
102line :obj:`self.proportion = 70` in your code, our spin box
103control would get updated as well. (I must admit I do not know if you
104appreciate this feature, but trust me, it may really help prototyping
105widgets with some more complex GUI.
106
107The rest of the OWGUI spin box call gives some parameters for the
108control (minimum and maximum value and the step size), tells about the
109label which will be placed on the top, and tells it which functions to
110call when the value in the spin box is changed. We need the first
111callback to make a data sample and report in the Info box what is the
112size of the sample, and a second callback to check if we can send this
113data out. In OWGUI, callbacks are either references to functions, or a
114list with references, just like in our case.
115
116With all of the above, the parameters for the call of
117:obj:`OWGUI.checkBox` should be clear as well. Notice that this
118and a call to :obj:`OWGUI.spin` do not need a parameter which
119would tell the control the value for initialization: upon construction,
120both controls will be set to the value that is pertained in the
121associated setting variable.
122
123That's it. Notice though that we have, as a default, disabled all
124the controls in the Options box. This is because at the start of the
125widget, there is no data to sample from. But this also means that when
126process the input tokens, we should take care for enabling and
127disabling. The data processing and token sending part of our widget
128now is::
129
130    def data(self, dataset):
131        if dataset:
132            self.dataset = dataset
133            self.infoa.setText('%d instances in input data set' % len(dataset))
134            self.optionsBox.setDisabled(0)
135            self.selection()
136            self.commit()
137        else:
138            self.send("Sampled Data", None)
139            self.optionsBox.setDisabled(1)
140            self.infoa.setText('No data on input yet, waiting to get something.')
141            self.infob.setText('')
142
143    def selection(self):
144        indices = orange.MakeRandomIndices2(p0=self.proportion / 100.)
145        ind = indices(self.dataset)
146        self.sample = self.dataset.select(ind, 0)
147        self.infob.setText('%d sampled instances' % len(self.sample))
148
149    def commit(self):
150        self.send("Sampled Data", self.sample)
151
152    def checkCommit(self):
153        if self.commitOnChange:
154            self.commit()
155
156You can now also inspect the :download:`complete code <OWDataSamplerB.py>`
157of this widget. To distinguish it with a widget we have developed in the
158previous section, we have designed a special
159:download:`icon <DataSamplerB.png>` for it. If you wish to test is
160widget in the Orange Canvas, put its code in the Test directory we
161have created for the previous widget, update the Canvas registry, and
162try it out using a schema with a File and Data Table widget.
163
164.. image:: schemawithdatasamplerB.png
165
166
167Well-behaved widgets remember their settings - the state of their
168checkboxes and radio-buttons, the text in their line edits, the
169selections in their combo boxes and similar. These settings are even
170maintained across sessions. This document describes the Orange's
171methods that take care of that.
172
173Orange doesn't really save the state of the controls but instead
174saves the value of the corresponding attributes. For a check box there
175should be a corresponding widget's attribute recording the check box's
176state so that when the user changes a check box, the attribute changes
177and vice-versa. You can create such a link manually, or you can use
178the :doc:`OWGUI <owgui>` module instead; for instance, for a check
179box, use :func:`OWGUI.checkBox`.
180
181The settings fall into two groups. Some of them do not depend on
182the data, while other are context-dependent. For the first to be saved
183properly, you only need to list them in the :obj:`settingsList`
184in the widget definition, as already described.
185
186
187.. module:: OWContexts
188
189**************************
190Context dependent settings
191**************************
192
193Context dependent settings usually depend upon the attributes that
194are present in the data set domain. For instance, the scatter plot
195widget contains settings that specify the attributes for x and y axis,
196and the settings that define the color, shape and size of the examples
197in the graph. An even more complicated case is the widget for data
198selection with which one can select the examples based on values of
199certain attributes. Before applying the saved settings, these widgets
200needs to check their compliance with the domain of the actual data
201set. To be truly useful, context dependent settings needs to save a
202setting configuration for each particular data set used. That is, when
203given a particular data set, it has to select the saved settings that
204is applicable and matches best currently used data set.
205
206Saving, loading and matching contexts is taken care of by context
207handlers. Currently, there are only two classes of context handlers
208implemented. The first one is the abstract :class:`ContextHandler`
209and the second one is :class:`DomainContextHandler` in which the
210context is defined by the data set domain and where the settings
211contain attribute names. The latter should cover most of your needs,
212while for more complicated widgets you will need to derive a new
213classes from it. There may even be some cases in which the context is
214not defined by the domain, in which case the
215:class:`ContextHandler` will be used as a base for your new
216handler.
217
218Contexts need to be declared, opened and closed. Opening and
219closing usually takes place (in the opposite order) in the function
220that handles the data signal. This is how it looks in the scatter plot
221(the code is somewhat simplified for clarity).
222
223::
224
225    def cdata(self, data, clearResults = 1):
226        self.closeContext()
227
228        exData = self.data
229        self.data = data
230        self.graph.setData(data)
231        self.graph.insideColors = None
232        self.graph.clusterClosure = None
233
234        self.initAttrValues()
235
236        self.openContext("", data)
237
238        self.updateGraph()
239        self.sendSelections()
240
241In general, the function should go like this.
242
243* Do any clean-up you need, but without clearing any of the settings that need
244  to be saved. Scatter plot needs none.
245* Call :obj:`self.closeContext()`; this ensures that all the context dependent
246  settings (e.g. attribute names from the list boxes) are remembered.
247* Get the data (or whatever you do) and set the controls to some defaults as
248  if there were no context retrieving mechanism. Scatter plot does it by
249  calling :obj:`initAttrValues()` which assigns the first two attributes to
250  the x and y axis and the class attribute to the color. At this phase, you
251  shouldn't call any functions that depend on the settings, such as drawing
252  the graph.
253* Call :obj:`self.openContext` (more about the arguments later). This will
254  search for a suitable context and assign the controls new values if one is
255  found. If there is no saved context that can be used, a new context is
256  created and filled with the default values that were assigned at the previous
257  point.
258* Finally, adjust the widget according to the retrieved controls. Scatter plot
259  now plots the graph by calling :obj:`updateGraph`.
260
261
262:obj:`closeContext` has an argument, the name of the context. If omitted
263(like above), the default name (:obj:`""`) is used. When opening the context,
264we give the name and some arguments on which the context depends. In case of
265:obj:`DomainContextHandler`, which scatter plot uses, we can give it a domain
266or any object that has a field :obj:`domain` containing a domain. Whether a
267saved context can be reused is judged upon the presence of attributes in the
268domain.
269
270If the widget is constructed appropriately (that is, if it strictly uses OWGUI
271controls instead of the Qt's), no other administration is needed to switch the
272context.
273
274Except for declaring the context settings, that is. Scatter plot has this just
275below the :obj:`settingsList` ::
276
277    contextHandlers = {"": DomainContextHandler("",
278      [("attrX", DomainContextHandler.Required),
279       ("attrY", DomainContextHandler.Required),
280       ("attrLabel", DomainContextHandler.Optional),
281       ("attrShape", DomainContextHandler.Optional),
282       ("attrSize", DomainContextHandler.Optional)])}
283
284:obj:`contextHandlers` is a dictionary whose keys are contexts' names. Each
285widget can have multiple contexts; for an unrealistic example, consider a
286scatter plot which gets two data sets and uses one attribute from the first
287for the x axis, and an attribute from the other for y. Since we won't see this
288often, the default name for a context is an empty string.
289
290The values in the dictionary are context handlers. Scatter plot declares that
291it has a DomainContextHandler with name "" (sorry for the repetition) with
292attributes "attrX", "attrY", "attrLabel", "attrShape" and "attrSize". The
293first two are required, while the other three are optional.
294
295*********************************
296Using :obj:`DomainContextHandler`
297*********************************
298
299What we said above is not exactly true. :obj:`DomainContextHandler.Required`
300is the default flag, so :obj:`("attrX", DomainContextHandler.Required)` can
301be replaced by simply :obj:`"attrX"`. And the latter three have the
302same flags, so they can be grouped into :obj:`(["attrLabel",
303"attrShape", "attrSize"], DomainContextHandler.Optional)`. So
304what scatter plot really says is::
305
306    contextHandlers = {"": DomainContextHandler("", [
307       "attrX", "attrY",
308       (["attrLabel", "attrShape", "attrSize"], DomainContextHandler.Optional)])}
309
310What do ``Optional`` and ``Required`` mean? Say that you used the
311scatter plot on the data with attributes A, B, C and D; A and B are
312used for the x and y axis and D defined the colors of examples. Now
313you load a new data with attributes A, B, E, and F. The same context
314can be used - A and B will again be shown on x and y axis and the
315default (the one set by :obj:`self.initAttrValues`) will be used
316for the color since the attribute D is missing in the new data. Now
317comes the third data set, which only has attributes A, D and E. The
318context now can't be reused since the attribute used for the
319*required* :obj:`attrY` (the y axis) is missing.
320
321OK, now it is time to be a bit formal. As said,
322:obj:`contextHandlers` is a dictionary and the values in it need
323to be context handlers derived from the abstract class
324:obj:`ContextHandler`. The way it is declared of course depends
325upon its constructor, so the above applies only to the usual
326:obj:`DomainContextHandler`.
327
328:class:`DomainContextHandler`'s constructor has the following arguments
329
330`contextName`
331   The name of the context; it should consist of letters and digits (it is
332   used as a part of a variable name). In case the widget has multiple
333   contexts, they should have unique names. In most cases there will be only
334   one context, so you can leave it empty.
335
336`fields`
337   The names of the attributes to be saved and the corresponding flags. They
338   are described in more details below.
339
340`cloneIfImperfect`
341   States that when the context doesn't match perfectly, that is, unless the
342   domain is exactly the same as the domain from which the context was
343   originally created, :obj:`openContext` shouldn't reuse a context but create
344   a copy of the best matching context instead. Default is :obj:`True`.
345
346`loadImperfect`
347   tells whether the contexts that do not match perfectly (see above) should
348   be used or not. Default is :obj:`True`.
349
350`findImperfect`
351   Tells whether imperfect contexts match at all or not (this flag is
352   somewhat confused with :obj:`loadImperfect`, but it may come useful some
353   day). Default is :obj:`True` again.
354
355`syncWithGlobal`
356   Tells whether instances of this widget should have a shared list of
357   contexts (default). The alternative is that each keeps its own list;
358   each individual list is merged with the global when the widget is deleted
359   from the canvas (or when the canvas is closed). This setting only applies
360   to canvas, while in saved applications widgets always have separate settings
361   lists.
362
363`maxAttributesToPickle`
364   To keep the size of the context file small, settings for domains exceeding
365   a certain number of attributes are not pickled. Default is 100, but you can
366   increase (or decrease this) if you need to.
367
368
369The truly interesting argument is :obj:`fields`. It roughly corresponds to the
370:obj:`settingsList` in that each element specifies one widget attribute to be
371saved. The elements of :obj:`fields` can be strings, tuples and/or instances of
372:obj:`ContextField` (whatever you give, it gets automatically converted to the
373latter). When given as tuples, they should consist of two elements, the field
374name (just like in :obj:`settingsList`) and a flag. Here are the possible flags:
375
376* :obj:`DomainContextHandler.Optional`,
377  :obj:`DomainContextHandler.SelectedRequired` and
378  :obj:`DomainContextHandler.Required` state whether the attribute is optional
379  or required, as explained above. Default is :obj:`Required`.
380  :obj:`DomainContextHandler.SelectedRequired` is applicable only if the
381  control is a list box, where it means that the attributes that are selected
382  are required while the other attributes from the list are not.
383
384* :obj:`DomainContextHandler.NotAttribute` the setting is not an attribute
385  name. You can essentially make a check box context dependent, but we very
386  strongly dissuade from this since it can really confuse the user if some
387  check boxes change with the data while most do not.
388
389* :obj:`DomainContextHandler.List` tells that the attribute corresponds to a
390  list box.
391
392
393Flags can be combined, so to specify a list in which all attributes
394are required, you would give :obj:`DomainContextHandler.List +
395DomainContextHandler.Required`. Since this combination is
396common, :obj:`DomainContextHandler.RequiredList` can be used
397instead.
398
399There are two shortcuts. The default flag is
400:obj:`DomainContextHandler.Required`. If your attribute is like
401this (as most are), you can give only its name instead of a
402tuple. This is how :obj:`"attrX"` and :obj:`"attrY"` are
403given in the scatter plot. If there are multiple attributes with the
404same flags, you can specify them with a tuple in which the first
405element is not a string but a list of strings. We have seen this trick
406in the scatter plot, too.
407
408But the tuples are actually a shortcut for instances of
409:obj:`ContextField`. When you say :obj:`"attrX"` this is actually
410:obj:`ContextField("attrX", DomainContextHandler.Required)`
411
412..
413   But see this monster from widget "Select Attributes" (file OWDataDomain.py)::
414
415       contextHandlers = {"": DomainContextHandler("",
416           [ContextField("chosenAttributes",
417                          DomainContextHandler.RequiredList,
418                          selected="selectedChosen", reservoir="inputAttributes"),
419            ContextField("classAttribute",
420                          DomainContextHandler.RequiredList,
421                          selected="selectedClass", reservoir="inputAttributes"),
422            ContextField("metaAttributes",
423                          DomainContextHandler.RequiredList,
424                          selected="selectedMeta", reservoir="inputAttributes")
425       ])}
426
427
428   :obj:`ContextField`'s constructor gets the name and flags and a list of
429   arguments that are written directly into the object instance. To follow the
430   example, recall what Select Attributes looks like: it allows you to select a
431   subset of attributes, the class attribute and the meta attributes that you
432   want to use; the attributes in the corresponding three list boxes are stored
433   in the widget's variables :obj:`chosenAttributes`, :obj:`classAttribute`
434   and :obj:`metaAttributes` respectively. When the user selects some attributes
435   in any of these boxes, the selection is stored in :obj:`selectedChosen`,
436   :obj:`selectedClass` and :obj:`selectedMeta`. The remaining attributes
437   - those that are not in any of these three list boxes - are in the leftover
438   listbox on the left-hand side of the widget, and the content of the box is
439   stored in the widget's variable :obj:`inputAttributes`.
440
441   The above definition tells that the context needs to store the contents of
442   the three list boxes by specifying the corresponding variables; the list of
443   attributes is given as the name of the field and the list of selected
444   attributes is in the optional named attribute :obj:`selected`. By
445   :obj:`reservoir` we told the context handler that the attributes are taken
446   from :obj:`inputAttributes`. So, when a context is retrieved, all the
447   attributes that are not in any of the three list boxes are put into
448   :obj:`inputAttributes`.
449
450   Why the mess? Couldn't we just store :obj:`inputAttributes` as the fourth
451   list box? Imagine that the user first loads the data with attributes A, B,
452   C, D, E and F, puts A, B, C in chosen and D in class. E and F are left in
453   :obj:`inputAttributes`. Now she loads another data which has attributes A,
454   B, C, D, E, and G. The contexts should match (the new data has all the
455   attributes we need), but :obj:`inputAttributes` should now contain E and
456   G, not E and F, since F doesn't exist any more, while G needs to be made
457   available.
458
459   You can use :obj:`ContextField` (instead of tuples and strings) for
460   declaring any fields, but you will usually need them only for lists or,
461   maybe, some complicated future controls.
462
463
464*****************************
465Defining New Context Handlers
466*****************************
467
468Avoid it if you can. If you can't, here's the list of the methods you may need
469to implement. You may want to copy as much from the :obj:`DomainContextHandler`
470as you can.
471
472
473:obj:`__init__`
474   Has the same arguments as the :obj:`DomainContextHandler`'s, except for the
475   :obj:`fields`.
476
477:obj:`newContext()`
478   Creates and returns a new context. In :obj:`ContextHandler` it returns an
479   instance of :obj:`Context`; you probably won't need to change this.
480
481:obj:`openContext(widget, *args)`
482   The method is given a widget and some additional arguments based on which
483   the contexts are compared. In case of :obj:`DomainContextHandler` this is
484   a domain. There can be one or more such arguments. Note that the method
485   :obj:`openContext` which we talked about above is a method of
486   :obj:`OWBaseWidget`, while here we describe a method of context handlers.
487   Actually, :obj:`OWBaseWidget.openContext(self,contextName, *args)` calls
488   the context handler's, passing it's :obj:`self` and :obj:`*args`.
489
490   It needs to find a matching context and copy its settings to the widget or
491   construct a new context and copy the settings from the widget. Also, when an
492   old context is reused, it should be moved to the beginning of the list.
493   :obj:`ContextHandler` already defines this method, which should usually
494   suffice. :obj:`DomainContextHandler` adds very little to it.
495
496:obj:`closeContext`
497   Copies the settings from the widget by calling :obj:`settingsFromWidget`.
498   You probably won't need to overwrite it.
499
500:obj:`match`
501   The method is called by :obj:`openContext` to find a matching context.
502   Given an existing context and the arguments that were given to
503   :obj:`openContext` (for instance, a domain), it should decide whether the
504   context matches or not. If it returns 2, it is a perfect match (e.g.
505   domains are the same). If it returns 0, the context is not applicable
506   (e.g. some of the required attributes are missing). In case it returns a
507   number between 0 and 1 (excluding 0), the higher the number the better the
508   match. :obj:`openContext` will use the best matching context (or the
509   perfect one, if found).
510
511:obj:`settingsToWidget` / :obj:`settingsFromWidget`
512   Copy the settings to and from the widget.
513
514:obj:`fastSave`
515   This function is called by the widget's :obj:`__setattr__` each time any
516   widget's variable is changed to immediately synchronize the context with
517   the state of the widget. The method is really needed only when
518   :obj:`syncWithGlobal` is set. When the context is closed,
519   :obj:`closeContext` will save the settings anyway.
520
521:obj:`cloneContext`
522   Given an existing context, it prepares and returns a copy. The method is
523   optional; :obj:`copy.deepcopy` can be used instead.
524
525
526***************************
527Saving and loading settings
528***************************
529
530Settings can be saved in two different places. Orange Canvas save
531settings in .ini files in its application data directory. Each widget type has
532a separate file; for instance, the scatter plot's settings are saved in
533:obj:`ScatterPlot.ini`. Saved schemas and applications save
534settings in .sav files; the .sav file is placed in the same directory
535as the schema or application, has the same name (except for the
536extension) and contains the settings for all widgets in the
537schema/application.
538
539Saving and loading is done automatically by canvas or the
540application. In a very rare case you need it to run these operations
541manually, the functions involved are :obj:`loadSettings(self, file=None)`,
542:obj:`saveSettings(self, file=None)`, :obj:`loadSettingsStr(self, str)`,
543:obj:`saveSettingsStr(self)`. The first two load and save from
544the file; if not given, the default name (widget's name +
545:obj:`.ini`) is used. They are called by the canvas, never by a
546schema or an application. The last two load and save from a string and
547are used by schemas and applications. All the functions are defined as
548methods of :obj:`OWBaseWidget`, which all other widgets are
549derived from.
Note: See TracBrowser for help on using the repository browser.