On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao
wrote:
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window =
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
>
On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao
wrote:
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window =
I'm not sure what you're proposing. Move what, to where, and for what use?
On Tue, Sep 21, 2021 at 8:02 PM Eric Bresie wrote:
> I’m very much an Observer here ;-) but
>
> Given the comparisons with FX and React implementations, is there value in
> moving some of this out of here and into the
I’m very much an Observer here ;-) but
Given the comparisons with FX and React implementations, is there value in
moving some of this out of here and into the JDK proper context making it
potentially usable outside of fx or react circles?
I’m reminded of old JDK workings when someone might be
On Tue, 21 Sep 2021 12:45:20 GMT, Kevin Rushforth wrote:
> As mentioned in JBS, the `clearQuad` methods in `D3DGraphics` and
> `ES2Graphics` are now identical, which should have been the case all along.
> The fact that they weren't identical was the source of a bug that was only
> discovered
On Tue, 21 Sep 2021 12:45:20 GMT, Kevin Rushforth wrote:
> As mentioned in JBS, the `clearQuad` methods in `D3DGraphics` and
> `ES2Graphics` are now identical, which should have been the case all along.
> The fact that they weren't identical was the source of a bug that was only
> discovered
As mentioned in JBS, the `clearQuad` methods in `D3DGraphics` and `ES2Graphics`
are now identical, which should have been the case all along. The fact that
they weren't identical was the source of a bug that was only discovered during
the testing of
On Fri, 2 Jul 2021 11:01:56 GMT, Jose Pereda wrote:
> Currently, `WebPage` has already a public `setBackgroundColor()` method, but
> the class is not public. Therefore, public API is needed in `WebView` to
> allow developers access to it.
>
> In line with the `fontSmoothingType` property,
On Tue, 21 Sep 2021 08:53:07 GMT, Hadzic Samir wrote:
>> JBS bug: [JDK-8090158](https://bugs.openjdk.java.net/browse/JDK-8090158)
>>
>> The javadoc of the ScrollBar#adjustValue specifically says that it will
>> adjust the value based on the block increment value. Therefore, there is no
>>
On Thu, 16 Sep 2021 13:22:32 GMT, Florian Kirmaier
wrote:
>> When using Swing it's possible to generate a Deadlock.
>> It's related to the nested eventloop started in enterFullScreenExitingLoop
>> - and the RenderLock aquired when using setView in Scene.
>> Sample Programm and Threaddump are
On Thu, 16 Sep 2021 22:25:27 GMT, Jose Pereda wrote:
>> Currently, `WebPage` has already a public `setBackgroundColor()` method, but
>> the class is not public. Therefore, public API is needed in `WebView` to
>> allow developers access to it.
>>
>> In line with the `fontSmoothingType`
>
> The OrElseBinding is incorrect
>
Yes, that was a typo with the order of the arguments in the ternary
statement.
I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
> think the tests would become pretty unreadable and less useful /
> thourough otherwise).
>
> What are the
As also written in a comment
here: https://github.com/openjdk/jfx/pull/610
I would like to propose one more convenience method which should be
added to JavaFX:
public static Border stroke(Paint stroke, double width) {
return new Border(new BorderStroke(stroke,
On Tue, 21 Sep 2021 08:53:07 GMT, Hadzic Samir wrote:
>> JBS bug: [JDK-8090158](https://bugs.openjdk.java.net/browse/JDK-8090158)
>>
>> The javadoc of the ScrollBar#adjustValue specifically says that it will
>> adjust the value based on the block increment value. Therefore, there is no
>>
> JBS bug: [JDK-8090158](https://bugs.openjdk.java.net/browse/JDK-8090158)
>
> The javadoc of the ScrollBar#adjustValue specifically says that it will
> adjust the value based on the block increment value. Therefore, there is no
> reason to stop at the given value when reaching an end.
Hadzic
On Tue, 20 Jul 2021 09:12:05 GMT, Hadzic Samir wrote:
> JBS bug: [JDK-8090158](https://bugs.openjdk.java.net/browse/JDK-8090158)
>
> The javadoc of the ScrollBar#adjustValue specifically says that it will
> adjust the value based on the block increment value. Therefore, there is no
> reason
17 matches
Mail list logo
