Skip to content
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

Update OpenDisplay action buttons as part of GUI refresh. #140

Open
DiamondRC opened this issue Oct 9, 2024 · 8 comments
Open

Update OpenDisplay action buttons as part of GUI refresh. #140

DiamondRC opened this issue Oct 9, 2024 · 8 comments

Comments

@DiamondRC
Copy link

Following the discussion of proposed breamline synoptic updates, change OpenDisplay action buttons to span group width, removing the button label. Then change the button text 'Open Display' to the (former) label text.

image
image

@evalott100
Copy link
Contributor

evalott100 commented Oct 9, 2024

This would mean mapping description

<description>Open Display</description>

in the property map

pvi/src/pvi/_format/dls.py

Lines 328 to 336 in 409ec57

search="OpenDisplay",
property_map={
"file": "file_name",
"text": "label",
"macros": "macros",
},
),
)
)

to the new attribute button_text (default "Open Display" still).

pvi/src/pvi/device.py

Lines 403 to 410 in 409ec57

class DeviceRef(Component):
"""Reference to another Device."""
pv: str = Field(description="Child device PVI PV")
ui: str = Field(description="UI file to open for referenced Device")
macros: dict[str, str] = Field(
default={}, description="Macro-value pairs for UI file"
)

@evalott100 evalott100 assigned evalott100 and DiamondRC and unassigned evalott100 Oct 9, 2024
@DiamondRC DiamondRC removed their assignment Oct 9, 2024
@GDYendell
Copy link
Member

I think this will need to be an option on DeviceRef, as in some cases we do want the label as well as the button label. For example when generating the index UI the label is the device type and the button label includes the macros, so that it shows know which instance of the device it opens.

@evalott100
Copy link
Contributor

I think this will need to be an option on DeviceRef

Whoops, I meant

to the new attribute button_text (default "Open Display" still).

@gilesknap
Copy link
Member

This is what a motor ioc index.bob currently looks like
image

@coretl
Copy link
Contributor

coretl commented Oct 10, 2024

I think this will need to be an option on DeviceRef, as in some cases we do want the label as well as the button label. For example when generating the index UI the label is the device type and the button label includes the macros, so that it shows know which instance of the device it opens.

Are we sure about this? Why not a full width button with asynMotorAxis BL01T-MO-SIMC-01:M1 on it?

@evalott100
Copy link
Contributor

evalott100 commented Oct 10, 2024

Are we sure about this? Why not a full width button with asynMotorAxis BL01T-MO-SIMC-01:M1 on it?

Currently label is on the Component class, and optional so that if you don't provide it the widget will take up the full width. If we do the above and don't have a separate attribute to label for the text then we have to write exemptions to the current parser to use label in the button <description> instead of displaying it as a new widget side by side. It could be nice to have a general way of doing this for widgets where the label would be an attribute in the widget itself. I'd have a slight preference against this because I think it's unneeded complexity, and because having both label and button_text gives the user more options.

@evalott100
Copy link
Contributor

It could be nice to have a general way of doing this for widgets where the label would be an attribute in the widget itself.

If we do want to have label be the <description> on the button itself then I'd opt to make this a new issue and use @DiamondRC's changes adding button_text separately for the time being.

@GDYendell
Copy link
Member

Are we sure about this? Why not a full width button with asynMotorAxis BL01T-MO-SIMC-01:M1 on it?

Yeah this is what I just discussed with Giles that we should do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants