Hi Kay
Thanks for the reply. All in all I would say it has been fairly easy
to get up and running with CSS and it is an impressive solution. We have
good Java expertise, though RCP was new to us, but the collaboration
meeting helped as did the "Eclipse plug-ins" book.
While the last part of your response answers my question I don't think I
articulated the original problem statement very well. I also got an
email from another tech talk member that expressed the same interest in,
as he put it, "in separating the display from the editor"
Basically our operators are used to being able to X display many
discrete UIs onto their desktop. There are written in different
languages and range in complexity from simple tcl/tk and dm screens to
complex java based UIs with docking frameworks etc. Many talk CA, some
don't. The operators are used to having the ability to simply and
quickly launch these, then size and position them over multiple physical
and virtual screens. Many of these are read only and once started the
operator doesn't interact with them again expect to occasionally monitor
the vales.
In most cases they don't want or need the complexity of having to deal
with different views or perspectives, having to resize internal windows
etc.
(That said there are definitely benefits to the CSS integrated tools
support and we will be looking at reducing UI clutter and improving
workflow at some stage by revisiting these UIs and perhaps better
integrating them into a more productized solution. This is what we did
with one test product that has the BEAST UI, probe, and PV tables. This
is essentially what we have also done with some of the Java apps though
they are simply using Matisse, Swing, JAI and the InfoNode docking
framework).
When I used the term "locked down" it wasn't related to screen position
or sizing but related to the fact that I want to have the equivalent of
a single standalone display that doesn't have any menu, perspective or
mouse functions not related to that display.
I realize that CSS allows panels to be move around and their location
saved and restored, this is what we do with our UIs that utilize the
docking framework, but we have cases where operators want a simpler
model where there is only one perspective or a small set that are
specific to the display.
Hopefully this better explains my earlier post. I just took DM/EDM/MEDM
as a primary example since they are clearly EPICS related.
In relation to your solution response this is basically what I had
figured out I would most likely need to do. I guess I was hoping that
someone had already looked into this area and had a simplified solution
that could simply take and display an opi file, something along the
lines of "> boy_displaymanager test.opi" and it would launch, size to
the OPI panel and enter run mode.
I guess I need to think about this a bit more perhaps a better solution
might be as you say to have a top level UI launcher product that could
be used to fire up these various displays on different virtual
workspaces.
Thanks again
Jimmy
- Replies:
- Re: How to use BOY/OPI to produce standalone simple displays Kasemir, Kay
- References:
- How to use BOY/OPI to produce standalone simple displays Jimmy Johnson
- Re: How to use BOY/OPI to produce standalone simple displays Kasemir, Kay
- Navigate by Date:
- Prev:
Re: EPID Capfast symbol Russell Kackley
- Next:
Re: How to use BOY/OPI to produce standalone simple displays Kasemir, Kay
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: How to use BOY/OPI to produce standalone simple displays Kasemir, Kay
- Next:
Re: How to use BOY/OPI to produce standalone simple displays Kasemir, Kay
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|