Re: [openjdk/jfx] 8234712: Add pivot properties for scale and rotation in Node, ScaleTransition and RotateTransition (#53)

> > As long as you do the following, it should work as expected: > > T(pivotRot) * T(rotate) * T(-pivotRot) * T(pivotScale) * T(scale) * > T(-pivotScale) * object coords > I think that this is what the PR does already. Line 5061 onward is: localToParentTx =

Re: Skara - bot sending can-be-integrated message prematurely?

Do other projects also have multi-reviewers requirements? I would think that at least for a CSR, which is OpenJDK-wide, a request could be put in with the Skara to track it. A Reviewer (or Committer?) could invoke a /csr command which will require the PR author to provide a link to the CSR, and

Re: [openjdk/jfx] 8234712: Add pivot properties for scale and rotation in Node, ScaleTransition and RotateTransition (#53)

On 12/15/2019 6:06 PM, Nir Lisker wrote: Replying on the mailing list to the questions raised on GitHub. The state of whether to use the computed center pivot or the value of the pivot attribute is implicit with no way for an application to know which it is, and no way to set it

Re: [openjdk/jfx] 8234712: Add pivot properties for scale and rotation in Node, ScaleTransition and RotateTransition (#53)

Thanks for the input Michael, > Introducing two separate centers for rotation and scaling is, to my > opinion, just academic without any practical use-case and in the end much > more complicated for the user. I have a practical use case in my app. I assume that the people who requested these

Re: [Rev 02] RFR: 8207759: VK_ENTER not consumed by TextField when default Button exists

On Mon, 16 Dec 2019 23:41:37 GMT, Jeanette Winzenburg wrote: >> This is a fix for https://bugs.openjdk.java.net/browse/JDK-8207759 >> >> The issue is that default/cancel button on a scene are triggered even though >> a onKeyPressed handler for ENTER/CANCEL consumes the keyEvent. See the bug

Re: openjfx 13 MediaPlayer vodeo stutter

Sorry I just realized that this is the dev team mailing list and my post may not be appropriate here. I have posted a question on this at stackoverflow along with a minimal standalone test program:

Re: [Rev 07] RFR: 8207957: TableSkinUtils should not contain actual code implementation

On Mon, 16 Dec 2019 21:33:11 GMT, Hadzic Samir wrote: >> Allright, this is a fix for JDK-8207957 > > The pull request has been updated with 1 additional commit. Looks good. Once the CSR is approved, this can be integrated. - Marked as reviewed by kcr (Lead). PR:

Re: Proposed schedule for JavaFX 14

The announced RDP1 date is the first Monday of the new year. In taking a closer look at the upcoming holiday schedule and accounting for additional days off some will be taking before or after, this doesn't allow enough time for the final stages of the review process to complete, including CSR

Re: Skara - bot sending can-be-integrated message prematurely?

That's a good question about whether we can ask for a slight rewording of the Skara bot message to indicate that there might be other things to check before "/integrate". I'll raise that question with the Skara team. As an aside, I noticed the other day that you typed "/integrate" after a

Re: Skara - bot sending can-be-integrated message prematurely?

Kevin, thanks for the clarification :) My bad that I didn't re-read the contrib.md. But then, who does? The lazy like myself do it occasionally only (down to once and then forget about it ) Maybe the bot message can be improved? With some indication that its (the bot's) knowledge about

Re: Skara - bot sending can-be-integrated message prematurely?

I added a comment to the two PRs in question, but it bears discussion here. The Skara bot can't know whether all criteria have been met. It can't, for example, know whether there are outstanding comments from some reviewers that need to be addressed. Nor does it know which PRs need two

Re: [Rev 07] RFR: 8207957: TableSkinUtils should not contain actual code implementation

On Mon, 16 Dec 2019 12:12:31 GMT, Jeanette Winzenburg wrote: >> > > hmm ... think that the bot isn't yet clever enough: this pull request needs > approval of two reviewer with _review_ role (mine is only informal) This one still needs an approved CSR (the CSR is Finalized, but needs to be

Re: [Rev 02] RFR: 8207759: VK_ENTER not consumed by TextField when default Button exists

On Mon, 16 Dec 2019 11:21:45 GMT, Jeanette Winzenburg wrote: >> > > Zitat von "openjdk[bot]" : > >> @kleopatra This change can now be integrated. The commit message will be: >> ``` > > Ajit, Kevin, > > hmm .. wondering if this message is a bot-error? Kevin stated that it > needs two

Re: Skara - bot sending can-be-integrated message prematurely?

Zitat von Nir Lisker : The bot doesn't know how many reviewers are needed. This was brought up before in point 3 in http://mail.openjdk.java.net/pipermail/openjfx-dev/2019-October/023662.html. missed that - thanks for the pointer :) - Nir On Mon, Dec 16, 2019 at 2:24 PM Jeanette

Re: Skara - bot sending can-be-integrated message prematurely?

The bot doesn't know how many reviewers are needed. This was brought up before in point 3 in http://mail.openjdk.java.net/pipermail/openjfx-dev/2019-October/023662.html. - Nir On Mon, Dec 16, 2019 at 2:24 PM Jeanette Winzenburg wrote: > > Looks like it assumes a pull request as properly

Re: [Rev 07] RFR: 8207957: TableSkinUtils should not contain actual code implementation

On Mon, 16 Dec 2019 11:46:57 GMT, Ajit Ghaisas wrote: >> The pull request has been updated with 1 additional commit. > > hmm ... think that the bot isn't yet clever enough: this pull request needs approval of two reviewer with _review_ role (mine is only informal) - PR:

Re: [Rev 07] RFR: 8207957: TableSkinUtils should not contain actual code implementation

On Mon, 16 Dec 2019 11:47:15 GMT, Hadzic Samir wrote: >> Allright, this is a fix for JDK-8207957 > > The pull request has been updated with 1 additional commit. - Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/6

Re: [openjdk/jfx] 8234712: Add pivot properties for scale and rotation in Node, ScaleTransition and RotateTransition (#53)

I don't think there are clearly right or wrong answers to all these questions, so I would just like to provide a view thoughts on this. The governing principle should be a principle of "least surprise" from a users point of view. That means we should not make things more complicated as they

Re: [Rev 02] RFR: 8207759: VK_ENTER not consumed by TextField when default Button exists

On Mon, 16 Dec 2019 08:52:56 GMT, Ajit Ghaisas wrote: >> The pull request has been updated with 1 additional commit. > > Zitat von "openjdk[bot]" : > @kleopatra This change can now be integrated. The commit message will be: > ``` Ajit, Kevin, hmm .. wondering if this message is a

Re: [Rev 05] RFR: 8207957: TableSkinUtils should not contain actual code implementation

On Wed, 11 Dec 2019 00:32:32 GMT, Kevin Rushforth wrote: >> Thanks for the review. I do not have access to a computer right now, I'll >> update next week on Monday. >> >> Le lun. 9 déc. 2019 à 17:01, Kevin Rushforth a >> écrit : >> >>> I would like both @aghaisas

Re: [Rev 07] RFR: 8207957: TableSkinUtils should not contain actual code implementation

> Allright, this is a fix for JDK-8207957 The pull request has been updated with 1 additional commit. - Added commits: - 79817025: Remove trailing spaces Changes: - all: https://git.openjdk.java.net/jfx/pull/6/files - new:

Re: [Rev 06] RFR: 8207957: TableSkinUtils should not contain actual code implementation

> Allright, this is a fix for JDK-8207957 The pull request has been updated with 1 additional commit. - Added commits: - 9991ec48: Minor typo fix upon Kevin's review Changes: - all: https://git.openjdk.java.net/jfx/pull/6/files - new:

Re: [Rev 02] RFR: 8207759: VK_ENTER not consumed by TextField when default Button exists

On Mon, 16 Dec 2019 08:53:10 GMT, Jeanette Winzenburg wrote: >> This is a fix for https://bugs.openjdk.java.net/browse/JDK-8207759 >> >> The issue is that default/cancel button on a scene are triggered even though >> a onKeyPressed handler for ENTER/CANCEL consumes the keyEvent. See the bug