g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

<20122013  2014  Index <20122013  2014 
<== Date ==> <== Thread ==>

Subject: Survey comments
From: Andrew Rhyder <Andrew.Rhyder@synchrotron.org.au>
To: "qti-talk@aps.anl.gov" <qti-talk@aps.anl.gov>
Date: Sun, 3 Jun 2012 18:32:22 +1000
Hi all

A lot of good Qt development work was presented at the last EPICS conference and I would like to see the results of that development effort magnified by migrating as much as possible towards a common Qt framework. Since the conference the results of the Qt survey set up by Andrew Johnson have been accumulating and I have been wondering where now from here. 
Developers can use each other’s widget sets right now, but you will need to deal with problems such as disparate management of alarm and status, multiple mechanisms for accessing CA data, limited integration between widgets, inconsistent property sets and property names to name a few issues. These issues, however, don’t all have to be addressed at once for a common toolkit to start to emerge. These issues also vary in scale. Some are probably simple, such as consistent property names, but I see one significant issue: harmonising data access. One reason for the significance of this is the implications that the different approaches used so far has had to application development. Compare the following:

•	The Australian Synchrotron’s EPICS Qt relies on widgets that manage their own data needs (albeit using common data classes). Along with GUI support widgets such as GUI launch buttons this feature enables code free GUI development with Qt Designer and a light weight GUI display application. Also, a coded application can create EPICS Qt widgets with no Channel Access related code overhead to manage their data needs.

•	PSI’s Cafe based GUI systems expect the application to provide sophisticated management of the relationship between the data system and the user interface components and provide Cafe classes to support that expectation. (apologies to PSI for any inaccuracy)

•	Future Qt applications will require an EPICS version 4 data interface.

I hope a solution will be developed that satisfies all needs. For example, EPICS Qt widgets could establish their own data sources but not if the application decided it was going to manage the widget’s data needs.
Any current thoughts on how to consolidate the work of the EPICS community and move forward need to take into account the goals and ideas seen as important in Andrew’s survey. As a response to the survey I thought I would go through each item and consider how our work at the Australian Synchrotron could support the item. They are generally in the order of most important to least, except where a few similar items have been grouped. As I said, my comments relate to how the EPICS Qt framework does, or could, support the item. If you think this is self promotion, well yes – I think the EPICS Qt framework has a lot of potential and could be part of a valid solution for many of the items. I would, however, encourage not only response to my input, but alternative solutions.

1.	Default installation should support C++ and python development

We will be working on a python wrapper for EPICS Qt soon – (probably using SWIG?)


2.	Live EPICS aware widgets when creating UIs with Qts Designer.

This is the default behaviour of EPICS Qt. Continued support of this is desirable, but this mode of operation needs to be compatible with allowing applications full control over the connection between the widgets and the data sources. While EPICS Qt currently has good separation between the GUI and data classes, and the data classes are available to non GUI applications, an application cannot interpose itself between the data system and the widgets. I see a need to change EPICS Qt so that an application can define the data source / widget relationship.


3.	StripTool rewritten using Qt
   and
Should include a common Qt 'plot' widget (maybe based on pyqtgraph, matplotlib, gnuplot, qwt, others)

EPICS Qt already has a basic qwt based strip chart widget (QCaPlot). We are writing a more comprehensive strip chart widget (also based on qwt) that will include backfilling from a traditional Channel Access archiver (in the first instance), among other enhancements.


4.	Adapter classes to make it easy to use epics PVs with any Qt application reducing the need for custom epics-aware widgets
The data classes that support EPICS Qt widgets are useable directly within an application where appropriate. Design of EPICS aware widgets is, however, simplified with EPICS Qt as all EPICS Qt widgets are based on a common set of support classes which sink and source data as Qt signals and slots, format data, manage PV names in tool tips, support drag and drop, manage message logging, etc.


5.	Use Qt Designer as the display editor to save development effort

Qt Designer is a primary GUI design tool for EPICS Qt. Qt Designer can be used to develop GUI systems without any coding and using live widgets.


6.	Read and display EDM files
    and
Converter for edm files to Qt
    and
Provide a framework to embed medm/edm display in Qt GUI
    and
A display manager/editor that can read MEDM files
    and
Compatibility with older display managers is not needed (low scoring item)

Together the first four of these items, along with the low score of the fifth indicate a strong need for a Qt based MEDM / EDM replacement.
While there are a couple of MEDM/EDM to Qt tools available already, I would like to see a solution where the resultant Qt .ui files do not have to be displayed using a specific Qt MEDM/EDM viewer, but can be used by the same Qt GUI display tools used for ongoing development unrelated to MEDM / ADM conversions.
EPICS Qt does not yet include an EDM or MEDM converter and I have been concerned about introducing outdated behaviour into EPICS Qt widgets to make conversion straight forward. A solution to this might be to develop a set of backward looking widgets which would support simple and accurate EDM and MEDM conversion to .ui Qt user interface files. These .ui files can be used beside any other EPICS Qt user interface file.
I would hope such a widget set and conversion code could be based on existing MEDM/EDM – Qt conversion tools


7.	Support widgets that can be coded easily in Python

(assuming this point relates to allowing python to use Qt widgets...) Initial investigation for wrapping EPICS Qt widgets for use in Python has been very promising, but has indicated there should be some changes to interfaces to make them more Python friendly.


8.	Code free GUI development - Design GUIs using Qt's Designer only. Then display GUIs using generic applications.

EPICS Qt is designed to allow GUI systems to be produced using only Qt Designer. The EPICS Qt widget set includes GUI control widgets as well as data access widgets. This allows rich GUI behaviour to be created in Qt Designer and then presented using a single simple generic application (ASgui) that does little more than display .ui files. The GUI control widgets manage sub forms, user level selection, logging, buttons for launching other GUI windows and widget interactions within a form. OK, the name ASgui should change to something less parochial...


9.	Allow me to embed Python code in a display

Not sure I understand the point. Where’s the Python expert please – It ain’t me.


10.	Provide examples and sample code (ex: how to integrate epics-aware widget, with non epics aware widget in the same display)

There are a few sample displays for EPICS Qt but it could do with more. Regarding the example given, there is no work required to mix EPICS Qt widgets and other widgets in the same display. Mixed use that includes other families of EPICS aware widgets also works fine, but some other EPICS aware widget families require action on the part of the application loading the user interface file to set up and activate the widgets.


11.	Coded mostly in C++ for performance
    and
I need the fastest display update rate that is possible
    and
Ease of code development is more important than the display update rate

EPICS Qt is in C++ (any one surprised at that?)
I don’t think the aspects of EPICS Qt that make development easy, such as a code free GUI development model option and an easily extendible widget set, compromise performance. Discussion welcome.


12.	Simple deployment method (maybe through yum, apt-get, other). No compilation needed

EPICS Qt isn’t yet set up to be deployed by a package management utility. With EPICS Qt installed GUI deployment only involves the deployment of .ui user interface files. The EPICS Qt GUI presenter itself consists of one executable image file and one library. Of course the EPICS libraries must be installed.


13.	A Qt-based replacement for ALH

Written as a Qt widget it could be used as part of a general EPICS Qt widgt set, or wrapped in its own application to run stand alone. Any volunteers?


14.	The display editor should have a "Run" button

EPICS Qt widgets are live during construction, and interactive when displayed in QT Designer’s preview mode.


15.	Create library to decouple UI updates from control system updates (a la PVManager).
    and
Design it to support PV Access (V4) as well as Channel Access (V3)

As mentioned earlier, while EPICS Qt currently has good separation between the GUI and data classes, and the data classes are available to non GUI applications, an application cannot interpose any decoupling mechanism between the data system and the widgets.
The ability to provide such decoupling is seen as important by several Qt developers and I want to move EPICS Qt in this direction, while retaining the ability for widgets to find their own data when running within an application which is not aware of them, such as Qt Designer and the EPICS Qt GUI presenter ASgui.
While we are providing the decoupling, let’s make the PV access V4 compatible. A Qt based EPICS V4 data layer is a foundational component for EPICS V4.


16.	Allow me to embed JavaScript code in a display

Roll on Qt version 5. You get it for free.


17.	Do not have any epics library requirement (CA lib is built in)

This would solve a few run time problems I have seen where people have built EPICS Qt, but not set up references to, or built EPICS properly. Are there any precedents for this?


18.	Provide a framework to integrate Qt StripTool, QT ALH, etc in our own QApplication.

EPICS Qt widgets (and widgets from other frameworks for that matter) can be used together. Either within a .ui file, or coded in a custom Qt application. Have I understood the item?


19.	Build as much of the engine as possible in HTML5 using QWebView for future proofing

Unqualified to comment...


20.	Provide sample code for touch interface (QML/QtQuick support and sample code)

Unqualified to comment...


21.	A common display-list file format with CSS/BOY

Some thought should be given to areas where CSS/BOY and Qt solutions might meet.


22.	Be able to write files that MEDM can read

An unnecessary rearguard action in my opinion. Any MEDM development can be done with MEDM tools for as long as MEDM is needed

Regards
Andrew Rhyder
Australian Synchrotron<br>This message and any attachments may contain proprietary or confidential information. If you are not the intended recipient or you received the message in error, you must not use, copy or distribute the message. Please notify the sender immediately and destroy the original message. Thank you.

Navigate by Date:
Prev: Re: Welcome & Survey Emmanuel Mayssat
Next: Survey comments So, Sung-Leung
Index: <20122013  2014 
Navigate by Thread:
Prev: Re: Welcome & Survey Emmanuel Mayssat
Next: Survey comments So, Sung-Leung
Index: <20122013  2014 
ANJ, 04 Jun 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·