Gašper Tkačik Cosylab, Slovenia EPICS Office HowTo Gašper Tkačik Cosylab, Slovenia http://users.cosylab.com/~kzagar/cso/

User’s viewpoint Same L&F, common actions, data interpreted by different applications Community knowledge (like TeX vs Word  example with colors in GUI) Chart example - reference exchange Scenarios: deployment, monitoring, exploration, configuration, spec. tasks I said I won’t talk about the use case in my first talk, but I got the feeling that some things should be made clear Started by trinity of office experience: we believe that this is beneficial, whatever kind of CS application you have -> general premises for making an application. We heard Heiko’s talk about user perspective, and this is one possible way to achieve it Connected to the second point: currently, even if there is an excellent programmer in your team that makes an excellent application, this knowledge Is lost if he or she goes; everybody rediscovers that using clear colors for GUI is OK: but even when you discover that, there are two things about how you can do it. You can first, change your Jlabel in the code to red color. Or you can define somewhere what an alarm condition is, and make all alarms appear in read everywhere (!!) This is important because of --) Everywhere --) You can add other behaviours connected to alarm later on Another example is chart --) One way: have a chart component embedded in your application --) Second way: have a charting application know how to chart anything --) Why not both ways? Where is the technical problem: this is what the office framework should solve. What is the minimum amount of info I have to give to a generic charting component so that it can start charting? Is it just the channel name? A channel name and a type? A Channel name and the names of the characteristics (units etc) that it has to read? How does it know how to change the refresh frequency (What does it have to say to the communication layer). Very important point: When I talk about office, drag and drop I.e. I talk about general mechanisms. I do not say that the whole control system will be replaced by this one workbench. NOT AT ALL: more realistic scenario is that you start with the workbench (navigator, views etc), try out things, do whatever you want, create panels such as in MEDM, save them, use them later (FIRST KIND, PANELS). Second kind, Group applications, now also possible such as in MEDM (virtual data sources, group things together, take them apart). COMPLEX APPLICATIONS, THIRD KIND, always need for manual code. Make workbench into the wizard that helps make such applications. Select the datasources and the data delivery QoS, make the code that delivers these into a script or a method. WE DO NOT AIM TO REPLACE EXISTING FUNCS. IT MUST BE POSSIBLE (and for profis, it is even more efficient), TO USE ALL THINGS COMPLETELY PROGRAMATICALY, IN API, TO CREATE APPS. Office functionality is a complement to traditional application functionality and API EPICS Workshop, SLAC, 2005-04-27

User’s viewpoint Name service if available, otherwise connected stuff Define e.g. groups Components in the main view Menu NOT hardcoded Scripting access from console EPICS Workshop, SLAC, 2005-04-27

Integrated Development… EPICS … and deployment environment EPICS Workshop, SLAC, 2005-04-27

Collecting feature requests More than ‘It would be nice’ argument? EPICS Office - Why now Is there a need? Collecting feature requests More than ‘It would be nice’ argument? (Is there really code reuse and added value) Is there a way? Java Shift towards Rich Client Platform Collaborative tools (Sourceforge) What is the cost? Be afraid of the framework? EPICS Workshop, SLAC, 2005-04-27

What kind of Java is brewing… Inversion-of-Control AOP Server side: great success of EJB, complexity Client side: slow adoption (JVM, GUI, services, packaging) OSGi a LOT of stuff Pure Java, Knoplerfish, Eclipse, Spring EPICS Workshop, SLAC, 2005-04-27

Eclipse for RCP OSGi Extension: Button in the toolbar Extension point: clicking on the price Plug-in component deployed as bundle EPICS Workshop, SLAC, 2005-04-27

EPICS Workshop, SLAC, 2005-04-27

EPICS Office is possible But we need to: Conclusions EPICS Office is possible But we need to: Leverage existing frameworks in a smart (= simple enough) way Design data-exchange core well Project management (= Office can not be a ‘hobby’ activity) Integration of cool stuff, tools (JEDM anyone), applications (VDCT model - suggestions) http://users.cosylab.com/~kzagar/cso/ EPICS Workshop, SLAC, 2005-04-27