On Fri, 7 Feb 2020 10:06:59 GMT, Ambarish Rapte wrote:
>> In general, this makes sense. I need to look into more detail that the
>> additional calls for freeing resources (in case of errors) don't cause e.g.
>> segmentation violations and lead to a crash -- which would be worse than
>>
> This proposed change does the following:
>
> - Ports DND target to use GTK reducing code size and adding extra text /
> image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward
> This proposed change does the following:
>
> - Ports DND target to use GTK reducing code size and adding extra text /
> image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward
> This proposed change does the following:
>
> - Ports DND target to use GTK reducing code size and adding extra text /
> image formats (such as .gif);
> - Use gtk signals instead of gdk events (also to reduce code size);
> - Simplifies geometry (sizing/positioning) with a more straightforward
On Mon, 10 Feb 2020 12:26:53 GMT, Johan Vos wrote:
> * add support for the "resource" protocol (which is used in the GraalVM URLs
> pointing to statically bundled resources)
> * avoid duplicate symbols with different gst plugins
> * statically register gst plugins
On Mon, 10 Feb 2020 12:26:53 GMT, Johan Vos wrote:
> * add support for the "resource" protocol (which is used in the GraalVM URLs
> pointing to statically bundled resources)
> * avoid duplicate symbols with different gst plugins
> * statically register gst plugins
I added a comment about using
My quick take is that this seems like a bug.
-- Kevin
On 2/10/2020 8:21 AM, Dirk Lemmermann wrote:
Need some help: I noticed that the DRAG_DONE event does not tell me the
location of the event. I am working on a docking framework and the fact that I
am receiving a DRAG_DONE event but not a
On Mon, 10 Feb 2020 16:45:26 GMT, Kevin Rushforth wrote:
>> The pull request has been updated with 1 additional commit.
>
> Marked as reviewed by kcr (Lead).
@johanvos the Skara team enabled the invalidation of stale reviews. Can you
re-review this when you get a chance?
Btw, tt isn't clear
On Mon, 10 Feb 2020 16:45:52 GMT, Ambarish Rapte wrote:
>> The finalize() method is deprecated in JDK9. See [Java 9 deprecated
>> features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html).
>> And so the
>>
Need some help: I noticed that the DRAG_DONE event does not tell me the
location of the event. I am working on a docking framework and the fact that I
am receiving a DRAG_DONE event but not a DRAG_DROPPED tells me that the user
dragged a docking item out of the docking container. If that is the
On Mon, 10 Feb 2020 12:26:53 GMT, Johan Vos wrote:
> * add support for the "resource" protocol (which is used in the GraalVM URLs
> pointing to statically bundled resources)
> * avoid duplicate symbols with different gst plugins
> * statically register gst plugins
I'll review this and also ask
And one last thing to try: can you run it with the JavaFX 15-ea+1 build
and see if that makes a difference?
-- Kevin
On 2/10/2020 6:59 AM, Kevin Rushforth wrote:
Seems I missed your comment about it being hung to the point you can't
run jstack.
If you are using JDK 12 or later, you might
Seems I missed your comment about it being hung to the point you can't
run jstack.
If you are using JDK 12 or later, you might try with JDK 11 and see if
that makes a difference. It will help narrow it down to a change in the
JDK versus a change in JavaFX (although I suspect it's a change in
Hi,
I am trying to add test-cases in ContextMenuTest.java to test ContextMenu
positioning,
but the test cases fails since it ignores the css padding applied on the
ContextMenu's menu/menu-item via css.
Test-cases:
@Test public void test_position_showOnTop() { // fails
ContextMenu cm =
A thread stack dump using "jstack" might be helpful.
Also, what version of the JDK are you running?
-- Kevin
On 2/9/2020 4:07 AM, Lior Yaffe wrote:
My application is a Java application running a Javascript/Html website
inside a JavaFX WebView. It was working stable for several years with
On Fri, 7 Feb 2020 18:36:18 GMT, Kevin Rushforth wrote:
>> `AbstractSurface.nativePtr` is needed to create the
>> `AbstractSurfaceDisposerRecord`.
>> It is created and set by the native method `initialize(dataType, width,
>> height);` invoked at line 45 in the `JavaSurface` constructor.
>> It
> Memory allocated in initDecompressor() and decompressIndirect() is not freed
> in error case.
> In error case,
> 1. Allocated memory should be freed.
> 2. Appropriate de-initialization jpeg library calls should be added.
>
> Verified that,
> 1. All unit and systems tests pass on three
On Wed, 27 Nov 2019 21:19:08 GMT, Johan Vos wrote:
>> The pull request has been updated with a new target base due to a merge or a
>> rebase.
>
> In general, this makes sense. I need to look into more detail that the
> additional calls for freeing resources (in case of errors) don't cause
* add support for the "resource" protocol (which is used in the GraalVM URLs
pointing to statically bundled resources)
* avoid duplicate symbols with different gst plugins
* statically register gst plugins
-
Commits:
- c334ba81: Fix for JDK-8238755
Changes:
19 matches
Mail list logo
