Ignore:
Timestamp:
03/19/13 19:36:52 (13 months ago)
Author:
Ales Erjavec <ales.erjavec@…>
Branch:
default
Message:

Fixes for Widgets Development documentation.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • docs/extend-widgets/rst/settings.rst

    r11049 r11408  
    154154            self.commit() 
    155155 
    156 You can now also inspect the `complete code <OWDataSamplerB.py>`_ of this 
    157 widget. To distinguish it with a widget we have developed in the 
    158 previous section, we have designed a special `icon <DataSamplerB.png>`_ for it. If you wish to test is 
     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 
    159160widget in the Orange Canvas, put its code in the Test directory we 
    160161have created for the previous widget, update the Canvas registry, and 
     
    175176state so that when the user changes a check box, the attribute changes 
    176177and vice-versa. Although you can create such a link manually, you 
    177 should always use the module <a href="owgui.htm">OWGUI</a> instead; 
     178should always use the module :doc:`OWGUI <owgui.rst>` instead; 
    178179for instance, for a check box, use :obj:`OWGUI.checkBox` and not 
    179180simply the Qt's :obj:`QCheckBox`. 
     
    182183the data, while other are context-dependent. For the first to be saved 
    183184properly, you only need to list them in the :obj:`settingsList` 
    184 in the widget definition, as already described <a 
    185 href="settings.htm">elsewhere</a>. 
     185in the widget definition, as already described :doc:`elsewhere <settings.rst>` 
    186186 
    187187************************** 
     
    286286comes the third data set, which only has attributes A, D and E. The 
    287287context now can't be reused since the attribute used for the 
    288 <em>required</em> :obj:`attrY` (the y axis) is missing. 
     288*required* :obj:`attrY` (the y axis) is missing. 
    289289 
    290290OK, now it is time to be a bit formal. As said, 
     
    347347 
    348348But the tuples are actually a shortcut for instances of 
    349 :obj:`ContextField`. When you say :obj:`"attrX"` this is 
    350 actually :obj:`ContextField("attrX", 
    351 DomainContextHandler.Required)` (you should appreciate the 
    352 shortcurt, right?). But see this monster from widget "Select 
     349:obj:`ContextField`. When you say :obj:`"attrX"` this is actually 
     350:obj:`ContextField("attrX", DomainContextHandler.Required)` (you should 
     351appreciate the shortcurt, right?). But see this monster from widget "Select 
    353352Attributes" (file OWDataDomain.py):: 
    354353 
     
    366365 
    367366 
    368 :obj:`ContextField`'s constructor gets the name and flags and a list of arguments that are written directly into the object instance. To follow the example, recall what Select Attributes looks like: it allows you to select a subset of attributes, the class attribute and the meta attributes that you want to use; the attributes in the corresponding three list boxes are stored in the widget's variables :obj:`chosenAttributes`, :obj:`classAttribute` and :obj:`metaAttributes` respectively. When the user selects some attributes in any of these boxes, the selection is stored in :obj:`selectedChosen`, :obj:`selectedClass` and <cose>selectedMeta</cose>. The remaining attributes - those that are not in any of these three list boxes - are in the leftover listbox on the left-hand side of the widget, and the content of the box is stored in the widget's variable :obj:`inputAttributes`. 
    369  
    370 The above definition tells that the context needs to store the contents of the three list boxes by specifying the corresponding variables; the list of attributes is given as the name of the field and the list of selected attributes is in the optional named attribute :obj:`selected`. By :obj:`reservoir` we told the context handler that the attributes are taken from :obj:`inputAttributes`. So, when a context is retrieved, all the attributes that are not in any of the three list boxes are put into :obj:`inputAttributes`. 
    371  
    372 Why the mess? Couldn't we just store :obj:`inputAttributes` as the fourth list box? Imagine that the user first loads the data with attributes A, B, C, D, E and F, puts A, B, C in chosen and D in class. E and F are left in :obj:`inputAttributes`. Now she loads another data which has attributes A, B, C, D, E, and G. The contexts should match (the new data has all the attributes we need), but :obj:`inputAttributes` should now contain E and G, not E and F, since F doesn't exist any more, while G needs to be made available. 
    373  
    374 You can use :obj:`ContextField` (instead of tuples and strings) for declaring any fields, but you will usually need them only for lists or, maybe, some complicated future controls. 
     367:obj:`ContextField`'s constructor gets the name and flags and a list of 
     368arguments that are written directly into the object instance. To follow the 
     369example, recall what Select Attributes looks like: it allows you to select a 
     370subset of attributes, the class attribute and the meta attributes that you 
     371want to use; the attributes in the corresponding three list boxes are stored 
     372in the widget's variables :obj:`chosenAttributes`, :obj:`classAttribute` 
     373and :obj:`metaAttributes` respectively. When the user selects some attributes 
     374in any of these boxes, the selection is stored in :obj:`selectedChosen`, 
     375:obj:`selectedClass` and :obj:`selectedMeta`. The remaining attributes 
     376- those that are not in any of these three list boxes - are in the leftover 
     377listbox on the left-hand side of the widget, and the content of the box is 
     378stored in the widget's variable :obj:`inputAttributes`. 
     379 
     380The above definition tells that the context needs to store the contents of 
     381the three list boxes by specifying the corresponding variables; the list of 
     382attributes is given as the name of the field and the list of selected 
     383attributes is in the optional named attribute :obj:`selected`. By 
     384:obj:`reservoir` we told the context handler that the attributes are taken 
     385from :obj:`inputAttributes`. So, when a context is retrieved, all the 
     386attributes that are not in any of the three list boxes are put into 
     387:obj:`inputAttributes`. 
     388 
     389Why the mess? Couldn't we just store :obj:`inputAttributes` as the fourth 
     390list box? Imagine that the user first loads the data with attributes A, B, 
     391C, D, E and F, puts A, B, C in chosen and D in class. E and F are left in 
     392:obj:`inputAttributes`. Now she loads another data which has attributes A, 
     393B, C, D, E, and G. The contexts should match (the new data has all the 
     394attributes we need), but :obj:`inputAttributes` should now contain E and 
     395G, not E and F, since F doesn't exist any more, while G needs to be made 
     396available. 
     397 
     398You can use :obj:`ContextField` (instead of tuples and strings) for 
     399declaring any fields, but you will usually need them only for lists or, 
     400maybe, some complicated future controls. 
    375401 
    376402 
Note: See TracChangeset for help on using the changeset viewer.