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

Flow latency analysis window is not sized based on content #2039

Closed
philip-alldredge opened this issue Nov 4, 2019 · 5 comments · Fixed by #2269
Closed

Flow latency analysis window is not sized based on content #2039

philip-alldredge opened this issue Nov 4, 2019 · 5 comments · Fixed by #2269
Assignees
Labels
analyses analyses from plugins category:bug
Milestone

Comments

@philip-alldredge
Copy link
Collaborator

The Flow Latency Analysis window is not sized based on content. On Windows systems which have a window scaling > 100%, buttons are cut off or hidden. Additionally, the window is not resizable so it is impossible to access those buttons.

Environment

  • OSATE Version: 2.5.2
  • Operating System: Windows 10
@philip-alldredge
Copy link
Collaborator Author

@lwrage I just noticed this was mislabeled. This is not an issue with the graphical editor's flow tools. This is related to the size of the window that appears when performing the latency analysis.

@philip-alldredge philip-alldredge added the analyses analyses from plugins label Jan 15, 2020
@lwrage lwrage added this to the 2.8.0 milestone Mar 24, 2020
@AaronGreenhouse
Copy link
Contributor

@philip-alldredge I'm trying to fix this, but I have a Mac, so I am not experiencing your problem and can only guess at it. Are you saying that the scaling is causing the contents of the window to be clipped to the borders of the window? This sounds like an SWT problem because in my snooping around of the Dialog/Shell/Window, it is supposed to be getting the size of the dialog contents and setting the dialog bounds accordingly.

Can you attach a screen shot of the problem?

It is easy enough to change the dialog to face the RESIZE flag, but strange that it should be necessary.

@philip-alldredge
Copy link
Collaborator Author

@AaronGreenhouse I'm away from my office computer so it's hard for me to reproduce at the moment. It only affects systems with certain DPI settings. The resize would definitely resolve the issue for me. A scrollbar would also work if there are any cases where the window wouldn't fit on a screen(Seems unlikely on modern displays).

@AaronGreenhouse
Copy link
Contributor

AaronGreenhouse commented Apr 6, 2020

@lwrage Was able to reproduce on Linux.

I found settings on OS X for changing magnification, but I was able to cause layout problems by using it.

Below are screen shots from Lutz:

144dpi.png

120dpi.png

96dpi.png

@AaronGreenhouse
Copy link
Contributor

AaronGreenhouse commented Apr 6, 2020

I fixed this I hope.

  1. Made the dialog resizable.

  2. Put the main content in a scroll panel. This was a little tricky, because the straightforward thing to do, that is, get the preferred size of the work panel and then put it in the scroller can make things look funny. Normally via the layout managers we expand the size of the work area to fit the preferred size of the window, but that doesn't work once you put in the work area inside a scroll pane. So it might be too narrow, and then looks odd because there is a chunk of blank space to the right size of the dialog. So I had to add a listener to the scroll pane that catches when it is resized and then expands the width/height of the work area to fill the initial size of the scroller. Then it listener removed itself. This captures the initial sizing of the window only.

This produces very intuitive and usable results on OS X. If someone could test on windows or linux that would be great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
analyses analyses from plugins category:bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants