You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Web Browser widget keeps its fixed design-time size at runtime, like every other widget. For displays built around a single browser filling the screen, that's awkward — the embedded page doesn't follow the window when it is resized.
This PR adds an opt-in resize_with_window property (Behavior category, default off). When enabled, the browser grows and shrinks to fill the runtime window/tab. The default is off, so existing displays are unaffected, and the property is left out of the saved file unless it is set (older versions ignore the unknown tag).
It is intended for top-level, browser-dominant displays: the widget should be a direct child of the display root. When the browser is nested in a Group, Tabs, or embedded display the property is a no-op and logs a warning.
Checklist
Testing:
The feature has automated tests
Tests were run
Added unit tests for the model property (default value, XML round-trip) and for the fit calculation; ran mvn clean install on JDK 21.
Well, the web browser widget has acknowledged limitations. Web pages with javascript may not work as expected and CPU load tends to be higher than in a "real" web browser. If your goal is to have a browser that fills the window, like a normal web browser, why don't you simply use an action button that opens the URL in a normal web browser? That way your users get the expected normal web browser behavior.
The idea is to have tabs containing documentation or specific tools that are HTML based, rather than a generic browser. We have a specific use case for such a feature. Having HTML pages in an external browser is an option but not ideal at all.
Sure, I can see resize_with_window being nice for images, plots, tables that are at the 'bottom' of a display so that they then extend downwards to fill the window. Also opens the door to widgets at the right growing to fill the available window widths.
You are right. I did not see the value in other widgets but it could be a nice to have everywhere. Should I edit this PR to generalize this? Otherwise this could be implemented on each widget separately with distinct PRs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Web Browser widget keeps its fixed design-time size at runtime, like every other widget. For displays built around a single browser filling the screen, that's awkward — the embedded page doesn't follow the window when it is resized.
This PR adds an opt-in
resize_with_windowproperty (Behavior category, default off). When enabled, the browser grows and shrinks to fill the runtime window/tab. The default is off, so existing displays are unaffected, and the property is left out of the saved file unless it is set (older versions ignore the unknown tag).It is intended for top-level, browser-dominant displays: the widget should be a direct child of the display root. When the browser is nested in a Group, Tabs, or embedded display the property is a no-op and logs a warning.
Checklist
mvn clean installon JDK 21.