Hi Michael,
Yes, this works! I wrote up a quick test app and it worked fine on the Mac.
I’ll try to write up a more comprehensive app but might not get around to it
for a few weeks.
Thanks,
Martin
> On Dec 6, 2024, at 8:40 AM, Michael Strauß wrote:
>
> Hi Martin,
>
> I've added the `HeaderB
Hi Martin,
I've added the `HeaderBar.overlappingSystemInset` property, which
controls whether the window buttons take up space in the layout.
Setting this property effectively ignores the system inset for layout
purposes.
In your example, you could now place one layout container in the
"leading"
Perhaps a better app to look at is Mac Weather. The sidebar background color
and translucency effects extend all the way to the top of the window. Easy to
set up with multiple header bars, considerably more complicated with just one.
If an application developer wants this effect we could either
: JavaFX controls in the title bar
Perhaps a better app to look at is Mac Weather. The sidebar background color
and translucency effects extend all the way to the top of the window. Easy to
set up with multiple header bars, considerably more complicated with just one.
If an application developer
That's correct. The only thing you can't do out-of-the-box with HeaderBar
is assign different backgrounds to each of the areas (HeaderBar is a
Region, which only has a single background).
Of course, you can place another layout container in one of the areas, and
give the nested container a differe
I don't really like the idea of supporting multiple HeaderBars. If we
did that, we'd have application developers deviating from the de-facto
implementation requirement that a HeaderBar be placed at the top of
the window, and extend its entire width. If that is not the case, then
leftSystemInset and
Michael,
On the Mac a common UI layout is to have a splitter view that extends to the
top of the window with separate toolbars in each panel. Have you given any
thought on supporting this layout in an EXTENDED window?
(I realize this is a Mac thing; Apple loves their sidebars. Microsoft dabbled
By the way, I came across this project:
https://github.com/xdsswar/nfx-lib?tab=readme-ov-file. It's only for
Windows, but allows manipulation of the title bar. Might be good to compare
with in terms of functionality.
On Mon, Oct 28, 2024 at 8:27 PM Andy Goryachev
wrote:
> Dear Michael:
>
>
>
> C
Dear Michael:
Could you add another row to the table in the JEP clarifying who is responsible
for the application title?
I would like to suggest to include this table in the javadoc - where do you
think it should be? HeaderBar?
Thanks,
-andy
From: openjfx-dev on behalf of Michael Strauß
> Right-click system menu: I think it should work rather well: on any platform,
> setting the context menu on the header works as expected (the FX menu
> appears), and on Windows, when the app does not set the context menu, the
> system menu appears as expected, unless the app sets its own (the
: Re: JEP: JavaFX controls in the title bar
> - Right-click system menu: you are right, we probably should not add an API
> to control the system menu. However, it might make sense to have the
> HeaderBar show the system menu on Windows by default, unless the
> onContextMenuRequestedPro
> - Right-click system menu: you are right, we probably should not add an API
> to control the system menu. However, it might make sense to have the
> HeaderBar show the system menu on Windows by default, unless the
> onContextMenuRequestedProperty is set. What do you think? Shouldn't the
>
riday, October 25, 2024 at 09:46
To:
Cc: openjfx-dev
Subject: Re: JEP: JavaFX controls in the title bar
> - Right-click system menu: is there any way to provide this functionality
> somehow? May be as a method in the HeaderBar?
This is probably more a question of whether we want to have t
> - Right-click system menu: is there any way to provide this functionality
> somehow? May be as a method in the HeaderBar?
This is probably more a question of whether we want to have this, not
of whether it is possible. The right-click system menu is a
Windows-only thing, it's not available on
will be more questions once we play with the initial
implementation.
Thank you,
-andy
From: openjfx-dev on behalf of Michael Strauß
Date: Thursday, October 24, 2024 at 16:29
To:
Cc: openjfx-dev
Subject: Re: JEP: JavaFX controls in the title bar
> In the table, you mention "custom i
> Perhaps the header bar should be a part of a new top-level container?
This would then be the first and only top-level container of JavaFX.
What would happen if you tried to add it to another container?
It would also make it harder to create certain UIs. Right now it is
pretty easy to place cont
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 which are not provided, per platform?
That is, columns: Feature | Linux | macOS | Windows | iOS | Andr
> 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
From: Thiago Milczarek Sayão
Date: Thursday, October 24, 2024 at 13:06
To: Andy Goryachev
Cc: Michael Strauß , openjfx-dev
Subject: [External] : Re: JEP: JavaFX controls in the title bar
Correcting the idea, it should be stage.initHeaderBar(), because it must know
the window would be undecorated
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
er 24, 2024 at 13:06
*To: *Andy Goryachev
*Cc: *Michael Strauß , openjfx-dev
*Subject: *[External] : Re: JEP: JavaFX controls in the title bar
Correcting the idea, it should be stage.initHeaderBar(), because it
must know the window would be undecorated and have resize grips
"installed"
different Scene
to an existing Stage?)
Maybe is it asking too much, and it's not worth it.
-andy
From: openjfx-dev on behalf of Kevin Rushforth
Date: Thursday, October 24, 2024 at 15:18
To: openjfx-dev@openjdk.org
Subject: Re: [External] : Re: JEP: JavaFX controls in the title bar
If you
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
answers will end up as clarifications in the JEP, as the
JEPs are typically the first thing an application developer looks in when
trying to understand the new feature.
Thank you for your work and patience!
-andy
From: openjfx-dev on behalf of Michael Strauß
Date: Thursday, October 24, 2
> 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
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
> 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 abstract base class that is only intended to
Hi Michael,
I like this proposal overall. It provides a commonly-requested feature
with a minimal API surface. While I share some of the concerns about
implementing it, it is reflective of modern UI design on all of the
desktop platforms, so I expect the platform vendors to continue
supportin
Michael,
I trust you on this one. I'm just throwing out some ideas, so maybe It
triggers a better idea :)
Ensemble8 has the "Advanced Stage" example. While it's a little unpractical
for a production application, some developers
might want to have different shapes of stages. So maybe it could be a
Hi Thiago!
If you use gtk_window_set_decorated() to remove the server-side title
bar, you also invariably lose the resizable window borders as they are
considered to be part of the "decoration".
We need the EXTENDED window style because it is materially different
from all of the other styles. The
Hi Michael,
Thank you for this effort.
It would be nice to have a TRANSPARENT window type with the HeaderBar so it
would be possible to have rounded corners on Linux.
I was going to suggest to not have a special window type (EXTENDED) at all
but then remembered the resize grips. Maybe they can b
35 matches
Mail list logo
