-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENH: layout changes for compact complex screens + row positioner widget #563
Conversation
The concept here is solid There's some friction with the templates in https://github.com/pcdshub/pcdsdevices/tree/master/pcdsdevices/ui which might need a simultaneous PR, for feeling-good-about-packaging reasons we've kept typhos to only having templates that match up with ophyd built-ins I think the layouts themselves are infinitely nitpick-able, I'd like to sit down together and nitpick maximally and agree on a final layout. It's worth comparing notes with https://github.com/pcdshub/ecs-pydm-ui/blob/master/widgets/positioner_row.ui |
Yeah, 100% agreed
Definitely - let's set up a meeting so we're all happy with this and then we can talk about how to move forward
Ah, I wasn't aware of this one. Maybe that should be taken as a starting point instead of what I have here. |
I think I'll need to pull out the screenshot feature into a separate PR so we can effectively diff this row positioner vs the standard one |
d241c20
to
9205e2a
Compare
(Rebased on #566 ; may do that again post-review/merge) |
9205e2a
to
4f102df
Compare
Clear_error blocking should not stop typhos from exiting
(The tests are broken because this PR temporarily changes internal templates. Those will be removed before this is marked as ready for review) In the meantime, I'm passing this over to @ZLLentz as he has some tweaks to do on the row positioner widget |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only saw one edge case bug, I'm pretty happy with how these look
Pushed a small commit to address Robert's screenshot
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the biggest pre-rel I've ever seen
panel = TyphosSignalPanel() | ||
panel.omitNames = self.get_names_to_omit() | ||
panel.sortBy = SignalOrder.byName | ||
panel.add_device(self.device) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing is here is filtering the new signal panel by the kinds specified in the menu above
interactively right now, if you deselect e.g. config or add omitted it only applies to existing signal panels
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch - that needs addressing
Edit: hmm, this should be finding the signal panels: https://github.com/klauer/typhos/blob/45c6e5cc546674a1285886ddc7d7c54526304753/typhos/display.py#L373
Needs further investigating - perhaps in a follow-up PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In more words: the filters work, but they only apply to positioner rows that have already been expanded at least once, because otherwise the signal panel has never been created
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll copy my original comment now that I fully understand - "good catch - that needs addressing!" 😁
I think the linked code will have to be modified to tell the positioner widget (when it's ready) how to create the signal panel with the appropriate kind settings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fwiw I think this is a small thing and could be ignored and doubled-back on later
the main drawback of the status quo is that all the omitted signals appear for the first expansion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM. The additional items mentioned make sense as follow up issues / PRs. I'm ready with my green stamp whenever. Did we want to solicit more scientist/PoC feedback first? I'm relatively sure this will be well received, but maybe I'm out of touch |
Zach has noted he's positive on this, so:
I think the best kind of feedback we can get is from them actually using the screens rather than nitpicking a screenshot. At least that's the quickest path to making everyone happi(er) with less effort - or so I think |
@klauer should I proceed to update the pcdsdevices templates tomorrow? |
Did we test the layout on controls rooms machines to make sure it's not broken there? |
I've tested on control room machines remotely (via ssh), but not in person. I assume the latter is what you are concerned about? |
I did test this in TMO, anticipating issues, and made further changes to the template based on that testing. |
Yes exactly, I've had issues with my pydm screens where they did not look as intended on the CR machines. |
Yeah, it's pretty annoying dealing with these sorts of scaling issues. We can either define fonts in terms of point-sizes, in which case they'll be readable on high-dpi displays at the risk of clipping, or we can define them in terms of pixel-sizes, in which case they'll often be hard to read on high-dpi displays but won't clip. A comprehensive solution isn't built into qt and so we find ourselves testing and retesting these (or not testing and then having bad displays) |
Description
Tweaks to the layout of the row positioner widget by @ZLLentz :
TODO
Motivation and Context
Request was "always show the embedded screen!" (#532)
That unfortunately does not render well if you take it literally. I'm of the opinion that it shouldn't be taken literally and we should explore options like this one.
Oh, turns out there was an actual issue for this: closes #543
I must have read it and forgotten about it. The single row display for motors was what we used by default back at NSLS-II with CSS, so this was something I always wanted to see in typhos and only recently found the inspiration for.
How Has This Been Tested?
Minimally, with at2l0 and multi motor example
Where Has This Been Documented?
Screenshots (if appropriate):
Latest screenshot with first-pass adjustments from Zach and now the new notes:
Previous screenshot(s) from WIP
Click here for typhos master screenshot for comparison (ew!):
at2l0:
It'd be nice to regain a bit more vertical space - but in any case, we still have drastically improved over the master branch version in that regard