RE: OS X edm/medm openmotif woes

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

There are translators from adl to the other 3 formats.  There is no other format with translators to all other 3.

Thus, for areaDetector I plan to stick to adl as the "standard", so we can autogenerate the other 3.

In areaDetector the opi, edl, and ui files are 2 directories, e.g. op/ui and op/ui/autoconvert.  The autoconverted files get put in op/ui/autoconvert, and should be updated each time the adl files change.  The op/ui directory is for files that were manually edited.

It would be nice if one could script the autoconversion process.  adl2ui and adl2edl are command line programs, so they can be scripted.  However, the conversion to CSS opi files can currently only be done in the CSS BOY GUI.  Since the conversion is really just a Java function it would be nice if someone were to package it so it can be called from the command line.

Mark


From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of J. Lewis Muir [jlmuir@imca-cat.org]
Sent: Tuesday, November 15, 2016 10:01 PM
To: Matt Newville
Cc: Eric Norum; tech-talk
Subject: Re: OS X edm/medm openmotif woes

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?

Thanks!

Lewis