Hi Ernest
Please excuse the late response. I have been unavailable due to a family illness.
Regarding the different CA implementations used by caQtDM and epicsqt:
Q: Can you explain the differences?
A: Yes. We just did our own thing back then. There is no reason why they should be different. We have some features we like about the way the epicsqt data system works, but these features do not mandate our own CA data system.
Q: Is there a plan to merge them into one implementation?
A: I think that would be a great idea, and I have given it some thought as follows:
It hasn't been a high priority since the two widget sets happily do their own thing at the cost of two sets of code supporting their data needs. Changes have been made to epicsqt to provide some of the same application level functionality that caQtDM does in reporting the number of connections, etc, so the behavior seen by the user is more consistent with caQtDM but integrating their data sources is still to come, and is something I would support.
Externally, epicsqt widgets appear to have a very different paradigm for sourcing data: caQtDM widgets wait for the application to start feeding them data (a very simple task done through the caQtDM library) whereas epicsqt widgets manage their own data. The difference is mostly smoke and mirrors, however. The epicsqt widgets operate like they do so they could be dropped into a .ui file and just work without any code on your part. This is irrelevant if you are using the epicsqt 'display manager' QEGui, but if you are using the widgets in your own application they run without any application support - an important point if used within dynamically loaded .ui files where the application may not know what widgets are in the .ui files.
The data system used automatically by epicsqt widgets is, however abstracted well away from the widgets. Each widget creates the data source objects it requires, connects to those data sources (using Qt's signal slot mechanism) and then simply receives data signals. The simplest change I envisage is to make the creation of the widgets optional and let a mechanism common with caQtDM send them the data signals they require. The epicsqt widgets don't know or care if they themselves have instigated the flow of data signals. A good example of this is the QEImage widget. It happily consumes image data supplied in signals from the CA data subsystem used by all epicsqt widgets, and also from signals from an mpeg source and from a image file source.
Re-reading the past paragraph I see I have used the word 'simply' a couple of times. I can think of quite a few issues that would haunt that word, but that doesn't change the main point - epicsqt widgets are well suited to be fed data from a system common with caQtDM. One issue I can think of is the fact that the epicsqt data subsystem can do a bit of pre-processing of data before the epicsqt widget sees the data. For example a QELabel widget is always fed text formatted as requested by the QELabel regardless of the CA data type. Within the epicsqt data system, this processing is itself also separated well from the mechanism that actually interacts with CA so maintaining this service within the epicsqt system would not be a problem if the underlying CA data system changes.
Which brings me to another point. Changing the underlying CA data system could be changed to be common to caQtDM, but could also be changed to source data from EPICS V4, or other data sources. This is something we have always considered and is indicated by the fact that in epicsqt CA data structures and terminology do not make it out of the underlying CA data system. The CA-centric code has been kept as tight and closed as possible.
I guess that is enough for now.
Please let me know if it all makes sense!
Regards
Andrew
________________________________________
From: [email protected] [[email protected]] on behalf of Williams Jr., Ernest L. [[email protected]]
Sent: Tuesday, 17 March 2015 11:03
To: Zai Wang
Cc: [email protected]; Babbitt, Alisha
Subject: RE: EPICS CA Interface for caQtDM and epicsqt
Hi Zai,
Can you explain the differences?
Is there a plan to merge them into one implementation?
Cheers,
Ernest
________________________________________
From: Zai Wang [[email protected]]
Sent: Monday, March 16, 2015 4:17 PM
To: Williams Jr., Ernest L.
Subject: EPICS CA Interface for caQtDM and epicsqt
Hi Ernest,
Both have their own interface implementation to CA.
Each serves its own application at moment.
Cheers
Zai
Subject:
EPICS CA Interface for caQtDM and epicsqt
From:
"Williams Jr., Ernest L." <[email protected]<mailto:ernesto_at_slac.stanford.edu>>
To:
"[email protected]<mailto:anton.mezger_at_psi.ch>" <[email protected]<mailto:anton.mezger_at_psi.ch>>, "[email protected]<mailto:Andrew.Rhyder_at_synchrotron.org.au>" <[email protected]<mailto:Andrew.Rhyder_at_synchrotron.org.au>>
Cc:
"Shankar, Murali" <[email protected]<mailto:mshankar_at_slac.stanford.edu>>, "[email protected]<mailto:qti-talk_at_aps.anl.gov>" <[email protected]<mailto:qti-talk_at_aps.anl.gov>>, "Babbitt, Alisha" <[email protected]<mailto:ababbitt_at_slac.stanford.edu>>, "Williams Jr., Ernest L." <[email protected]<mailto:ernesto_at_slac.stanford.edu>>
Date:
Mon, 16 Mar 2015 20:08:12 +0000
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
- References:
- RE: EPICS CA Interface for caQtDM and epicsqt Williams Jr., Ernest L.
- Navigate by Date:
- Prev:
caQtDM w/QT5 gives ==> libGL error: failed to load driver: nouveau Williams Jr., Ernest L.
- Next:
RE: EPICS CA Interface for caQtDM and epicsqt Andrew Rhyder
- Index:
2012
2013
2014
<2015>
2016
2017
2018
2019
- Navigate by Thread:
- Prev:
RE: EPICS CA Interface for caQtDM and epicsqt Zai Wang
- Next:
caQtDM w/QT5 gives ==> libGL error: failed to load driver: nouveau Williams Jr., Ernest L.
- Index:
2012
2013
2014
<2015>
2016
2017
2018
2019
|