Experimental Physics and Industrial Control System
Hi All,
Since I have been working at SNS I have been using BOY more than edm and I have to say that BOY is very nice, having capabilities that far exceed those of edm. My only negative reaction is the multiple document interface provided by the current implementation. But, what I hear in this discussion is a negative reaction to the opposite case, the existence of independent screens littering up an otherwise productive workspace. So, at this point let me as a question, just for the sake of curiosity - I absolutely do not have strong feelings about this issue one way or the other.
Before my question, at comment.
I have always used a window manager that allows me to click in a window without the window manager popping up the window being clicked. In this scenario, a large window is being displayed and I click a button to bring up one or several small related displays. I interact with the related displays and then interact (by clicking) in the larger window. For my configuration, when I do this (interact with the larger window) , it does not pop-up and occlude the small related displays. Over the years I have observed many sites that do not configure this behavior. Instead they have things configured so clicking in the larger window does cause it to pop up, covering up all the small related display windows. I could never imagine how one could live with this behavior.
So, my question is: How do you have your window manager configured? The way I described my configuration or a configuration that gives the behavior you would get from, for example, Microsoft Windows.
Thanks,
John Sinclair
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Emma Shepherd
Sent: Wednesday, December 18, 2013 5:37 PM
To: [email protected]; [email protected]
Subject: RE: Design strategies for CSS BOY screens
Hi Tom,
As you know we're using Qt, not BOY. However we're going down much the same EDM replacement path at the moment and tackling very similar problems so I thought I'd share our thoughts with you anyway.
Our solution is still very much a work in progress, but we're starting to settle on some design principles. We've gone for a tabbed display for the beamline synoptic, with one tab per component (e.g. a DCM). However, we're trying to keep it as flexible as possible so the tabs are 'dockable' and can be moved out into separate windows if desired. A recent development in the epicsqt framework is to allow window configurations to be saved, so that beamlines can come up with their own customized layout. It is also possible for layouts to be 'locked' so that users can't mess around with them too much! We decided this kind of approach was best as it's impossible to satisfy everyone's requirements otherwise...
I completely agree with your point about having multiple copies of EDM windows everywhere and not being able to find anything, it's very frustrating. In our solution, configuration screens e.g. for the motor record will open up as separate windows, but there is at least a 'Windows' menu in the application so you can see what is open and bring something to the front if it is minimized.
Good luck! I'd be interested to see what you come up with.
Emma
> -----Original Message-----
> From: [email protected] [mailto:tech-talk-
> [email protected]] On Behalf Of [email protected]
> Sent: Thursday, 19 December 2013 3:38 AM
> To: [email protected]
> Subject: Design strategies for CSS BOY screens
>
> Hi all,
>
> We're currently evaluating CSS and BOY as an EDM replacement, and I am
> considering how display screens on beamlines might look in this
> framework.
>
> Currently we have an EDM "Synoptic" view of the beamline, with icons
> that show the status of each component on the beamline. Clicking on
> one of these icons brings up a summary screen for the objects that
> make up the component (motors, temperatures, diode readings, etc.)
> These summary screens are mainly auto-generated from tags in the EPICS
> database, but a significant minority are manually created. Clicking
> through from one of the summary screens takes you to manually created
> detailed screens for that object.
>
> All of this means that a typical desktop might look like this:
> http://controls.diamond.ac.uk/downloads/other/files/EDMScreenShot.png
>
> Multiply this by 4 monitors and 8 Linux workspaces and users have an
> awful lot of screen real estate to get lost in. The main synoptic
> typically gets buried in the background, so the users open another
> one, then you have multiple copies of everything and can never find
> what you're looking for.
>
> Now the simplistic approach when converting to CSS BOY would be to
> translate every EDM screen into a BOY screen, launched in its own
> window. But then we aren't really solving any problems, we're just
> making BOY look like EDM, and it takes a lot of work to persuade
> eclipse not to put toolbars everywhere...
>
> Another simple solution would be to use tabs, default action is open
> in current tab, with an option to open in a new tab. This solves the
> mess of windows, but all our EDM screens are different sizes, so if we
> assume a large central area for the current BOY screen, then small
> screens with only a couple of widgets on them mean rather a lot of
> wasted space.
>
> So how have other sites designed their BOY screens? Are most of your
> opi screens similar sizes? Do you make use of the various different
> tear off tabs that eclipse offers you? Do you open multiple windows on
> multiple workspaces? Do you try to manage how the users perspective
> should look, or do you leave it to the users to dock their windows
> where they like?
>
> Any feedback/screenshots gratefully received, anything that helps us
> get better at GUI design has got to be a good thing!
>
> Thanks,
> Tom Cobb
>
> --
> This e-mail and any attachments may contain confidential, copyright
> and or privileged material, and are for the use of the intended
> addressee only. If you are not the intended addressee or an authorised
> recipient of the addressee please notify us of receipt by returning
> the e-mail and do not use, copy, retain, distribute or disclose the
> information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual
> and not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
> attachments are free from viruses and we cannot accept liability for
> any damage which you may sustain as a result of software viruses which
> may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in
> England and Wales with its registered office at Diamond House, Harwell
> Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United
> Kingdom
>
>
>
>
- Replies:
- RE: Design strategies for CSS BOY screens Emmanuel Mayssat
- RE: Design strategies for CSS BOY screens tom.cobb
- References:
- Design strategies for CSS BOY screens tom.cobb
- RE: Design strategies for CSS BOY screens Emma Shepherd
- Navigate by Date:
- Prev:
RE: Design strategies for CSS BOY screens kathryn.baker
- Next:
RE: areaDetector driver for Point Grey FlyCapture2 SDK? tom.cobb
- 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: Design strategies for CSS BOY screens Emma Shepherd
- Next:
RE: Design strategies for CSS BOY screens Emmanuel Mayssat
- 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