Closed rhfogh closed 5 years ago
Additional change - cleaned up warning message for missiing CameraBrick.set_scale_visible function
Now adapted to web meeting agreements. Hopefully ready to merge.
If nobody is against then I will accept the PR to work on beamline object.
If nobody is against then I will accept the PR to work on beamline object.
Certainly fine with me
Thanks!
On 26/09/2019 12:00, Ivars Karpics wrote:
Merged #357 https://github.com/mxcube/mxcube/pull/357 into master.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mxcube/mxcube/pull/357?email_source=notifications&email_token=ACK5QEGXVUHZQTR3Z7DI4D3QLSI5RA5CNFSM4IJMWKS2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOT3LDCTY#event-2664837455, or mute the thread https://github.com/notifications/unsubscribe-auth/ACK5QEDZUGH22RXLQOXI5LTQLSI5RANCNFSM4IJMWKSQ.
-- Rasmus Fogh Cambridge, UK.
This one is big - and there is a parallel one for the HardwareRepository repository.
It is no longer WIP, so please comment. I would propose that we dispatch this one, one way or the other, before making any other important PRs - it will be real painful to merge this with anything else.
Some points:
I have made the new beamline_object and removed all references to api. I have removed (as far as possible) all references via getObjectByRole, getHardwareObject etc. to the objects now available in the beamline_object. I have removed internal attributes (like camera_hwobj) that were used to track now unnecessary locally configured objects. Beyond that there was some necessary refactoring, but I have tried to keep that down.
This change is so big, and I can only test the mock version, that there is bound to be errors. It cannot be helped (and if I did not makie the changes now, would they ever have happened?) I ask you forbearance.
I have made changes everywhere, but kept the qt3 directories and MultiCollect classes out. NanoDiff may not be completely covered (it does not seem to be useed from anycode I have).
image_tracking and ppu_control are implemented only in the EMBL-specific object and config.
HardwareObjects that the meeting agreed should be contained within the objects in the top layer have been implemented as properties, but theri underlying ocnfiguration has been left as it was.
If we need suport for hot-switching the defined HardwareObjects more coding would be required.
The first thing needed after this is for sites to make their own configs in the new scheme, and test the result. There is a whole layer of further clean-up, once this is accepted. A lot of functions on e.g. Diffractometer should be removed as obsolete, Some classes should be as well. In the longer term we might want to switch to using yaml configuration for everything,
I would propose that we deal with this one before we get into any other changes. Merging this with anything else would be a paoinful job.****