Re: Gitter chat + StackOverflow [was: Concatenating transforms to scale positions but not objects]

Zitat von John-Val Rose : I’ve all but given up on StackOverflow. It seems to be a haven for trolls or control freaks who deem perfectly reasonable questions as off-topic or inappropriate whereby the question then gets put on hold and can’t be answered. It’s ridiculous and makes the

Re: Problem running tests in module controls inside Eclipse

arrrggg .. head on desktop edited the arg-file of base project, not that of the controls ... now it's time to call it a day, tsssee thanks for your help! and have a nice evening everybody :) Zitat von Tom Schindl : i run them with

Re: Problem running tests in module controls inside Eclipse

okay, found something in the gradle tasks which point into direction of some success: it sets the stubtoolkit in a vm arg: -Djavafx.toolkit=test.com.sun.javafx.pgstub.StubToolkit which does indeed work inside Eclipse if I add it to the runtime config of the test. Next step would be to

Re: Problem running tests in module controls inside Eclipse

Zitat von Nir Lisker : I don't recall seeing this problem. Just to be sure, did you circumvent the compilation error in Dialog's lambda? yes, I did - not seeing any compile errors, nothing red but just the app thread doesn't seem to be fired up. On Sun, Nov 18, 2018 at 5:42 PM wrote:

Problem running tests in module controls inside Eclipse

With the step-by-step debugging help provided by nlisker over at javafxports (https://github.com/javafxports/openjdk-jfx/issues/187 - which cleaned up some inherent misconception on my part, thanks!) I managed to run tests in base and graphics from inside Eclipse (right click and run

Re: Problems building openjfx

yes, I think so - don't have it and nothing barked at me Zitat von Nir Lisker : Can I remove the step for "DirectX SDK June 2010"? I think it was already verified that it's not needed. - Nir On Wed, Oct 31, 2018 at 4:59 PM wrote: wasn't as bad as expected, just had to interrupt because

Re: Problems building openjfx

wasn't as bad as expected, just had to interrupt because it took ages to test the webkit (which wasn't build so all its tests ran until each timed out) Task :web:test * WARNING: running web tests without building webkit. The webkit

Re: Problems building openjfx

okay after deleting the properties and running again, it at least lists the tasks without error - thanks :) now will try a real build - expecting all hell breaking loose Zitat von faste...@swingempire.de: thanks for the quick answer :) hmm, those are nearly all empty:

Re: Problems building openjfx

forgot the link to the instruction page, just in case there's another: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-EnvironmentVariables Zitat von faste...@swingempire.de: first try, following the instructions (for win10) at: that is having downloaded,

Problems building openjfx

first try, following the instructions (for win10) at: that is having downloaded, installed the required tools, added env vars as desribed. Then in cygwin, navigate to the git working dir, typing gradle tasks fails with: FAILURE: Build failed with an exception. * Where: Script

Re: Openjfx ea: error on trying to access private fields

Hi Kevin, thanks for your quick answer. The relaxed permissions, which are allowed given the default '--illegal-access=permit' mode, only apply to modules that are linked into the Java runtime. Modules that are loaded on the module-path are subject to strict access controls. ahh

Re: Table Input

Zitat von Tom Eugelink : This is a well known and already deeply discussed issue. I'm still not sure where we are with it, but Jonathan knows I believe. https://bugs.openjdk.java.net/browse/JDK-8089514 tbd_major ... since nearly 7 years :(( actually, it took 4 years to get the

Re: Additional info on JDK-8197536: TableView, ListView: unexpected scrolling behaviour on up/down keys

Seems to have happened right at the start of moving VirtualFlow into public scope (which included lots changes to the implementation plus some refactoring, codereader's brain cells need to be kept alert ;) see my comment at https://bugs.openjdk.java.net/browse/JDK-8197536 Zitat von Nir

Re: Support custom VirtualFlow in VirtualContainerBase ... now, please :)

interesting ... never thought along those lines, really understanding modules is still on my todo-list ;) Zitat von Michael Paus : Just for curiosity, would it be an option for you to patch this yourself in your code via the --patch-module mechanism of Java 9? I did something

Support custom VirtualFlow in VirtualContainerBase ... now, please :)

Attempting to move https://bugs.openjdk.java.net/browse/JDK-8187379 up the list - I need it, really, really, really! And absolutely nothing - no tweak, no dirtyness, no wickedness - I can do until this is fixed :(( Hoping and crossing fingers, Jeanette

FX-9: strange (?) factory pattern in BehaviorBase:

The implementation of creating/accessing its inputMap looks strange to me: // no field // abstract getter protected abstract InputMap getInputMap(); // implemented factory method protected InputMap createInputMap() { return new InputMap(getNode()); } Now all subclasses (need to) contain

Re: TableCellSkinBase: columnVisibility/Width should be protected

Zitat von Jonathan Giles : Probably it is best to just email me directly rather than email the list multiple times per day. I'll bundle them up and review and make plans on what should happen for each. Eventually we'll end up with jira issues - which you're

Re: TableCellSkinBase: columnVisibility/Width should be protected

Zitat von Jonathan Giles : In moving most of the skin code to public API (as part of JEP 253), I worked with the plan of minimising the API as much as possible, and would then spend time this year bringing API back out in a more considered way (as opposed to

Re: TableCellSkinBase: columnVisibility/Width should be protected

just noticed that I can't even compile any subclass, so filed a bug: https://bugs.openjdk.java.net/browse/JDK-8148573 Zitat von faste...@swingempire.de: On the move into public, its abstract methods columnVisibility/Width/Property changed scope from protected to package - this makes the base

TableCellSkinBase: columnVisibility/Width should be protected

On the move into public, its abstract methods columnVisibility/Width/Property changed scope from protected to package - this makes the base class rather useless for extension: it's main job is sync'ing the cell's visible property to the column's visible property and triggering and doing the

Re: Bug when combining ListView and SortedList?

Zitat von "Fisher, Robert" : https://bugs.openjdk.java.net/browse/JDK-8141124 This is a regression introduced in 1.8.0_60, so it might have a different origin than the problems you mention. Thanks! You are right, the "visible" behavior indeed is a

Re: Bug when combining ListView and SortedList?

Jonathan, thanks for the clarification, I indeed misunderstood the new tag. On the other hand: not all (related) selection issues are tagged as such, are those in danger of not being fixed for 9? Anyway, all of them _could_ be fixed in one stroke by throwing away the evil

Re: Bug when combining ListView and SortedList?

Zitat von "Fisher, Robert" : Done. Mind to add the issue #? Note that there are tons of issues around incorrect selection notification/state after modifying the underlying items. One very basic problem in all core implementations is that they simply can't

Re: Regression or feature: editable comboBox doesn't commit on focus lost

Thanks for the info and filing an issue :-) Cheers Jeanette Zitat von Leif Samuelsson : This is a regression in 8u60. I have filed a new issue for this and I hope that we can backport a fix to an 8u release. https://bugs.openjdk.java.net/browse/JDK-8136838

Regression or feature: editable comboBox doesn't commit on focus lost

short description (for a complete description and a workaround see http://stackoverflow.com/q/32620739/203657): edit the text in an editable comboBox, focus another control - expected: the edited text is committed (aka: combo's value changed), actual: combo's value unchanged Worked as