search

mxcube / mxcubecore

Backend used by MXCuBE
http://mxcube.github.io/mxcube/
GNU Lesser General Public License v3.0
11 stars 52 forks source link

Adding __category__ label #298

Closed IvarsKarpics closed 5 years ago

IvarsKarpics commented 5 years ago

What about adding a __category__label to the hardware objects? In the qt bricks category is used to sort all bricks in the available bricks tree. In this case it would be useful to see it in the summary log:

+ ============================================================================== +
| Xml                      | Class                      | Category |Load time | Comment|
+ ============================================================================== +
| /Qt4_graphics-manager    | Qt4_GraphicsManager        | Graphics | 7 ms    |    |
| /Qt4_video-mockup        | Qt4_VideoMockup            | Graphics |104 ms   |    |
| /attenuators             | Attenuators                |  Beam    |23 ms    |    |

And maybe in the future it could be possible to do some clever imports like

from motors import TangoMotor

beteva commented 5 years ago

This is a good idea. There used to be something like that fro the Bricks. We should not abuse, though, with the number of categories we create. It is also essential to agree on the category names before applying the rule. This is my proposal for the list of categories: positioning (all motors, piezos, encoders), detectors (pixel, MCA, cameras), io (input/output - actuators), instrumentation (diffractometer, beamstop, ...) and sequence (collection, XRF, energy scan, workflows, ...). Did I forget anything?

marcus-oscarsson commented 5 years ago

I think I would prefer to derive that kind of information from its abstract base class, or would this category have a different function ?

I'm not sure that I know how what you mean by the import part ?

IvarsKarpics commented 5 years ago

Use abstract classes to deriver new classes. api/beamline object to be initialized via config file and not categories