RE: Operator display description, to get off QT-based tools: Expressions of interest requested

["Dalesio, Leo" <dalesio@bnl.gov>]

Underlying any good display tool, is a robust communication layer that separates the communication threading and performance from the display behavior. This communication layer has a lot of different aspects other than caching/queing - connection management, combining requests to optimize performance, optimizing memory management as connection are made and broken, cache connections through reconnect events.

In addition to these synoptic display issues - are the idea of an integrated operator tool set. For me, an appealing part of CSS is the ability to drag and drop things from the synoptic display tool to the operator log and from the operator log in into the archive data browser. These interactions between tools are a very important aspect.

Then on the other side - is the ability of the commissioners and testers to use scripts to do ad-hoc data analysis and manipulation. The tools to display these results should be readily available. 

It would be great if you could get all of this and outrageous performance in one environment. Perhaps the requirements push toward different solutions.

Looking forward to the iscussion.

Bob

________________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Kasemir, Kay [kasemirk@ornl.gov]
Sent: Wednesday, February 29, 2012 9:31 AM
To: Matthieu Bec; tech-talk@aps.anl.gov
Subject: Operator display description, to get off QT-based tools:       Expressions of interest requested

Hi:

Well, you did it! I was sitting on my hands trying to
stay out of this, but now Matthieu brings up the key point:

>"what really makes a user interface"?
>
>buttons, textbox, graphics, etc - they all do that...
>
>Could there be a reasonably (good) standard to define user interfaces?
>can it be modeled? formally (xsd like) defined?
>
>Would that bring cross compatible DMs (qt/eclipse/etc)..

It's relatively easy to create the basics of a new display tool,

something that can edit and display lines, rectangles, labels,
text-updates,
plus it has a cute meter widget.
I think the first cut of EDM was done in two months,
and it looks like there are already many Qt-based tools at that level.

What comes next is that people build displays for whatever tool they pick,
while the remaining 10% of the display tool features require 90% of the
time
to make it all robust.

Finally, you're stuck with your display tool because your display
descriptions
contain more representation than meaning.
Way back at LANL I remember edd/dm screens that used many rectangles,
offset by just one pixel and using different shades of a color
to simulate "raised" or "sunken" borders.
At SNS, many edm displays have rectangles with a label on top
of the top-left corner to create a "named group" of widgets.
Or hidden buttons writing to local PVs combined with conditionally
visible stuff and embedded displays to create "tabbed" panels.

In principle we know better!
We prefer source code over binaries;
HTML with style sheets and "<h1>" over "<b><huge><font color=...>";
Docbook or LaTeX over MS Word.
If you do use MS Word, employ styles like "Emphasis" and not "italic,
Comic Sans MS, ...".

A good display tool should have widgets with options to select


"alarm sensitive border", "alarm sensitive foreground color", "alarm
sensitive background color",
"raised border", "sunken border" because that describes the meaning of
what you want.
Sure, if you add one black and one white rectangle on top of the widget
you can get
the same "raised border" effect.
If you associate your background color with a "dynamic color" you can get
the same
"alarm sensitive background color".
But when you later want to translate that display for another tool, you'll
have a hard time
figuring out if that rectangle is part of a very essential piping diagram,
a "raised border"
that you might want to translate, or just visual gimmickry that you would
rather omit.
.. if the flickering color is essential for alarm info, or if it's just a
light show
that seemed like a good idea at the time.

A good display tool should also have
* Macros for fonts and colors so you can define TITLE etc.
  instead of Times-bold-...
* an "LED" widget so you don't need to add
  circles that happen to change color if you
  want to create an LED-type indicator.
* a Group widget that can wrap other widgets
  to create a real 'group' of widgets both
  visually (border, label, ...) and semantically
  (editor can move, resize, copy, paste them as a group, ...)
* a Tab widget that can wrap other widgets
  to create a real set of 'tabs' both
  visually and semantically

Thanks,
Kay