Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: EPICS CA Interface for caQtDM and epicsqt
From: "Mooney, Tim M." <mooney@aps.anl.gov>
To: Zenon Szalata <zms@slac.stanford.edu>, Andrew Rhyder <Andrew.Rhyder@synchrotron.org.au>, "Mezger Anton Christian (PSI)" <anton.mezger@psi.ch>, "Williams Jr., Ernest L." <ernesto@slac.stanford.edu>
Cc: "qti-talk@aps.anl.gov" <qti-talk@aps.anl.gov>, "Shankar, Murali" <mshankar@slac.stanford.edu>, "Babbitt, Alisha" <ababbitt@slac.stanford.edu>
Date: Mon, 23 Mar 2015 21:18:01 +0000
For me, the advantage of having both caQtDM and epicsqt is that I can have a nearly exact replacement for MEDM, and also add custom widgets in an easily maintainable way.  At least, I hope this is or will be the case.  Here's why:

I wrote a custom widget for caQtDM (to display 2D raster-scan data as they are acquired), and added it to several versions of caQtDM as they became available.  It was great; I could never have done this with MEDM.  Now, I don't want to bother Anton Mezger with any additional maintenence that my widget might require, and it isn't ready for general distribution in any case.  But adding a custom widget to each new release of caQtDM is a complicated and error prone process, involving edits to nine sections of six caQtDM files, in addition to adding source files for the custom widget, and maybe editing them for compatibility with the new version of caQtDM.  It's not going to be exactly the same edits every time, of course, so some study is required in advance.  Every time.  I did it three times, and that's enough to persuade me to look for an alternative way to add custom epics-aware widgets.

What I would prefer is to be able to maintain my custom widget in my own repository, and use qt's native ability to include widgets from different sources into an application.  This is what I think epicsqt's widget model will enable me to do, though I'm not yet far enough up the learning curve to know that it will work or how to do it.

Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab


________________________________________
From: qti-talk-bounces@aps.anl.gov [qti-talk-bounces@aps.anl.gov] on behalf of Zenon Szalata [zms@slac.stanford.edu]
Sent: Monday, March 23, 2015 2:07 PM
To: Andrew Rhyder; Mezger Anton Christian       (PSI); Williams Jr., Ernest L.
Cc: qti-talk@aps.anl.gov; Shankar,      Murali; Babbitt,        Alisha
Subject: Re: EPICS CA Interface for caQtDM and epicsqt

Hi All,
I have been using epicsQT for a number of years.  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.
The related display I implement with a Qt push button and a little C++
code around, which works perfectly well for me.  I am using QEForm
widget the way I would use Embedded Window widget in EDM.
I have not looked at caQtDM, since I became aware of it some time after
I started using epicsQT.  I wonder what is the advantage of combining
epicsQT and caQtDM?  Perhaps caQtDM has some useful widgets which might
be missing in epicsQT?  In my opinion, epicsQT is very well written and
reasonably complete and yet when I find it lacking, I just subclass my
own widget either from a Qt widget, QWT widget, or from an epicsQT
widget, to get what I need.
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.
Anyway, my 2 cents,
Zen

On 03/23/15 04:54, Andrew Rhyder wrote:
> Hi Anton,
>
> You are right, related display functionality is still display manager-centric.
>
> I have some thoughts on improving widgets from both widget sets so associated displays requests work well regardless of the display manager they are running within. Also some thoughts on the justification for keeping the current different behavior of each display manager.
>
> Improvements:
> =============
>
> Cross pollination would be good.
> The epicsqt widgets could use the caQtDM library to request associated displays when running within the caQtDM display manager. The epicsqt framework already uses caQtDM library functions when built with caQtDM and this would just build on that. Epicsqt widgets also already know if there is an application responding to their requests for associated displays (and even launch their own basic related display if there is no application support for related displays). This could be extended to ensure both display managers are supported by epicsqt widgets.
>
> Considering the other way round, the epicsqt framework display manager 'QEGui' will respond to requests to launch related displays from any widgets (including caQtDM widgets) that use the launch mechanism provided by the epicsqt framework library.
>
> Different display manager behavior:
> ====================================
>
> An accurate medm conversion tool should accurately mimic medm associated displays. A task that caQtDM does very well. The epicsqt framework can create related displays medm style, but does not target medm conversion and can also launch related displays as a tab within the current window, as a new main window, or as a dock in the current window. Also, these options are available from custom application menu bars and toolbars within QEGui as well as from epicsqt widgets (QEPushButtons). This functionality is intended to allow for the development of a suite of .ui files that run within QEGui and behave like a single modern custom application, with application specific menu bars and tool bars, not like a set of medm displays running with a display manager. If I have undersold caQtDM related displays, Anton, please correct me, but I think having a pair of display managers that handle both medm simulation, and modern application expectations is a plus.
>
> Regards
> Andrew
> ________________________________________
> From: Mezger Anton Christian (PSI) [anton.mezger@psi.ch]
> Sent: Tuesday, 17 March 2015 18:35
> To: Williams Jr., Ernest L.; Andrew Rhyder
> Cc: Babbitt, Alisha; Szalata, Zenon M.; Shankar, Murali; qti-talk@aps.anl.gov
> Subject: RE: EPICS CA Interface for caQtDM and epicsqt
>
> Dear All,
>
> caQtDM and epicsqt have a different philosophy concerning the data io. caQtDM uses pure graphics objects that are populated by the caQtDM viewer. Epicsqt uses epics aware widgets, i.e epics is sitting underneath the widgets. Epicqt can view therefore the variables in the designer and the graphical widgets of caQtDM cannot. The two packages can be concurrent, while they consist of plugins for the designer. The viewer of both packages can thus use both widget sets. It is already some time ago that the integration of both widgets took place. It is however not impossible that after a year, things diverged. I think that related displays are not (well?) supported by the epicsqt viewer (Andrew, please correct me). If you use this feature of caQtDM, then use the caQtDM viewer and plugin the epicsqt widgets.
>
> I hope this explanation helps you.
>
> Best regards
>
> Anton
>
> -----Original Message-----
> From: Williams Jr., Ernest L. [mailto:ernesto@slac.stanford.edu]
> Sent: Montag, 16. März 2015 21:08
> To: Mezger Anton Christian (PSI); Andrew.Rhyder@synchrotron.org.au
> Cc: Babbitt, Alisha; Szalata, Zenon M.; Shankar, Murali; Williams Jr., Ernest L.; qti-talk@aps.anl.gov
> Subject: EPICS CA Interface for caQtDM and epicsqt
>
> Hi Guys,
>
> Can you tell us a bit about the Channel Access interface you have for your package?
> Is it the same for both  "caQtDM" and "epicsqt" ?
> If not, how is it different?
>
>
> Thanks in advance for your time.
>
>
> Cheers,
> Ernest





Replies:
RE: EPICS CA Interface for caQtDM and epicsqt Williams Jr., Ernest L.
References:
EPICS CA Interface for caQtDM and epicsqt Williams Jr., Ernest L.
RE: EPICS CA Interface for caQtDM and epicsqt Mezger Anton Christian (PSI)
RE: EPICS CA Interface for caQtDM and epicsqt Andrew Rhyder
Re: EPICS CA Interface for caQtDM and epicsqt Zenon Szalata

Navigate by Date:
Prev: Re: EPICS CA Interface for caQtDM and epicsqt Zenon Szalata
Next: RE: EPICS CA Interface for caQtDM and epicsqt Williams Jr., Ernest L.
Index: 2012  2013  2014  <20152016  2017  2018  2019 
Navigate by Thread:
Prev: Re: EPICS CA Interface for caQtDM and epicsqt Zenon Szalata
Next: RE: EPICS CA Interface for caQtDM and epicsqt Williams Jr., Ernest L.
Index: 2012  2013  2014  <20152016  2017  2018  2019 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·