> One suggestion: in the "what is the EXTENDED stage style?" section, is it
> possible to provide a table showing which elements are provided by the OS and
> which are provided by FX, and which are not provided, per platform?
I've added a table with some information to the JEP.
> Also, since t
Continuing this line of thought, maybe when .initHeaderBar() is called the
DECORATED stage loses its native title bar and gets the FX one, without the
need to introduce the EXTENDED style?
Also it becomes impossible to create more than one header bar, or place it in a
weird location?
-andy
Fr
Em qui., 24 de out. de 2024 às 12:11, Andy Goryachev <
andy.goryac...@oracle.com> escreveu:
> Thank you.
>
>
>
> One suggestion: in the "what is the EXTENDED stage style?" section, is it
> possible to provide a table showing which elements are provided by the OS
> and which are provided by FX, and
> In the table, you mention "custom implementation" for resize borders. What
> does it mean (who is providing the implementation?)
glass-gtk is providing the implementation; added to the JEP
> Also in the table, please add "right click to invoke the system menu" (this
> might be a windows-on
Yeah, this idea creates more problems that it tries to solve.
-andy
From: openjfx-dev on behalf of Michael Strauß
Date: Thursday, October 24, 2024 at 15:57
To:
Cc: openjfx-dev@openjdk.org
Subject: Re: [External] : Re: JEP: JavaFX controls in the title bar
> Perhaps the header bar should be
> The RichTextArea control
> ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom
> control that needs non-trivial navigation within complex or wrapped text
> needs a public API to get information about text layout.
>
> This change fixes the missing functionality by addin
On Wed, 23 Oct 2024 18:51:27 GMT, Kevin Rushforth wrote:
>> Andy Goryachev has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 13 additional
>> comm
If you want arbitrary content in it, then it should be a container in
the scene graph. The idea of a layout container added directly to the
stage doesn't seem clean to me.
-- Kevin
On 10/24/2024 3:14 PM, Andy Goryachev wrote:
Continuing this line of thought, maybe when .initHeaderBar() is
Perhaps the header bar should be a part of a new top-level container?
We may or may not need EXTENDED, if for example, the stage can examine whether
the scene contains that particular type of container and drops the native title
bar, or something like that? (Do we really support setting a diffe
Em qui., 24 de out. de 2024 18:32, Michael Strauß
escreveu:
> > Sounds like a good idea, maybe stage.setHeaderBar(), which can be the
> HeaderBar provided or a custom Control (any control, or that extends
> HeaderBar, because the reserved space on Mac).
> >
> > This also limits the control usage
Thank you, Michael, this clarifies a lot. And thank you for updating the JEP.
In the table, you mention "custom implementation" for resize borders. What
does it mean (who is providing the implementation?)
Also in the table, please add "right click to invoke the system menu" (this
might be a w
> Sounds like a good idea, maybe stage.setHeaderBar(), which can be the
> HeaderBar provided or a custom Control (any control, or that extends
> HeaderBar, because the reserved space on Mac).
>
> This also limits the control usage on the top.
What would be the advantage of this, compared to the
Correcting the idea, it should be stage.initHeaderBar(), because it must
know the window would be undecorated and have resize grips "installed".
Em qui., 24 de out. de 2024 às 16:09, Thiago Milczarek Sayão <
thiago.sa...@gmail.com> escreveu:
>
>
> Em qui., 24 de out. de 2024 às 12:11, Andy Goryac
> Let's consider the typical case of a root container that is either a
> BorderPane or a VBox, with a HeaderBar in the top portion of the
> BorderPane or as the first (top) child of the VBox. In that case, the
> root container will size the HeaderBar to its preferred height. If there
> are no child
> This PR is a new take on a highly requested feature: JavaFX controls in the
> header bar (see also #594 for an earlier iteration).
>
> This is a feature with many possible ways to skin the cat, and it has taken
> quite a bit of effort to come up with a good user model. In contrast to the
> pr
On 10/23/2024 8:00 AM, Michael Strauß wrote:
I presume that the preferred width and height of HeaderBarBase is the
width of the window and the height of the system-reserved area for
window buttons?
HeaderBarBase is a resizable `Region`, and as such has no preferred
width or height. It is an
Hi,
I'm not really sure about this feature, but integration with linux
desktops should be done with XDG Desktop Portals
https://flatpak.github.io/xdg-desktop-portal/docs/
Em qua., 23 de out. de 2024 às 14:23, David Kopp
escreveu:
> That is a good question. I need to look into what Ubuntu doe
17 matches
Mail list logo
