Re: [OpenJDK 2D-Dev] RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v3]
> Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the > border, hence when the border is not painted the foxus is not displayed. The > idea is to paint the glowing border on the focused component anyways. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Update copyright year - Changes: - all: https://git.openjdk.java.net/jdk/pull/5082/files - new: https://git.openjdk.java.net/jdk/pull/5082/files/bda91782..fefcd37d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5082.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5082/head:pull/5082 PR: https://git.openjdk.java.net/jdk/pull/5082
Re: [OpenJDK 2D-Dev] RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked
On Thu, 12 Aug 2021 18:17:47 GMT, Sergey Bylokhov wrote: > There are two choices: draw this rectangle ourselves or request this feature > from the JRS. There i pushed the code that only draws the focus ring without the rest of the border. - PR: https://git.openjdk.java.net/jdk/pull/5082
Re: [OpenJDK 2D-Dev] RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked [v2]
> Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the > border, hence when the border is not painted the foxus is not displayed. The > idea is to paint the glowing border on the focused component anyways. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Changed to only paing focus ring without the entire border painting - Changes: - all: https://git.openjdk.java.net/jdk/pull/5082/files - new: https://git.openjdk.java.net/jdk/pull/5082/files/d4b21edc..bda91782 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5082&range=00-01 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5082.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5082/head:pull/5082 PR: https://git.openjdk.java.net/jdk/pull/5082
Re: [OpenJDK 2D-Dev] RFR: 8205138: Remove Applet references from Font2DTest [v2]
On Thu, 12 Aug 2021 19:16:55 GMT, Phil Race wrote: >> Applet support was removed already but the .html file was left as well as >> docs on applet issues >> and a parameter only relevant to applets. > > Phil Race has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains three additional commits since > the last revision: > > - 8205138: Remove Applet references from Font2DTest > - Merge remote-tracking branch 'origin/master' into f2d_applet >Merge > - 8205138: Remove Applet references from Font2DTest Marked as reviewed by psadhukhan (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4831
[OpenJDK 2D-Dev] RFR: JDK-8272374: doclint should report missing "body" comments
Please review a relatively simple update to have doclnt check for empty "descriptions" -- the body of a doc comment, before the block tags. It is already the case that doclint checks for missing/empty descriptions in block tags, like @param, @return, etc. There are three cases to consider: * The comment itself is missing: this was already checked and reported as "missing comment". * The comment is present, but is empty ... this seems relatively unlikely, but is nevertheless checked and reported as "empty comment". * The comment is present but only has block tags. This is not always a problem, since the description may be inherited, for example, in an overriding method, but when it is an issue, it is reported as "no initial description". No diagnostic is reported if the description is missing but the first tag is `@deprecated`, because in this case, javadoc will use the body of the `@deprecated` tag for the summary. See [`Character.UnicodeBlock#SURROGATES_AREA`](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Character.UnicodeBlock.html#SURROGATES_AREA) and the corresponding entry in the summary table to see an example of this situation. Diagnostics are reported if the declaration is not an overriding method and does not begin with `@deprecated`. This occurs in a number of places in the `java.desktop` module, often where the doc comment is of the form `/** @return _description_ */`. To suppress those warnings for now, the `-missing` option is added to `DOCLINT_OPTIONS` for the `java.desktop` module. To see the effects of this anti-pattern, look at the empty descriptions for [`javax.swing.text.html.parser.AttributeList`](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/text/html/parser/AttributeList.html#method.summary) Many of the doclint tests needed to be updated, because of their over-simplistic minimal comments. It was not possible, in general, to avoid updating the source code while preserving line numbers, so in many cases, the golden `*.out` files had to be updated as well. A new test is added, focussing on the different forms of empty/missing descriptions, as described above. - Commit messages: - JDK-8272374: doclint should report missing "body" comments Changes: https://git.openjdk.java.net/jdk/pull/5106/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5106&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272374 Stats: 281 lines in 37 files changed: 152 ins; 10 del; 119 mod Patch: https://git.openjdk.java.net/jdk/pull/5106.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5106/head:pull/5106 PR: https://git.openjdk.java.net/jdk/pull/5106
Re: [OpenJDK 2D-Dev] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v3]
On Thu, 12 Aug 2021 23:33:51 GMT, Alexey Ushakov wrote: >> Then you can roll back this change to the default opaque layer? > > Did you mean to make MTLLayer opaque by default? Yes, I did it in the latest > version. Then why do you need " platformWindow.setOpaque(!isTranslucent());" above? - PR: https://git.openjdk.java.net/jdk/pull/4946
Re: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working with fonts on Linux [v4]
On Thu, 12 Aug 2021 21:58:07 GMT, Phil Race wrote: >> Maxim Kartashev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Addressed PR comments >> >> 1. Added CHECK_NULL() to awt_Component.cpp > > test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java line 29: > >> 27: * @summary Verifies that -Xcheck:jni issues no warnings from >> freetypeScaler.c >> 28: * @library /test/lib >> 29: * @key headful > > What about this test is headful ? oh you are getting metrics for a JFrame ? That's not going to exercise any new font code so is pointless except to make it so the test has to be headful. - PR: https://git.openjdk.java.net/jdk/pull/4572
Re: [OpenJDK 2D-Dev] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v3]
On Thu, 12 Aug 2021 22:05:03 GMT, Sergey Bylokhov wrote: >> I've filed a separate CR for this problem JDK-8272392 > > Then you can roll back this change to the default opaque layer? Did you mean to make MTLLayer opaque by default? Yes, I did it in the latest version. - PR: https://git.openjdk.java.net/jdk/pull/4946
Re: [OpenJDK 2D-Dev] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v3]
On Thu, 12 Aug 2021 18:58:59 GMT, Alexey Ushakov wrote: >> Interesting, now I'm also able to reproduce this problem with the latest >> version of the fix. Actually, looks like the problem exists even without the >> fix. We get invalid background with the same scenario. It's not so visible >> because of default L&F (light). Nevertheless, the color of the background is >> not exact the same. If we provide >> apple.awt.application.appearance=NSAppearanceNameDarkAqua VM option, the >> problem became visible with metal and not reproducible with OGL. > > I've filed a separate CR for this problem JDK-8272392 Then you can roll back this change to the default opaque layer? - PR: https://git.openjdk.java.net/jdk/pull/4946
Re: [OpenJDK 2D-Dev] RFR: 8205138: Remove Applet references from Font2DTest [v2]
On Thu, 12 Aug 2021 19:16:55 GMT, Phil Race wrote: >> Applet support was removed already but the .html file was left as well as >> docs on applet issues >> and a parameter only relevant to applets. > > Phil Race has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains three additional commits since > the last revision: > > - 8205138: Remove Applet references from Font2DTest > - Merge remote-tracking branch 'origin/master' into f2d_applet >Merge > - 8205138: Remove Applet references from Font2DTest Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4831
Re: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working with fonts on Linux [v3]
On Mon, 19 Jul 2021 08:31:21 GMT, Maxim Kartashev wrote: >> src/java.desktop/windows/native/libawt/java2d/d3d/D3DRenderQueue.cpp line >> 870: >> >>> 868: J2dTraceLn(J2D_TRACE_VERBOSE, " executing runnable"); >>> 869: jboolean ignoreException; >>> 870: JNU_CallMethodByName(env, &ignoreException, pFlush->runnable, >>> "run", "()V"); >> >> What is the purpose of this change? the only difference is that in the >> second case the ExceptionCheck will be called, does it affect something? > > Yes, the `ExceptionCheck()` call will silence the warnings from `-Xcheck:jni`. Does it actually suppress the "Xcheck:jni" or it clears a raised exception? If an exception is still "raised" after this call we should do some additional steps to log/clean it. - PR: https://git.openjdk.java.net/jdk/pull/4572
Re: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working with fonts on Linux [v4]
On Mon, 19 Jul 2021 09:38:27 GMT, Maxim Kartashev
wrote:
>> Added an `ExceptionCheck()` followed by `ExceptionDescribe()` and
>> `ExceptionClear()` immediately after the Java calls made from the callback
>> function `ReadTTFontFileFunc()` in `freetypeScaler.c`.
>>
>> The exception(s) need to be cleared because we're not returning immediately
>> to Java that would've been able to handle them gracefully. And in order not
>> to loose the exception entirely (even though the return value would also
>> indicate an error condition), print out the exception with
>> `ExceptionDescribe()` to aid in debugging.
>
> Maxim Kartashev has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Addressed PR comments
>
> 1. Added CHECK_NULL() to awt_Component.cpp
test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java line 29:
> 27: * @summary Verifies that -Xcheck:jni issues no warnings from
> freetypeScaler.c
> 28: * @library /test/lib
> 29: * @key headful
What about this test is headful ?
test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java line 36:
> 34: import java.awt.geom.Rectangle2D;
> 35: import java.awt.image.*;
> 36: import java.io.*;
Can we get rid of all these wild card imports ?
test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java line 59:
> 57: for (String ff : families)
> 58: {
> 59: Font font = Font.decode(ff);
Gosh, does anyone still use decode() ? I keep forgetting it exists.
You have all the family names, why not just new Font(ff, Font.PLAIN, 12) ?
-
PR: https://git.openjdk.java.net/jdk/pull/4572
Re: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working with fonts on Linux [v4]
On Mon, 19 Jul 2021 09:38:27 GMT, Maxim Kartashev wrote: >> Added an `ExceptionCheck()` followed by `ExceptionDescribe()` and >> `ExceptionClear()` immediately after the Java calls made from the callback >> function `ReadTTFontFileFunc()` in `freetypeScaler.c`. >> >> The exception(s) need to be cleared because we're not returning immediately >> to Java that would've been able to handle them gracefully. And in order not >> to loose the exception entirely (even though the return value would also >> indicate an error condition), print out the exception with >> `ExceptionDescribe()` to aid in debugging. > > Maxim Kartashev has updated the pull request incrementally with one > additional commit since the last revision: > > Addressed PR comments > > 1. Added CHECK_NULL() to awt_Component.cpp I'm going to see if the test passes on the internal systems we use which I think will be mostly variout RH/OL systems for this headless test for Linux - and it also will get run on Windows Server of some kind .. I don't think macOS will hit this code path at all for this test. - PR: https://git.openjdk.java.net/jdk/pull/4572
Re: [OpenJDK 2D-Dev] RFR: 8181571: printing to CUPS fails on mac sandbox app
On Wed, 21 Jul 2021 15:45:55 GMT, Alexander Scherbatiy
wrote:
> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
>
> Create a native macOS app from the Hello.java file, sign and run it in
> sandbox:
>
> import javax.print.*;
> import javax.swing.*;
>
> public class Hello {
>
> public static void main(String[] args) throws Exception {
> SwingUtilities.invokeAndWait(() -> {
> boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID")
> != null;
> PrintService defaultPrinter =
> PrintServiceLookup.lookupDefaultPrintService();
> PrintService[] services =
> PrintServiceLookup.lookupPrintServices(null, null);
>
> StringBuilder builder = new StringBuilder();
> builder.append("is sandboxed: ").append(isSandboxed).append("\n");
> builder.append("default printer:
> ").append(defaultPrinter).append("\n");
> int size = services.length;
> for (int i = 0; i < size; i++) {
>
> builder.append("printer[").append(i).append("]=").append(services[i]).append("\n");
> }
> JOptionPane.showMessageDialog(null, builder.toString());
> });
> }
> }
>
> The signed app in sandbox shows null default printer and
> PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp".
> 
>
> The problem has been discussed on 2d-dev mail list:
> https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html
> https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html
>
> According to the discussion:
>
>> I've submitted a DTS incident to Apple and a friend there has followed-up.
>> Their unofficial position is that java should be connecting to the cups
>> interface returned
>> by the cupsServer() function and not changing the interface string to
>> "localhost".
>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>> network-client access with print access. They don't seem interested in
>> loosening that change.
>
>
> The proposed solution is to use the domain socket pathname in
> httpConnect(...) cups function and cupsGetDests(...) to get list of printers
> from cups when the app is signed and is run in sandbox on MacOs.
Changes requested by prr (Reviewer).
src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 96:
> 94: libFound = initIDs();
> 95: if (libFound) {
> 96:cupsServer = getCupsServer();
I think we should wrap all the new lines in isMac()
Also can you explain the reasons for the logic that implies we may have a
server starting with "/"
in which case your always change the cupServer to localhost even if it is not
sandboxed ?
I ask because it seems to contradict what you pasted
"by the cupsServer() function and not changing the interface string to
"localhost""
src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 399:
> 397: return printerURIs;
> 398: }
> 399: }
So if getCupsDefaultPrinters() doesn't find anything you always continue to the
original code even though
it would seem that you know we are in a sandboxed app and it won't find
anything ?
src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 489:
> 487: return domainSocketPathname;
> 488: }
> 489:
You will need to suppress deprecation warnings here.
src/java.desktop/unix/classes/sun/print/CUPSPrinter.java line 506:
> 504: IPPPrintService.debug_println(debugPrefix+"libFound "+libFound);
> 505: if (libFound) {
> 506: String server = getDomainSocketPathname() != null ?
> getDomainSocketPathname() : getServer();
Split this long line
src/java.desktop/unix/native/common/awt/CUPSfuncs.c line 244:
> 242: DPRINTF("CUPSfuncs::bad alloc new array\n", "")
> 243: (*env)->ExceptionClear(env);
> 244: JNU_ThrowOutOfMemoryError(env, "OutOfMemoryError");
I find this weird. What is the ExceptionClear for ? The only possible exception
here is for
an OOME which might be thrown by NewObjectArray. So you clear that and then
re-create it ?
And who do will catch this ? What's the point ? Maybe just clear and return
null.
src/java.desktop/unix/native/common/awt/CUPSfuncs.c line 253:
> 251: j2d_cupsFreeDests(num_dests, dests);
> 252: DPRINTF("CUPSfuncs::bad alloc new string ->name\n", "")
> 253: JNU_ThrowOutOfMemoryError(env, "OutOfMemoryError");
similar comments to above plus I am fairly sure you want to delete nameArray
since it isn't returned.
For that matter if the NewString fails on the 4th printer you want to free the
3 previous ones too before returning.
-
PR: https://git.openjdk.java.net/jdk/pull/4861
Re: [OpenJDK 2D-Dev] RFR: 8205138: Remove Applet references from Font2DTest [v2]
> Applet support was removed already but the .html file was left as well as > docs on applet issues > and a parameter only relevant to applets. Phil Race has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - 8205138: Remove Applet references from Font2DTest - Merge remote-tracking branch 'origin/master' into f2d_applet Merge - 8205138: Remove Applet references from Font2DTest - Changes: - all: https://git.openjdk.java.net/jdk/pull/4831/files - new: https://git.openjdk.java.net/jdk/pull/4831/files/64ffdd81..3f2aa44c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4831&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4831&range=00-01 Stats: 50890 lines in 806 files changed: 42259 ins; 3998 del; 4633 mod Patch: https://git.openjdk.java.net/jdk/pull/4831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4831/head:pull/4831 PR: https://git.openjdk.java.net/jdk/pull/4831
Re: [OpenJDK 2D-Dev] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v3]
On Wed, 11 Aug 2021 12:48:47 GMT, Alexey Ushakov wrote: >> I check the steps below and was able to reproduce the same artifacts(black >> rectangles) in the tree tab with the current version of the fix. And I do >> not see a big difference between setting the layer to YES at the beginning >> or a little bit later, at the end, it will be opaque and artifacts occur. >> >> 1. Run SwingSet2 >> 2. Click on all tabs starting from the second one, delay on each tab for the >> second or so >> 3. On the tab with swing tree control try to expand some tree nodes -> >> you'll see black rectangles while performing the clicks >> 4. Repeat from step 2 if no artifacts are visible > > Interesting, now I'm also able to reproduce this problem with the latest > version of the fix. Actually, looks like the problem exists even without the > fix. We get invalid background with the same scenario. It's not so visible > because of default L&F (light). Nevertheless, the color of the background is > not exact the same. If we provide > apple.awt.application.appearance=NSAppearanceNameDarkAqua VM option, the > problem became visible with metal and not reproducible with OGL. I've filed a separate CR for this problem JDK-8272392 - PR: https://git.openjdk.java.net/jdk/pull/4946
Re: [OpenJDK 2D-Dev] RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked
On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the > border, hence when the border is not painted the foxus is not displayed. The > idea is to paint the glowing border on the focused component anyways. Probably solution should be somewhere similar to this one: https://github.com/openjdk/jdk/commit/440db35e - PR: https://git.openjdk.java.net/jdk/pull/5082
Re: [OpenJDK 2D-Dev] RFR: 8205138: Remove Applet references from Font2DTest
On Wed, 21 Jul 2021 06:19:13 GMT, Sergey Bylokhov wrote: > Probably we can delete the SwingSet2.html as well? Yes, there's a separate bug for that which I'll be getting around to. - PR: https://git.openjdk.java.net/jdk/pull/4831
Re: [OpenJDK 2D-Dev] RFR: 8205138: Remove Applet references from Font2DTest
On Thu, 22 Jul 2021 05:04:55 GMT, Prasanta Sadhukhan wrote: >> Applet support was removed already but the .html file was left as well as >> docs on applet issues >> and a parameter only relevant to applets. > > src/demo/share/jfc/Font2DTest/Font2DTest.java line 272: > >> 270: fileMenu.addSeparator(); >> 271: if ( !isApplet ) >> 272: fileMenu.add( new MenuItemV2( "Exit", this )); > > If it is not Applet, should we not retain this line? oopsy. I did not mean to do that. I will restore. > src/demo/share/jfc/Font2DTest/README.txt line 142: > >> 140: - There are still some bugs around the error handling. >> 141: Most of these problems will usually get fixed when some parameters >> 142: are changed, or the screen is refreshed. > > Are the 1st 2 known problems are not there now? I do not know of problems with getting metrics for Postscript fonts and I have no idea what the 2nd comment means and it may be ancient history which is why I want to clean it up. - PR: https://git.openjdk.java.net/jdk/pull/4831
Re: [OpenJDK 2D-Dev] RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked
On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the > border, hence when the border is not painted the foxus is not displayed. The > idea is to paint the glowing border on the focused component anyways. BTW this issue was known for a long time, and even the spec was updated specifically for it: https://bugs.openjdk.java.net/browse/JDK-4416026 - PR: https://git.openjdk.java.net/jdk/pull/5082
Re: [OpenJDK 2D-Dev] RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked
On Wed, 11 Aug 2021 11:22:50 GMT, Alexander Zuev wrote: > Initial implementation and a test case. > > The problem is that Aqua LaF shows the focused component with the glow on the > border, hence when the border is not painted the foxus is not displayed. The > idea is to paint the glowing border on the focused component anyways. The motif L&F is not supported for a while and is ready to remove, so that L&F behavior cannot be referenced as a proper way to work. The focused button on macOS is highlighted by the "blue" rounded rectangle. There are two choices: draw this rectangle ourselves or request this feature from the JRS. But the change should not break the behavior of the "setBorderPainted(false)". - PR: https://git.openjdk.java.net/jdk/pull/5082
Re: [OpenJDK 2D-Dev] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v3]
> Keep MTLLayer opacity in sync with window content view > Keep layer translucent for translucent windows Alexey Ushakov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL Keep MTLLayer opacity in sync with window content view Keep layer translucent for translucent windows Update opacity on textured property change Make native MTLLayer opaque by default to match java component state - Changes: https://git.openjdk.java.net/jdk/pull/4946/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4946&range=02 Stats: 274 lines in 7 files changed: 269 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4946.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4946/head:pull/4946 PR: https://git.openjdk.java.net/jdk/pull/4946
[OpenJDK 2D-Dev] Withdrawn: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
On Thu, 22 Apr 2021 09:21:20 GMT, Toshio Nakamura wrote: > Hi, > > Could you review the fix? > When non-English characters were printed from JTable on MacOS, > CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, > CTextPipe seems not support glyph with slot number of composite fonts. > > The slot data mask of GlyphVector is 0xff00. In my environment, Japanese > font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, > unexpected glyph was drawn. > > This patch checks slot data of each character. If slot data exists, it will > branch to GlyphVector's drawing path. > > Well, I couldn't create automatic test for this fix. This method seems to be > called for printing only. I appreciate any advice. > Tested java/awt and javax/swing on MacOS BigSur, and there was no regression. > > Regards, > Toshio Nakamura This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/3619
Re: [OpenJDK 2D-Dev] RFR: 8269951: [macos] Focus not painted in JButton when setBorderPainted(false) is invoked
On Thu, 12 Aug 2021 02:15:06 GMT, Sergey Bylokhov wrote: > Painting the border while the user tries to disable the border via > setBorderPainted(false) does not look like a correct solution. The user might > be drawn something there already. I remember we discussed a similar a11y bug > related to focus and the only possible solution was to draw the focus > ourselves or request this feature in the JRS. There is no other way on Mac OS to indicate focused button but the glowing border. The same situation happens on Motif L&F - the only way to differentiate focused button from unfocused is by the border and in Motif - just as in Aqua - once border painting is disabled there is no way to tell if button is focused or not. User might draw something but if button becomes focused the focus indication will be drawn over it. If focus indicator disrupts user's painting on top of the button insets area user can always disable focus painting on such a component deliberately by calling JButton.setFocusPainted(boolean) - PR: https://git.openjdk.java.net/jdk/pull/5082
[OpenJDK 2D-Dev] Integrated: 8272332: --with-harfbuzz=system doesn't add -lharfbuzz after JDK-8255790
On Wed, 11 Aug 2021 17:58:04 GMT, Severin Gehwolf wrote: > Please review this simple build fix to correct the typo done in JDK-8255790. > After the patch correct external library is added to the `libfontmanager.so` > link command when building with `--with-harfbuzz=system`. > > Thoughts? This pull request has now been integrated. Changeset: d38b3143 Author:Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/d38b31438dd4730ee2149c02277d60c35b9d7d81 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8272332: --with-harfbuzz=system doesn't add -lharfbuzz after JDK-8255790 Reviewed-by: prr - PR: https://git.openjdk.java.net/jdk/pull/5091
Re: [OpenJDK 2D-Dev] RFR: 8272332: --with-harfbuzz=system doesn't add -lharfbuzz after JDK-8255790
On Wed, 11 Aug 2021 18:21:14 GMT, Phil Race wrote: >> Please review this simple build fix to correct the typo done in JDK-8255790. >> After the patch correct external library is added to the `libfontmanager.so` >> link command when building with `--with-harfbuzz=system`. >> >> Thoughts? > > Marked as reviewed by prr (Reviewer). Thanks for the review @prrace! - PR: https://git.openjdk.java.net/jdk/pull/5091
