EclipseVsStandaloneTools

= Comparison of Eclipse/CSS to Standalone Tools =

Before CSS, control system toolsets like EPICS offered several standalone tools, for example

• (X11) Probe - Single-PV inspection
• !StripTool - Plot live data over time
• Archive Data Viewer - Plot historic data over time
• *DM: DM, EDM, MEDM, DM2K - Operator interface panel display (and editor)

Eclipse/CSS combines these into one tool:

• (CSS) Probe - Single-PV inspection
• Data Browser !StripTool - Plot historic and live data over time
• SDS, BOY - Operator interface panel display (and editor)

== What is the advantage? ==

The standalone tools were not integrated. None of them had a preference GUI to configure the EPICS CA address list, nor online help that explains this setting. You had to know how EPICS_CA_ADDR_LIST happens to be set in your environment.

With CSS, the configuration of your connection to EPICS or another supported control system network protocol can be done in the preference GUI, there is online help.

With standalone tools, you can move the *DM screens around, minimize them, open a separate !StripTool and place that on top of *DM etc. On Linux/GTK/KDE or OS X the user can setup several "Workspace" or "Spaces", i.e. several desktop arrangements and switch between them.

CSS/Eclipse gives you the same flexibility, but integrated for the control system tools: You can move Preference Panels, Probe, EPICS PV Tree, ... around, and it will remember the last locations through restarts of the application. You can have several desktop arrangements ("Perspectives") where the 'main' sections (operator displays, data browser plots) stay as they are but the auxiliary views (preference panel, ...) can be arranged or hidden as you like.

== Isn't that confusing? ==

With the old *DM, there was just that: Operator runs *DM, and that's it. No access to archived data, no links to a !StripTool/Data Browser.

It's less flexible, but to a first time user certainly easier to understand compared to all the options you see in a CSS menu bar.

== How do I create the Product that I want? ==

See [wiki:EclipseAndCSS] for an explanation of terms and some pointers.

== Can I create something closer to the old standalone tools? How? ==

Yes. You could take for example the BOY '''Plugins''' and bundle them into your own "MyDM" '''Product'''. It could have a very limited menu bar, no perspective switch.

It could include the display files that you want, and open your 'top level' screen on startup. Technically, you'd have to create your own '''Product''' with your own '''Application''' that defines the menu bar, includes the screens that you want similar to the BOY example screens, automatically installing them on first startup. You could also have your product automatically download the latest screens, or always use screens behind an '!http://....' path.

== What's the disadvantage? ==

That would be like the existing *DM. There would be no EPICS PV Tree, Data Browser, Probe; they wouldn't show up in the context menu of PVs. You could create a separate, standalone "!MyProbe" application, so users would have to start that separately, then copy/past PV names from "!MyDM" to "!MyProbe". Or you could choose to combine BOY & Probe & EPICS PV Tree into one product, the alarm tools into another product. It's all up to you.

Just as you can install either EDM & !StripTool, or MEDM & !StripTool, or DM & Probe. With EDM, !StripTool, Probe, ... you would typically install what you want, then create something like a tcl/tk or top-level *DM screen that users start to access these tools. Yet the tools remain standalone, no data exchange beyond copy/paste, no common preferences and online help.

With CSS/Eclipse, the tcl/tk or top-level *DM screen changes into the "Product". Creating that "Product" is more involved than hacking a tcl/tk or top-level *DM screen. On the upside, the tools inside the product are more integrated; the product can (auto-)update itself. You can as easily create it for Windows as you can for Linux and OS X.