Allow more window customization
Andy Goryachev
andy.goryachev at oracle.com
Tue Apr 8 22:19:32 UTC 2025
I like the idea, it's a conceptually cleaner design.
I am sure you'd agree that whatever we do should retain compatibility with the existing application code.
-andy
From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago Milczarek Sayão <thiago.sayao at gmail.com>
Date: Tuesday, April 8, 2025 at 15:10
To: Michael Strauß <michaelstrau2 at gmail.com>
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Re: Allow more window customization
Hi everyone,
I present the transparent decorated JavaFx stage (with some tinkering, of course):
[cid:ii_m991jlyd0]
(I'm unsure if the list supports images, but there's a pink translucent decorated JavaFX Stage)
I had deleted my original comment, thinking it wouldn't gain any interest, but I'm glad it did.
I like this line of thought, as it allows more customization, as Michael pointed out,
and prevents us from ending up with combinations of properties on the StageStyle enum.
-- Thiago
Em ter., 8 de abr. de 2025 às 18:11, Michael Strauß <michaelstrau2 at gmail.com<mailto:michaelstrau2 at gmail.com>> escreveu:
Thiago suggested in a comment on PR 1605 [0] that the proposed
EXTENDED and EXTENDED_UTILITY stage styles might not be needed, and
that the "extended client area" attribute might be a toggle that is
independent of the stage style. This would allow users to, for
example, combine an extended client area with a transparent window.
While I think that the EXTENDED style is semantically quite different
from all the other stage styles, and as such should be its own stage
style, the idea has some merit.
But instead of making "extended-ness" an independent attribute, we
should look at the TRANSPARENT and UTILITY styles. The argument for
those two being separate stage styles is a lot less convincing. Both
of these could easily be independent attributes:
Stage.initTransparency(boolean) and Stage.initUtility(boolean).
The existing TRANSPARENT style would then be equivalent to the
UNDECORATED style with the initTransparency(true) attribute, while the
existing UTILITY style would be equivalent to the DECORATED style with
the initUtility(true) attribute.
As for PR 1605, this would also eliminate the EXTENDED_UTILITY style.
That would leave us with only three main stage styles [2]: DECORATED,
UNDECORATED, EXTENDED. We would deprecate all other styles (but
probably not for removal).
Having these two attributes as independent toggles would enable more
customization, and it would also solve another enhancement request
that asks for a utility-style undecorated transparent window [1].
What do you think of this idea?
[0] https://github.com/openjdk/jfx/pull/1605
[1] https://bugs.openjdk.org/browse/JDK-8091566
[2] not counting UNIFIED, which seems to be of questionable use
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250408/ea0744ac/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 40802 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250408/ea0744ac/image-0001.png>
More information about the openjfx-dev
mailing list