On Wed, 7 Aug 2024 02:13:12 GMT, John Hendrikx wrote:
>> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>>
>> This can be done with only a minor API break, as `SimpleSelector` and
>> `CompoundSelector` were public before. However, these classes could not be
>> constructed
On Wed, 7 Aug 2024 02:13:12 GMT, John Hendrikx wrote:
>> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>>
>> This can be done with only a minor API break, as `SimpleSelector` and
>> `CompoundSelector` were public before. However, these classes could not be
>> constructed
On Tue, 13 Aug 2024 11:54:16 GMT, Nir Lisker wrote:
> I see a lot of aversion from for-each loops in favor of indexed loops in the
> classes this PR touches. While I don't suggest to change it here, any idea
> why?
It's just the style the original code was written with. There is no reason to
On Tue, 13 Aug 2024 11:51:39 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix bug
>
> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 90:
>
>> 88: private final int specifi
On Tue, 13 Aug 2024 12:05:18 GMT, John Hendrikx wrote:
>> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 90:
>>
>>> 88: private final int specificity;
>>> 89:
>>> 90: @SuppressWarnings("removal")
>>
>> What is this removal warning suppression? I know it was there befo
> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>
> This can be done with only a minor API break, as `SimpleSelector` and
> `CompoundSelector` were public before. However, these classes could not be
> constructed by 3rd parties. The only way to access them was by doing a
On Wed, 7 Aug 2024 22:31:57 GMT, Andy Goryachev wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix bug
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/CompoundSelector.java
> line 75:
>
>> 73:
On Tue, 13 Aug 2024 01:03:32 GMT, Alexander Matveev
wrote:
> Yes, it compiles fine. It was changed by libFFI itself in 3.4.6. I think to
> be inline with rest of comments in this file.
What I meant was that you missed making that change when you updated the file.
The old line with the inline
On Wed, 7 Aug 2024 22:47:28 GMT, Andy Goryachev wrote:
> oops, yes, you did, my mistake. the master progressed since then, got me
> confused.
>
> I got a bunch of errors again after switching:
>
> ```
> Description ResourceTypePathLocation
> Cannot infer type arguments for Pa
On Tue, 13 Aug 2024 14:10:52 GMT, Nir Lisker wrote:
> > oops, yes, you did, my mistake. the master progressed since then, got me
> > confused.
> > I got a bunch of errors again after switching:
> > ```
> > Description ResourceTypePathLocation
> > Cannot infer type arguments for P
On Tue, 13 Aug 2024 14:18:39 GMT, John Hendrikx wrote:
> ```
> The method createShader(String, InputStream, Map,
> Map, int, boolean, boolean) in the type ShaderFactory is not
> applicable for the arguments (InputStream, HashMap,
> HashMap, int, boolean, boolean)
> ```
>
> I haven't worked on
On Mon, 12 Aug 2024 21:31:49 GMT, Kevin Rushforth wrote:
>> 1. Added logic to look in the standard locations for Visual Studio 2022,
>> with a fallback to 2019 and then 2017 if 2022 is not found. It will look in
>> the following locations:
>>
>> C:("Program Files"|"Program Files (x86)")\Micros
> - libFFI updated to 3.4.6.
> - No additional changes are done.
> - Tested on Windows, macOS and Linux with all supported formats.
Alexander Matveev has updated the pull request incrementally with one
additional commit since the last revision:
8336938: Update libFFI to 3.4.6 [v2]
---
On Tue, 13 Aug 2024 19:04:09 GMT, Alexander Matveev
wrote:
>> - libFFI updated to 3.4.6.
>> - No additional changes are done.
>> - Tested on Windows, macOS and Linux with all supported formats.
>
> Alexander Matveev has updated the pull request incrementally with one
> additional commit since t
On Mon, 12 Aug 2024 21:31:49 GMT, Kevin Rushforth wrote:
>> 1. Added logic to look in the standard locations for Visual Studio 2022,
>> with a fallback to 2019 and then 2017 if 2022 is not found. It will look in
>> the following locations:
>>
>> C:("Program Files"|"Program Files (x86)")\Micros
On Sat, 10 Aug 2024 16:21:11 GMT, Markus Mack wrote:
>> This PR is a fix for another IOOBE that I discovered while working on #1476.
>>
>> The PR simplifies the code for adding a series that already contains data by
>> adding the data points one-by-one.
>> As far as I can see no attempt was pre
On Tue, 13 Aug 2024 12:18:12 GMT, John Hendrikx wrote:
>> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>>
>> This can be done with only a minor API break, as `SimpleSelector` and
>> `CompoundSelector` were public before. However, these classes could not be
>> constructe
> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events
> cloned via `Event.copyFor()`.
>
> This change has a minimal API impact and allows for a fine-grained control of
> when to propagate and when not to propagate.
>
> The proposed change could make
> [JDK-8303209](https:/
On Fri, 9 Aug 2024 20:16:29 GMT, Martin Fox wrote:
> An EventDispatcher that creates a new event without linking it to the
> original will break this PR. But that's a consequence you're creating. You
> can't say the developer is making a choice about event linking when the very
> notion is new
On Tue, 13 Aug 2024 21:35:11 GMT, Andy Goryachev wrote:
>> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events
>> cloned via `Event.copyFor()`.
>>
>> This change has a minimal API impact and allows for a fine-grained control
>> of when to propagate and when not to propagat
On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao
wrote:
>> This replaces obsolete XIM and uses gtk api for IME.
>> Gtk uses [ibus](https://github.com/ibus/ibus)
>>
>> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative
>> positioning on `InputMethodRequest`.
>>
On Tue, 13 Aug 2024 06:27:51 GMT, Lukasz Kostyra wrote:
>> Thanks, that would be helpful. Let me know what you find.
>
> I checked on a Win 11 system where Build Tools 2022 are installed in default
> directory (no other Visual Studio edition) and the build failed with "Cannot
> locate Visual St
> 1. Added logic to look in the standard locations for Visual Studio 2022, with
> a fallback to 2019 and then 2017 if 2022 is not found. It will look in the
> following locations:
>
> C:("Program Files"|"Program Files (x86)")\Microsoft Visual
> Studio(2022|2019|2017)\
> (Enterprise|Profess
This changeset introduces the `Util.isOnWayland()` method and skips failing
tests on Wayland.
After that, all tests run on Wayland without failures.
-
Commit messages:
- add javadoc
- 8337827: [XWayland] Skip failing tests on Wayland
Changes: https://git.openjdk.org/jfx/pull/1536
24 matches
Mail list logo
