Re: Class ButtonAccessibility is implemented twice in JFX 17.0.13

[Johan Vos]

This is a good question. JDK-8311806 is a P4 bug, so my (non-formal)
algorithm would say not to backport this. But then, this clearly can create
crashes and it is a simple fix that is not affecting other platforms, so I
am very much in favour of backporting it. Note that I raised this point on
the jdk-dev list [1] and it is discussed there as well [2].
>From those discussions, it becomes clear that a formal algorithm is most
likely not enough, and there should always be room for manual judgement.

In this particular case, I would vote +1 for backporting it.

- Johan

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-November/009625.html
[2] https://mail.openjdk.org/pipermail/jdk-dev/2024-November/009629.html


On Thu, Nov 14, 2024 at 9:10 PM Kevin Rushforth 
wrote:

> This does look like JDK-8311806.
>
> Gluon maintains jfx17u, so Johan can comment on your request.
>
> -- Kevin
>
>
> On 11/14/2024 2:29 AM, Glavo wrote:
>
> Hi,
>
> We received a JVM crash report[1] for our JavaFX application and I noticed
> it contained these lines:
>
> objc[71933]: Class ButtonAccessibility is implemented in both
>> /Library/Java/JavaVirtualMachines/jdk-22.jdk/Contents/Home/lib/libawt_lwawt.dylib
>> (0x100d6caa0) and /Users/lolimaster/.openjfx/cache/17.0.13/libglass.dylib
>> (0x14c4fe218). One of the two will be used. Which one is undefined.
>
>
> *** Terminating app due to uncaught exception
>> 'NSInvalidArgumentException', reason: '-[ButtonAccessibility
>> initWithEnv:accessible:]: unrecognized selector sent to instance
>> 0x624fb540'
>
>
> This crash occurred after we bumped the JavaFX from 19.0.2.1 to 17.0.13.
> It looks like it's related to JDK-8311806, is it?
> If yes, I'd like to request a backport of the patch that fixes it to
> JavaFX 17u.
>
> Glavo
>
> [1]: https://github.com/HMCL-dev/HMCL/issues/3409
>
>
>
>

Scene 3D objects throw exception on Android devices

[Ashley Hales]

Hi,

I posted a thread some time ago about Scene 3D objects causing a error when
they try to create the shader.  At the time I was advised to recompile the
project using the new Gluon library rather than JavaFXPorts.  I have now
done this but the result is not compatible with my device.  I have found
that the Gluon project works fine on a Motorola device running Android 13
and the JavaFXPorts project works on an old Samsung device running Android
4.4.2.  However the Gluon project won't even install on my intended target
device, which is an MBOX running Android 6.0.1, but the JavaFXPorts project
installs fine but throws  'java.lang.RuntimeException: Error creating shader
program' on the MBOX.  I have found that the MBOX will run projects not
containing any 3D objects, for example the two sample projects included in
the Dalvik SDK - Ensemble8 and HelloAndroid - work fine.  Is there any way
around this using the JavaFXPorts technology as this has produced the best
results?  When I try to do a push install to  the MBOX using ADB it gives an
error of 'Failure [INSTALL_FAILED_NO_MATCHING_ABIS]'.  My searches online
indicate that this may be due to the version of the NDK it was compiled with
but I have found that the project only seems to compile with the Android 21
NDK.

Thanks for your help,

Ashley


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Re: JEP: JavaFX controls in the title bar

[Michael Strauß]

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 rightSystemInset don't meanignfully correspond to
the visuals on display. In addition to that, HeaderBarBase negotiates
its height with the platform decorations on macOS, and having more
than one would require us to think about what would happen if they
were different in height.

Why not create a SplitHeaderBar instead? You could have two slots, and
maybe also accept different background paints for the two slots. This
is all possible within the proposed API.



On Fri, Nov 15, 2024 at 10:09 PM Martin Fox  wrote:
>
> 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 
> with this design language but it seems to be fading away. I have seen it in a 
> few Windows apps like 1Password.)
>
> In UIKit Apple implements this using separate views. The equivalent in JavaFX 
> would be to add a separate HeaderBarBase object to the top of each panel in a 
> SplitPane. That would require supporting multiple HeaderBarBase instances and 
> providing an API to tell one to ignore leftSystemInset or rightSystemInset 
> (or both). I like this solution since it allows the background visuals for 
> each header bar to be customized.
>
> The way Apple shoe-horned this into the older AppKit is a bit less elegant. 
> There’s still one NSToolbar that spans the entire window. A developer can add 
> special items to the toolbar that track the dividers in an NSSplitView. I 
> would let developers roll their own solutions if they want that design. 
> Replicating that in JavaFX wouldn’t require any alterations to the 
> HeaderBarBase class and it’s too specialized to be added to HeaderBar.
>
> Martin

Re: JEP: JavaFX controls in the title bar

[Andy Goryachev]

weather app effect: extend the HeaderBar to the full height, use that as the 
main container.

multiple HeaderBars is something we probably should avoid.

-andy


From: openjfx-dev  on behalf of Martin Fox 

Date: Friday, November 15, 2024 at 15:24
To: Michael Strauß 
Cc: OpenJFX 
Subject: Re: JEP: 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 wants this effect we could either tell them to 
create multiple HeaderBars and make sure they’re all the same height (which is 
what they were probably planning to do anyway) OR we could tell them to use a 
single HeaderBarBase and roll their own solution from scratch including 
duplicating the SplitPane’s visuals.

> On Nov 15, 2024, at 2:31 PM, Michael Strauß  wrote:
>
> 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.

The Mac API that implements the split UI automatically creates enough toolbars 
to span the window, places them in the title bar area, and ensures they’re all 
the same height. I agree the JavaFX API is more piecemeal which would allow 
developers to mis-configure the UI. But why would they?

I’m not going to press on this. It just seems that with a little tweaking we 
could make multiple HeaderBars work and it would provide a cleaner solution 
going forward.

Martin

Re: RFR: 8290037: Bindings should clean up after themselves when their weak listeners go out of scope [v2]

[Marius Hanl]

On Thu, 14 Jul 2022 19:48:04 GMT, John Hendrikx  wrote:

>> This is an initial (incomplete) implementation of 8290037 for evaluation.
>> 
>> If the approach is agreed, I will modify the rest of the `*PropertyBase` 
>> classes which use weak listeners, and add some tests.
>> 
>> I didn't use `Cleaner` because cleaning up a listener may block.
>
> John Hendrikx has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Made accidental public field private

Does this address the problem that Bindings seem to not clean up properly, e.g. 
something a Binding like this:
`xyz.bind(col.visibleProperty().and(col.resizableProperty())`
seems to not properly cleanup after calling:
`xyz.undbind()`
as when checking the listener in the `ExpressionHelper`, the 
`col.visibleProperty()` Binding is still in there (`xyz` binding is of course 
cleared, but this remains).

This is something I discovered some days ago and was not aware that this is the 
case, although not sure if I miss something here.

-

PR Comment: https://git.openjdk.org/jfx/pull/827#issuecomment-2480199574

Re: RFR: 8301121: RichTextArea Control (Incubator) [v45]

[Andy Goryachev]

> Incubating a new feature - rich text control, **RichTextArea**, intended to 
> bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The 
> main design goal is to provide a control that is complete enough to be useful 
> out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly 
> impossible to get right the first time, even after an extensive review. We 
> are, therefore, introducing this in an incubating module, 
> **jfx.incubator.richtext**. This will allow us to evolve the API in future 
> releases without the strict compatibility constraints that other JavaFX 
> modules have.
> 
> Please check out two manual test applications - one for RichTextArea 
> (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). 
> Also, a small example provides a standalone rich text editor, see 
> **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather 
> than implementation.  There **will be** changes to the implementation once/if 
> the module is promoted to the core by popular demand.  The goal of the 
> incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): 
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: 
> https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: 
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains 63 commits:

 - whitespace
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - save as
 - removed function handler
 - removed add handler last
 - use focus traversal api
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - settings
 - comment
 - review comments
 - ... and 53 more: https://git.openjdk.org/jfx/compare/dd600658...52a7dba1

-

Changes: https://git.openjdk.org/jfx/pull/1524/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=44
  Stats: 40118 lines in 210 files changed: 40104 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

PR: https://git.openjdk.org/jfx/pull/1524

Re: JEP: JavaFX controls in the title bar

[Michael Strauß]

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 different background.

But this doesn't really work for the part of the header bar that is
obscured by window controls. For example, let's assume we want to have a
split header bar, but have the background of the left area be different
than the background of the right area. If we simply place another container
in the left area, and change its background, then the new background will
be shifted to the right on macOS (due to the window controls on the left
side of the window), and will not be shown below the window controls.

Application developers could solve this problem in several ways, but here's
one: make the HeaderBar background transparent, and place a background node
with the appropriate width and height _below_ the HeaderBar in the scene
graph.


On Sat, Nov 16, 2024 at 12:07 AM Andy Goryachev 
wrote:

>
>
> I think the Notes-like UI can be implemented using the proposed HeaderBar
> (HB), all one needs to do is to bind the width of the left part in the HB
> to the split pane's divider position, without the need for multiple HB.
>
>
>
> -andy
>

Re: JEP: JavaFX controls in the title bar

[Martin Fox]

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 
with this design language but it seems to be fading away. I have seen it in a 
few Windows apps like 1Password.)

In UIKit Apple implements this using separate views. The equivalent in JavaFX 
would be to add a separate HeaderBarBase object to the top of each panel in a 
SplitPane. That would require supporting multiple HeaderBarBase instances and 
providing an API to tell one to ignore leftSystemInset or rightSystemInset (or 
both). I like this solution since it allows the background visuals for each 
header bar to be customized.

The way Apple shoe-horned this into the older AppKit is a bit less elegant. 
There’s still one NSToolbar that spans the entire window. A developer can add 
special items to the toolbar that track the dividers in an NSSplitView. I would 
let developers roll their own solutions if they want that design. Replicating 
that in JavaFX wouldn’t require any alterations to the HeaderBarBase class and 
it’s too specialized to be added to HeaderBar.

Martin

> On Oct 23, 2024, at 7:19 AM, Kevin Rushforth  
> wrote:
> 
> 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 supporting the features this needs 
> to run.
> 
> You had mentioned in your PR the possibility of making this a preview 
> feature, which seems like a good idea. I think it is worth reviving the 
> preview feature proposal, and to consider using it for this feature.
> 
> I have a few overall questions after an initial reading of the JEP. I'll take 
> a closer look and send more specific feedback.
> 
> 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?
> 
> Are leftSystemInset and rightSystemInset read-only?
> 
> What is the behavior if an application adds more than one HeaderBar? What if 
> they add a HeaderBar that isn't positioned at the top of the Stage? What is 
> the behavior if an app adds a HeaderBar to a DECORATED or UNDECORATED Stage?
> 
> I want to make sure I understand the centering policy: To my eyes, the text 
> field in the macOS example is not horizontally centered in the window. Is 
> this a bug or am I misunderstanding something?
> 
> As Andy already mentioned in the PR, the `EXTENDED` StageStyle should be a 
> ConditionalFeature, similar to TRANSPARENT or UNIFIED. Oh, I see from the PR 
> that you already did this. Can you update the JEP to indicate this?
> 
> And speaking of UNIFIED, it might be worth mentioning the differences between 
> EXTENDED and UNIFIED. Somewhat related to this, we have talked about 
> deprecating (not for removal) UNIFIED and always returning `false` from 
> `ConditionalFeature.isSupported(UNIFIED_WINDOW)`.
> 
> -- Kevin
> 
> On 10/22/2024 4:55 PM, Michael Strauß wrote:
>> Hi everyone,
>> 
>> the discussion in PR #1605 has shown that the proposed feature needs a
>> better presentation in a JEP-like format, so here it is:
>> 
>> https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09
> 

RFR: 8341687: Memory leak in TableView after interacting with TableMenuButton

[Marius Hanl]

There are multiple issues in the `TableMenu` logic that result in a memory leak.

The following problems are now fixed with this PR:
- The listener, that is registered to the `col.visibleProperty()` was not weak 
nor was it ever unregistered
   - The fix is to do pretty much the same that was already done with the 
`col.textProperty()` listener
- The `col.visibleProperty()` and `col.textProperty()` where added again and 
again and again to the column when the columns changed (which happens when 
toggling the visibility).
  - The fix is to add the listeners once - when the `MenuItem` is created. This 
way, when the `TableMenu` is rebuild and the cached `MenuItem` is used, the 
whole listener logic is not run again for the column

-

Commit messages:
 - 8341687: Memory leak in TableView after interacting with TableMenuButton

Changes: https://git.openjdk.org/jfx/pull/1640/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1640&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341687
  Stats: 177 lines in 3 files changed: 159 ins; 14 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1640.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1640/head:pull/1640

PR: https://git.openjdk.org/jfx/pull/1640

Re: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session overlaps with an FX ScreenCast session [v2]

[Kevin Rushforth]

On Fri, 15 Nov 2024 02:21:57 GMT, Alexander Zvegintsev  
wrote:

>> This is the FX counterpart of the 
>> [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / 
>> `b.`(aka crash prevention part)
>> 
>> It does not crash without the 
>> [openjdk/jdk/pull/22131](https://github.com/openjdk/jdk/pull/22131) / `a.` 
>> part.
>> 
>> The crash prevention part  is the same for the JDK and JavaFX, except that 
>> this PR includes a test.
>> 
>>  
>> 
>> Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and 
>> their implementations are almost identical).
>> This is to reduce overhead in case of frequent consecutive screen captures.
>> 
>> When we perform a 
>> [cleanup](https://github.com/openjdk/jdk/blob/db56266ad164b4ecae59451dc0a832097dbfbd8e/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c#L91)
>>  to close the session, we internally call 
>> [`pw_deinit`](https://docs.pipewire.org/group__pw__pipewire.html#gafa6045cd7391b467af4575c6752d6c4e).
>> 
>> It becomes a problem if these sessions overlap in time, so that the second 
>> session cleanup crashes when it tries to call pipewire functions without 
>> initializing the pipewire system by  
>> [`pw_init`](https://docs.pipewire.org/group__pw__pipewire.html#ga06c879b2d800579f4724109054368d99)
>>  (please note that `This function can be called multiple times.`).
>> 
>> So the solution is not to call `pw_deinit` because we don't really need it, 
>> and it needs to be applied to both the JDK and JavaFX.
>> 
>> [jdk 
>> commit](https://github.com/openjdk/jdk/pull/22131/commits/19956fda202269e92ec70670bc88c8d3c7accf73)
>>  / [jfx 
>> commit](https://github.com/openjdk/jfx/pull/1639/commits/dba8a8871a38831d0a0da697a2be41f0c240c8f0)
>> 
>> 
>> 
>> The newly introduced test is disabled for now(as part  of 
>> [JDK-8335470](https://bugs.openjdk.org/browse/JDK-8335470)), because it 
>> requires the fix on both the JavaFX and JDK sides.
>> For the same reason 
>> `tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java`
>>  and `tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java` are 
>> not enabled back.
>> But if the JDK and JavaFX have the fixes, everything works fine.
>> Testing in other different scenarios also looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with two 
> additional commits since the last revision:
> 
>  - test cleanup
>  - add missing copyright header

@azvegint All of the GHA builds failed with what looks like an infra problem 
(connection to `download.eclipse.org` failed). Can you rerun it?

I'll test this both with and without the JDK fix for openjdk/jdk#22131

-

PR Comment: https://git.openjdk.org/jfx/pull/1639#issuecomment-2478749887

Re: RFR: 8343196: Add build property to identify experimental builds of JavaFX

[Ambarish Rapte]

On Thu, 14 Nov 2024 12:02:02 GMT, Ambarish Rapte  wrote:

>> Introduce a new build property `jfx.experimental.release.suffix` to be used 
>> for the early access builds of an under development feature in JavaFX.
>> This property would be set to a value ONLY in a branch specific to an 
>> experiment in [jfx-sandbox](https://github.com/openjdk/jfx-sandbox) repo.
>> For example:
>> For the metal branch in jfx-sandbox repo, it would be set to `-metal`.  The 
>> javafx.version for the early access build generated from that branch would 
>> be `24-metal`.
>> 
>> And it would always be empty for master branch in both main jfx repo and in 
>> jfx-sandbox repo.
>> This change has no effect on a regular developer build from master branch.
>
> @kevinrushforth  Please take a look.

> @arapte Can you merge in the latest master?

Thanks @kevinrushforth , The checks pass after merging in the latest master.

-

PR Comment: https://git.openjdk.org/jfx/pull/1637#issuecomment-2478766562

Re: [External] : Re: Class ButtonAccessibility is implemented twice in JFX 17.0.13

[Kevin Rushforth]

FWIW, since it is crashing, I would suggest that the priority -- at 
least for jfx17u -- is higher than a P4 (maybe a P2). We usually don't 
take the time to adjust the priority of a bug after it is fixed, so we 
will sometimes backport bugs with a lower priority than would otherwise 
meet the criteria. This one seems to be a good candidate.


-- Kevin


On 11/15/2024 1:10 AM, Johan Vos wrote:
This is a good question. JDK-8311806 is a P4 bug, so my (non-formal) 
algorithm would say not to backport this. But then, this clearly can 
create crashes and it is a simple fix that is not affecting other 
platforms, so I am very much in favour of backporting it. Note that I 
raised this point on the jdk-dev list [1] and it is discussed there as 
well [2].
From those discussions, it becomes clear that a formal algorithm is 
most likely not enough, and there should always be room for manual 
judgement.


In this particular case, I would vote +1 for backporting it.

- Johan

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-November/009625.html
[2] https://mail.openjdk.org/pipermail/jdk-dev/2024-November/009629.html


On Thu, Nov 14, 2024 at 9:10 PM Kevin Rushforth 
 wrote:


This does look like JDK-8311806.

Gluon maintains jfx17u, so Johan can comment on your request.

-- Kevin


On 11/14/2024 2:29 AM, Glavo wrote:

Hi,

We received a JVM crash report[1] for our JavaFX application and
I noticed it contained these lines:

objc[71933]: Class ButtonAccessibility is implemented in both

/Library/Java/JavaVirtualMachines/jdk-22.jdk/Contents/Home/lib/libawt_lwawt.dylib
(0x100d6caa0) and
/Users/lolimaster/.openjfx/cache/17.0.13/libglass.dylib
(0x14c4fe218). One of the two will be used. Which one is
undefined.


*** Terminating app due to uncaught exception
'NSInvalidArgumentException', reason: '-[ButtonAccessibility
initWithEnv:accessible:]: unrecognized selector sent to
instance 0x624fb540'


This crash occurred after we bumped the JavaFX from 19.0.2.1 to
17.0.13.
It looks like it's related to JDK-8311806, is it?
If yes, I'd like to request a backport of the patch that fixes it
to JavaFX 17u.

Glavo

[1]: https://github.com/HMCL-dev/HMCL/issues/3409

[jfx17u] RFR: 8311806: Class ButtonAccessibility is implemented twice

[Johan Vos]

8311806: Class ButtonAccessibility is implemented twice

-

Commit messages:
 - Backport ad5e66a7ca31994ecbdae3fc7d0b951e0a6f8197

Changes: https://git.openjdk.org/jfx17u/pull/209/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=209&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311806
  Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jfx17u/pull/209.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/209/head:pull/209

PR: https://git.openjdk.org/jfx17u/pull/209

[jfx17u] Integrated: 8311806: Class ButtonAccessibility is implemented twice

[Johan Vos]

On Fri, 15 Nov 2024 09:29:17 GMT, Johan Vos  wrote:

> 8311806: Class ButtonAccessibility is implemented twice

This pull request has now been integrated.

Changeset: 00dc6895
Author:Johan Vos 
URL:   
https://git.openjdk.org/jfx17u/commit/00dc6895117b2aff8a5120ce9d32bc8317a704a5
Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod

8311806: Class ButtonAccessibility is implemented twice

Backport-of: ad5e66a7ca31994ecbdae3fc7d0b951e0a6f8197

-

PR: https://git.openjdk.org/jfx17u/pull/209

Re: RFR: 8335469: [XWayland] crash when an AWT ScreenCast session overlaps with an FX ScreenCast session [v2]

[Alexander Zvegintsev]

On Fri, 15 Nov 2024 12:53:46 GMT, Kevin Rushforth  wrote:

> Can you rerun it?

Sure, done

https://github.com/azvegint/jfx/actions/runs/11849042656

-

PR Comment: https://git.openjdk.org/jfx/pull/1639#issuecomment-2478894882

Re: Scene 3D objects throw exception on Android devices

[Nir Lisker]

This is a question for Gluon, not OpenJFX, as JavaFXPorts and the newer
Gluon client are not part of JavaFX (it's the other way around). I suggest
StackOverflow, they are active there.

I can tell you that JavaFXPorts was EOL years ago. Also that the MBOX might
not have a pipeline with 3D support (in JavaFX it's a ConditionalFeature),
so that's why it might be failing. You might have some luck with setting
the pipeline to the software (SW) pipeline.

On Fri, Nov 15, 2024 at 5:14 PM Ashley Hales 
wrote:

> Hi,
>
> I posted a thread some time ago about Scene 3D objects causing a error when
> they try to create the shader.  At the time I was advised to recompile the
> project using the new Gluon library rather than JavaFXPorts.  I have now
> done this but the result is not compatible with my device.  I have found
> that the Gluon project works fine on a Motorola device running Android 13
> and the JavaFXPorts project works on an old Samsung device running Android
> 4.4.2.  However the Gluon project won't even install on my intended target
> device, which is an MBOX running Android 6.0.1, but the JavaFXPorts project
> installs fine but throws  'java.lang.RuntimeException: Error creating
> shader
> program' on the MBOX.  I have found that the MBOX will run projects not
> containing any 3D objects, for example the two sample projects included in
> the Dalvik SDK - Ensemble8 and HelloAndroid - work fine.  Is there any way
> around this using the JavaFXPorts technology as this has produced the best
> results?  When I try to do a push install to  the MBOX using ADB it gives
> an
> error of 'Failure [INSTALL_FAILED_NO_MATCHING_ABIS]'.  My searches online
> indicate that this may be due to the version of the NDK it was compiled
> with
> but I have found that the project only seems to compile with the Android 21
> NDK.
>
> Thanks for your help,
>
> Ashley
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>

Re: RFR: 8301121: RichTextArea Control (Incubator) [v44]

[Andy Goryachev]

> Incubating a new feature - rich text control, **RichTextArea**, intended to 
> bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The 
> main design goal is to provide a control that is complete enough to be useful 
> out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly 
> impossible to get right the first time, even after an extensive review. We 
> are, therefore, introducing this in an incubating module, 
> **jfx.incubator.richtext**. This will allow us to evolve the API in future 
> releases without the strict compatibility constraints that other JavaFX 
> modules have.
> 
> Please check out two manual test applications - one for RichTextArea 
> (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). 
> Also, a small example provides a standalone rich text editor, see 
> **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather 
> than implementation.  There **will be** changes to the implementation once/if 
> the module is promoted to the core by popular demand.  The goal of the 
> incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): 
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: 
> https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: 
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request incrementally with one additional 
commit since the last revision:

  save as

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/ff3f5afe..6a02a757

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=43
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=42-43

  Stats: 109 lines in 4 files changed: 69 ins; 30 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

PR: https://git.openjdk.org/jfx/pull/1524

Re: JEP: JavaFX controls in the title bar

[Martin Fox]

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 tell them to 
create multiple HeaderBars and make sure they’re all the same height (which is 
what they were probably planning to do anyway) OR we could tell them to use a 
single HeaderBarBase and roll their own solution from scratch including 
duplicating the SplitPane’s visuals.

> On Nov 15, 2024, at 2:31 PM, Michael Strauß  wrote:
> 
> 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.

The Mac API that implements the split UI automatically creates enough toolbars 
to span the window, places them in the title bar area, and ensures they’re all 
the same height. I agree the JavaFX API is more piecemeal which would allow 
developers to mis-configure the UI. But why would they?

I’m not going to press on this. It just seems that with a little tweaking we 
could make multiple HeaderBars work and it would provide a cleaner solution 
going forward.

Martin