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:
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.
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)
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:
Tim wrote: …and that's enough to persuade me to look for an
alternative way to add custom epics-aware widgets.
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.
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.
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.