Linux Glass - WindowContextChild and WindowContextPlug

2019-12-31 Thread Thiago Milczarek Sayao


Does anyone knows the context of use of WindowContextChild and 
WindowContextPlug on the linux glass implementation?

File: glass_window.cpp

They seem to be never called.

Thanks.




Re: [Rev 06] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-31 Thread Kevin Rushforth
On Tue, 31 Dec 2019 18:19:29 GMT, Scott Palmer  wrote:

>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute 
>> to both.  TextFlow's tab size overrides that of contained Text nodes.
> 
> The pull request has been updated with 1 additional commit.

Looks good now.

-

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/32


Re: error in tutorial

2019-12-31 Thread Kevin Rushforth
Ignoring jmods for a moment, since those are only intended to be used by 
jlink to produce an image that includes the modules (jmods are not a 
runtime format)...


The issue being caused by the src.zip in the lib directory of the JavaFX 
SDK seems more like a problem with the IDE(s) in question than with the 
JavaFX SDK. Both javac and java are perfectly happy with a module path 
that points to the lib directory, and will only consider the .jar files 
in that directory, ignoring other files. I note that in addition to 
src.zip, the lib directory contains several native libraries on Linux 
(*.so) and Mac (*.dylib).


While we could relocate just the src.zip file, as a workaround for what 
looks like an IDE problem, it isn't as trivial as Ty's post suggests. 
For one thing, this would be an incompatible change (although a minor 
one), and would require a CSR. I am not in favor of this change, but we 
can discuss it on this list if others feel differently. Also, as Johan 
pointed out, we will need a bug in JBS to track this.


-- Kevin


On 12/30/2019 8:55 AM, Anthony Vanelverdinghe wrote:

Hi

Some observations:
This is the mentioned e-mail: 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022497.html
The lib folder contains a src.zip file, both in JDK 13.0.1 and in 
JavaFX SDK 13.0.1, so this is consistent.

For NetBeans and IntelliJ IDEA (I didn't check Eclipse):
- neither supports jmod files in libraries (see [1])
- both support selecting individual jar files, after which things work 
as expected
- neither constructs an optimal modulepath, even if the application is 
modular


So I believe that this is mostly just a documentation issue: rather 
than saying "add the lib folder of the SDK" it should say "add all jar 
files in the lib folder of the SDK". Additionally, IDEs should be 
improved to support jmod files in libraries, and to construct optimal 
modulepaths for modular applications.


Kind regards,
Anthony

[1] https://youtrack.jetbrains.com/issue/IDEA-171448

On 28/12/2019 20:11, Ty Young wrote:






On 12/28/19 4:53 AM, Johan Vos wrote:

Hi Ty,

Since I have absolutely no idea what you are talking about, I have a 
few questions:


1. "... push changes to the repo..."? -> It would help giving a bit 
context instead of talking about "the repo". Since this is the 
openjfx-dev list, chances are high you're talking about the JavaFX 
repository at https://github.com/openjdk/jfx. In that case, please 
read the README and CONTRIBUTING files there for advice on how to 
propose/make changes (note that this will probably take longer than 
1 minute, as we have strong quality checks in place). If you talk 
about a different "repo", please follow the explicit or implicit 
rules on that repo(sitory). For example, if you talk about 
https://github.com/openjfx/openjfx-docs , please create an issue and 
file a PR, and work with the community to get it accepted. (note 
that in this case, this should not be discussed on the openjfx-dev 
list (note the *dev*)).



This is not an issue of documentation. IDEs can and do provide the 
ability to designate an entire folder as a location of project 
libraries. You can specify a directory manually via command line in 
which contains Java 9 modules. To continue to entertain the idea that 
this is an issue of documentation is simply crazy. It's an easily 
fixable technical error.





2. You refer to informal or formal talks you had, but it is totally 
unclear to me who you talked to about what. Frankly, we spent lots 
of time moving all code and as much as possible the documentation to 
github, so we can easily track discussions. (for JavaFX bugs, we use 
JBS, so that can be discussed there) If someone said "it’s the way 
we’ve always done it”" please refer to the issue where your request 
has been made and subsequently rejected, so I can have a look at the 
context,



It was an email a very long time ago on this list. Too lazy to dig it 
up, but I'm pretty sure it was from Kevin Rushforth. Again, very long 
time ago at this point.





3. Can you write a few words about what the word "Community" means 
to you? Many people in the JavaFX Ecosystem spent tons of spare time 
in making the JavaFX "Community" a friendly place. I'm interested in 
your opinion about that word. To give a few options, does it mean
A: I insult people and companies, use words like "smoking shrooms" 
and "stubborn" and I expect everything I think about to be fixed 
magically (since I suppose the volunteers have no life apart from 
doing what I want them to do)



"community" is a funny word to describe JavaFX given it is 100% owned 
by Oracle and which no one(AFAIK) can contribute to without signing 
away their rights to their own code.



If this was a feature request I'd understand this nonsense but that's 
not at all what this is. This is a self created, self perpetuated, 
and needlessly self harming *technical* error defended using the 
worst possible defense against very real iss

Should Skara tooling invalidate approvals when new commits are pushed? [was: RFR: 8130738: Add tabSize property to Text and TextFlow]

2019-12-31 Thread Kevin Rushforth
Since this isn't directly related to the PR in question, I'm starting a 
new thread.


On 12/20/2019 7:22 PM, Philip Race wrote:

On 12/20/19, 7:04 PM, Scott Palmer wrote:
I'm not sure if I'me supposed to try to integrate now that I've made 
that 10 ->  0 change, or if the new change resets the need for review...


It shows ready, which surprises me.
Still learning skara .. I'd expect any change to reset as how can it 
know if it is
a  good or insignificant change or not no matter how the commenter 
characterised the issue ?


Pushing a new commit doesn't automatically invalidate existing 
approvals, although it is highlighted in the "Approvers" section that 
the approval was for a prior commit:


    Approvers
    Phil Race (prr - Reviewer) Note! Review applies to f846ad6

I remember bringing this up with the Skara team during my initial 
testing, since I also had wondered whether pushing a new commit should 
invalidate approvals. The current policy allows for doing trivial fixes 
brought up when approving a review (e.g., a change in a comment or 
formatting) without requiring all reviewers to re-approve. It matches 
current practice for email-based reviews, so I think the current 
behavior is a reasonable default.


They did say that they could implement an optional feature (i.e., a 
project would need to opt-in to this behavior, probably via a 
.jcheck/conf property) to invalidate all approvals upon pushing a new 
commit, but I don't think an RFE was filed to track it.


This seems like it could be a valuable feature, although it does come 
with a slight cost in terms of timing and flexibility. What do others think?


-- Kevin



Re: RFR: 8236484: Compile error in monocle dispman

2019-12-31 Thread Kevin Rushforth
On Sat, 21 Dec 2019 18:10:37 GMT, Johan Vos  wrote:

> Trivial fix for a compiler error where a void function returns a long



-

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/74


Re: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-31 Thread Kevin Rushforth
On Sat, 21 Dec 2019 20:35:10 GMT, Phil Race  wrote:

>> Link problem appears to just be a missing slash: 
>> https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
> 
>> Link problem appears to just be a missing slash: 
>> https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
> 
> Seems this was fixed yesterday : https://github.com/openjdk/skara/pull/344

@swpalmer The change still needs my completed review -- note that there is 
currently only one reviewer listed in the __Approvers__ section above. Once I 
approve, which I will do soon, I will sponsor it.

I'm still looking for ways to make the CONTRIBUTING guidelines more clear as to 
when it is OK to integrate. I'll take a stab at it in the new year...

-

PR: https://git.openjdk.java.net/jfx/pull/32