Re: The crisp fonts saga

[Mark Raynsford]

On Fri, 2023-12-15 at 17:55 -0800, John Neffenger wrote:
> On 12/15/23 2:21 PM, Mark Raynsford wrote:
> >    2. Add an -fx-font-hinting CSS attribute that, by default, will
> > be
> >   set to false. Setting this value to true will enable hinting
> >   using whatever is the default (in other words, not setting
> >   FT_LOAD_NO_HINTING).
> 
> Have you thought of a 'prism.hinting' system property similar to the 
> current 'prism.lcdtext'?
> 
> Simply being able to toggle off FT_LOAD_NO_HINTING would, I think, 
> result in text rendering on Linux similar to the JDK (vertical-only 
> hinting when using FreeType 2.8 or later).
> 
> A system property would allow end users to control the hinting, too, 
> with the added benefit of being a very simple code change.

I have, yes. I actually considered properties for each of these, but I
thought it more important to be able to specify them on a node-by-node
basis.

Of course, I could always do both, as with the way font smoothing is
right now (prism.lcdtext and -fx-font-smoothing-type: gray). :)

-- 
Mark Raynsford | https://www.io7m.com

RE: Converting a Color object to its string representation

[Eran Leshem]

Thanks. 

 

The #rrggbbaa format isn’t documented on 
https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/doc-files/cssref.html#typecolor
 for some reason, so I missed it. Can I contribute a fix to the doc?

 

What’s the process for approving option 1?

Eran

 

From: openjfx-dev [mailto:openjfx-dev-r...@openjdk.org] On Behalf Of Kevin 
Rushforth
Sent: Wednesday, December 13, 2023 2:46 PM
To: openjfx-dev@openjdk.org
Subject: Re: Converting a Color object to its string representation

 

Or the third option:

3. Do nothing

I would go for option 1 or 3. I do not recommend option 2.

I see some value in a minimal API (option 1), returning a fixed format, perhaps:

if alpha == 1 { "#rrggbb" } else { "#rrggbbaa" }

-- Kevin



On 12/12/2023 4:04 PM, Eran Leshem wrote:

I can see two options:

1.   Minimal, just in order to satisfy the style APIs need – supporting a 
single format. I would go with non-% rgba, since it covers all dimensions in 
the most straightforward way.

2.   Complete – supporting all formats accepted by Color.web(), either via 
multiple methods or via an enum parameter

 

Eran

 

From: openjfx-dev [mailto:openjfx-dev-r...@openjdk.org] On Behalf Of Andy 
Goryachev
Sent: Tuesday, December 12, 2023 6:08 PM
To: Scott Palmer; openjfx-dev@openjdk.org
Subject: Re: Converting a Color object to its string representation

 

I also think that the platform will benefit from adding this symmetrical API.  

 

It is less clear how that new API should deal with all the multiple variants of 
the web format (#rgb, #rrggbb, rgb, rgba, 0x*, ...).

 

-andy

 

 

 

From: openjfx-dev   
 on behalf of Scott Palmer  
 
Date: Monday, December 11, 2023 at 17:12
To: openjfx-dev@openjdk.org   

Subject: Re: Converting a Color object to its string representation

I agree. I was going to write pretty much this exact email, but you beat me to 
it.

I was implementing some user-configurable colour customizations in an 
application and needed to do it with style sheets, along with something that 
reads colours along the lines of what the new platform preferences API does. 

I make a base64 data URL from a dynamically generated style sheet to avoid 
writing temp CSS files to style the app. 

I also needed to do this to work around the style sheet having higher priority 
than programmatically set colours as per my misunderstanding in 
https://bugs.openjdk.org/browse/JDK-8317434

So I see value in having Color implement something like this.

 

Scott

 

On Dec 11, 2023, at 4:19 PM, Eran Leshem   
 wrote:

Thank you for your responses.

Given that the framework requires colors in string format in its style APIs, I 
think it should provide some way to convert colors to strings as expected by 
these APIs. Otherwise, clients are forced to implement this bridging logic on 
their own, due to a framework gap.

And given that Color already parses these string representations, I think it 
makes sense for it to provide the inverse conversion.

Eran

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-r...@openjdk.org] On Behalf Of John 
Hendrikx
Sent: Saturday, December 09, 2023 11:35 PM
To: openjfx-dev@openjdk.org
Subject: Re: Converting a Color object to its string representation

I think this is too niche to have Color provide.

Just make a utility method for whatever format you desire, instead of 
making Color responsible for half a dozen ways of formatting colors, and 
then probably still missing some format that someone needs.

Ticket should be closed as won't fix.

--John

On 09/12/2023 22:06, Michael Strauß wrote:

I obviously meant to write withPrefix("#"), not withDelimiter("#")...

 

On Sat, Dec 9, 2023 at 9:57 PM Michael Strauß   
 wrote:

How would HexFormat work with Color, other than using an extremely

unwieldy syntax?

 

String formatted = HexFormat.of()

.withDelimiter("#")

.formatHex(new byte[] {

(byte)(color.getRed() * 255.0f),

(byte)(color.getGreen() * 255.0f),

(byte)(color.getBlue() * 255.0f),

(byte)(color.getOpacity() * 255.0f)

});

 

 

 

On Sat, Dec 9, 2023 at 9:40 PM David Alayachew  
  wrote:

Apologies - java.util.HexFormat

 

That's what I get for firing from the hip, then looking afterwards.

 

 

Re: The crisp fonts saga

[John Neffenger]

On 12/16/23 3:30 AM, Mark Raynsford wrote:

I have, yes. I actually considered properties for each of these, but I
thought it more important to be able to specify them on a node-by-node
basis.


I would prefer not to have the tyranny of the project default replaced 
with a new tyranny of the app default. :-)


Wouldn't it be nice to allow developers and end users to enable hinting 
for any JavaFX application just by defining a system property?


Bonus: JavaFX doesn't include its system properties in the API 
documentation yet, and there's no guarantees made that they won't 
change, so you're kind of off the hook on documentation, too.



Of course, I could always do both, as with the way font smoothing is
right now (prism.lcdtext and -fx-font-smoothing-type: gray). :)


Would you consider splitting it into two enhancement requests? The first 
could propose the global properties, and a second could allow the 
developer to set them node by node.


You may know much of this already, but for what it's worth, below are 
some suggestions based on my own experience.


For all the reasons mentioned in Phil's message, text rendering issues 
are in their own special category, regardless of the project. They can 
be a tough sell, so the burden is on the reporter to provide 
overwhelming evidence, preferably with text and images all on one page.


It helps to go big with any "before" and "after" screenshots: 800 
percent minimum, 400 percent for a retina display, with "smoothing" 
disabled for the image zoom. If at all possible, do what you can to take 
the issue out of the realm of opinions, where it's often dismissed 
outright. For example, see 
.


The template below is a good format for enhancement requests. I find 
it's better to be too formal than too causal. You could post it all on 
one page, with images inline, somewhere on GitHub.


  JEP Template
  https://openjdk.org/jeps/2

See also, of course:

  Contributing to OpenJFX
  https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md

John

Re: The crisp fonts saga

[Mark Raynsford]

On Sat, 2023-12-16 at 12:10 -0800, John Neffenger wrote:
> 
> I would prefer not to have the tyranny of the project default
> replaced 
> with a new tyranny of the app default. :-)
> 
> Wouldn't it be nice to allow developers and end users to enable
> hinting 
> for any JavaFX application just by defining a system property?

That is a good point. I had forgotten that most applications don't
allow the user to specify their own CSS.

What's the expected precedence? I assume it's:

* If the CSS specifies a setting, and the corresponding property isn't
  set, the CSS wins.
* If the property specifies a setting, and the CSS isn't set, the
  property wins.
* If the CSS specifies a setting, and the corresponding property
specifies a setting, the property wins.

> > Of course, I could always do both, as with the way font smoothing
> > is
> > right now (prism.lcdtext and -fx-font-smoothing-type: gray). :)
> 
> Would you consider splitting it into two enhancement requests? The
> first 
> could propose the global properties, and a second could allow the 
> developer to set them node by node.

I'm pretty discouraged in the sense of getting things upstream. I've
watched the project turn away contributors for years now, sadly. I'll
definitely be implementing this in separate pieces, so the patches will
be available for consideration afterwards.

> It helps to go big with any "before" and "after" screenshots: 800 
> percent minimum, 400 percent for a retina display, with "smoothing" 
> disabled for the image zoom. If at all possible, do what you can to
> take 
> the issue out of the realm of opinions, where it's often dismissed 
> outright. For example, see 
> .

I can definitely do this.

-- 
Mark Raynsford | https://www.io7m.com

Re: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v2]

[Thiago Milczarek Sayao]

On Thu, 14 Dec 2023 20:19:12 GMT, Jose Pereda  wrote:

>> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and 
>> `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and 
>> wrapped functions for GTK 3.20+ (so systems without it still run with GTK 
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   remove compile-time if checks

modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c line 197:

> 195: return TRUE;
> 196: }
> 197: return FALSE;

I did try to test on Ubuntu 16.04 and compilation failed (no surprise because 
`GdkSeat` does not exists there). Suggestion to keep  `#ifdef` here and `return 
FALSE` on `#else` so it would still compile on Ubuntu 16.04 and older systems. 
Will need to `#ifdef` all `GdkSeat` usage.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1305#discussion_r1428953396

Re: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v14]

[Thiago Milczarek Sayao]

> This replaces obsolete XIM and uses gtk api for IME.
> Gtk uses [ibus](https://github.com/ibus/ibus)
> 
> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative 
> positioning on `InputMethodRequest`.
> 
> [Screencast from 17-09-2023 
> 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3)

Thiago Milczarek Sayao has updated the pull request with a new target base due 
to a merge or a rebase. The pull request now contains 88 commits:

 - - Use a work-around to relative positioning (until wayland is not officially 
supported)
   - Unref pango attr list
 - Merge branch 'master' into new_ime
 - Account the case of !filtered
 - Fix change of focus when on preedit + add filter on key release
 - Merge branch 'master' into new_ime
 - Remove unused include
 - Make it a default method for compatibility
 - Fix JavaDoc
 - Fix @Override
 - Forgot one check
 - ... and 78 more: https://git.openjdk.org/jfx/compare/8872f7af...ba03adce

-

Changes: https://git.openjdk.org/jfx/pull/1080/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=13
  Stats: 462 lines in 7 files changed: 72 ins; 291 del; 99 mod
  Patch: https://git.openjdk.org/jfx/pull/1080.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080

PR: https://git.openjdk.org/jfx/pull/1080

Re: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v13]

[Thiago Milczarek Sayao]

On Wed, 13 Dec 2023 19:01:25 GMT, Martin Fox  wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Account the case of !filtered
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java
>  line 681:
> 
>> 679: public double[] getInputMethodCandidateRelativePos(int offset) {
>> 680: Point2D p2d = 
>> scene.inputMethodRequests.getTextLocationRelative(offset);
>> 681: return new double[] { p2d.getX(), p2d.getY() };
> 
> On my system the IM window is incorrectly positioned. This appears to be 
> because I'm running a high-DPI display with 200% magnification. I think you 
> need to call getPlatformScaleX and getPlatformScaleY and apply those scaling 
> factors before passing these coordinates on to glass. You'll see other places 
> in this file where conversions like that are being performed.

I did revert the relative positioning change as it will get in the way of 
merging this. Could you check if it's correctly positioned now? I don't own a 
fancy monitor :) Tried 200% scale here and everything looks monstrous. 125% 
scale looks correct.

> modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 
> 67:
> 
>> 65: } while (pango_attr_iterator_next(iter));
>> 66: 
>> 67: pango_attr_iterator_destroy (iter);
> 
> According to the docs you need to release the attribute list using 
> pango_attr_list_unref().

You're right. Fixed.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1428963127
PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1428962734

Re: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v13]

[Thiago Milczarek Sayao]

On Wed, 13 Dec 2023 19:22:49 GMT, Martin Fox  wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Account the case of !filtered
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 486:
> 
>> 484: CHECK_JNI_EXCEPTION(mainEnv)
>> 485: 
>> 486: if (press && key > 0) { // TYPED events should only be sent for 
>> printable characters.
> 
> A handler for the PRESS event might close the window. In that case `jview` 
> will be set to zero before you send out the TYPED event. You should do 
> another check for that here.
> 
> See [JDK-8301219](https://bugs.openjdk.org/browse/JDK-8301219) for some 
> sample code. I'll be submitting a fix for that bug just as soon as I get a 
> test case working reliably.

There's a check before.


if (!jview) {
return;
}

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1428971893

Re: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v15]

[Thiago Milczarek Sayao]

> This replaces obsolete XIM and uses gtk api for IME.
> Gtk uses [ibus](https://github.com/ibus/ibus)
> 
> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative 
> positioning on `InputMethodRequest`.
> 
> [Screencast from 17-09-2023 
> 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3)

Thiago Milczarek Sayao has updated the pull request incrementally with one 
additional commit since the last revision:

  - Fix double keyrelease

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1080/files
  - new: https://git.openjdk.org/jfx/pull/1080/files/ba03adce..ceb054a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=14
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=13-14

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1080.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080

PR: https://git.openjdk.org/jfx/pull/1080