Execute Display window ignores width/ height
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start by reproducing the mismatch with the Execute Display button, especially in a docked window, and compare its autoscaling with the editor’s red-border dimensions. Trace where the executed display determines its viewport and applies the width/height zoom functions. Done means the executed display respects the configured size and its content fits the viewport without the reported scrollbar mismatch.
Written by the indexing model from the issue text.
Description
Similar to the Issue from 2023 see https://github.com/ControlSystemStudio/phoebus/issues/2729:
Version 5.0.2 still has this issue at our site. Any suggestion how to fix it?
In the Display editor, everything works fine and the dropdown width/height/all in a separate or docked window will scale according to the displayed red border. However, every time we use the execute display button, these autoscaling functions ignore the set display size (red border) in the file. This is more obvious in the docked window state.
Seems like Display does not get correct viewport sizes of the current window and in addition the display ignores the set display sizes.
Does anyone else can replicate it?
Editor Screenshot:
Executed Display manually zoomed out: (Background is greater than the editor borders)
Executed Display after 'height' zoom function: (mismatch of height to viewport (scrollbar))
- Dominant language
- Java
- Stars
- 130
- Forks
- 132
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 19
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ControlSystemStudio/phoebus
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
ControlSystemStudio/phoebus#3983 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ControlSystemStudio/phoebus#3979 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
ControlSystemStudio/phoebus#3962 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
ControlSystemStudio/phoebus#3865 · 1 comment ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 52/100
ControlSystemStudio/phoebus#3980 ·
Maintainers usually reply within 2 days
All issues in ControlSystemStudio/phoebus
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
geonetwork/core-geonetwork#9592 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
NationalSecurityAgency/ghidra#10040 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
Maintainers usually reply within 1 day
-
[Bug] ServerHttpRequest.getURI() throws NumberFormatException when Host contains an explicit portOpencomponent/need-triage type/need-triage
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
apache/rocketmq-dashboard#7361 ·
Maintainers usually reply within 3 days