Orange Widgets wrap Orange's classes in an easy to use interactive graphical interface. As such, much of their code is about the interface, event control and maintaining the state of the GUI controls.
In the spirit of constructive laziness, we wrote a library using which a single line of code can construct a check box, line edit or a combo, make it being synchronized with a Python object's attribute (which, by the way, gets automatically saved and retrieved when the widgets is closed and reopened), attaches a callback function to the control, make it disable or enable other controls...
Many functions that construct controls share one or more common arguments, usually in the same order. These are described here. Descriptions of individual controls will only list their specific arguments, while the arguments which are presented here will only be described in cases where they have a different meaning.
controlArea
or another box.settingsList
, so that it is automatically saved and retrieved.box
is None
, no box is drawn; if it is a string, it is also used as box's name. If box
is any other true value (such as True
:), an unlabeled box is drawn.value
argument described above) it may trigger a cycle; a simple trick to avoid this is shown in the description of listBox function.True
and False
or 1 and 0, respectively. (Remember this as "vertical" being the usual order of controls in the widgets, so vertical is "true".)OWGUI.separator
. addSpace
can also be an integer specifying the height of the added space.This section describes the OWGUI wrappers for controls like check boxes, buttons and similar. All the important Qt's controls can be constructed through this functions. You should always use them instead of calling Qt directly, not only because they are convenient, but also because they set up a lot of things that happen in behind.
Check box, a wrapper around QCheckBox, adding a label, box, tooltip, callback and synchronization with the designated widget's attribute.
checkBox(widget, master, value, label[, box, tooltip, callback, disabled, labelWidth, disables])
disables
, e.g. disables=[someOtherCheckBox, someLineEdit]
. If the other control should be disabled when the checkbox is checked, do it like this: disables=[someOtherCheckBox, (-1, someLineEdit)]
- now someOtherCheckBox
will be enabled when this check box is checked, while someLineEdit
will be enabled when the check box is unchecked.labelWidth
can be used to align this widget with others.In the following code we define two check boxes. The second one disables (enables) the box with the spin box, depending on the state of the checkbox.
|
![]() |
Edit box, a wrapper around QLineEdit.
lineEdit(widget, master, value[, label, labelWidth, orientation, box, tooltip, callback, valueType, validator, controlWidth])
|
![]() |
A wrapper around QPushButton, just to be able to define a button and its callback in a single line.
button(widget, master, label[, callback, disabled, tooltip])
OWGUI can create an individual radio button or a box of radio buttons or an individual radio button.
An individual radio button is created by radioButton
.
radioButton(widget, master, value, label[, box, tooltip, callback, addSpace])
The function provides the usual capabilities of OWGUI controls. It is though your responsibility to put it in something like a QVButtonGroup
.
A box of radio buttons is created by function radioButtonsInBox
.
radioButtonsInBox(widget, master, value, btnLabels[, box, tooltips, callback)
|
![]() |
A wrapper around QComboBox.
comboBox(widget, master, value[, box, label, labelWidth, orientation, items, tooltip, callback, sendSelectedValue, valueType, control2attributeDict, emptyString])
items
have one Orange-specific quirk: its element can be either a string, in which case it is used as a label, or a tuple, where the first element is a label name and the last is the attribute type which is used to create an icon. Most attribute lists in Orange Widgets are constructed this way.value
will be assigned the index of the selected item. Otherwise, it is assigned the currently selected item's label.value
. It is used only is sendSelectedValue
is true, and even then a label is translated only if an item with such a key is found in the dictionary; otherwise, label is written to value
as it is. value
. This is typically used when combo box's labels are attribute names and an item "(none)", which allows user to select no attribute. If we give emptyString="(none)"
, value
will be an empty string when the user selects "(none)". This is equivalent to specifying control2attributeDict = {"(none)": ""}
(and is actually implemented like that), but far more convenient.control2attributeDict
. Needed to convert Qt's QString.We shall create a widget with two combo boxes: one will contain a simple choice of three colors, while the other will let the user select an attribute or no attribute (none).
|
![]() |
The widget's snapshot on the right is a cheat: the above code leaves the bottom list box empty. To be able to fill it later on, when the widget gets some data, we stored the control (self.attrCombo
).
Say that the widget received an example table and stored it in self.data
. This is how we fill out the combo.
|
The first item is "(none)". When the user selects it, the value of chosenAttribute
is set to "", since we specified emptyString="(none)"
when initializing the combo. Next we insert items using Qt QComboBox's function insertItem
, where the first argument is a QPixmap (an icon for the corresponding attribute type) and the second is an attribute name. Finally, we set self.chosenAttribute
(and with that the selection in the combo box) to the first attribute. (For simplicity, we here left out testing whether the data contains any attribute.)
This control, which might be the most complicated control in OWGUI, is a sophisticated wrapper around QListBox. It's complexity arises from synchronization.
listBox(widget, master, value, labels[, box, tooltip, callback, selectionMode])
items
in combo box, list labels
have one Orange-specific quirk: its element can be either a string, in which case it is used as a label, or a tuple, where the first element is a label name and the second can be either an icon on an integer, representing the attribute type which is used to create an icon. Most attribute lists in Orange Widgets are constructed this way.QListWidget.SingleSelection
), multiple items (QListWidget.MultiSelection
, QListWidget.ExtendedSelection
) or nothing (QListWidget.NoSelection
).value
is automatically cast to OWGUI.ControlledList
(this is needed because the list should report any changes to the control, the list box; OWGUI.ControlledList
is like an ordinary Python list
except that it triggers synchronization with the list box at every change).
labels
is only partially synchronized with the list box: if a new list is assigning to labels
attribute, the list will change. If elements of the existing list are changed or added, the list box won't budge. You should never change the list, but always assign a new list (or reassign the same after it's changed). If the labels are stored in self.listLabels
and you write self.listLabels[1]="a new label"
, the list box won't change. To trigger the synchronization, you should continue by self.listLabels = self.listLabels
. This may seem awkward, but by our experience a list of selected items is seldom changed changed "per-item", so we were too lazy to write the annoyingly complex backward callbacks.
In first example, we will set up to list boxes, one with single and one with multiple selection. To see what is going on, we provide two labels that show the values of the corresponding attributes. Besides that, if all items in the second list box are chosen, the value of the first list box will change to red and the user will be prevented to change it from red until she deselects some of the items in the second list.
|
![]() |
Selecting the red color and not allowing any other color but red when the entire second list is selected is ensured by function checkAll
which is used as a callback for both list box. An important point not to be overlooked here is self.chosenColor != [0]
in condition here. If omitted, setting self.chosenColor
would trigger a change in the list box selection, change in the list box selection causes the callback function self.chosenColor
to be called again and ... you see where this leads.
The second example shows a construction of an attribute list. If a discrete attribute is selected, the second list box will let the user select one or more of its values.
|
![]() |
We avoided the temptation of writing self.attributes = self.chosenAttribute = self.values = self.chosenValues = []
. This would assign all attributes the same empty list and would, through self.chosenAttributes
and self.chosenValues
keep the selection in two lists synchronized (try it, it looks funny).
The second list box is filled every time the selection in the first is changed. This is done through the callback setValues
.
How does the list fill when the widget gets the data? In the above code, self.chosenAttribute = [0]
changes the selection in the first lists and causes the callback, setValues
to be called. That's how.
Spin control, a wrapper around QSpinBox.
spin(widget, master, value, min, max[, step, box, label, labelWidth, orientation, tooltip, callback, controlWidth])
Following is an excerpt of the code in the initialization part of the widget. It defines three spin boxes, where the second and third invoke the callback which sets the text in the info box.
|
![]() |
The callback for setting the info box is simple. Notice that OWGUI associates each control's state with some value, which is updated automatically on any change of the control.
|
By the way, such functions are needed only when updating the label requires more than simply inserting some attributes' values. This code becomes redundant if we use OWGUI.label
instead of QLabel
.
A wrapper around QSlider that allows user setting a numerical value between the given bounds.
hSlider(widget, master, value[, box, minValue, maxValue, step, callback, labelFormat, ticks, divideFactor])
divideFactor
.For an example of usage, see the second example in the description of labels.
Check box with spin, or, essentially, a wrapper around OWGUI.checkBox and OWGUI.spin.
checkWithSpin(widget, master, label, min, max, checked, value[, posttext, step, tooltip, checkCallback, spinCallback, labelWidth])
|
![]() |
There are two functions for constructing labels. The first is a simple wrapper around QLabel which differs only in allowing to specify a fixed width without needing an extra line. Note that unlike most other OWGUI widgets, this one does not have the argument master
.
widgetLabel(widget, label[, labelWidth])
The second is a label which can synchronize with values of master widget's attributes.
label(widget, master, label[, labelWidth])
label
is a format string following Python's syntax (see the corresponding Python documentation): the label's content is rendered as label % master.__dict__
.The following code, taken from OWPurgeDomain
, construct four labels that change whenever the value of self.removedAttrs
, self.reducedAttrs
, self.resortedAttrs
or self.classAttr
changes in the code.
|
Each label can contain any number of attributes, which can be strings (as in %(name)s
) or of any type supported by Python (e.g. %(name)5.3f
), like in the toy example below.
|
![]() |
box
is given and not false, the box will be framed. If box
is a string, it will be used for the box name (don't capitalize each word; spaces in front or after the string will be trimmed and replaced with a single space). Argument orientation
can be "vertical"
or "horizontal"
(or True
and False
, or 1
and 0
, respectively).sep
.The first box in this example widget contains three check boxes: the first enables and disables the other two, which are for this reason indented. Note that we are disabling both check boxes at once by disabling the indented box.
The second box contains only two check boxes, the first disabling the second. Note the shortcut we used - the indented check box is created on the fly.
|
![]() |
Most widgets look better if we insert some vertical space between the controls or groups of controls. A few functions have an optional argument addSpace
by which we can request such space to be added. For other occasions, we can use the following two functions.
separator(widget, width=0, height=8)
Function separator
inserts a fixed amount of space into widget
. Although the caller can specify the amount, leaving the default will help the widgets having uniform look.
rubber(widget[, orientation="vertical"])
Similar to separator, except that the size is (1, 1) and that it expands in the specified direction if the widget is expanded. Most widgets should have rubber somewhere in their controlArea
.
getAttributeIcons()
Returns a dictionary with attribute types (orange.VarTypes.Discrete
, orange.VarTypes.Continuous
, orange.VarTypes.String
, -1) as keys and colored pixmaps as values. The dictionary can be used in list and combo boxes showing attributes for easier distinguishing between attributes of different types.
Many widgets have a "Send" button (perhaps named "Apply", "Commit"...) accompanied with a check box "Send automatically", having the same effect as if the user pressed the button after each change. A well behaved widget cares to:
setStopper(master, sendButton, stopCheckbox, changedFlag, callback)
master
's attribute which tells whether there is a change which has not been sent/applied yet.sendButton
's callback.setStopper
is a trivial three lines long function which connects a few signals. Its true importance is in enforcing the correct procedure for implementing such button-check box combinations. Make sure to carefully observe and follow the example provided below.
In this somewhat lengthy example we shall write a widget for a new learning method XLearner, which will feature a few radio buttons and check boxes, and an "apply box", with an Apply button and a check box for automatic application of each change.
Except for two import statements and the construction of learner, which typically takes one line, this is a complete source. This is how much code a typical learner-wrapping widget takes.
|
![]() |
First note the two apply functions. The first, applyIf
is a conditional apply; if automatic application is enabled, the "true" apply function is called, elsewhere we just set the flag that settings have been changed since the last application. The other apply function, apply
would construct a learner and send the signal to widget's outputs, while we just show a message box. In either case, we have to clear the flag that settings have been changed.
All controls that set the learner's properties specify applyIf
as the callback function. If other code needs to be executed when the control is changed, this is OK, but at the end it needs to call applyIf
. Apply button naturally calls apply
function, which unconditionally applies the changes.
The callback function that setStopper
attaches to the check box "Apply automatically" does this and which is called at each change of the check box, verifies whether the check box has been just checked and whether any settings have been changed (settingsChanged
). If so, apply
is called. Otherwise, it does nothing. (Button Apply gets disabled, of course, but this happens using another, more general OWGUI's mechanism.)