Re: PageOrientation partially ignored?

2020-08-17 Thread Tobias Oelgarte 
I used the following printers together with JavaFX (versions 14.0.2.1 
and 16-ea+1):


- cups-pdf under Ubuntu 18.04 (supports A4, all orientations, down to 0 
margins)

- PDF24 under Windows 7 (supports A4, all orientations, down to 0 margins)
- Kyocera FS 2020DN under Windows 7 (supports A4, all orientations, 
margins adjusted to match printer)


All show exactly the same (wrong) result.

Tobias Oelgarte
Mail: tobias.oelga...@gmail.com

On 18.08.20 06:42, Phil Race wrote:

what printer, driver, and os?
did you call any methods to verify the values being passed are supported ?

-Phil.


On Aug 17, 2020, at 9:01 PM, Tobias Oelgarte  wrote:

I just experimented with the JavaFX printing API and I'm confused about the 
results.

If I request to print in landscape format the resulting page is still in 
portrait mode, but rotated by 90 degrees and with mirrored borders/margins. Is 
this intentional or should I file a bug report?

Simplified Example:

Printer printer = Printer.getDefaultPrinter();
PageLayout layout = printer.createPageLayout(Paper.A4, 
PageOrientation.LANDSCAPE, 80, 20, 10, 40);
PrinterJob job = PrinterJob.createPrinterJob(printer);
job.getJobSettings().setPageLayout(layout);
boolean success = job.printPage(someNode);
if (success) {
job.endJob();
}

What i would expect would be an A4 page in landscape orientation, with a top 
border (long side) of 10, a bottom border of 40, a left border of 80 and a 
right border of 20. The content/node will not be rotated.

But what i get is the following. The paper size is A4 as requested. The 
orientation is portrait (not as requested). The top border (long side) is 40, 
the bottom border is 10, the left border is 20, the right border is 80. The 
content/node is rotated by 90 degrees to the left.

My guess is that the orientation is partially ignored, resulting in the 
confusing margins.

--
Tobias Oelgarte
Mail: tobias.oelga...@gmail.com

Re: PageOrientation partially ignored?

2020-08-17 Thread Phil Race 
what printer, driver, and os?
did you call any methods to verify the values being passed are supported ?

-Phil.

> On Aug 17, 2020, at 9:01 PM, Tobias Oelgarte  
> wrote:
> 
> I just experimented with the JavaFX printing API and I'm confused about the 
> results.
> 
> If I request to print in landscape format the resulting page is still in 
> portrait mode, but rotated by 90 degrees and with mirrored borders/margins. 
> Is this intentional or should I file a bug report?
> 
> Simplified Example:
> 
> Printer printer = Printer.getDefaultPrinter();
> PageLayout layout = printer.createPageLayout(Paper.A4, 
> PageOrientation.LANDSCAPE, 80, 20, 10, 40);
> PrinterJob job = PrinterJob.createPrinterJob(printer);
> job.getJobSettings().setPageLayout(layout);
> boolean success = job.printPage(someNode);
> if (success) {
>job.endJob();
> }
> 
> What i would expect would be an A4 page in landscape orientation, with a top 
> border (long side) of 10, a bottom border of 40, a left border of 80 and a 
> right border of 20. The content/node will not be rotated.
> 
> But what i get is the following. The paper size is A4 as requested. The 
> orientation is portrait (not as requested). The top border (long side) is 40, 
> the bottom border is 10, the left border is 20, the right border is 80. The 
> content/node is rotated by 90 degrees to the left.
> 
> My guess is that the orientation is partially ignored, resulting in the 
> confusing margins.
> 
> -- 
> Tobias Oelgarte
> Mail: tobias.oelga...@gmail.com

PageOrientation partially ignored?

2020-08-17 Thread Tobias Oelgarte 
I just experimented with the JavaFX printing API and I'm confused about 
the results.


If I request to print in landscape format the resulting page is still in 
portrait mode, but rotated by 90 degrees and with mirrored 
borders/margins. Is this intentional or should I file a bug report?


Simplified Example:

Printer printer = Printer.getDefaultPrinter();
PageLayout layout = printer.createPageLayout(Paper.A4, 
PageOrientation.LANDSCAPE, 80, 20, 10, 40);

PrinterJob job = PrinterJob.createPrinterJob(printer);
job.getJobSettings().setPageLayout(layout);
boolean success = job.printPage(someNode);
if (success) {
    job.endJob();
}

What i would expect would be an A4 page in landscape orientation, with a 
top border (long side) of 10, a bottom border of 40, a left border of 80 
and a right border of 20. The content/node will not be rotated.


But what i get is the following. The paper size is A4 as requested. The 
orientation is portrait (not as requested). The top border (long side) 
is 40, the bottom border is 10, the left border is 20, the right border 
is 80. The content/node is rotated by 90 degrees to the left.


My guess is that the orientation is partially ignored, resulting in the 
confusing margins.


--
Tobias Oelgarte
Mail: tobias.oelga...@gmail.com

Re: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors

2020-08-17 Thread Kevin Rushforth 
On Mon, 17 Aug 2020 11:16:55 GMT, Bhawesh Choudhary  
wrote:

> Added missing explicit no-arg constructors to classes in package 
> javafx.scene, javafx.css and javafx.stage.

Marked as reviewed by kcr (Lead).

-

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

Re: RFR: 8251352: Many javafx.base classes have implicit no-arg constructors

2020-08-17 Thread Kevin Rushforth 
On Mon, 17 Aug 2020 09:23:34 GMT, Bhawesh Choudhary  
wrote:

> Added missing explicit no-arg constructors to classes in package 
> javafx.beans.property, javafx.collections, javafx.util
> and javafx.util.converter in module javafx.base.

Marked as reviewed by kcr (Lead).

-

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

Re: openjfx-dev Digest, Vol 105, Issue 26

2020-08-17 Thread John Theisen 
Remove

> On Aug 17, 2020, at 4:35 AM, openjfx-dev-requ...@openjdk.java.net wrote:
> 
> Send openjfx-dev mailing list submissions to
>openjfx-dev@openjdk.java.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
>openjfx-dev-requ...@openjdk.java.net
> 
> You can reach the person managing the list at
>openjfx-dev-ow...@openjdk.java.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openjfx-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. Make TransformationList (Filtered and Sorted) extendable
>  (Tobias Diez)
>   2. Re: Unable to import OpenJFX Build into Eclipse (Nir Lisker)
>   3. [jfx15] RFR: 8249537: Update copyright header for files
>  modified in 2020 (Ambarish Rapte)
>   4. Re: Unable to import OpenJFX Build into Eclipse (Tom Schindl)
>   5. RFR: 8251352: Many javafx.base classes have implicit no-arg
>  constructors (Bhawesh Choudhary)
> 
> 
> --
> 
> Message: 1
> Date: Sun, 16 Aug 2020 15:28:25 +0200
> From: "Tobias Diez" 
> To: 
> Subject: Make TransformationList (Filtered and Sorted) extendable
> Message-ID: <000601d673d1$1ef218f0$5cd64ad0$@gmx.de>
> Content-Type: text/plain;charset="us-ascii"
> 
> Hello everybody,
> 
> Right now it is hard to extend the FilteredList and the SortedList as these
> classes are marked final. This makes it practically impossible to add
> convenient helper methods, or change or extend the behavior of these
> classes.
> I agree that normally you don't need to extend them, but I also don't see
> any reason why you shouldn't be allowed to do so.
> 
> Usually, you could use composition over inheritance if a class is marked
> final but you still want to extend it. However, some of the controls expect
> really a SortedList , e.g.
> https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/
> java/javafx/scene/control/TableView.java#L442
> So this approach does not work either.
> 
> The motivation for me comes from some limitations that we encountered while
> developing EasyBind, a small library to make bindings easier. We provide a
> few convenient methods that extend the ObservableList, and we want to
> provide a fluent interface similar to streams, e.g.
> EasyBind.wrap(standard observable list).filter(predicate).map(mapper).
> For this to work, the filter method needs to return a FilteredList with the
> additional map method. The easiest solution would be to derive from
> FilteredList, and implement the "EasyObservableList" interface that we have.
> 
> Removing the final keyword is done in the following PR:
> https://github.com/openjdk/jfx/pull/278
> 
> Looking forward to your feedback.
> Best regards
> Tobias
> 
> 
> 
> --
> 
> Message: 2
> Date: Sun, 16 Aug 2020 22:49:47 +0300
> From: Nir Lisker 
> To: Andrew Waters 
> Cc: "openjfx-dev@openjdk.java.net Mailing"
>
> Subject: Re: Unable to import OpenJFX Build into Eclipse
> Message-ID:
>
> Content-Type: text/plain; charset="UTF-8"
> 
> Hi Andrew,
> 
> I did the same setup only with Ubuntu 18, which shouldn't matter, and I
> don't remember having this issue. I can try redoing it next time I boot the
> Ubuntu partition.
> 
> What looks odd is that the error references the build directory. What
> happens if you clean the project first?
> 
> - Nir
> 
>> On Sat, Aug 15, 2020 at 1:55 PM Andrew Waters  wrote:
>> 
>> Hi All,
>> 
>> 
>> I'm trying to diagnose a bug in OpenJFX that I've been struggling with
>> on and off for almost a year(!) and I decided to build OpenJFX from
>> source and use Eclipse to help.  I've built a brand new Ubuntu
>> 20.04.1-Desktop system with OpenJDK 14.0.1 and the latest stable OpenJFX
>> 14.  I've run the Gradle build and run the tests and all looks 100%.
>> 
>> 
>> When importing the root directory (home/jdkdev/dev/jfx) into Eclipse
>> using the gradle import tool (using the wrapper option as recommended) I
>> get this build path error:
>> 
>> 
>> Cannot nest
>> 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main/javafx.base'
>> 
>> inside library
>> 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main'
>> 
>> 
>> It seems to be trying to set up a looped import to itself somehow.  I've
>> tried to edit the build path in eclipse but the fields appear to be all
>> non-editable.  Has anyone any idea as to what the problem is and how to
>> fix it?  Has anyone recently done a successful import with these latest
>> levels?
>> 
>> 
>> As this is the base module none of the other modules compile of course
>> so they too may have other problems once the base module is fixed.
>> 
>> 
>> I tried the "existing projects" import too but that just appears to have
>> even more problems.
>> 
>> 
>> Thanks,
>> 
>> Andrew Waters
>> 
>> UK.
>> 
>> 
> 
> 
>

Re: JDK-8154847 : Windows content is blank when using StageStyle.UNIFIED

2020-08-17 Thread Anirvan Sarkar 
Hi,

I can see in the implementation that
Platform.isSupported(ConditionalFeature.UNIFIED_WINDOW) is always false on
Linux [1].
So it seems that the issue does not occur in Linux because
StageStyle.UNIFIED is not supported there and so as per the specification
[2] the StageStyle is downgraded to StageStyle.DECORATED.

The workaround of using SW pipeline does not resolve the issue for me when
the below option is selected and accent color is changed.

Settings (Win + I) -> Personalization -> Colors -> Show accent
color on the following surfaces -> Title bars and window borders

I was expecting the background color of the window content to be the same
as the title bar color / accent color but it is not.
Since this issue is in the SW pipeline I don't think the issue is due to a
graphics driver bug, or maybe this is a different bug.

I have attached my observations in the JBS issue.

[1] :
https://github.com/openjdk/jfx/blob/2aed5ad3e57cd8aa9875965d17eeb76e09dae13c/modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkApplication.java#L474

[2] :
https://openjfx.io/javadoc/14/javafx.graphics/javafx/stage/StageStyle.html#UNIFIED


On Sat, 8 Aug 2020 at 05:25, Kevin Rushforth 
wrote:

> Thanks for the additional information. I added it to the bug report.
>
> It is interesting to note that it doesn't happen on Linux when running
> on the same HW, although it isn't surprising. This is likely a graphics
> driver bug, as opposed to a fundamental HW issue, so it isn't surprising
> that the results would be different on Linux.
>
> -- Kevin
>
>
> On 8/7/2020 1:09 PM, Hannes H. wrote:
> > Good evening,
> >
> > Weeks ago I reported a duplicate to JDK-8154847 because I did not realize
> > that this has been reported years ago.
> >
> > As far as I understand most of the contributors to this ticket believe
> that
> > the problem is related to specific video cards. Since I can reproduce
> this
> > issue on my developer notebook on Windows 10, I decided to install Linux
> > (not on a VM but actually on the hardware) to check if I can reproduce
> > the issue there as well.
> >
> > First tests show that this issue cannot be reproduced on Linux Mint while
> > it can on the very same hardware when using Windows 10.
> >
> > I am not sure if this information helps anyone. I decided to send it to
> > this mailing list since I find it very cumbersome to create - another -
> > duplicate of an issue just to add information.
> >
> > If you have any further questions or I can be of assistance with
> > reproducing the issue please let me know.
> >
> > Kind regards,
> > Hannes
>
>

-- 
Anirvan

Re: RFR: 8251352: Many javafx.base classes have implicit no-arg constructors

2020-08-17 Thread Nir Lisker 
On Mon, 17 Aug 2020 09:23:34 GMT, Bhawesh Choudhary  
wrote:

> Added missing explicit no-arg constructors to classes in package 
> javafx.beans.property, javafx.collections, javafx.util
> and javafx.util.converter in module javafx.base.

Marked as reviewed by nlisker (Reviewer).

-

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

Re: Unable to import OpenJFX Build into Eclipse

2020-08-17 Thread Nir Lisker 
They are not required if you use the command line interface, but I find
that they do make things easier since I can run the gradle command from
Eclipse directly.

The instructions mention that if you import through gradle, you will need
to replace the Eclipse files with the ones in the repo because at this
point gradle still messes them up.

On Mon, Aug 17, 2020 at 10:43 AM Tom Schindl 
wrote:

> Hi,
>
> Do we really use the Eclipse-Gradle-Tooling now? I think the reasons we
> checked in all .product/.classpath files is that this did not work in
> the past.
>
> At least my Eclipse install I use for OpenJFX-Development does not have
> the gradle-tooling installed and things work there just fine.
>
> Tom
>
> Am 16.08.20 um 21:49 schrieb Nir Lisker:
> > Hi Andrew,
> >
> > I did the same setup only with Ubuntu 18, which shouldn't matter, and I
> > don't remember having this issue. I can try redoing it next time I boot
> the
> > Ubuntu partition.
> >
> > What looks odd is that the error references the build directory. What
> > happens if you clean the project first?
> >
> > - Nir
> >
> > On Sat, Aug 15, 2020 at 1:55 PM Andrew Waters  wrote:
> >
> >> Hi All,
> >>
> >>
> >> I'm trying to diagnose a bug in OpenJFX that I've been struggling with
> >> on and off for almost a year(!) and I decided to build OpenJFX from
> >> source and use Eclipse to help.  I've built a brand new Ubuntu
> >> 20.04.1-Desktop system with OpenJDK 14.0.1 and the latest stable OpenJFX
> >> 14.  I've run the Gradle build and run the tests and all looks 100%.
> >>
> >>
> >> When importing the root directory (home/jdkdev/dev/jfx) into Eclipse
> >> using the gradle import tool (using the wrapper option as recommended) I
> >> get this build path error:
> >>
> >>
> >> Cannot nest
> >>
> 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main/javafx.base'
> >>
> >> inside library
> >> 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main'
> >>
> >>
> >> It seems to be trying to set up a looped import to itself somehow.  I've
> >> tried to edit the build path in eclipse but the fields appear to be all
> >> non-editable.  Has anyone any idea as to what the problem is and how to
> >> fix it?  Has anyone recently done a successful import with these latest
> >> levels?
> >>
> >>
> >> As this is the base module none of the other modules compile of course
> >> so they too may have other problems once the base module is fixed.
> >>
> >>
> >> I tried the "existing projects" import too but that just appears to have
> >> even more problems.
> >>
> >>
> >> Thanks,
> >>
> >> Andrew Waters
> >>
> >> UK.
> >>
> >>
>

RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors

2020-08-17 Thread Bhawesh Choudhary 
Added missing explicit no-arg constructors to classes in package javafx.scene, 
javafx.css and javafx.stage.

-

Commit messages:
 - 8251353: Many javafx scenegraph classes have implicit no-arg constructors

Changes: https://git.openjdk.java.net/jfx/pull/283/files
 Webrev: https://webrevs.openjdk.java.net/jfx/283/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251353
  Stats: 92 lines in 14 files changed: 92 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/283.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/283/head:pull/283

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

RFR: 8251352: Many javafx.base classes have implicit no-arg constructors

2020-08-17 Thread Bhawesh Choudhary 
Added missing explicit no-arg constructors to classes in package 
javafx.beans.property, javafx.collections, javafx.util
and javafx.util.converter in module javafx.base.

-

Commit messages:
 - 8251352: Many javafx.base classes have implicit no-arg constructors

Changes: https://git.openjdk.java.net/jfx/pull/282/files
 Webrev: https://webrevs.openjdk.java.net/jfx/282/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251352
  Stats: 224 lines in 35 files changed: 224 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/282.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/282/head:pull/282

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

Re: Unable to import OpenJFX Build into Eclipse

2020-08-17 Thread Tom Schindl 

Hi,

Do we really use the Eclipse-Gradle-Tooling now? I think the reasons we 
checked in all .product/.classpath files is that this did not work in 
the past.


At least my Eclipse install I use for OpenJFX-Development does not have 
the gradle-tooling installed and things work there just fine.


Tom

Am 16.08.20 um 21:49 schrieb Nir Lisker:

Hi Andrew,

I did the same setup only with Ubuntu 18, which shouldn't matter, and I
don't remember having this issue. I can try redoing it next time I boot the
Ubuntu partition.

What looks odd is that the error references the build directory. What
happens if you clean the project first?

- Nir

On Sat, Aug 15, 2020 at 1:55 PM Andrew Waters  wrote:


Hi All,


I'm trying to diagnose a bug in OpenJFX that I've been struggling with
on and off for almost a year(!) and I decided to build OpenJFX from
source and use Eclipse to help.  I've built a brand new Ubuntu
20.04.1-Desktop system with OpenJDK 14.0.1 and the latest stable OpenJFX
14.  I've run the Gradle build and run the tests and all looks 100%.


When importing the root directory (home/jdkdev/dev/jfx) into Eclipse
using the gradle import tool (using the wrapper option as recommended) I
get this build path error:


Cannot nest
'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main/javafx.base'

inside library
'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main'


It seems to be trying to set up a looped import to itself somehow.  I've
tried to edit the build path in eclipse but the fields appear to be all
non-editable.  Has anyone any idea as to what the problem is and how to
fix it?  Has anyone recently done a successful import with these latest
levels?


As this is the base module none of the other modules compile of course
so they too may have other problems once the base module is fixed.


I tried the "existing projects" import too but that just appears to have
even more problems.


Thanks,

Andrew Waters

UK.

[jfx15] RFR: 8249537: Update copyright header for files modified in 2020

2020-08-17 Thread Ambarish Rapte 
Update last modified year of copyright headers for files modified in 2020.

-

Commit messages:
 - 8249537: Update copyright header for files modified in 2020

Changes: https://git.openjdk.java.net/jfx/pull/281/files
 Webrev: https://webrevs.openjdk.java.net/jfx/281/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8249537
  Stats: 92 lines in 91 files changed: 0 ins; 0 del; 92 mod
  Patch: https://git.openjdk.java.net/jfx/pull/281.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/281/head:pull/281

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