Argonne National Laboratory

Experimental Physics and
Industrial Control System

2012  2013  2014  <20152016  2017  Index 2012  2013  2014  <20152016  2017 
<== Date ==> <== Thread ==>

Subject: epicsqt and caQtDM
From: Andrew Rhyder <>
To: "Mooney, Tim M." <>, Zenon Szalata <>, "Mezger Anton Christian (PSI)" <>, "Williams Jr., Ernest L." <>
Cc: "" <>, "Shankar, Murali" <>, "Babbitt, Alisha" <>
Date: Tue, 24 Mar 2015 11:53:20 +0000

Hi All

This is a reply to comments in several emails over the last day or so…

Zen wrote: My approach is to use epicsQT widgets only when Channel Access is needed, for anything else I use Qt widgets.  Also, I did not find the QEGui display manager useful, since I prefer to create well defined standalone applications.

This is a completely valid way to use epicsqt. It was designed from day one to be used in one of following ways:

1) Code free. Layout GUIs using Qt’s Designer, view them in QEGui. A lot of work has gone into QEGui and the framework in general over the past year to also allow the creation of custom menu bars and toolbars, user levels, and configuration save and restore, to create the look and feel of a custom application, if required, without writing any application code.

2) Code rich. (Zen’s choice) Write your own application and use what you want to from the framework, including:

a.  Use the epicsqt widgets, as they are, within your code as you would widgets from any widget set. You are not limited to epicsqt widgets of course.

b.  Use the data objects within the epicsqt framework to source CA data in a Qt friendly way into your own code. For example, create a QCaString object, give it a PV and start getting a stream of Qt signals containing QString data (with all relevant meta data available if required)

c.  Use the epicsqt framework to add functionality currently available in QEGui to your own application to interact with epicsqt widgets. For example, receive log messages from epicsqt widgets you have created, manage user levels, respond to requests from widgets such as epicsqt push buttons, or participate in the epicsqt configuration/save restore mechanism.

Another option (which can then be applied to either of the above modes) is to create your own widgets (in your own Qt plugin project) using the epicsqt framework.

This can be achieved in the following ways:

1) Using an epicsqt widget as a base class.

2) Using epicsqt widgets (and any other widgets) as components within your own composite widget.

3) Using the public functionality from the epicsqt library to write your own widget that behaves like an epicqt widget. Using this method you can write a widget and use the epicsqt framework to manage what you don’t want to, such as epics data management, connections and disconnections, context menus, copy and paste, widget message logging, and widget participation in the epicsqt configuration save/restore system. To put this in perspective, the epicsqt CA aware label widget QELabel is less than 250 lines of code (half of which are comments). Most of its functionality is derived from its QLabel base class and support from public classes in the epicsqt framework.

Tim wrote:and that's enough to persuade me to look for an alternative way to add custom epics-aware widgets.

None of the above options for creating new widgets involve modifying the epicsqt framework, so new releases of epicsqt should just require a rebuild of your own widget plugin project. I say ‘should’ but Zen will testify that we have occasionally had to correct a mistake introduced in a release that has affected his code base. By the way, building your own widget plugin library is easy and well supported in the Qt documentation.

Zen wrote: Now, my concern is that should epicsQT and caQtDM merge into one package, then all my epicsQT based application would stop working. But perhaps this kind of merger is not what is being contemplated.

Combining epicsqt and caQtDM does not need to include merging the packages. Qt loves working with multiple widget sets from different vendors. Where possible, however, our widget sets should demonstrate common behavior, have familiar property sets and context menu options, and would benefit from sharing common code for identical functionality. Possibly the most significant aspect they should share is a common data system, although this actually has little, if any material effect on the use of the widgets. No matter how much we draw these widget sets together, I would anticipate they would remain separate widget plugin libraries.



Navigate by Date:
Prev: RE: EPICS CA Interface for caQtDM and epicsqt Mezger Anton Christian (PSI)
Next: QEForm Zenon Szalata
Index: 2012  2013  2014  <20152016  2017 
Navigate by Thread:
Prev: caQtDM w/QT5 gives ==> libGL error: failed to load driver: nouveau Williams Jr., Ernest L.
Next: QEForm Zenon Szalata
Index: 2012  2013  2014  <20152016  2017 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·