Martin, I agree — this behavior is likely to be platform-specific, and it could be difficult to guarantee consistent results if we try to enforce a specific outcome. It seems more practical to document that variations should be expected.
I'll be filing a PR soon with fixes for Glass on Linux, along with additional tests related to window sizing, positioning and window state management. -- Thiago. Em seg., 21 de abr. de 2025 às 17:04, Martin Fox <martinfox...@gmail.com> escreveu: > Christopher — Thanks for the details. > > Thiago — I’m still of the opinion that we shouldn’t try to specify what > happens when a client tries to resize a maximized window. I don’t like > leaving these things unspecified but I’m not sure there’s a compelling use > case that would justify the effort involved in nailing this down. Simpler > to just document that the window should be de-maximized first. > > I’m also seeing some bugs on macOS related to maximizing and de-maximizing > the window and it looks like we don’t have good system tests for some of > this (or they’re disabled). Personally I would rather focus on fixing those > issues. > > Martin > > On Apr 17, 2025, at 10:44 PM, Christopher Schnick <crschn...@xpipe.io> > wrote: > > I wasn't really trying it, our application just had functionality to > resize the window on a certain action. And this functionality then broke > the window content when triggered while the window was maximized, which is > a case I didn't consider. I implemented a workaround for this now by just > setting the maximized property to false prior and only resizing the window > if really necessary, but I can imagine other applications possibly being > affected by this. > > For reference, here is a video on how the issue looked like initially on > Linux: https://github.com/xpipe-io/xpipe/issues/485 > On 17/04/2025 22:24, Martin Fox wrote: > > Christopher, > > Why are you trying to change the size of a maximized stage? I’m not sure > what the intended effect is. > > Currently this produces all sort of platform-specific behavior and since > what you’re seeing on Windows doesn’t match what I’m seeing I think there > might be some variation based on OS version. The easiest way out of this > thicket is to de-maximize the stage before trying to change its size. > > With that said, yes, this Linux bug definitely needs to be fixed. Whatever > happens the scene shouldn’t break. > > On Apr 16, 2025, at 3:32 AM, Thiago Milczarek Sayão > <thiago.sa...@gmail.com> <thiago.sa...@gmail.com> wrote: > > Hi, > > I’d like to get your thoughts on what the expected behavior should be when > setting the size of a window while it's in a maximized state. > > Here are the options I’ve considered: > > a) Ignore the resize while maximized, and when restored, revert to the > size before it was maximized > b) Demaximize the window and apply the new size immediately > c) Ignore the resize request, but store the values and apply them upon > restore > > > Option A forces the client to de-maximize the window before changing its > size. Option B de-maximizes the window automatically. Option C is the only > one that brings new functionality to the table but it would be complicated > to implement (assuming it can be implemented). > > The documentation states that this is how things work when a stage is in > fullscreen mode but from I can tell that’s not how any of the platforms > actually behave. Trying to resize a fullscreen window produces a variety of > immediate platform-specific effects. > > If I understood correctly, Martin mentioned that both macOS and Windows > apply the resize immediately while keeping the window maximized. > > > You understood correctly but I was wrong. On Windows 11 the size changes > (I’m seeing only one resize event) and the window stays in the maximized > state. This seems to be confusing the OS and it draws the title bar > incorrectly. On macOS the size changes and the window leaves the maximized > state but due to a bug in the code we don’t update the maximized property > correctly. > > Martin > > Then, when the window is demaximized, it restores the previous > (pre-maximized) size, which suggests behavior leaning toward option a. > > For fullscreen mode, the expected behavior appears to align more with > option c, as documented for Stage fullscreen. > > -- Thiago. > > > Em sáb., 29 de mar. de 2025 às 09:24, Thiago Milczarek Sayão < > thiago.sa...@gmail.com> escreveu: > >> I did not find a bug report, so I did one and provided a fix: >> >> https://github.com/openjdk/jfx/pull/1748 >> >> >> >> Em sáb., 29 de mar. de 2025 às 08:26, Thiago Milczarek Sayão < >> thiago.sa...@gmail.com> escreveu: >> >>> @Christopher Schnick <crschn...@xpipe.io> >>> >>> Hi, did you open a bug? I have a fix for this. >>> >>> Thanks >>> >>> -- Thiago. >>> >>> Em seg., 17 de mar. de 2025 às 09:49, Christopher Schnick < >>> crschn...@xpipe.io> escreveu: >>> >>>> So on Windows at least, it will change the width temporarily and then >>>> revert back to the original width value. So you will receive two width >>>> change events if you listen to the stage width property. The maximized >>>> property is not changed. >>>> >>>> I guess this also not optimal handling of this. Ideally, no changes >>>> would be made in that case. >>>> On 17/03/2025 10:53, Thiago Milczarek Sayão wrote: >>>> >>>> Hi Christopher, >>>> >>>> It seems like a simple fix. >>>> >>>> How does it behave on other platforms? Does it ignore the resize, >>>> restore the window to its unmaximized state before resizing, or keep it >>>> maximized while adjusting the unmaximized size. >>>> >>>> -- Thiago >>>> >>>> >>>> >>>> >>>> >>>> >>>> Em dom., 16 de mar. de 2025 às 05:25, Christopher Schnick < >>>> crschn...@xpipe.io> escreveu: >>>> >>>>> Hello, >>>>> >>>>> we encountered an issue on Linux where resizing the stage while it is >>>>> maximized breaks the size of the scene. You can see a video of this at >>>>> https://github.com/xpipe-io/xpipe/issues/485 . The root cause is that >>>>> the stage size is modified. >>>>> >>>>> When doing this, it temporarily or permanently switches to the size >>>>> the stage had prior to being maximized, leading to either a flicker or a >>>>> permanently broken scene that has the wrong size. This happens on Gnome >>>>> and >>>>> KDE for me with the latest JavaFX ea version. >>>>> >>>>> Here is a simple reproducer: >>>>> >>>>> import javafx.application.Application;import javafx.scene.Scene;import >>>>> javafx.scene.control.Button;import javafx.scene.layout.Region;import >>>>> javafx.scene.layout.StackPane;import javafx.stage.Stage; >>>>> import java.io.IOException;import java.util.Base64; >>>>> public class MaximizeLinuxBug extends Application { >>>>> >>>>> @Override public void start(Stage stage) throws IOException { >>>>> Scene scene = new Scene(createContent(), 640, 480); >>>>> var s = "data:text/css;base64," + >>>>> Base64.getEncoder().encodeToString(createCss().getBytes()); >>>>> scene.getStylesheets().add(s); >>>>> stage.setTitle("Hello!"); >>>>> stage.setScene(scene); >>>>> stage.show(); >>>>> stage.centerOnScreen(); >>>>> stage.setMaximized(true); >>>>> } >>>>> >>>>> private String createCss() { >>>>> return """ * { -fx-border-color: >>>>> red; -fx-border-width: 1; } >>>>> """; >>>>> } >>>>> >>>>> private Region createContent() { >>>>> var button = new Button("Click me!"); >>>>> button.setOnAction(event -> { >>>>> var w = button.getScene().getWindow(); >>>>> w.setWidth(w.getWidth() - 1); >>>>> event.consume(); >>>>> }); >>>>> var stack = new StackPane(button); >>>>> return stack; >>>>> } >>>>> >>>>> public static void main(String[] args) { >>>>> launch(); >>>>> } >>>>> } >>>>> >>>>> >>>>> Best >>>>> Christopher Schnick >>>>> >>>> > >
