Bliss GUI Framework Quick introduction : concepts & practical examples

1. Bliss GUI FrameworkQuick introduction : concepts & practical examples Presented by Matias Guijarro BLISS group

2. What is the Bliss GUI Framework ? 1/2 • Project started in 2003 • Main goals • to provide libraries and tools to develop Graphical User Interfaces on beamlines • to emphasise on code reusability and GUI standardization • to free GUI programming from data sources and controllers (spec, taco, tango, etc.) • Written in Python, graphical toolkit : Trolltech Qt • Fundamental principles • “Model-View-Controller” architecture • “Bricks” instead of widgets as building blocks • GUI Editor hides layout complexity for rapid GUI building

3. What is the Bliss GUI Framework ? 2/2 • Scope of the project Application Bliss Framework project Bricks library Abstraction layer Control software (spec, taco, tango, etc.) hardware

4. GUI user Abstraction from Hardware and Control Software • Model-View-Controller (MVC) architecture • view is separated from model • this ensures GUI code does not get mixed with beamline control Bliss Framework abstraction layer Beamline GUI application GUI Bricks hardware, spec, device servers • The Hardware Repository ≡ abstraction layer • part of the Bliss GUI Framework • provides objects representing beamline control devices

5. Hardware Objects pool Shutter Slit Motor Mirror Thermo -meter Hardware Repository • The Hardware Repository holds the description of the devices, equipments and procedures of a beamline in a database • The database is a set of XML files • Each file represents at least one Hardware Object • The Hardware Repository manages the pool of Hardware Objects Hardware Repository module XML

6. Using “bricks” as building blocks • A Framework GUI application is made of “cemented” bricks • All bricks derive from the same base class : BlissWidget Bricks can communicate between them Beamline GUI Bricks have a behavior A brick holds a set of properties for configuration A brick has a graphical representation • The Framework provide services for the bricks • application • properties persistance • layout management • run modes • access to Hardware Repository

7. 1/2 Practical exercise 1 : let’s install the Framework on a beamline • Packages are available in the Bliss Installer • applications/control/Framework/BlissFramework Core : the base components • applications/control/Framework/Bricks : bricks of the standard library ; each brick has its own package • applications/control/Framework/Icons : icons library • control/HWR/HardwareRepositoryServer : one Hardware Repository server is needed per beamline • control/HWR/HardwareRepositoryClient • control/HWR/Object : Hardware Objects library, each Hardware Object has its own package • Core :

8. /users/blissadm/local/daemon/config/device_servers : [HardwareRepositoryServer] /users/blissadm/local/HardwareRepository basil:~/local/HardwareRepository/oh1 % ls att1.xml lambda.xml mtb.xml pshg.xml roll.xml ssu.xml torh.xml att2.xml m2.xml mtf.xml psho.xml ssb.xml ssvg.xml tory.xml calo.xml mben.xml mtt.xml psu.xml ssd.xml ssvo.xml u35.xml din.xml mbv1.xml psb.xml psvg.xml ssf.xml tor01f.xml wbv.xml dm2in.xml mbv2.xml psd.xml psvo.xml sshg.xml tor02b.xml yaw.xml energy.xml mono.xml psf.xml push111.xml ssho.xml tor03b.xml basil:~/local/HardwareRepository/oh1 % 2/2 Practical exercise 1 : let’s install the Framework on a beamline • Configuring Hardware Repository server • needs one parameter : path to the xml files • optional parameter : name of the server (“hwr” by default) • The Hardware Repository server should start with the main beamline control computer : use the bliss_dserver script • Once it is running, you can fill the Hardware Repository directory with xml files describing Hardware Objects • the genSpecXML tool can generate automatically xml files for a Spec version basil:~ % genSpecXML basil oh1 ~/local/HardwareRepository

9. 1/3 Practical exercise 2 : let’s create a new GUI application • use the newGUI script • it generates an empty GUI application file • it creates a startup script

10. x2 x2 2/3 Practical exercise 2 : let’s create a new GUI application • Today there are more than 60 bricks • approximatively 75% percent are for general use • others are beamline-specific (MX, BM29, ID21, ID13, etc.) • Building a GUI application using the standard bricks is easy • 6 clicks example

11. Practical exercise 2 : let’s create a new GUI application 3/3 • After setting properties, here is the result

12. 1/3 Practical exercise 3 : let’s write a (very) simple brick • The brick will be able to display a motor position and status • At the beginning, just code the appearance of the brick from BlissFramework.BaseComponents import BlissWidget from qt import * class ExampleBrick(BlissWidget): def __init__(self, *args): BlissWidget.__init__(self, *args) self.motor_frame = QVGroupBox(“Motor name here”, self) hbox = QHBox(self.motor_frame) QLabel(“Motor position : “, hbox) self.motor_pos = QLabel(hbox) QVBoxLayout(self) self.layout().addWidget(self.motor_frame) self.setSizePolicy(QSizePolicy.MinimumExpanding, QSizePolicy.Fixed) • Then save the file with the same name as the brick class : ExampleBrick.py in a Bricks directory • You can already see the new brick in the GUI Editor by clicking on the Refresh button

13. 2/3 Practical exercise : let’s write a (very) simple brick • add a “mnemonic” property to the brick from BlissFramework.BaseComponents import BlissWidget from qt import * class ExampleBrick(BlissWidget): def __init__(self, *args): BlissWidget.__init__(self, *args) self.addProperty(“mnemonic”, “string”) self.motor_frame = QVGroupBox(“Motor name here”, self) hbox = QHBox(self.motor_frame) QLabel(“Motor position : “, hbox) self.motor_pos = QLabel(hbox) QVBoxLayout(self) self.layout().addWidget(self.motor_frame) self.setSizePolicy(QSizePolicy.MinimumExpanding, QSizePolicy.Fixed) def propertyChanged(self, property, old_value, new_value): if property==“mnemonic”: self.motor = self.getHardwareObject(new_value) if self.motor is not None: self.connect(self.motor, “positionChanged”, self.motor_pos_changed) self.connect(self.motor, “stateChanged”, self.motor_state_changed) self.motor_frame.setTitle("Motor name : %s" % self.motor.username) • 2nd step is to add the brick properties • when the property changes, get the Hardware Object (which should be a motor in this case) • create connections between the Hardware Object and the brick • In this example we just need a “mnemonic” property that will contain a reference to the Motor Hardware Object • When the property changes, the brick is connected to the Motor Hardware Object

14. 3/3 Practical exercise : let’s write a (very) simple brick • now we just need to write the two missing methods • motor_pos_changed : called when “positionChanged” signal is emitted by Motor Hardware Object • motor_state_changed : called when “stateChanged” signal is emitted by Motor Hardware Object def motor_pos_changed(self, pos): self.motor_pos.setText(str(pos)) def motor_state_changed(self, state): bg_color = self.colorGroup().background() color = [bg_color, bg_color, Qt.green, Qt.yellow, Qt.yellow, Qt.red, bg_color] self.motor_pos.setPaletteBackgroundColor(color[state]) • the final step is to test the brick into a GUI

16. Results already obtained with the Framework • at the beginning of the project, high demand for GUI on MX beamlines ; recently, Framework-based GUIs are being created for other beamlines mxCuBE ID13 / Microfocus ID21 • Ways of improvement • better Hardware Repository • making interface to spec for small GUIs even simpler • more possibilities for windows, layout, menu bars, etc. • documentation

17. Already existing documentation (don’t laugh) • Bliss Framework Startup Guide http://www.esrf.fr/computing/bliss/guides/gui/framework/FrameworkInstall.pdf • Bricks documentation http://blissdb/bricks • this talk…

18. Thanks for your attention  Any questions ?