Slide: 1

Bliss GUI FrameworkBliss GUI Framework

Quick introduction : concepts & practical examples

Presented by Matias Guijarro BLISS group

Bliss FrameworkM. Guijarro - 15/Jan/2007

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

Written in Python, graphical toolkit : Trolltech Qt

• to free GUI programming from data sources and controllers (spec, taco, tango, etc.)

Fundamental principles

• “Model-View-Controller” architecture

• “Bricks” instead of widgets as building blocks

• GUI Editor hides layout complexity for rapid GUI building

What is the Bliss GUI Framework ? 2/2

Application

Bricks library

Abstraction layer

Control software (spec, taco, tango, etc.)

BlissFramework

project

hardware

Scope of the project

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

The Hardware Repository ≡ abstraction layer

• part of the Bliss GUI Framework

Bliss Framework

hardware, spec, device servers

abstraction layer

GUI user

Beamline GUI application

GUI Bricks

• provides objects representing beamline control devices

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

Hardware Repository

module

Hardware Objects pool

Motor Shutter Slit

MirrorThermo-meterXML

The Hardware Repository manages the pool of Hardware Objects

Using “bricks” as building blocks

A Framework GUI application is made of “cemented” bricks

All bricks derive from the same base class : BlissWidget

A brick has a graphical representation

Bricks can communicate between them

Bricks have a behavior

A brick holds a set of properties for configuration

Beamline GUI

The Framework provide services for the bricks• application • properties persistance• layout management• run modes• access to Hardware Repository

Practical exercise 1 : let’s install the Framework on a beamline

Packages are available in the Bliss Installer

• Core :

• 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

1/2

• 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

Practical exercise 1 : let’s install the Framework on a beamline

Configuring Hardware Repository server

2/2

• 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

/users/blissadm/local/daemon/config/device_servers :

[HardwareRepositoryServer]

/users/blissadm/local/HardwareRepository

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

basil:~/local/HardwareRepository/oh1 % lsatt1.xml lambda.xml mtb.xml pshg.xml roll.xml ssu.xml torh.xmlatt2.xml m2.xml mtf.xml psho.xml ssb.xml ssvg.xml tory.xmlcalo.xml mben.xml mtt.xml psu.xml ssd.xml ssvo.xml u35.xmldin.xml mbv1.xml psb.xml psvg.xml ssf.xml tor01f.xml wbv.xmldm2in.xml mbv2.xml psd.xml psvo.xml sshg.xml tor02b.xml yaw.xmlenergy.xml mono.xml psf.xml push111.xml ssho.xml tor03b.xmlbasil:~/local/HardwareRepository/oh1 %

Practical exercise 2 : let’s create a new GUI application

use the newGUI script

1/3

• it generates an empty GUI application file

• it creates a startup script

Practical exercise 2 : let’s create a new GUI application

Today there are more than 60 bricks

2/3

• 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

x2

x2

Practical exercise 2 : let’s create a new GUI application 3/3

After setting properties, here is the result

Practical exercise 3 : let’s write a (very) simple brick

The brick will be able to display a motor position and status

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)

• At the beginning, just code the appearance of the brick

• Then save the file with the same name as the brick class : ExampleBrick.py in a Bricks directory

1/3

• You can already see the new brick in the GUI Editor by clicking on the Refresh button

Practical exercise : let’s write a (very) simple brick

add a “mnemonic” property to the brick 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

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

• 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

2/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])

3/3

the final step is to test the brick into a GUI

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

ID21 mxCuBE ID13 / Microfocus

Ways of improvement

• better Hardware Repository• making interface to spec for small GUIs even simpler• more possibilities for windows, layout, menu bars, etc.• documentation

Already existing documentation (don’t laugh) Bliss Framework Startup Guide

http://www.esrf.fr/computing/bliss/guides/gui/framework/FrameworkInstall.pdf

Bricks documentation

this talk…

http://blissdb/bricks

Thanks for your attention

Any questions ?