On Sun, 17 Jan 2021 15:49:33 GMT, Laurent Bourgès wrote:
> Changes:
> - Removed single-precision Marlin renderer
> - class name refactoring
> - fix prism
> - copyright year
How to run tests again ? I tried pull commands but it does nothing.
-
PR:
On Mon, 18 Jan 2021 15:48:20 GMT, Nir Lisker wrote:
>> wondering how small a doc error is small enough to go into this: just
>> noticed that Skinnable talks about "Control" in all of its methods - should
>> be "Skinnable" everywhere (except as example implementation in overview
>> doc), IMO.
On Mon, 18 Jan 2021 15:30:03 GMT, Jeanette Winzenburg
wrote:
>> The usual doc fixes (for OpenJFX 16).
>>
>> Can wait until RDP2 to see if something else comes up.
>
> wondering how small a doc error is small enough to go into this: just noticed
> that Skinnable talks about "Control" in all of
On Mon, 18 Jan 2021 15:07:34 GMT, Nir Lisker wrote:
> The usual doc fixes (for OpenJFX 16).
>
> Can wait until RDP2 to see if something else comes up.
wondering how small a doc error is small enough to go into this: just noticed
that Skinnable talks about "Control" in all of its methods -
The usual doc fixes (for OpenJFX 16).
Can wait until RDP2 to see if something else comes up.
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.java.net/jfx/pull/380/files
Webrev: https://webrevs.openjdk.java.net/?repo=jfx=380=00
Issue:
If I'm not mistaken, the original proposal was only for API, rather a
change in implementation.
On Mon, 18 Jan 2021, 12:47 pm Tom Eugelink, wrote:
> I'm curious about the reasons, because reinventing the wheel does not seem
> to be smart as well...
>
>
> On 18-1-2021 13:10, Michael Paus wrote:
I'm curious about the reasons, because reinventing the wheel does not seem to
be smart as well...
On 18-1-2021 13:10, Michael Paus wrote:
I just mentioned JTS in a tweet myself
(https://twitter.com/MichaelPaus/status/1351133904409915395)
but I think it would be a mistake to integrate that
Michael
I think I agree, I would not like to see JavaFX incorporated into JTS, for the
reasons you mention.
But I would like to see JTS, or at least the structure and logic incorporated
into JavaFX. This would then give the JavaFX world a useful set of tools that
would greatly extend its rather
I just mentioned JTS in a tweet myself
(https://twitter.com/MichaelPaus/status/1351133904409915395)
but I think it would be a mistake to integrate that into JavaFX for
various reasons. The main problem is
that Java never provided and used a graphics system independent geometry
and math library.
If we are adding non-static methods, then the whole "bundle" should
probably be included for consistency. E.g. union, subtract, etc.
On Mon, 18 Jan 2021, 11:43 am Nir Lisker, wrote:
> If this is to be implemented in JavaFX, then it's better to do (not
> tested):
>
> 1. Extract the intersection
I have used the JTS library (https://github.com/locationtech/jts) a lot over
the years; this is my 'go to' library for all 2D geometry routines. It is very
extensive and very well written by it’s main author Martin Davis. This library
has entities such as Geometry, LineString, Polygon etc and
If this is to be implemented in JavaFX, then it's better to do (not tested):
1. Extract the intersection computation from Shape.intersect
private static Area intersectionArea(Shape shape1, Shape shape2) {
Area result = shape1.getTransformedArea();
return
I just noticed that there is no „intuitive“ API to check whether two shapes
intersect with each other. The only way (I think) to do it is as follows:
Shape.intersect((Shape) child, circle).getBoundsInLocal().getWidth() != -1
If this is indeed the case I would like to propose that a method shall
On Sat, 16 Jan 2021 21:30:17 GMT, Kevin Rushforth wrote:
>> There are references to `eglx11` and `eglfb` in some of the
>> `buildSrc/*.gradle` files. I recommend cleaning those up, too.
>
> I also see references in `ES2Pipeline.java`, `GLFactory.java` and
> `PrismES2Defs.h`. Should those be
> Fix for JDK-8259864
> Remove java and native files that are not used/maintained in prism
> configurations.
Johan Vos has updated the pull request incrementally with one additional commit
since the last revision:
Process review comments.
Remove more references to egl{fb/x11}
Related to this question, there is the comment from Kevin about removing
references to es2-eglfb/es2-eglx11 in other files, e.g. ES2Pipeline.java [1]
While I believe this is a good idea, it opens room for more cleanup (or at
least more consistency):
In some cases, library names indicate a
Looking at the use case for this request, which is to warn the user while
typing in password fields, I tried to write some simple code for it using
the Optional approach:
Optional result = Platform.isKeyLocked(KeyCode.CAPS+LOCK);
result.ifPresentOrElse(on -> label.setText("Caps
17 matches
Mail list logo
