RE: OS X edm/medm openmotif woes

[Mark Rivers <rivers@cars.uchicago.edu>]

Going forward I expect that most sites will migrate from medm/edm to either CSS or caQtDM.  If BCDA discontinues medm support, then synApps will be supplied with only caQtDM screens?  This will leave CSS users with no way to convert synApps screens for their use?  I ask because I am also trying to figure out the best way forward for areaDetector, quadEM, dxp, mca and the other packages that I support.  Being able to quickly utilize a new PV that is added to a module with the display files provided in the distribution is useful.

Mark


-----Original Message-----
From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Pete Jemian
Sent: Wednesday, November 16, 2016 8:31 AM
To: tech-talk@aps.anl.gov
Subject: Re: OS X edm/medm openmotif woes

The workflow BCDA is using to support its beam lines at the APS to 
transition from MEDM to caQtDM is

1. implement on-demand scripted conversion from .adl to .ui files
2. beam lines to use caQtDM when screens are ready
3. continue to edit screens as .adl files during transition
    and convert to .ui (choices managed by a Makefile rule)
4. train facility staff to use Qt Designer
5. edit screens in Qt Designer
6. discontinue MEDM altogether

Hope to complete that by spring 2017

On 11/16/2016 8:17 AM, Matt Newville wrote:
> Hi Lewis,
>
>
> On Tue, Nov 15, 2016 at 10:01 PM, J. Lewis Muir <jlmuir@imca-cat.org
> <mailto:jlmuir@imca-cat.org>> wrote:
>
>     On 11/15, Matt Newville wrote:
>     > Hi Lewis,
>     >
>     > I highly recommend caQtDM.  It works great on Mac OS X.  Automated
>     > translations of MEDM files with adl2ui works with very few (sometimes
>     > controls that have been grouped together in MEDM need to be un-grouped for
>     > accurate translation). Once translated, modifying or building new displays
>     > with QtDesigner is very easy, and allows features that MEDM will never
>     > support.
>
>     Hi, Matt!
>
>     Thanks for the recommendation!  caQtDM looks quite interesting.
>
>     A concern for me is that I often want to include a GUI with EPICS-based
>     software I write.  To date, I've always included MEDM screens (i.e.,
>     .adl files).  I've noticed, however, that some modules include more than
>     one type of GUI.  For example, areaDetectors's ADCore has .adl, .edl,
>     and .opi files.  caQtDm's native GUI file format seems to be .ui files.
>     That makes four different GUI formats.  I'd hate to have to maintain
>     more than one GUI.
>
>     So, how do I provide a useful GUI and at the same time avoid maintaining
>     more than one?  You mention that adl2ui works well, but it sounds like
>     you would plan to convert MEDM screens once to .ui files, and then
>     continue in .ui files from there.  Is there a way to automatically
>     generate .adl, .edl, and .opi files from .ui files?  Or is there a
>     consensus forming around .ui files such that it would be reasonable to
>     just provide .ui files where I previously provided .adl files?
>
>
> CaQtDM is an upgrade of MEDM (and I suppose EDM, though I have much less
> experience with EDM).  MEDM is no longer supported, and has always been
> a pain on Mac and Windows due to its dependency on X11, and even Linux
> due to its dependency on Motif.  On top of that, MEDM uses custom fonts
> that basically require editing X11 files -- no sane application has done
> this in the past twenty years.  Honestly, these problems with MEDM have
> been there forever, it's just that people are now used to working around
> it.   CaQtDM does not require libraries that it does not provide, and is
> actively maintained.
>
> I converted all the adl files I use to ui files once a couple years ago,
> though I have occasionally gone back to re-translate a few files or
> translate altered adl files.  I have a few ui files that use features
> (especially Tabs) not possible with MEDM.  At this point, adl files are
> legacy files, just as MEDM is a legacy application, well past its
> expiration date.
>
> --Matt
>

-- 
----------------------------------------------------------
Pete R. Jemian, Ph.D.                <jemian@anl.gov>
Beam line Controls and Data Acquisition, Group Leader
Advanced Photon Source,   Argonne National Laboratory
Argonne, IL  60439                   630 - 252 - 3189
-----------------------------------------------------------
    Education is the one thing for which people
       are willing to pay yet not receive.
-----------------------------------------------------------