[jira] [Comment Edited] (NETBEANS-4095) NPE saving Java file with type error in for-each
[
https://issues.apache.org/jira/browse/NETBEANS-4095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094511#comment-17094511
]
Eirik Bakke edited comment on NETBEANS-4095 at 4/28/20, 1:41 PM:
-
I managed to reproduce it again on a fresh build of NetBeans 11.3 on Java 14,
with nbjavac installed and CoS enabled. It did not seem to occur without
nbjavac installed.
At some point it wasn't triggering the error, so I added
ystem.out.println("hello, world"); in the body of the for loop (to force a
recompilation--not sure what kinds of changes will do so). That triggered the
error again.
That was with source level 14, too.
was (Author: ebakke):
I managed to reproduce it again on a fresh build of NetBeans 11.3 on Java 14,
with nbjavac installed and CoS enabled. It did not seem to occur without
nbjavac installed.
At some point it wasn't triggering the error, so I added
ystem.out.println("hello, world"); in the body of the for loop (to force a
recompilation--not sure what kinds of changes will do so). That triggered the
error again.
> NPE saving Java file with type error in for-each
>
>
> Key: NETBEANS-4095
> URL: https://issues.apache.org/jira/browse/NETBEANS-4095
> Project: NetBeans
> Issue Type: Bug
> Components: java - Source
>Affects Versions: 11.3
> Environment: Java 14, NetBeans with nbjavac plugin installed
>Reporter: Eirik Bakke
>Assignee: Arunava Sinha
>Priority: Major
> Labels: nbjavac
>
> If, during editing, a for-each loop appears with an incorrect pair of types,
> an error dialog shows up showing a NullPointerException every time the Java
> source file is saved, interrupting the user. A minimized example exhibiting
> this behavior is as follows:
> {code:java}
> public final class CausesVisitIterableForeachLoopNPE {
> public static final void main(String args[]) {
> final Map someMap = null;
> for (Object someVar : someMap) { }
> }
> }
> {code}
> This example causes the IDE to throw the following exception:
> {noformat}
> java.lang.NullPointerException
> at
> com.sun.tools.javac.comp.Lower.visitIterableForeachLoop(Lower.java:3275)
> at com.sun.tools.javac.comp.Lower.visitForeachLoop(Lower.java:3162)
> at
> com.sun.tools.javac.tree.JCTree$JCEnhancedForLoop.accept(JCTree.java:1176)
> at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
> at com.sun.tools.javac.comp.Lower.translate(Lower.java:2080)
> at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70)
> at
> com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:167)
> at com.sun.tools.javac.comp.Lower.visitBlock(Lower.java:3347)
> at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1036)
> at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
> at com.sun.tools.javac.comp.Lower.translate(Lower.java:2080)
> at
> com.sun.tools.javac.tree.TreeTranslator.visitMethodDef(TreeTranslator.java:150)
> at
> com.sun.tools.javac.comp.Lower.visitMethodDefInternal(Lower.java:2538)
> at com.sun.tools.javac.comp.Lower.visitMethodDef(Lower.java:2448)
> at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:882)
> at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
> at com.sun.tools.javac.comp.Lower.translate(Lower.java:2080)
> at com.sun.tools.javac.comp.Lower.visitClassDef(Lower.java:2219)
> at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:788)
> at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
> at com.sun.tools.javac.comp.Lower.translate(Lower.java:2080)
> at com.sun.tools.javac.comp.Lower.translate(Lower.java:2099)
> at
> com.sun.tools.javac.comp.Lower.translateTopLevelClass(Lower.java:3813)
> at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1691)
> at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1532)
> at
> com.sun.tools.javac.api.JavacTaskImpl$2.process(JavacTaskImpl.java:574)
> at
> com.sun.tools.javac.api.JavacTaskImpl$Filter.run(JavacTaskImpl.java:651)
> at
> com.sun.tools.javac.api.JavacTaskImpl.generate(JavacTaskImpl.java:577)
> [catch] at
> org.netbeans.modules.java.source.nbjavac.indexing.MultiPassCompileWorker.compile(MultiPassCompileWorker.java:303)
> at
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer.index(JavaCustomIndexer.java:361)
> at
> org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$2.run(Indexable.java:138)
> at
>
[jira] [Updated] (NETBEANS-4179) Assertion error in javac when saving file with missing comma in method parameter list
[
https://issues.apache.org/jira/browse/NETBEANS-4179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-4179:
--
Description:
If, during editing, a method parameter list occurs with a missing comma (in
certain cases), an error dialog shows up showing an assertion error in javac
every time the Java source file is saved, interrupting the user. A minimized
example exhibiting this behavior is as follows:
{code:java}
public class BugErrorUncaught {
private Object testMethod(String param1 final String param2) {
return null;
}
}
{code}
This is a variation of the example in NETBEANS-4095, but filed here as a
separate bug since the two cause different exceptions at different levels
(inside javac here vs. at the semantic highlighting layer in NETBEANS-4095).
This example causes the IDE to throw the following exception:
{noformat}
java.lang.AssertionError
at com.sun.tools.javac.util.Assert.error(Assert.java:155)
at com.sun.tools.javac.util.Assert.check(Assert.java:46)
at
com.sun.tools.javac.comp.Flow$FlowAnalyzer.errorUncaught(Flow.java:918)
at
com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitClassDef(Flow.java:1008)
at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:788)
at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:422)
at
com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1456)
at
com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1446)
at com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:219)
at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1499)
at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1473)
at
com.sun.tools.javac.api.JavacTaskImpl$1.process(JavacTaskImpl.java:504)
at
com.sun.tools.javac.api.JavacTaskImpl$Filter.run(JavacTaskImpl.java:651)
at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:507)
[catch] at
org.netbeans.modules.java.source.nbjavac.indexing.MultiPassCompileWorker.compile(MultiPassCompileWorker.java:261)
at
org.netbeans.modules.java.source.indexing.JavaCustomIndexer.index(JavaCustomIndexer.java:361)
at
org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$2.run(Indexable.java:138)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runIndexer(RepositoryUpdater.java:275)
at
org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor.index(Indexable.java:136)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doIndex(RepositoryUpdater.java:2750)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.access$800(RepositoryUpdater.java:2154)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2636)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2634)
at
org.netbeans.modules.parsing.impl.indexing.errors.TaskCache.refreshTransaction(TaskCache.java:540)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.index(RepositoryUpdater.java:2634)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$3.call(RepositoryUpdater.java:3300)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$3.call(RepositoryUpdater.java:3255)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$4.run(RepositoryUpdater.java:2127)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runInContext(RepositoryUpdater.java:2123)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runInContext(RepositoryUpdater.java:2104)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.access$1500(RepositoryUpdater.java:136)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.scanFiles(RepositoryUpdater.java:3255)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$FileListWork.getDone(RepositoryUpdater.java:3785)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3420)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6183)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$4300(RepositoryUpdater.java:5834)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2$1.run(RepositoryUpdater.java:6099)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
at
[jira] [Created] (NETBEANS-4259) NPE in code completion when in incorrect cast syntax
Eirik Bakke created NETBEANS-4259:
-
Summary: NPE in code completion when in incorrect cast syntax
Key: NETBEANS-4259
URL: https://issues.apache.org/jira/browse/NETBEANS-4259
Project: NetBeans
Issue Type: Bug
Components: java - Source
Affects Versions: 11.3
Environment: NetBeans 11.3 on Windows (OS shouldn't matter)
Reporter: Eirik Bakke
In the following class, put the cursor after "dat" and invoke code completion
(Ctrl+Space). This situation often happens from muscle memory while typing a
cast. A NPE will result:
{code:java}
public class TestFoo {
private String someMethod(Object someArg) {
if (someArg instanceof String)
return (String dat); // To see parser error, open code completion with
cursor after "dat
return null;
}
}
{code}
The desired behavior is to just ignore the incorrect syntax, and perform no
completion. Instead, the following exception is shown:
{noformat}
java.lang.NullPointerException
at
org.netbeans.modules.java.completion.BaseTask.getEnvImpl(BaseTask.java:389)
at
org.netbeans.modules.java.completion.BaseTask.getCompletionEnvironment(BaseTask.java:270)
at
org.netbeans.modules.java.completion.JavaCompletionTask.resolve(JavaCompletionTask.java:297)
at org.netbeans.modules.java.completion.BaseTask.run(BaseTask.java:94)
at
org.netbeans.modules.java.completion.JavaCompletionTask.run(JavaCompletionTask.java:60)
at
org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
at
org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:130)
at
org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:114)
at
org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
at
org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
at
org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
at
org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
at
org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
at
org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
at
org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
Caused: org.netbeans.modules.parsing.spi.ParseException
at
org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:186)
at
org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:81)
[catch] at
org.netbeans.modules.editor.java.JavaCompletionProvider$JavaCompletionQuery.query(JavaCompletionProvider.java:193)
at
org.netbeans.spi.editor.completion.support.AsyncCompletionTask.run(AsyncCompletionTask.java:198)
at
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
{noformat}
Reporting this bug in case a pattern emerges where various kinds of errors like
this pop up instead of being silently ignored.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-4238) Umlauts (ÖÄÜ...) invisible in editor with Consolas font (Windows 10)
[ https://issues.apache.org/jira/browse/NETBEANS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-4238: -- Description: This issue created from an email on the nbusers list. Thomas Kellerer writes: I am using the (built-in) Consolas font for editing in NetBeans (and all other code editors actually). It seems that the line height in the NetBeans editor is a bit too small and cuts off the top most pixels. This isn't really a problem, except for upper case German umlauts (ÖÄÜ). However the output window (using the same font) does not suffer from this. I have uploaded a screenshot to show the problem [attached to JIRA issue here] I remember in very old NetBeans versions it was possible to influence the line height in the editor, but apparently this isn't possible any more. Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case with 11 as well. was: This issue created from an email on the nbusers list. Thomas Kellerer writes: I am using the (built-in) Consolas font for editing in NetBeans (and all other code editors actually). It seems that the line height in the NetBeans editor is a bit too small and cuts off the top most pixels. This isn't really a problem, except for upper case German umlauts (ÖÄÜ). However the output window (using the same font) does not suffer from this. I have uploaded a screenshot to show the problem: https://i.imgur.com/g8gGvLK.png I remember in very old NetBeans versions it was possible to influence the line height in the editor, but apparently this isn't possible any more. Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case with 11 as well. > Umlauts (ÖÄÜ...) invisible in editor with Consolas font (Windows 10) > > > Key: NETBEANS-4238 > URL: https://issues.apache.org/jira/browse/NETBEANS-4238 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting Printing >Affects Versions: 11.3 > Environment: This happens both in 11.3 and 12-beta3. I am using > Windows 10, and this is not a High-DPI display (standard 1920*1200 monitor). >Reporter: Eirik Bakke >Priority: Minor > Attachments: umlauts.png > > > This issue created from an email on the nbusers list. Thomas Kellerer writes: > I am using the (built-in) Consolas font for editing in NetBeans (and all > other code editors actually). > It seems that the line height in the NetBeans editor is a bit too small and > cuts off the top most pixels. > This isn't really a problem, except for upper case German umlauts (ÖÄÜ). > However the output window (using the same font) does not suffer from this. > I have uploaded a screenshot to show the problem [attached to JIRA issue here] > I remember in very old NetBeans versions it was possible to influence the > line height in the editor, but apparently this isn't possible any more. > Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case > with 11 as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-4238) Umlauts (ÖÄÜ...) invisible in editor with Consolas font (Windows 10)
[ https://issues.apache.org/jira/browse/NETBEANS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-4238: -- Description: This issue created from an email on the nbusers list. Thomas Kellerer writes: I am using the (built-in) Consolas font for editing in NetBeans (and all other code editors actually). It seems that the line height in the NetBeans editor is a bit too small and cuts off the top most pixels. This isn't really a problem, except for upper case German umlauts (ÖÄÜ). However the output window (using the same font) does not suffer from this. I have uploaded a screenshot to show the problem: https://i.imgur.com/g8gGvLK.png I remember in very old NetBeans versions it was possible to influence the line height in the editor, but apparently this isn't possible any more. Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case with 11 as well. was: I am using the (built-in) Consolas font for editing in NetBeans (and all other code editors actually). It seems that the line height in the NetBeans editor is a bit too small and cuts off the top most pixels. This isn't really a problem, except for upper case German umlauts (ÖÄÜ). However the output window (using the same font) does not suffer from this. I have uploaded a screenshot to show the problem: https://i.imgur.com/g8gGvLK.png I remember in very old NetBeans versions it was possible to influence the line height in the editor, but apparently this isn't possible any more. Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case with 11 as well. > Umlauts (ÖÄÜ...) invisible in editor with Consolas font (Windows 10) > > > Key: NETBEANS-4238 > URL: https://issues.apache.org/jira/browse/NETBEANS-4238 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting Printing >Affects Versions: 11.3 > Environment: This happens both in 11.3 and 12-beta3. I am using > Windows 10, and this is not a High-DPI display (standard 1920*1200 monitor). >Reporter: Eirik Bakke >Priority: Minor > Attachments: umlauts.png > > > This issue created from an email on the nbusers list. Thomas Kellerer writes: > I am using the (built-in) Consolas font for editing in NetBeans (and all > other code editors actually). > It seems that the line height in the NetBeans editor is a bit too small and > cuts off the top most pixels. > This isn't really a problem, except for upper case German umlauts (ÖÄÜ). > However the output window (using the same font) does not suffer from this. > I have uploaded a screenshot to show the problem: > https://i.imgur.com/g8gGvLK.png > I remember in very old NetBeans versions it was possible to influence the > line height in the editor, but apparently this isn't possible any more. > Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case > with 11 as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-4238) Umlauts (ÖÄÜ...) invisible in editor with Consolas font (Windows 10)
Eirik Bakke created NETBEANS-4238: - Summary: Umlauts (ÖÄÜ...) invisible in editor with Consolas font (Windows 10) Key: NETBEANS-4238 URL: https://issues.apache.org/jira/browse/NETBEANS-4238 Project: NetBeans Issue Type: Bug Components: editor - Painting Printing Affects Versions: 11.3 Environment: This happens both in 11.3 and 12-beta3. I am using Windows 10, and this is not a High-DPI display (standard 1920*1200 monitor). Reporter: Eirik Bakke Attachments: umlauts.png I am using the (built-in) Consolas font for editing in NetBeans (and all other code editors actually). It seems that the line height in the NetBeans editor is a bit too small and cuts off the top most pixels. This isn't really a problem, except for upper case German umlauts (ÖÄÜ). However the output window (using the same font) does not suffer from this. I have uploaded a screenshot to show the problem: https://i.imgur.com/g8gGvLK.png I remember in very old NetBeans versions it was possible to influence the line height in the editor, but apparently this isn't possible any more. Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case with 11 as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-2196) Move field "database" below "user name" & "password" on the new database connection wizard
[ https://issues.apache.org/jira/browse/NETBEANS-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17090703#comment-17090703 ] Eirik Bakke commented on NETBEANS-2196: --- Beware of the difference between a database and a schema--on some backends, you can't login without specifying a database (PostgreSQL I believe), and I'm not sure it's possible to retrieve a list of databases (though you can retrieve a list of schemas within a database, which is shown on the next wizard page). The "database" field is something which becomes part of the JDBC URL, which you need in order to connect in the first place. > Move field "database" below "user name" & "password" on the new database > connection wizard > -- > > Key: NETBEANS-2196 > URL: https://issues.apache.org/jira/browse/NETBEANS-2196 > Project: NetBeans > Issue Type: Improvement > Components: db - Code >Affects Versions: Next >Reporter: Christian Lenz >Priority: Major > Labels: UX > Attachments: current behaviour.png, wanted behaviour.png > > > To make it clear, it is not that I don't like the Database field above the > user credentials, it is that it doesn't make sense for a specific context, > which will be handled in an other ticket. First I will choose the connection: > localhost + port. This is the first one. There is no login, so I don't know > the available databases. Now I want to add my credentials and after it, I > want to choose my database which can be known by asking the server to fetch > the databases to make it visible inside of the auto completion combo box > which is common these days to have this if you have a lot of entries. > So this ticket is only to moving the field Databases below the credentials > because of a new feature coming later. It doesn't make sense to add the > database name, before filling all the credentials first. You can't see > databases if you not logged into phpmyadmin for example. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-1901) Font rendering issue - Display bug on a space followed by a tab
[ https://issues.apache.org/jira/browse/NETBEANS-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17090697#comment-17090697 ] Eirik Bakke commented on NETBEANS-1901: --- Once NetBeans 12 is out, please see if this problem still exists. Some tab/space alignment issues were fixed by https://github.com/apache/netbeans/pull/2076 . > Font rendering issue - Display bug on a space followed by a tab > --- > > Key: NETBEANS-1901 > URL: https://issues.apache.org/jira/browse/NETBEANS-1901 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting Printing >Affects Versions: 10.0, 11.0, 11.1 > Environment: Windows 10, MacOS High Sierra & MacOS Mojave > Netbeans 10, Netbeans 11 & Netbeans 11.1 > JRE 11 & 12 >Reporter: Admeen >Priority: Minor > Labels: editor, formatting > Attachments: 20190319_actual_result.png, 20190319_example_code.php, > 20190319_expected_result.png, 20190320_syntax_settings.png, > editor_bug_space_tab.png, formatting_settings.png, netbeans-1901-jy-01.png, > netbeans-1901-jy-02.png > > > There appears to be a bug in the editor when a space is followed by a tab. > The editor does not display the space and tab, but the space and tab > characters are present in the file. > The editor / code formatting does not appear to be functioning correctly here. > UPDATE: > In the tab "Fonts & Colors" in the "Syntax" subtab I had the "default" font > set to "Monospaced 16". The issue occurs when using this font size. When I > change it back to the default value "Monospaced 13" or "Monospaced 18" it > works just fine. After some more testing I found out that with the font set > to "Monospaced 10, 11, 12, 14, 15, 16, 17, 19 & 20" it does not work (didn't > test higher or lower values). > UPDATE 2: > The issue persists in Netbeans version 11.1 now with JRE 12.0.2 installed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-584) Find and Replace boxes not rendered correctly
[ https://issues.apache.org/jira/browse/NETBEANS-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-584. -- Resolution: Duplicate Partially fixed by https://github.com/apache/netbeans/pull/1777 ; further improvements depend on https://bugs.openjdk.java.net/browse/JDK-8241561 . > Find and Replace boxes not rendered correctly > - > > Key: NETBEANS-584 > URL: https://issues.apache.org/jira/browse/NETBEANS-584 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting Printing, editor - Search >Affects Versions: 9.0 > Environment: Product Version: Apache NetBeans IDE Dev (Build > incubator-netbeans-release-205-on-20180202) > Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2 > Java: 10; Java HotSpot(TM) 64-Bit Server VM 10+46 > Runtime: Java(TM) SE Runtime Environment 10+46 > System: Windows 10 version 10.0 running on amd64; Cp1252; en_AU (nb) > User directory: Z:\tmp\.other\user\netbeans\v09.00-beta\watchdog > Cache directory: Z:\tmp\.other\cache\netbeans\watchdog-09 >Reporter: will mason >Priority: Major > Labels: Regression, textfield > Attachments: 2018-04-04 10_09_35-Handler.java - Find.png, 2018-04-04 > 10_09_35-Handler.java - Replace.png > > > h3. expected > * Clear rendering with an outline on Find and Replace boxes in editor > h3. actual > * See screenshots -- Both the replace and find boxes are rendered incorrectly > h3. supporting materials > * Find dialogue > * Replace dialogue -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-346) Tabs, characters, and the right Margin don't line up
[ https://issues.apache.org/jira/browse/NETBEANS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-346. -- Fix Version/s: 12.0 Resolution: Fixed Marking as resolved as PR was merged. > Tabs, characters, and the right Margin don't line up > > > Key: NETBEANS-346 > URL: https://issues.apache.org/jira/browse/NETBEANS-346 > Project: NetBeans > Issue Type: Bug > Components: editor - Other >Affects Versions: 9.0 > Environment: Mac OS 10.10 (at least) >Reporter: Austin Stephens >Priority: Critical > Labels: HiDPI, font, pull-request-available > Fix For: 12.0 > > Attachments: Screen Shot 2018-01-29 at 4.58.35 PM.png, Screen Shot > 2018-02-28 at 11.27.32 AM.png, linewidth.png > > Time Spent: 20m > Remaining Estimate: 0h > > When the Right Margin is set at 80 chars, it is drawn at 8*2* chars. This is > annoying because I have a 1440x900 screen that I split vertically in to two. > This results in two editing areas that are about 80 chars wide. I could see > the margin line in both editors when scrolled all the way to the left. Since > Netbeans (9.0 beta) is now drawing them at char 8*2*, it is not possible to > size those editors so I can see the line in both windows and it is driving me > crazy. > This is a first world issue at the moment, but you might find code coming > from mac programmers coming in two or more chars too wide in the Netbeans > source code. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-2543) File names clipped in Files and Projects tabs
[ https://issues.apache.org/jira/browse/NETBEANS-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-2543. --- Fix Version/s: 12.0 Resolution: Fixed Marking issue as resolved since PR was merged. > File names clipped in Files and Projects tabs > - > > Key: NETBEANS-2543 > URL: https://issues.apache.org/jira/browse/NETBEANS-2543 > Project: NetBeans > Issue Type: Bug > Components: platform - Other, projects - Generic Projects UI >Affects Versions: 9.0, 10.0, 11.0 > Environment: Windows Pro 10 1809, HP 500-210qe >Reporter: Geo B >Priority: Major > Labels: HiDPI, pull-request-available > Fix For: 12.0 > > Attachments: netbeans_display.jpg > > Time Spent: 0.5h > Remaining Estimate: 0h > > File name extensions appear clipped in Files window. For example, files with > extension `.yaml` may appear as .yaml, .yam or .yar. See attached screen grab. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-4198) Bad text rendering for Test results on macOS, and with HiDPI scaling on Windows
[ https://issues.apache.org/jira/browse/NETBEANS-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-4198: -- Summary: Bad text rendering for Test results on macOS, and with HiDPI scaling on Windows (was: Bad text rendering for Test results on macOS, and with HiDPI scaling) > Bad text rendering for Test results on macOS, and with HiDPI scaling on > Windows > --- > > Key: NETBEANS-4198 > URL: https://issues.apache.org/jira/browse/NETBEANS-4198 > Project: NetBeans > Issue Type: Bug > Components: utilities - Test Runner >Affects Versions: 11.3 >Reporter: Scott Palmer >Priority: Minor > Labels: HiDPI > Attachments: bad test text.jpg > > > The message “Tests passed: XX%” is poorly rendered. It’s like the alpha > channel is blending in a binary way. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-4198) Bad text rendering for Test results on macOS, and with HiDPI scaling
[ https://issues.apache.org/jira/browse/NETBEANS-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-4198: -- Summary: Bad text rendering for Test results on macOS, and with HiDPI scaling (was: Bad text rendering for Test results on macOS) > Bad text rendering for Test results on macOS, and with HiDPI scaling > > > Key: NETBEANS-4198 > URL: https://issues.apache.org/jira/browse/NETBEANS-4198 > Project: NetBeans > Issue Type: Bug > Components: utilities - Test Runner >Affects Versions: 11.3 >Reporter: Scott Palmer >Priority: Minor > Attachments: bad test text.jpg > > > The message “Tests passed: XX%” is poorly rendered. It’s like the alpha > channel is blending in a binary way. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-4198) Bad text rendering for Test results on macOS, and with HiDPI scaling
[ https://issues.apache.org/jira/browse/NETBEANS-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-4198: -- Labels: HiDPI (was: ) > Bad text rendering for Test results on macOS, and with HiDPI scaling > > > Key: NETBEANS-4198 > URL: https://issues.apache.org/jira/browse/NETBEANS-4198 > Project: NetBeans > Issue Type: Bug > Components: utilities - Test Runner >Affects Versions: 11.3 >Reporter: Scott Palmer >Priority: Minor > Labels: HiDPI > Attachments: bad test text.jpg > > > The message “Tests passed: XX%” is poorly rendered. It’s like the alpha > channel is blending in a binary way. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-885) NPE on invalid Java source code
[
https://issues.apache.org/jira/browse/NETBEANS-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-885:
-
Labels: nbjavac (was: )
> NPE on invalid Java source code
> ---
>
> Key: NETBEANS-885
> URL: https://issues.apache.org/jira/browse/NETBEANS-885
> Project: NetBeans
> Issue Type: Bug
> Components: java - Editor
>Affects Versions: 9.0
> Environment: Linux, NetBeans 9.0 RC1 (and predecessors).
>Reporter: Peter Nabbefeld
>Assignee: Jan Lahoda
>Priority: Critical
> Labels: nbjavac
>
> I sometimes like to write some code using hints for completion like this:
> package test;
> import java.io.File;
> public class Test {
> public void test() {
> File[] files = new File[0];
> for (file : files)
> }
> }
> This results in NullPointerExceptions on editing, formatting, or even just
> re-opening the file.
> Additionally to bug resolution I'd like to know how to write tests for such
> situations, so I'd be glad if You could append a diff for the changes.
> Relevant part of stacktrace:
> java.lang.NullPointerException
> SEVERE [org.openide.util.Exceptions]
> java.lang.NullPointerException
> at
> jdk.compiler/com.sun.tools.javac.tree.Pretty.visitVarDef(Pretty.java:636)
> at
> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:950)
> at jdk.compiler/com.sun.tools.javac.tree.Pretty.printExpr(Pretty.java:194)
> at jdk.compiler/com.sun.tools.javac.tree.Pretty.printExpr(Pretty.java:209)
> at jdk.compiler/com.sun.tools.javac.tree.JCTree.toString(JCTree.java:429)
> at
> org.netbeans.modules.java.navigation.BreadCrumbsNodeImpl.createBreadcrumbs(BreadCrumbsNodeImpl.java:260)
> at
> org.netbeans.modules.java.navigation.BreadCrumbsNodeImpl$3$1.scan(BreadCrumbsNodeImpl.java:535)
> at
> org.netbeans.modules.java.navigation.BreadCrumbsNodeImpl$3$1.scan(BreadCrumbsNodeImpl.java:514)
> at
> jdk.compiler/com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:90)
> at jdk.compiler/com.sun.source.util.TreeScanner.scan(TreeScanner.java:105)
> at
> jdk.compiler/com.sun.source.util.TreeScanner.visitBlock(TreeScanner.java:248)
> at
> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1026)
> at jdk.compiler/com.sun.source.util.TreeScanner.scan(TreeScanner.java:86)
> at
> org.netbeans.modules.java.navigation.BreadCrumbsNodeImpl$3$1.scan(BreadCrumbsNodeImpl.java:539)
> at
> org.netbeans.modules.java.navigation.BreadCrumbsNodeImpl$3$1.visitMethod(BreadCrumbsNodeImpl.java:544)
> at
> org.netbeans.modules.java.navigation.BreadCrumbsNodeImpl$3$1.visitMethod(BreadCrumbsNodeImpl.java:514)
> at
> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:898)
> at
> org.netbeans.modules.java.navigation.BreadCrumbsNodeImpl$3.run(BreadCrumbsNodeImpl.java:514)
> at
> org.netbeans.modules.java.navigation.BreadCrumbsNodeImpl$3.run(BreadCrumbsNodeImpl.java:503)
> at
> org.netbeans.api.java.source.JavaSource$MultiTask.run(JavaSource.java:501)
> at
> org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
> at
> org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:130)
> at
> org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:114)
> at
> org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
> at
> org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
> at
> org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
> at
> org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
> at
> org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
> at
> org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
> at
> org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
> at
> org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:81)
> at
> org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:451)
> at
> org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:422)
> at
> org.netbeans.modules.java.navigation.BreadCrumbsNodeImpl.getChildren(BreadCrumbsNodeImpl.java:503)
> at
> org.netbeans.modules.java.navigation.BreadCrumbsScanningTask.rootAndSelection(BreadCrumbsScanningTask.java:114)
> at
> org.netbeans.modules.java.navigation.BreadCrumbsScanningTask.run(BreadCrumbsScanningTask.java:82)
> at
>
[jira] [Commented] (NETBEANS-1704) java.io.UnsupportedEncodingException: ISO-Latin-1
[
https://issues.apache.org/jira/browse/NETBEANS-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17086186#comment-17086186
]
Eirik Bakke commented on NETBEANS-1704:
---
Looks like it happens when the project contains an XML file with an incorrect
encoding specification ("ISO-Latin-1", which is not correct--probably meant
"ISO-8859-1").
org.netbeans.modules.openide.filesystems.declmime.DefaultParser.parse should
probably just catch the UnsupportedEncodingException and mark it as an
erroneous file, like for other errors.
> java.io.UnsupportedEncodingException: ISO-Latin-1
> -
>
> Key: NETBEANS-1704
> URL: https://issues.apache.org/jira/browse/NETBEANS-1704
> Project: NetBeans
> Issue Type: Bug
>Affects Versions: 9.0
>Reporter: Alex Tomb
>Priority: Critical
> Attachments: nb_bug.txt.zip
>
>
> Just open the project
> Can not attach the file
> "JIRA could not attach the file as there was a missing token. Please try
> attaching the file again."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-3858) java.util.NoSuchElementException
[ https://issues.apache.org/jira/browse/NETBEANS-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3858: -- Labels: nbjavac (was: ) > java.util.NoSuchElementException > > > Key: NETBEANS-3858 > URL: https://issues.apache.org/jira/browse/NETBEANS-3858 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.2 > Environment: W10, JDK 8 >Reporter: jose luis romero >Priority: Critical > Labels: nbjavac > > This exception invalidate completely the IDE, it happens all the time for > many reasons: renaming methods, creating overloads, removing files. Even > after restarting the IDE, it seems that it keeps trying to reach some > "references". > I know that it is a problem related to *nb-javac*, but it is extremely > annoying! I had been told in SEP/19 that would be fixed soon (N) > java.util.NoSuchElementException > at > java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:721) > at > java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:742) > at > org.netbeans.modules.java.source.parsing.ParameterNameProviderImpl.capCache(ParameterNameProviderImpl.java:196) > at > org.netbeans.modules.java.source.parsing.ParameterNameProviderImpl.getParameterName(ParameterNameProviderImpl.java:181) > at > org.netbeans.modules.java.source.parsing.ParameterNameProviderImpl$1.invoke(ParameterNameProviderImpl.java:90) > at com.sun.proxy.$Proxy56.getParameterName(Unknown Source) > at > com.sun.tools.javac.code.MissingInfoHandler.getParameterName(MissingInfoHandler.java:63) > at > com.sun.tools.javac.code.Symbol$ParamSymbol.getSimpleName(Symbol.java:1746) > at > com.sun.tools.javac.code.Symbol$ParamSymbol.getSimpleName(Symbol.java:1731) > at > org.netbeans.modules.java.navigation.ElementScanningTask.createHtmlHeader(ElementScanningTask.java:497) > at > org.netbeans.modules.java.navigation.ElementScanningTask.element2description(ElementScanningTask.java:359) > at > org.netbeans.modules.java.navigation.ElementScanningTask.addMembers(ElementScanningTask.java:309) > at > org.netbeans.modules.java.navigation.ElementScanningTask.runImpl(ElementScanningTask.java:157) > at > org.netbeans.modules.java.navigation.ElementScanningTask.run(ElementScanningTask.java:96) > at > org.netbeans.modules.java.navigation.ElementScanningTask.run(ElementScanningTask.java:77) > [catch] at > org.netbeans.modules.java.source.JavaSourceAccessor$CancelableTaskWrapper.run(JavaSourceAccessor.java:273) > at > org.netbeans.modules.parsing.impl.TaskProcessor.callParserResultTask(TaskProcessor.java:561) > at > org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.run(TaskProcessor.java:786) > at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279) > at > org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.execute(TaskProcessor.java:702) > at > org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:663) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418) > at > org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45) > at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278) > at > org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-4180) Assertion error in javac when processing errors in anonymous class
Eirik Bakke created NETBEANS-4180:
-
Summary: Assertion error in javac when processing errors in
anonymous class
Key: NETBEANS-4180
URL: https://issues.apache.org/jira/browse/NETBEANS-4180
Project: NetBeans
Issue Type: Bug
Components: java - Source
Affects Versions: 11.3
Environment: NetBeans 11.3 with nbjavac plugin installed
Reporter: Eirik Bakke
If a source file is saved with with certain errors in the syntax of an
anonymous inner class, an error dialog shows up showing an assertion error in
javac. A minimized example exhibiting this behavior is as follows:
{code:java}
public final class BugExhibitAnalyserError {
public void testMethod() {
new Thread(new Runnable() {
//public void run() {
System.out.println("Hello world");
//}
});
}
}
{code}
This example causes the IDE to throw the following exception (shown in a
user-visible dialog):
{noformat}
java.lang.AssertionError: Analyzer error when processing: new Thread(new
Runnable(){
() {
super();
}
System.out.println ((ERROR) );
});
at com.sun.tools.javac.util.Assert.error(Assert.java:162)
at com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:578)
at com.sun.tools.javac.comp.Analyzer$2.flush(Analyzer.java:549)
at com.sun.tools.javac.comp.Analyzer.flush(Analyzer.java:586)
at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1505)
at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1473)
at
com.sun.tools.javac.api.JavacTaskImpl$1.process(JavacTaskImpl.java:504)
at
com.sun.tools.javac.api.JavacTaskImpl$Filter.run(JavacTaskImpl.java:651)
at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:507)
[catch] at
org.netbeans.modules.java.source.nbjavac.indexing.MultiPassCompileWorker.compile(MultiPassCompileWorker.java:261)
at
org.netbeans.modules.java.source.indexing.JavaCustomIndexer.index(JavaCustomIndexer.java:361)
at
org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$2.run(Indexable.java:138)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runIndexer(RepositoryUpdater.java:275)
at
org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor.index(Indexable.java:136)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doIndex(RepositoryUpdater.java:2750)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.access$800(RepositoryUpdater.java:2154)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2636)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2634)
at
org.netbeans.modules.parsing.impl.indexing.errors.TaskCache.refreshTransaction(TaskCache.java:540)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.index(RepositoryUpdater.java:2634)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$3.call(RepositoryUpdater.java:3300)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$3.call(RepositoryUpdater.java:3255)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$4.run(RepositoryUpdater.java:2127)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runInContext(RepositoryUpdater.java:2123)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runInContext(RepositoryUpdater.java:2104)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.access$1500(RepositoryUpdater.java:136)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.scanFiles(RepositoryUpdater.java:3255)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$FileListWork.getDone(RepositoryUpdater.java:3785)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3420)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6183)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$4300(RepositoryUpdater.java:5834)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2$1.run(RepositoryUpdater.java:6099)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
at
org.netbeans.modules.parsing.impl.RunWhenScanFinishedSupport.performScan(RunWhenScanFinishedSupport.java:83)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:6095)
at
[jira] [Updated] (NETBEANS-4179) Assertion error in javac when saving file with missing comma in method parameter list
[
https://issues.apache.org/jira/browse/NETBEANS-4179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-4179:
--
Description:
If, during editing, a method parameter list occurs with a missing comma (in
certain cases), an error dialog shows up showing an assertion error in javac
every time the Java source file is saved, interrupting the user. A minimized
example exhibiting this behavior is as follows:
{code:java}
public class BugErrorUncaught {
private Object testMethod(String param1 final String param2) {
return null;
}
}
{code}
This is a variation of the example in NETBEANS-4095, but filed here as a
separate bug since the two cause different exceptions at different levels
(inside javac here vs. at the semantic highlighting layer in NETBEANS-4095).
This example causes the IDE to throw the following exception:
{noformat}
java.lang.AssertionError
at com.sun.tools.javac.util.Assert.error(Assert.java:155)
at com.sun.tools.javac.util.Assert.check(Assert.java:46)
at
com.sun.tools.javac.comp.Flow$FlowAnalyzer.errorUncaught(Flow.java:918)
at
com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitClassDef(Flow.java:1008)
at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:788)
at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:422)
at
com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1456)
at
com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1446)
at com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:219)
at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1499)
at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1473)
at
com.sun.tools.javac.api.JavacTaskImpl$1.process(JavacTaskImpl.java:504)
at
com.sun.tools.javac.api.JavacTaskImpl$Filter.run(JavacTaskImpl.java:651)
at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:507)
[catch] at
org.netbeans.modules.java.source.nbjavac.indexing.MultiPassCompileWorker.compile(MultiPassCompileWorker.java:261)
at
org.netbeans.modules.java.source.indexing.JavaCustomIndexer.index(JavaCustomIndexer.java:361)
at
org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$2.run(Indexable.java:138)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runIndexer(RepositoryUpdater.java:275)
at
org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor.index(Indexable.java:136)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doIndex(RepositoryUpdater.java:2750)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.access$800(RepositoryUpdater.java:2154)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2636)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2634)
at
org.netbeans.modules.parsing.impl.indexing.errors.TaskCache.refreshTransaction(TaskCache.java:540)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.index(RepositoryUpdater.java:2634)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$3.call(RepositoryUpdater.java:3300)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$3.call(RepositoryUpdater.java:3255)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$4.run(RepositoryUpdater.java:2127)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runInContext(RepositoryUpdater.java:2123)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runInContext(RepositoryUpdater.java:2104)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.access$1500(RepositoryUpdater.java:136)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.scanFiles(RepositoryUpdater.java:3255)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$FileListWork.getDone(RepositoryUpdater.java:3785)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3420)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6183)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$4300(RepositoryUpdater.java:5834)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2$1.run(RepositoryUpdater.java:6099)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
at
[jira] [Created] (NETBEANS-4179) Assertion error in javac when saving file with missing comma in method parameter list
Eirik Bakke created NETBEANS-4179:
-
Summary: Assertion error in javac when saving file with missing
comma in method parameter list
Key: NETBEANS-4179
URL: https://issues.apache.org/jira/browse/NETBEANS-4179
Project: NetBeans
Issue Type: Bug
Components: java - Source
Affects Versions: 11.3
Environment: NetBeans 11.3 with nbjavac plugin installed
Reporter: Eirik Bakke
If, during editing, a method parameter list occurs with a missing comma (in
certainc cases), an error dialog shows up showing an assertion error in javac
every time the Java source file is saved, interrupting the user. A minimized
example exhibiting this behavior is as follows:
{code:java}
public class BugErrorUncaught {
private Object testMethod(String param1 final String param2) {
return null;
}
}
{code}
This is a variation of the example in NETBEANS-4095, but filed here as a
separate bug since the two cause different exceptions at different levels
(inside javac here vs. at the semantic highlighting layer in NETBEANS-4095).
This example causes the IDE to throw the following exception:
{noformat}
java.lang.AssertionError
at com.sun.tools.javac.util.Assert.error(Assert.java:155)
at com.sun.tools.javac.util.Assert.check(Assert.java:46)
at
com.sun.tools.javac.comp.Flow$FlowAnalyzer.errorUncaught(Flow.java:918)
at
com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitClassDef(Flow.java:1008)
at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:788)
at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:422)
at
com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1456)
at
com.sun.tools.javac.comp.Flow$FlowAnalyzer.analyzeTree(Flow.java:1446)
at com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:219)
at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1499)
at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1473)
at
com.sun.tools.javac.api.JavacTaskImpl$1.process(JavacTaskImpl.java:504)
at
com.sun.tools.javac.api.JavacTaskImpl$Filter.run(JavacTaskImpl.java:651)
at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:507)
[catch] at
org.netbeans.modules.java.source.nbjavac.indexing.MultiPassCompileWorker.compile(MultiPassCompileWorker.java:261)
at
org.netbeans.modules.java.source.indexing.JavaCustomIndexer.index(JavaCustomIndexer.java:361)
at
org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$2.run(Indexable.java:138)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runIndexer(RepositoryUpdater.java:275)
at
org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor.index(Indexable.java:136)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doIndex(RepositoryUpdater.java:2750)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.access$800(RepositoryUpdater.java:2154)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2636)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2634)
at
org.netbeans.modules.parsing.impl.indexing.errors.TaskCache.refreshTransaction(TaskCache.java:540)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.index(RepositoryUpdater.java:2634)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$3.call(RepositoryUpdater.java:3300)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$3.call(RepositoryUpdater.java:3255)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$4.run(RepositoryUpdater.java:2127)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runInContext(RepositoryUpdater.java:2123)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runInContext(RepositoryUpdater.java:2104)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.access$1500(RepositoryUpdater.java:136)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.scanFiles(RepositoryUpdater.java:3255)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$FileListWork.getDone(RepositoryUpdater.java:3785)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3420)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6183)
at
[jira] [Updated] (NETBEANS-4177) IOOBE when editing Java file with temporarily missing comma in method parameter list
[
https://issues.apache.org/jira/browse/NETBEANS-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-4177:
--
Labels: nbjavac (was: )
> IOOBE when editing Java file with temporarily missing comma in method
> parameter list
>
>
> Key: NETBEANS-4177
> URL: https://issues.apache.org/jira/browse/NETBEANS-4177
> Project: NetBeans
> Issue Type: Bug
> Components: java - Editor
>Affects Versions: 11.3
> Environment: NetBeans 11.3
>Reporter: Eirik Bakke
>Priority: Major
> Labels: nbjavac
>
> If, during editing, a comma is momentarily deleted in the parameter list of a
> method (in certain cases), an error dialog shows up showing an
> IndexOutOfBoundsException in
> SemanticHighlighterBase$DetectorVisitor.addParameterInlineHint. A minimized
> example exhibiting this behavior is as follows:
> {code:java}
> public class BugSemanticHighlighterBase {
> private Object testMethod(final String arg1 final String arg2) {
> return new String("");
> }
> }
> {code}
> This example causes the IDE to throw the following exception:
> {noformat}
> java.lang.IndexOutOfBoundsException: -1
> at com.sun.tools.javac.util.List.get(List.java:482)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.addParameterInlineHint(SemanticHighlighterBase.java:1241)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitLiteral(SemanticHighlighterBase.java:1180)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitLiteral(SemanticHighlighterBase.java:424)
> at com.sun.tools.javac.tree.JCTree$JCLiteral.accept(JCTree.java:2410)
> at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
> at
> org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1199)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:424)
> at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
> at
> org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:78)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitNewClass(SemanticHighlighterBase.java:1085)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitNewClass(SemanticHighlighterBase.java:424)
> at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1820)
> at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
> at
> org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1199)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:424)
> at com.sun.source.util.TreeScanner.visitReturn(TreeScanner.java:495)
> at com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1663)
> at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
> at
> org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1199)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:424)
> at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
> at
> org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:78)
> at com.sun.source.util.TreeScanner.visitBlock(TreeScanner.java:249)
> at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1048)
> at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
> at
> org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1199)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:424)
> at
[jira] [Updated] (NETBEANS-4177) IOOBE when editing Java file with temporarily missing comma in method parameter list
[
https://issues.apache.org/jira/browse/NETBEANS-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-4177:
--
Environment: NetBeans 11.3 with nbjavac plugin installed (was: NetBeans
11.3)
> IOOBE when editing Java file with temporarily missing comma in method
> parameter list
>
>
> Key: NETBEANS-4177
> URL: https://issues.apache.org/jira/browse/NETBEANS-4177
> Project: NetBeans
> Issue Type: Bug
> Components: java - Editor
>Affects Versions: 11.3
> Environment: NetBeans 11.3 with nbjavac plugin installed
>Reporter: Eirik Bakke
>Priority: Major
> Labels: nbjavac
>
> If, during editing, a comma is momentarily deleted in the parameter list of a
> method (in certain cases), an error dialog shows up showing an
> IndexOutOfBoundsException in
> SemanticHighlighterBase$DetectorVisitor.addParameterInlineHint. A minimized
> example exhibiting this behavior is as follows:
> {code:java}
> public class BugSemanticHighlighterBase {
> private Object testMethod(final String arg1 final String arg2) {
> return new String("");
> }
> }
> {code}
> This example causes the IDE to throw the following exception:
> {noformat}
> java.lang.IndexOutOfBoundsException: -1
> at com.sun.tools.javac.util.List.get(List.java:482)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.addParameterInlineHint(SemanticHighlighterBase.java:1241)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitLiteral(SemanticHighlighterBase.java:1180)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitLiteral(SemanticHighlighterBase.java:424)
> at com.sun.tools.javac.tree.JCTree$JCLiteral.accept(JCTree.java:2410)
> at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
> at
> org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1199)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:424)
> at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
> at
> org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:78)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitNewClass(SemanticHighlighterBase.java:1085)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitNewClass(SemanticHighlighterBase.java:424)
> at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1820)
> at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
> at
> org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1199)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:424)
> at com.sun.source.util.TreeScanner.visitReturn(TreeScanner.java:495)
> at com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1663)
> at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
> at
> org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1199)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:424)
> at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
> at
> org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:78)
> at com.sun.source.util.TreeScanner.visitBlock(TreeScanner.java:249)
> at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1048)
> at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
> at
> org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
> at
> org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1199)
> at
>
[jira] [Updated] (NETBEANS-4095) NPE saving Java file with type error in for-each
[
https://issues.apache.org/jira/browse/NETBEANS-4095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-4095:
--
Labels: nbjavac (was: )
> NPE saving Java file with type error in for-each
>
>
> Key: NETBEANS-4095
> URL: https://issues.apache.org/jira/browse/NETBEANS-4095
> Project: NetBeans
> Issue Type: Bug
> Components: java - Source
>Affects Versions: 11.3
> Environment: Java 14, NetBeans with nbjavac plugin installed
>Reporter: Eirik Bakke
>Priority: Major
> Labels: nbjavac
>
> If, during editing, a for-each loop appears with an incorrect pair of types,
> an error dialog shows up showing a NullPointerException every time the Java
> source file is saved, interrupting the user. A minimized example exhibiting
> this behavior is as follows:
> {code:java}
> public final class CausesVisitIterableForeachLoopNPE {
> public static final void main(String args[]) {
> final Map someMap = null;
> for (Object someVar : someMap) { }
> }
> }
> {code}
> This example causes the IDE to throw the following exception:
> {noformat}
> java.lang.NullPointerException
> at
> com.sun.tools.javac.comp.Lower.visitIterableForeachLoop(Lower.java:3275)
> at com.sun.tools.javac.comp.Lower.visitForeachLoop(Lower.java:3162)
> at
> com.sun.tools.javac.tree.JCTree$JCEnhancedForLoop.accept(JCTree.java:1176)
> at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
> at com.sun.tools.javac.comp.Lower.translate(Lower.java:2080)
> at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70)
> at
> com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:167)
> at com.sun.tools.javac.comp.Lower.visitBlock(Lower.java:3347)
> at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1036)
> at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
> at com.sun.tools.javac.comp.Lower.translate(Lower.java:2080)
> at
> com.sun.tools.javac.tree.TreeTranslator.visitMethodDef(TreeTranslator.java:150)
> at
> com.sun.tools.javac.comp.Lower.visitMethodDefInternal(Lower.java:2538)
> at com.sun.tools.javac.comp.Lower.visitMethodDef(Lower.java:2448)
> at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:882)
> at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
> at com.sun.tools.javac.comp.Lower.translate(Lower.java:2080)
> at com.sun.tools.javac.comp.Lower.visitClassDef(Lower.java:2219)
> at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:788)
> at
> com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
> at com.sun.tools.javac.comp.Lower.translate(Lower.java:2080)
> at com.sun.tools.javac.comp.Lower.translate(Lower.java:2099)
> at
> com.sun.tools.javac.comp.Lower.translateTopLevelClass(Lower.java:3813)
> at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1691)
> at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1532)
> at
> com.sun.tools.javac.api.JavacTaskImpl$2.process(JavacTaskImpl.java:574)
> at
> com.sun.tools.javac.api.JavacTaskImpl$Filter.run(JavacTaskImpl.java:651)
> at
> com.sun.tools.javac.api.JavacTaskImpl.generate(JavacTaskImpl.java:577)
> [catch] at
> org.netbeans.modules.java.source.nbjavac.indexing.MultiPassCompileWorker.compile(MultiPassCompileWorker.java:303)
> at
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer.index(JavaCustomIndexer.java:361)
> at
> org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$2.run(Indexable.java:138)
> at
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runIndexer(RepositoryUpdater.java:275)
> at
> org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor.index(Indexable.java:136)
> at
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doIndex(RepositoryUpdater.java:2750)
> at
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.access$800(RepositoryUpdater.java:2154)
> at
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2636)
> at
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2634)
> at
> org.netbeans.modules.parsing.impl.indexing.errors.TaskCache.refreshTransaction(TaskCache.java:540)
> at
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.index(RepositoryUpdater.java:2634)
> at
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$3.call(RepositoryUpdater.java:3300)
> at
>
[jira] [Created] (NETBEANS-4177) IOOBE when editing Java file with temporarily missing comma in method parameter list
Eirik Bakke created NETBEANS-4177:
-
Summary: IOOBE when editing Java file with temporarily missing
comma in method parameter list
Key: NETBEANS-4177
URL: https://issues.apache.org/jira/browse/NETBEANS-4177
Project: NetBeans
Issue Type: Bug
Components: java - Editor
Affects Versions: 11.3
Environment: NetBeans 11.3
Reporter: Eirik Bakke
If, during editing, a comma is momentarily deleted in the parameter list of a
method (in certain cases), an error dialog shows up showing an
IndexOutOfBoundsException in
SemanticHighlighterBase$DetectorVisitor.addParameterInlineHint. A minimized
example exhibiting this behavior is as follows:
{code:java}
public class BugSemanticHighlighterBase {
private Object testMethod(final String arg1 final String arg2) {
return new String("");
}
}
{code}
This example causes the IDE to throw the following exception:
{noformat}
java.lang.IndexOutOfBoundsException: -1
at com.sun.tools.javac.util.List.get(List.java:482)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.addParameterInlineHint(SemanticHighlighterBase.java:1241)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitLiteral(SemanticHighlighterBase.java:1180)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitLiteral(SemanticHighlighterBase.java:424)
at com.sun.tools.javac.tree.JCTree$JCLiteral.accept(JCTree.java:2410)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1199)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:424)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:78)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitNewClass(SemanticHighlighterBase.java:1085)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitNewClass(SemanticHighlighterBase.java:424)
at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1820)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1199)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:424)
at com.sun.source.util.TreeScanner.visitReturn(TreeScanner.java:495)
at com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1663)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1199)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:424)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:78)
at com.sun.source.util.TreeScanner.visitBlock(TreeScanner.java:249)
at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1048)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1199)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:424)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:91)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:78)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitClass(SemanticHighlighterBase.java:1124)
[jira] [Updated] (NETBEANS-4166) Review likely inaccurate int-based character width calculations in editor UI
[ https://issues.apache.org/jira/browse/NETBEANS-4166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-4166: -- Labels: HiDPI (was: ) > Review likely inaccurate int-based character width calculations in editor UI > > > Key: NETBEANS-4166 > URL: https://issues.apache.org/jira/browse/NETBEANS-4166 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting Printing >Affects Versions: 11.3 > Environment: Windows and MacOS with HiDPI/retina displays, Java 9 and > above >Reporter: Eirik Bakke >Priority: Minor > Labels: HiDPI > > While fixing NETBEANS-346, I discovered several other editor painting > coordinate calculations which are likely inaccurate due to rounding errors. > Fixing these will be a bit of work, though, and it may be preferable to wait > until specific bugs are identified before doing so, so that the changes can > be verified to have had the desired effect. > The following members should likely be changed from an int to a float, and > initialized from font metrics to full precision: > * org.netbeans.editor.EditorUI.defaultSpaceWidth > * org.netbeans.modules.editor.lib.drawing.DrawEngine.spaceWidth, > defaultSpaceWidth, and possibly fragmentWidth > * org.netbeans.modules.editor.lib.drawing.DrawGraphics.defaultSpaceWidth > These changes will propagate to related APIs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-4166) Review likely inaccurate int-based character width calculations in editor UI
[ https://issues.apache.org/jira/browse/NETBEANS-4166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-4166: -- Description: While fixing NETBEANS-346, I discovered several other editor painting coordinate calculations which are likely inaccurate due to rounding errors. Fixing these will be a bit of work, though, and it may be preferable to wait until specific bugs are identified before doing so, so that the changes can be verified to have had the desired effect. The following members should likely be changed from an int to a float, and initialized from font metrics to full precision: * org.netbeans.editor.EditorUI.defaultSpaceWidth * org.netbeans.modules.editor.lib.drawing.DrawEngine.spaceWidth, defaultSpaceWidth, and possibly fragmentWidth * org.netbeans.modules.editor.lib.drawing.DrawGraphics.defaultSpaceWidth Changing these from int to float will require various other methods and members to be updated as well. was: While fixing NETBEANS-346, I discovered several other editor painting coordinate calculations which are likely inaccurate due to rounding errors. Fixing these will be a bit of work, though, and it may be preferable to wait until specific bugs are identified before doing so, so that the changes can be verified to have had the desired effect. The following members should likely be changed from an int to a float, and initialized from font metrics to full precision: * org.netbeans.editor.EditorUI.defaultSpaceWidth * org.netbeans.modules.editor.lib.drawing.DrawEngine.spaceWidth, defaultSpaceWidth, and possibly fragmentWidth * org.netbeans.modules.editor.lib.drawing.DrawGraphics.defaultSpaceWidth These changes will propagate to related APIs. > Review likely inaccurate int-based character width calculations in editor UI > > > Key: NETBEANS-4166 > URL: https://issues.apache.org/jira/browse/NETBEANS-4166 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting Printing >Affects Versions: 11.3 > Environment: Windows and MacOS with HiDPI/retina displays, Java 9 and > above >Reporter: Eirik Bakke >Priority: Minor > Labels: HiDPI > > While fixing NETBEANS-346, I discovered several other editor painting > coordinate calculations which are likely inaccurate due to rounding errors. > Fixing these will be a bit of work, though, and it may be preferable to wait > until specific bugs are identified before doing so, so that the changes can > be verified to have had the desired effect. > The following members should likely be changed from an int to a float, and > initialized from font metrics to full precision: > * org.netbeans.editor.EditorUI.defaultSpaceWidth > * org.netbeans.modules.editor.lib.drawing.DrawEngine.spaceWidth, > defaultSpaceWidth, and possibly fragmentWidth > * org.netbeans.modules.editor.lib.drawing.DrawGraphics.defaultSpaceWidth > Changing these from int to float will require various other methods and > members to be updated as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-4166) Review likely inaccurate int-based character width calculations in editor UI
Eirik Bakke created NETBEANS-4166: - Summary: Review likely inaccurate int-based character width calculations in editor UI Key: NETBEANS-4166 URL: https://issues.apache.org/jira/browse/NETBEANS-4166 Project: NetBeans Issue Type: Bug Components: editor - Painting Printing Affects Versions: 11.3 Environment: Windows and MacOS with HiDPI/retina displays, Java 9 and above Reporter: Eirik Bakke While fixing NETBEANS-346, I discovered several other editor painting coordinate calculations which are likely inaccurate due to rounding errors. Fixing these will be a bit of work, though, and it may be preferable to wait until specific bugs are identified before doing so, so that the changes can be verified to have had the desired effect. The following members should likely be changed from an int to a float, and initialized from font metrics to full precision: * org.netbeans.editor.EditorUI.defaultSpaceWidth * org.netbeans.modules.editor.lib.drawing.DrawEngine.spaceWidth, defaultSpaceWidth, and possibly fragmentWidth * org.netbeans.modules.editor.lib.drawing.DrawGraphics.defaultSpaceWidth These changes will propagate to related APIs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-4095) NPE saving Java file with type error in for-each
Eirik Bakke created NETBEANS-4095:
-
Summary: NPE saving Java file with type error in for-each
Key: NETBEANS-4095
URL: https://issues.apache.org/jira/browse/NETBEANS-4095
Project: NetBeans
Issue Type: Bug
Components: java - Source
Affects Versions: 11.3
Environment: Java 14, NetBeans with nbjavac plugin installed
Reporter: Eirik Bakke
If, during editing, a for-each loop appears with an incorrect pair of types, an
error dialog shows up showing a NullPointerException every time the Java source
file is saved, interrupting the user. A minimized example exhibiting this
behavior is as follows:
{code:java}
public final class CausesVisitIterableForeachLoopNPE {
public static final void main(String args[]) {
final Map someMap = null;
for (Object someVar : someMap) { }
}
}
{code}
This example causes the IDE to throw the following exception:
{noformat}
java.lang.NullPointerException
at
com.sun.tools.javac.comp.Lower.visitIterableForeachLoop(Lower.java:3275)
at com.sun.tools.javac.comp.Lower.visitForeachLoop(Lower.java:3162)
at
com.sun.tools.javac.tree.JCTree$JCEnhancedForLoop.accept(JCTree.java:1176)
at
com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
at com.sun.tools.javac.comp.Lower.translate(Lower.java:2080)
at
com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70)
at
com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:167)
at com.sun.tools.javac.comp.Lower.visitBlock(Lower.java:3347)
at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1036)
at
com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
at com.sun.tools.javac.comp.Lower.translate(Lower.java:2080)
at
com.sun.tools.javac.tree.TreeTranslator.visitMethodDef(TreeTranslator.java:150)
at
com.sun.tools.javac.comp.Lower.visitMethodDefInternal(Lower.java:2538)
at com.sun.tools.javac.comp.Lower.visitMethodDef(Lower.java:2448)
at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:882)
at
com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
at com.sun.tools.javac.comp.Lower.translate(Lower.java:2080)
at com.sun.tools.javac.comp.Lower.visitClassDef(Lower.java:2219)
at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:788)
at
com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58)
at com.sun.tools.javac.comp.Lower.translate(Lower.java:2080)
at com.sun.tools.javac.comp.Lower.translate(Lower.java:2099)
at
com.sun.tools.javac.comp.Lower.translateTopLevelClass(Lower.java:3813)
at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1691)
at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1532)
at
com.sun.tools.javac.api.JavacTaskImpl$2.process(JavacTaskImpl.java:574)
at
com.sun.tools.javac.api.JavacTaskImpl$Filter.run(JavacTaskImpl.java:651)
at
com.sun.tools.javac.api.JavacTaskImpl.generate(JavacTaskImpl.java:577)
[catch] at
org.netbeans.modules.java.source.nbjavac.indexing.MultiPassCompileWorker.compile(MultiPassCompileWorker.java:303)
at
org.netbeans.modules.java.source.indexing.JavaCustomIndexer.index(JavaCustomIndexer.java:361)
at
org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$2.run(Indexable.java:138)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runIndexer(RepositoryUpdater.java:275)
at
org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor.index(Indexable.java:136)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doIndex(RepositoryUpdater.java:2750)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.access$800(RepositoryUpdater.java:2154)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2636)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$1.run(RepositoryUpdater.java:2634)
at
org.netbeans.modules.parsing.impl.indexing.errors.TaskCache.refreshTransaction(TaskCache.java:540)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.index(RepositoryUpdater.java:2634)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$3.call(RepositoryUpdater.java:3300)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$3.call(RepositoryUpdater.java:3255)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$4.run(RepositoryUpdater.java:2127)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
at
[jira] [Commented] (NETBEANS-3699) Netbeans not properly working in multiple HiDpi screens
[ https://issues.apache.org/jira/browse/NETBEANS-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066263#comment-17066263 ] Eirik Bakke commented on NETBEANS-3699: --- Inaccurate text measurement in tab titles is now tracked separately in NETBEANS-4066. > Netbeans not properly working in multiple HiDpi screens > --- > > Key: NETBEANS-3699 > URL: https://issues.apache.org/jira/browse/NETBEANS-3699 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Affects Versions: 11.2 > Environment: Product Version: Apache NetBeans IDE 11.2 > Java: 11.0.2; OpenJDK 64-Bit Server VM 11.0.2+9 > Runtime: OpenJDK Runtime Environment 11.0.2+9 > System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb) >Reporter: Sammy >Priority: Major > Labels: HiDPI > Fix For: 11.3 > > Attachments: image-2020-01-15-13-40-19-726.png, > image-2020-01-15-13-40-50-746.png, image-2020-01-15-13-43-39-587.png > > > !image-2020-01-15-13-40-19-726.png! > Netbeans doesn't seem to handle per-monitor dpi scaling properly. You can see > the icon pixelated and the tab bar text is cut off. I'm running 3 monitors, > the main one on 125%, the other on 100% scaling. When I drag Netbeans to > Monitor 3 at 100% scaling it looks correct. But main one is wrong. > !image-2020-01-15-13-40-50-746.png! > > > I have this setting enabled to ensure scaling is done based on main monitor: > > !image-2020-01-15-13-43-39-587.png! > this doesn't make a difference. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-4066) Inaccurate text measurement in editor tabs on HiDPI displays on Windows
[ https://issues.apache.org/jira/browse/NETBEANS-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-4066: -- Description: Having fixed NETBEANS-2543, I see there is a similar issue in the NetBeans tab component, e.g. in the editor tabs. On Windows 10, with HiDPI scaling enabled on either 150% or 200% (for example), a tab title "AaaiA" will overshoot its allocated space. See the attached screenshot. Presumably this is another case where text measurement is done on a FontRenderContext that hasn't properly had the appropriate monitor's HiDPI scaling applied. was: Having fixed NETBEANS-2543, I see there is a similar issue in the NetBeans tab component, e.g. in the editor tabs. On Windows 10, with HiDPI scaling enabled on either 150% or 200% (for example), a tab title "AaaiA" will overshoot its allocated space. Presumably this is another case where text measurement is done on a FontRenderContext that hasn't properly had the appropriate monitor's HiDPI scaling applied. > Inaccurate text measurement in editor tabs on HiDPI displays on Windows > --- > > Key: NETBEANS-4066 > URL: https://issues.apache.org/jira/browse/NETBEANS-4066 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Affects Versions: 11.3 > Environment: Windows 10 with HiDPI scaling enabled (e.g. 150% or > 200%--not necessarily fractional scalings only) >Reporter: Eirik Bakke >Priority: Minor > Labels: HiDPI > Attachments: Inaccurate tab text mesaurement.png > > > Having fixed NETBEANS-2543, I see there is a similar issue in the NetBeans > tab component, e.g. in the editor tabs. On Windows 10, with HiDPI scaling > enabled on either 150% or 200% (for example), a tab title > "AaaiA" will overshoot its > allocated space. See the attached screenshot. > Presumably this is another case where text measurement is done on a > FontRenderContext that hasn't properly had the appropriate monitor's HiDPI > scaling applied. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-4066) Inaccurate text measurement in editor tabs on HiDPI displays on Windows
Eirik Bakke created NETBEANS-4066: - Summary: Inaccurate text measurement in editor tabs on HiDPI displays on Windows Key: NETBEANS-4066 URL: https://issues.apache.org/jira/browse/NETBEANS-4066 Project: NetBeans Issue Type: Improvement Components: platform - Other Affects Versions: 11.3 Environment: Windows 10 with HiDPI scaling enabled (e.g. 150% or 200%--not necessarily fractional scalings only) Reporter: Eirik Bakke Attachments: Inaccurate tab text mesaurement.png Having fixed NETBEANS-2543, I see there is a similar issue in the NetBeans tab component, e.g. in the editor tabs. On Windows 10, with HiDPI scaling enabled on either 150% or 200% (for example), a tab title "AaaiA" will overshoot its allocated space. Presumably this is another case where text measurement is done on a FontRenderContext that hasn't properly had the appropriate monitor's HiDPI scaling applied. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3469) Cache PNG versions of loaded SVG icons
[ https://issues.apache.org/jira/browse/NETBEANS-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17062110#comment-17062110 ] Eirik Bakke commented on NETBEANS-3469: --- It's actually useful to implement this to solve NETBEANS-3468 (see comment there). For the PNG files in the cache, be sure to use the same naming convention as is expected by Toolkit.getImage() on MacOS. See also the discussion in NETBEANS-1583 about these naming conventions. > Cache PNG versions of loaded SVG icons > -- > > Key: NETBEANS-3469 > URL: https://issues.apache.org/jira/browse/NETBEANS-3469 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Affects Versions: 11.3 >Reporter: Eirik Bakke >Priority: Minor > Labels: HiDPI > > Support for SVG file loading via ImageUtilities was added in NETBEANS-2604. > Once a substantial number of icons have been migrated to SVG versions ( > NETBEANS-2617 ), we should consider doing some performance work to ensure > that icons can be loaded as quickly as before in the common case. See the > benchmark and discussion in https://github.com/apache/netbeans/pull/1278 . > timboudreau had the idea of caching rasterized versions of the SVG icons in > the cache directory the first time they are loaded (and painted at a specific > HiDPI scaling factor). I'd guess that this could speed up SVG file loading by > about 4x. If all icons are cached, it would also save the overhead of loading > the ~3MB Batik library JARs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Comment Edited] (NETBEANS-3468) Make HiDPI (Retina) icons work in MacOS menu bar
[ https://issues.apache.org/jira/browse/NETBEANS-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17062106#comment-17062106 ] Eirik Bakke edited comment on NETBEANS-3468 at 3/18/20, 10:51 PM: -- >From mailing list discussions, it seems that NetBeans will continue to be >built on Java 8 for the forseeable future. The java.lang.reflect.Proxy >interface could be used to implement MultiResolutionImage by reflection, but >it does not seem possible to simultaneously have the proxy object extend from >Image (or BufferedImage), which is required here. A better approach, for backwards-compatibility with Java 8, is to implement NETBEANS-3469, having ImageUtilities write out pre-rendered PNG files at 1x and 2x resolution into the NetBeans cache directory, following the prescribed MacOS naming convention (e.g. "icon.png" and "i...@2x.png"), and then using Toolkit.getImage(URL) to produce the actual Image object (on MacOS only). This will produce retina-capable images on both Java 8 and Java 9 and above. (Note that MacOS uses only 1x and 2x scaling, unlike Windows, where arbitrary HiDPI scalings can occur.) was (Author: ebakke): >From mailing list discussions, it seems that NetBeans will continue to be >built on Java 8 for the forseeable future. The java.lang.reflect.Proxy >interface could be used to implement MultiResolutionImage by reflection, but >it does not seem possible to simultaneously have the Proxy object extend from >Image (or BufferedImage), which is required here. A better approach, for backwards-compatibility with Java 8, is to implement NETBEANS-3469, having ImageUtilities write out pre-rendered PNG files at 1x and 2x resolution into the NetBeans cache directory, following the prescribed MacOS naming convention (e.g. "icon.png" and "i...@2x.png"), and then using Toolkit.getImage(URL) to produce the actual Image object (on MacOS only). This will produce retina-capable images on both Java 8 and Java 9 and above. (Note that MacOS uses only 1x and 2x scaling, unlike Windows, where arbitrary HiDPI scalings can occur.) > Make HiDPI (Retina) icons work in MacOS menu bar > > > Key: NETBEANS-3468 > URL: https://issues.apache.org/jira/browse/NETBEANS-3468 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Affects Versions: 11.3 > Environment: MacOS with retina display >Reporter: Eirik Bakke >Priority: Minor > Labels: HiDPI > Attachments: menuicon_retina.png > > > HiDPI icons, introduced in NETBEANS-2614 and NETBEANS-2604, do not yet show > up in the correct resolution when used in the menu bar on MacOS. See the > attached screenshot (from a NetBeans Platform application). This should be > fixed. > Note that we have only so far introduced HiDPI icons for the "Undo" and > "Redo" actions. > Emilian Bold probably figured this out in his earlier experimental Retina > support branch; see RetinaMultiResolutionImage in > https://github.com/emilianbold/nextbeans/commit/0f99dba0c1b3e8e0bc4e7cec407b53d30e85ead1 > . If the solution involves implementing MultiResolutionImage, then make sure > not to do this on Windows (to avoid > https://bugs.openjdk.java.net/browse/JDK-8212226 ). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3468) Make HiDPI (Retina) icons work in MacOS menu bar
[ https://issues.apache.org/jira/browse/NETBEANS-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17062106#comment-17062106 ] Eirik Bakke commented on NETBEANS-3468: --- >From mailing list discussions, it seems that NetBeans will continue to be >built on Java 8 for the forseeable future. The java.lang.reflect.Proxy >interface could be used to implement MultiResolutionImage by reflection, but >it does not seem possible to simultaneously have the Proxy object extend from >Image (or BufferedImage), which is required here. A better approach, for backwards-compatibility with Java 8, is to implement NETBEANS-3469, having ImageUtilities write out pre-rendered PNG files at 1x and 2x resolution into the NetBeans cache directory, following the prescribed MacOS naming convention (e.g. "icon.png" and "i...@2x.png"), and then using Toolkit.getImage(URL) to produce the actual Image object (on MacOS only). This will produce retina-capable images on both Java 8 and Java 9 and above. (Note that MacOS uses only 1x and 2x scaling, unlike Windows, where arbitrary HiDPI scalings can occur.) > Make HiDPI (Retina) icons work in MacOS menu bar > > > Key: NETBEANS-3468 > URL: https://issues.apache.org/jira/browse/NETBEANS-3468 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Affects Versions: 11.3 > Environment: MacOS with retina display >Reporter: Eirik Bakke >Priority: Minor > Labels: HiDPI > Attachments: menuicon_retina.png > > > HiDPI icons, introduced in NETBEANS-2614 and NETBEANS-2604, do not yet show > up in the correct resolution when used in the menu bar on MacOS. See the > attached screenshot (from a NetBeans Platform application). This should be > fixed. > Note that we have only so far introduced HiDPI icons for the "Undo" and > "Redo" actions. > Emilian Bold probably figured this out in his earlier experimental Retina > support branch; see RetinaMultiResolutionImage in > https://github.com/emilianbold/nextbeans/commit/0f99dba0c1b3e8e0bc4e7cec407b53d30e85ead1 > . If the solution involves implementing MultiResolutionImage, then make sure > not to do this on Windows (to avoid > https://bugs.openjdk.java.net/browse/JDK-8212226 ). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-3469) Cache PNG versions of loaded SVG icons
[ https://issues.apache.org/jira/browse/NETBEANS-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3469: -- Labels: HiDPI (was: ) > Cache PNG versions of loaded SVG icons > -- > > Key: NETBEANS-3469 > URL: https://issues.apache.org/jira/browse/NETBEANS-3469 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Affects Versions: 11.3 >Reporter: Eirik Bakke >Priority: Minor > Labels: HiDPI > > Support for SVG file loading via ImageUtilities was added in NETBEANS-2604. > Once a substantial number of icons have been migrated to SVG versions ( > NETBEANS-2617 ), we should consider doing some performance work to ensure > that icons can be loaded as quickly as before in the common case. See the > benchmark and discussion in https://github.com/apache/netbeans/pull/1278 . > timboudreau had the idea of caching rasterized versions of the SVG icons in > the cache directory the first time they are loaded (and painted at a specific > HiDPI scaling factor). I'd guess that this could speed up SVG file loading by > about 4x. If all icons are cached, it would also save the overhead of loading > the ~3MB Batik library JARs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3727) Probably a darker color of the desktop background would be good for FlatLaf
[ https://issues.apache.org/jira/browse/NETBEANS-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17061274#comment-17061274 ] Eirik Bakke commented on NETBEANS-3727: --- Looks good to me, too! > Probably a darker color of the desktop background would be good for FlatLaf > --- > > Key: NETBEANS-3727 > URL: https://issues.apache.org/jira/browse/NETBEANS-3727 > Project: NetBeans > Issue Type: Improvement >Reporter: Laszlo Kishalmi >Assignee: Karl Tauber >Priority: Minor > Labels: pull-request-available > Fix For: 11.3 > > Attachments: image-2020-01-21-16-30-56-282.png, > image-2020-01-23-11-58-16-141.png, image-2020-02-04-19-25-05-570.png, > image-2020-02-04-19-27-10-325.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Well, I'm not entirely convinced that this is an issue at all. > Those rare times when we do not have an editor window open, the IDE might > look strange not having upper/left/right border on the opened tabs. I'd not > put border there, but probably mark the desktop color different (like the > editor default background on FlatLafDark). > [~ebakke] [~DevCharly] what do you think. Of course you are free to drop this > one. > !image-2020-01-21-16-30-56-282.png! > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-2543) File names clipped in Files and Projects tabs
[ https://issues.apache.org/jira/browse/NETBEANS-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17061137#comment-17061137 ] Eirik Bakke commented on NETBEANS-2543: --- Geo B: Thank you! OK, good, so your IDE was indeed running on a recent Java version. The patch should fix the bug in the next NetBeans version. (And I don't think the bug actually appears on Java 8 either, since that one doesn't support HiDPI scaling on Windows.) > File names clipped in Files and Projects tabs > - > > Key: NETBEANS-2543 > URL: https://issues.apache.org/jira/browse/NETBEANS-2543 > Project: NetBeans > Issue Type: Bug > Components: platform - Other, projects - Generic Projects UI >Affects Versions: 9.0, 10.0, 11.0 > Environment: Windows Pro 10 1809, HP 500-210qe >Reporter: Geo B >Priority: Major > Labels: HiDPI, pull-request-available > Attachments: netbeans_display.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > File name extensions appear clipped in Files window. For example, files with > extension `.yaml` may appear as .yaml, .yam or .yar. See attached screen grab. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-2543) File names clipped in Files and Projects tabs
[ https://issues.apache.org/jira/browse/NETBEANS-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17061034#comment-17061034 ] Eirik Bakke commented on NETBEANS-2543: --- I created a patch. By the way, Geo B, can you check which Java version your IDE is running, by going to Help->About? The version returned by "java -version" on the command line is not necessarily the same. The upcoming fix might only work when the IDE is running Java 9 or above. > File names clipped in Files and Projects tabs > - > > Key: NETBEANS-2543 > URL: https://issues.apache.org/jira/browse/NETBEANS-2543 > Project: NetBeans > Issue Type: Bug > Components: platform - Other, projects - Generic Projects UI >Affects Versions: 9.0, 10.0, 11.0 > Environment: Windows Pro 10 1809, HP 500-210qe >Reporter: Geo B >Priority: Major > Labels: HiDPI, pull-request-available > Attachments: netbeans_display.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > File name extensions appear clipped in Files window. For example, files with > extension `.yaml` may appear as .yaml, .yam or .yar. See attached screen grab. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-2543) File names clipped in Files and Projects tabs
[ https://issues.apache.org/jira/browse/NETBEANS-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060703#comment-17060703 ] Eirik Bakke commented on NETBEANS-2543: --- To reliably reproduce, use 150% HiDPI scaling and make a file called "AaaiAbc12345678910". It will show up as "AaaiAbc123456", dropping multiple characters. Patch forthcoming... > File names clipped in Files and Projects tabs > - > > Key: NETBEANS-2543 > URL: https://issues.apache.org/jira/browse/NETBEANS-2543 > Project: NetBeans > Issue Type: Bug > Components: platform - Other, projects - Generic Projects UI >Affects Versions: 9.0, 10.0, 11.0 > Environment: Windows Pro 10 1809, HP 500-210qe >Reporter: Geo B >Priority: Major > Labels: HiDPI > Attachments: netbeans_display.jpg > > > File name extensions appear clipped in Files window. For example, files with > extension `.yaml` may appear as .yaml, .yam or .yar. See attached screen grab. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-2543) File names clipped in Files and Projects tabs
[ https://issues.apache.org/jira/browse/NETBEANS-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060643#comment-17060643 ] Eirik Bakke commented on NETBEANS-2543: --- Testing just now, this occurs on Windows fractional HiDPI scalings (e.g. 150%), and not on integral scalings (100% or 200%). It seems to be a problem with org.openide.explorer.view.NodeRenderer/org.openide.awt.HtmlRendererImpl , which is used in the NetBeans BeanTreeView JTree instead of the standard DefaultTreeCellRenderer. The DefaultTreeCellRenderer seems not to have the same problem. > File names clipped in Files and Projects tabs > - > > Key: NETBEANS-2543 > URL: https://issues.apache.org/jira/browse/NETBEANS-2543 > Project: NetBeans > Issue Type: Bug > Components: platform - Other, projects - Generic Projects UI >Affects Versions: 9.0, 10.0, 11.0 > Environment: Windows Pro 10 1809, HP 500-210qe >Reporter: Geo B >Priority: Major > Labels: HiDPI > Attachments: netbeans_display.jpg > > > File name extensions appear clipped in Files window. For example, files with > extension `.yaml` may appear as .yaml, .yam or .yar. See attached screen grab. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2543) File names clipped in Files and Projects tabs
[ https://issues.apache.org/jira/browse/NETBEANS-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-2543: -- Summary: File names clipped in Files and Projects tabs (was: File names clipped in Files window) > File names clipped in Files and Projects tabs > - > > Key: NETBEANS-2543 > URL: https://issues.apache.org/jira/browse/NETBEANS-2543 > Project: NetBeans > Issue Type: Bug > Components: platform - Other, projects - Generic Projects UI >Affects Versions: 9.0, 10.0, 11.0 > Environment: Windows Pro 10 1809, HP 500-210qe >Reporter: Geo B >Priority: Major > Labels: HiDPI > Attachments: netbeans_display.jpg > > > File name extensions appear clipped in Files window. For example, files with > extension `.yaml` may appear as .yaml, .yam or .yar. See attached screen grab. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-2278) FolderName last character truncating
[ https://issues.apache.org/jira/browse/NETBEANS-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-2278. --- Resolution: Duplicate Now looking into this... consolidating duplicate reports. > FolderName last character truncating > > > Key: NETBEANS-2278 > URL: https://issues.apache.org/jira/browse/NETBEANS-2278 > Project: NetBeans > Issue Type: Bug >Affects Versions: 9.0, 10.0, 11.0 > Environment: windows >Reporter: Simerdeep Arora >Priority: Critical > Labels: HiDPI > Attachments: image-2019-03-19-16-57-45-526.png > > > The last character of all of my folders, with long names, is truncating. > See the screenshot. > > The issue is in version 9 and 10 and 11..I have not tested in previous > versions. > > See the folder name is abc12345678910 but 0 is truncating. > > From CosmicClasses s is truncating > > !image-2019-03-19-16-57-45-526.png! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2543) File names clipped in Files window
[ https://issues.apache.org/jira/browse/NETBEANS-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-2543: -- Priority: Major (was: Trivial) > File names clipped in Files window > -- > > Key: NETBEANS-2543 > URL: https://issues.apache.org/jira/browse/NETBEANS-2543 > Project: NetBeans > Issue Type: Bug > Components: platform - Other, projects - Generic Projects UI >Affects Versions: 9.0, 10.0, 11.0 > Environment: Windows Pro 10 1809, HP 500-210qe >Reporter: Geo B >Priority: Major > Labels: HiDPI > Attachments: netbeans_display.jpg > > > File name extensions appear clipped in Files window. For example, files with > extension `.yaml` may appear as .yaml, .yam or .yar. See attached screen grab. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2543) File names clipped in Files window
[ https://issues.apache.org/jira/browse/NETBEANS-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-2543: -- Labels: HiDPI (was: ) > File names clipped in Files window > -- > > Key: NETBEANS-2543 > URL: https://issues.apache.org/jira/browse/NETBEANS-2543 > Project: NetBeans > Issue Type: Bug > Components: platform - Other, projects - Generic Projects UI >Affects Versions: 9.0, 10.0, 11.0 > Environment: Windows Pro 10 1809, HP 500-210qe >Reporter: Geo B >Priority: Trivial > Labels: HiDPI > Attachments: netbeans_display.jpg > > > File name extensions appear clipped in Files window. For example, files with > extension `.yaml` may appear as .yaml, .yam or .yar. See attached screen grab. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-2576) Truncating names in project or files view using a small font in windows 10
[ https://issues.apache.org/jira/browse/NETBEANS-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-2576. --- Resolution: Duplicate Now looking into this... marking resolved/duplicate so we have one issue number only. > Truncating names in project or files view using a small font in windows 10 > -- > > Key: NETBEANS-2576 > URL: https://issues.apache.org/jira/browse/NETBEANS-2576 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.0 >Reporter: Martin Both >Priority: Major > Attachments: image-2019-05-21-10-52-55-341.png, > image-2019-05-21-10-55-22-505.png > > > I use a new dell laptop and windows 10 with no modifications. On the display > the last characters of the file names in the project or files view are > truncated. > So I see "Application.jav" instead of "Application.java". > If I connect an old monitor to this laptop with low resolution then windows > 10 is using a different font on this monitor. On my external monitor I see > "Application.java" now but on my laptop I still see "Application.jav". > I use Netbeans 11 with OpenJDK 11 on Windows 10. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-3748) Displayed text lines in Project & Files Windows gets truncated
[ https://issues.apache.org/jira/browse/NETBEANS-3748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-3748. --- Resolution: Duplicate Now looking into this... consolidating the JIRA reports. > Displayed text lines in Project & Files Windows gets truncated > -- > > Key: NETBEANS-3748 > URL: https://issues.apache.org/jira/browse/NETBEANS-3748 > Project: NetBeans > Issue Type: Bug > Components: projects - Generic Projects UI >Affects Versions: 11.2 > Environment: Product Version: Apache NetBeans IDE 11.2 > Java: 13.0.1; Java HotSpot(TM) 64-Bit Server VM 13.0.1+9 > Runtime: Java(TM) SE Runtime Environment 13.0.1+9 > System: Windows 10 version 10.0 running on amd64; Cp1252; en_GB (nb) > User directory: C:\Users\Anders Thulin\AppData\Roaming\NetBeans\11.2 > Cache directory: C:\Users\Anders Thulin\AppData\Local\NetBeans\Cache\11.2 >Reporter: Anders Thulin >Priority: Minor > Attachments: Netbeans_Files.png, Netbeans_Files_Metal.png, > Netbeans_Projects.png > > > After opening a project, and getting the Projects and Files Windows > populated, I find that the text lines shown are often truncated: the last > character is often only partially visible, in rare cases it is almost > unreadable. (See attached screenshots below) > I prefer Windows L, as I'm running on Windows 10, but the same issue is > present also in Nimbus L – with no obvious change. When I switch to Metal > L, the issue changes: most of the semi-visible characters become visible, > but not all (Attached Netbeans_Files_Metal.png as example below, where only > the 'O' of the .ISO file appears to be affected) > While I have changed Fonts & Colors, this does not seem to affect this > particular issue. > The issue becomes really irritating in situations where the last character is > the one that distinguishes project information (iso9660test005 or > iso9660test003, for example?); apart from that I can live with it. > > > > !Netbeans_Projects.png!!Netbeans_Files.png!!Netbeans_Files_Metal.png! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-3807) cleanup ArrayList rawtype warnings..
[
https://issues.apache.org/jira/browse/NETBEANS-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke resolved NETBEANS-3807.
---
Resolution: Fixed
PR was merged; resolving issue.
> cleanup ArrayList rawtype warnings..
>
>
> Key: NETBEANS-3807
> URL: https://issues.apache.org/jira/browse/NETBEANS-3807
> Project: NetBeans
> Issue Type: Improvement
>Reporter: Brad Walker
>Assignee: Brad Walker
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h
> Remaining Estimate: 0h
>
> This change cleans up the following warning..
> {code:java}
>[repeat]
> /home/bwalker/src/netbeans/webcommon/javascript2.model/src/org/netbeans/modules/javascript2/model/ModelVisitor.java:1454:
> warning: [rawtypes] found raw type: ArrayList
>[repeat] private List declaredVars = new ArrayList();
>[repeat] ^
>[repeat] missing type arguments for generic class ArrayList
>[repeat] where E is a type-variable:
>[repeat] E extends Object declared in class ArrayList
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-458) TestNG results not shown in Test Result window
[ https://issues.apache.org/jira/browse/NETBEANS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17045650#comment-17045650 ] Eirik Bakke commented on NETBEANS-458: -- Same issue for me when running tests using maven-surefire-plugin 2.19.0 or above (2.18.1 still works). This was supposedly fixed in https://netbeans.org/bugzilla/show_bug.cgi?id=257563 , but it still does not work for me as of NetBeans 11.3. (I confirmed that the patch for 257563 is present in the NetBeans 11.3 source repo.) > TestNG results not shown in Test Result window > -- > > Key: NETBEANS-458 > URL: https://issues.apache.org/jira/browse/NETBEANS-458 > Project: NetBeans > Issue Type: Bug > Components: java - JUnit, java - TestNG >Affects Versions: 9.0 > Environment: Product Version: Apache NetBeans IDE Dev (Build > incubator-netbeans-linux-362-on-20180312) > Java: 9.0.4; Java HotSpot(TM) 64-Bit Server VM 9.0.4+11 > Runtime: Java(TM) SE Runtime Environment 9.0.4+11 > System: Mac OS X version 10.13.3 running on x86_64; UTF-8; en_US (nb) >Reporter: Javier A. Ortiz >Priority: Major > > The tests showed the results in the output tab but Test Results remained > empty. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2955) Menu font is ways too big on a HiDPI monitor (Linux)
[ https://issues.apache.org/jira/browse/NETBEANS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-2955: -- Summary: Menu font is ways too big on a HiDPI monitor (Linux) (was: Menu font is ways too big on a HiDPI monitor) > Menu font is ways too big on a HiDPI monitor (Linux) > > > Key: NETBEANS-2955 > URL: https://issues.apache.org/jira/browse/NETBEANS-2955 > Project: NetBeans > Issue Type: Bug > Environment: 3840x2160 monitor, Ubuntu 18.04, Unity-desktop, "Scale > for menu and title bars" is set to 1.88 >Reporter: John Walker >Priority: Major > Labels: HiDPI > Attachments: Screenshot from 2019-08-05 21-33-18.png, Screenshot from > 2019-08-05 21-34-47.png, Screenshot from 2019-08-05 21-36-49.png > > > Hi There, > My setup is: 3840x2160 monitor, Ubuntu 18.04, Unity-desktop, "Scale for menu > and title bars" is set to 1.88. > The netbeans font size of menus, Project Explorer etc is enormously huge. > This unexpected growth of size happens when I move the scaling ratio from > 1.38 to 1.5. > I have already tried everything I was able to find on the topic, only > switching from GTK+ worked. Please advice on how I can fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-1583) Support MultiResolutionImage loading from ImageUtilities
[
https://issues.apache.org/jira/browse/NETBEANS-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke resolved NETBEANS-1583.
---
Resolution: Won't Fix
See previous comment--closing as won't fix, since SVG loading now replaces this
functionality.
> Support MultiResolutionImage loading from ImageUtilities
> -
>
> Key: NETBEANS-1583
> URL: https://issues.apache.org/jira/browse/NETBEANS-1583
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Other
>Affects Versions: 10.0
> Environment: Windows, Linux, and MacOS
>Reporter: Eirik Bakke
>Priority: Minor
> Labels: HiDPI
>
> To look good on HiDPI/Retina displays, the NetBeans IDE, and NetBeans
> Platform (RCP) applications, will eventually need to provide high-resolution
> versions of various image asset (typically icons). In Swing, multi-resolution
> image assets are supported via the
> [MultiResolutionImage|https://docs.oracle.com/javase/10/docs/api/java/awt/image/MultiResolutionImage.html]
> class; such images are automatically loaded by methods such as
> Toolkit.getImage based on a standard naming convention. For instance, on
> MacOS, Toolkit.getImage("myicon.png") will also load the file "myi...@2x.png"
> if present, returning a MultiResolutionImage (implemented in
> [JDK-8011059|https://bugs.openjdk.java.net/browse/JDK-8011059]). NetBeans'
> ImageUtilities.loadImage and friends should do the same.
> The same naming convention for multi-resolution image assets should be used
> as in the JDK. See Philip Race's comment on
> [JDK-8151787|https://bugs.openjdk.java.net/browse/JDK-8151787] :
> {quote}The proposed name convention for splash screens *and* other multi-res
> images is @125pct @150pct @200pct @2x @250pct @300pct @3x
> ie @2x and @3x are supported as synonyms for @200pct and @300pct respectively
> and also because we already supported @2x on retina Mac.
> {quote}
>
> On the naming convention, see also
> [JDK-8090575|https://bugs.openjdk.java.net/browse/JDK-8090575]. Also make
> sure to retain the ability to add a "_dark" suffix for dark LAFs.
> As far as I know, only MacOS currently supports the automatic loading of such
> assets via Toolkit.getImage, but both Windows and MacOS (and Linux?) support
> the underlying MultiResolutionImage class. So it's already possible to
> implement this on the latest JDK. Note, however, that we should probably wait
> for [JDK-8212226|https://bugs.openjdk.java.net/browse/JDK-8212226] to be
> fixed before enabling this on Windows.
> As part of this patch, other ImageUtilities methods such as
> createDisabledIcon, createDisabledImage, and mergeImages should also be
> updated to support both MultiResolutionImage and the new
> org.openide.util.VectorIcon class (introduced at
> https://github.com/apache/incubator-netbeans/pull/859/files ). Emilian Bold
> has done some work on this in the past; see
> https://github.com/emilianbold/nextbeans/commit/0f99dba0c1b3e8e0bc4e7cec407b53d30e85ead1
> . Eirik Bakke also has a [Pull
> Request|https://github.com/apache/incubator-netbeans/pull/998] for
> createDisabledIcon in particular, which works with the VectorIcon class and
> any other Icon instance.
> Last, note that there are two ways to create icons that look good on HiDPI
> displays: either by using MultiResolutionImage, or by hand-painting vector
> graphics in a custom implementation of the Icon class. This issue deals with
> the MultiResolutionImage approach; the vector painting approach is supported
> via the existing helper class org.openide.util.VectorIcon. Both approaches
> are valid and should be supported by the NetBeans Platform. (Update on
> 2019-05-27: There's a third approach, which is to supply each icon as an SVG
> file. That one is probably the better approach. See
> https://issues.apache.org/jira/browse/NETBEANS-2604 .)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-3785) Make memory gauge look better, especially on HiDPI displays
[ https://issues.apache.org/jira/browse/NETBEANS-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-3785. --- Fix Version/s: 11.3 Resolution: Fixed PR was merged; marking issue as resolved. For additional cosmetic improvements, create a new issue. > Make memory gauge look better, especially on HiDPI displays > --- > > Key: NETBEANS-3785 > URL: https://issues.apache.org/jira/browse/NETBEANS-3785 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Affects Versions: 11.2 > Environment: Windows, MacOS, and probably Linux, especially on > HiDPI/retina displays >Reporter: Eirik Bakke >Priority: Minor > Labels: HiDPI, pull-request-available > Fix For: 11.3 > > Attachments: gauge.jpg > > Time Spent: 4h > Remaining Estimate: 0h > > Scott Palmer writes: "Does anyone else see really ugly text in the memory > usage widget on the toolbar? This has been an issue for a while and I can’t > recall if I have reported it or it is already a known issue. It seems like > something that shouldn’t be hard to address. The text showing heap used vs > available heap is rendered in such a way that the letters are very puffy and > jagged. Almost like any anti-aliasing that would be blending the edges has > the alpha channel interpreted as a binary 0% or 100% opacity. I’ve attached > an image, not sure if it will are it through. I’m testing NB 11.3-beta 2 with > JDK 13.0.2 on macOS 10.15.3 (beta)" > Eirik Bakke confirms that this has been an issue for a long time. In > particular, the memory gauge should be updated to look good on HiDPI/Retina > displays. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-3593) Make web browser icon in the toolbar take advantage of improved HiDPI scaling
[ https://issues.apache.org/jira/browse/NETBEANS-3593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-3593. --- Fix Version/s: 11.3 Resolution: Fixed PR was merged; closing. > Make web browser icon in the toolbar take advantage of improved HiDPI scaling > - > > Key: NETBEANS-3593 > URL: https://issues.apache.org/jira/browse/NETBEANS-3593 > Project: NetBeans > Issue Type: Improvement >Affects Versions: 11.1 >Reporter: Eirik Bakke >Priority: Minor > Labels: HiDPI, pull-request-available > Fix For: 11.3 > > Attachments: browsericon.png > > Time Spent: 40m > Remaining Estimate: 0h > > This PR ensures that the HiDPI icon scaling improvements made in > NETBEANS-2614 applies to the browser icon in the toolbar. (Created a separate > PR for this one because it requires one API change to expose the > DropDownButton icon.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-2278) FolderName last character truncating
[ https://issues.apache.org/jira/browse/NETBEANS-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17045158#comment-17045158 ] Eirik Bakke commented on NETBEANS-2278: --- Possibly caused by https://bugs.openjdk.java.net/browse/JDK-8213535 . Not sure. The Projects pane component is a TreeView, which extends from JTree. > FolderName last character truncating > > > Key: NETBEANS-2278 > URL: https://issues.apache.org/jira/browse/NETBEANS-2278 > Project: NetBeans > Issue Type: Bug >Affects Versions: 9.0, 10.0, 11.0 > Environment: windows >Reporter: Simerdeep Arora >Priority: Critical > Labels: HiDPI > Attachments: image-2019-03-19-16-57-45-526.png > > > The last character of all of my folders, with long names, is truncating. > See the screenshot. > > The issue is in version 9 and 10 and 11..I have not tested in previous > versions. > > See the folder name is abc12345678910 but 0 is truncating. > > From CosmicClasses s is truncating > > !image-2019-03-19-16-57-45-526.png! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3808) "Go to Symbol" and "Go to File" orders results incorrectly
[ https://issues.apache.org/jira/browse/NETBEANS-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032538#comment-17032538 ] Eirik Bakke commented on NETBEANS-3808: --- Another ordering issue: a search term like "SomeFoozle" will list 50 "someFoozle" variables before the actual "SomeFoozle" class. > "Go to Symbol" and "Go to File" orders results incorrectly > -- > > Key: NETBEANS-3808 > URL: https://issues.apache.org/jira/browse/NETBEANS-3808 > Project: NetBeans > Issue Type: Improvement > Components: ide - UI >Affects Versions: 11.1 >Reporter: Eirik Bakke >Priority: Major > > If a project contains two Java classes "TestClass" and "TestAnotherClass", > and the user types in "TestClass" into either the "Go to Symbol" or "Go to > File" dialog, then "TestAnotherClass" ends up being listed before > "TestClass", and ends up being the default selection. In this case the > correct, the default result should obviously be "TestClass". Some tweaking of > the ordering logic is needed to achieve this. > In many practical cases, the right class ends up being way down the list. > This greatly diminishes the value of the Go to Symbol/File functionality. > I believe this used to work correctly in older (pre-Apache?) NetBeans > versions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3017) Navigate -> Go to File... does not work anymore
[ https://issues.apache.org/jira/browse/NETBEANS-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032083#comment-17032083 ] Eirik Bakke commented on NETBEANS-3017: --- I can confirm that this feature (and "Go to Symbol") worked a lot better in older NetBeans versions... would be good to get fixed. > Navigate -> Go to File... does not work anymore > --- > > Key: NETBEANS-3017 > URL: https://issues.apache.org/jira/browse/NETBEANS-3017 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.1 > Environment: Linux (Debian 9), JDK 1.8.0_202 >Reporter: Burkhard Graves >Priority: Major > > Navigate -> Go to File... does not (always) work as expected. Sometimes it > works, but often it does not find files which definitely exist. Same result > when removing the cache beforehand. > It works _much better_ in 8.x (also not always but much better). > (I ended up installing the plugin "Open File Fast"...) > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-3808) "Go to Symbol" and "Go to File" orders results incorrectly
Eirik Bakke created NETBEANS-3808: - Summary: "Go to Symbol" and "Go to File" orders results incorrectly Key: NETBEANS-3808 URL: https://issues.apache.org/jira/browse/NETBEANS-3808 Project: NetBeans Issue Type: Improvement Components: ide - UI Affects Versions: 11.1 Reporter: Eirik Bakke If a project contains two Java classes "TestClass" and "TestAnotherClass", and the user types in "TestClass" into either the "Go to Symbol" or "Go to File" dialog, then "TestAnotherClass" ends up being listed before "TestClass", and ends up being the default selection. In this case the correct, the default result should obviously be "TestClass". Some tweaking of the ordering logic is needed to achieve this. In many practical cases, the right class ends up being way down the list. This greatly diminishes the value of the Go to Symbol/File functionality. I believe this used to work correctly in older (pre-Apache?) NetBeans versions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-3671) IllegalArgumentException CachedHiDPIIcon
[
https://issues.apache.org/jira/browse/NETBEANS-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke resolved NETBEANS-3671.
---
Fix Version/s: Next
Resolution: Fixed
A fix to handle this case gracefully was merged. A warning message
(""NETBEANS-3671: FilteredIcon.create got {0} of invalid dimensions {1}x{2}
with URL={3}"") may be logged in the future when negative Icon dimensions are
encountered; feel free to paste the message as a comment in this JIRA issue if
it is encountered.
> IllegalArgumentException CachedHiDPIIcon
>
>
> Key: NETBEANS-3671
> URL: https://issues.apache.org/jira/browse/NETBEANS-3671
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Other
>Affects Versions: 11.1
> Environment: Linux: Ubuntu 18.04.3 LTS
>Reporter: Thomas
>Assignee: Eirik Bakke
>Priority: Major
> Labels: pull-request-available
> Fix For: Next
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Now and then I get the following exception when opening the "Tools" menu item
> via mouse:
>
> java.lang.IllegalArgumentException
> at org.openide.util.CachedHiDPIIcon.(CachedHiDPIIcon.java:63)
> at org.openide.util.FilteredIcon.(FilteredIcon.java:50)
> at org.openide.util.FilteredIcon.create(FilteredIcon.java:58)
> at
> org.openide.util.ImageUtilities.createDisabledIcon(ImageUtilities.java:415)
> at org.openide.awt.Actions$MenuBridge.updateButtonIcon(Actions.java:1375)
> at org.openide.awt.Actions$MenuBridge.updateState(Actions.java:1324)
> at org.openide.awt.Actions$MenuItem.synchMenuPresenters(Actions.java:1667)
> at org.openide.awt.DynaMenuModel.checkSubmenu(DynaMenuModel.java:171)
> at org.openide.awt.MenuBar$LazyMenu.setPopupMenuVisible(MenuBar.java:722)
> at
> java.desktop/javax.swing.JPopupMenu.menuSelectionChanged(JPopupMenu.java:1486)
> at
> java.desktop/javax.swing.MenuSelectionManager.setSelectedPath(MenuSelectionManager.java:129)
> at
> java.desktop/javax.swing.plaf.basic.BasicMenuUI.appendPath(BasicMenuUI.java:259)
> at
> java.desktop/javax.swing.plaf.basic.BasicMenuUI$Handler.mousePressed(BasicMenuUI.java:520)
> at java.desktop/java.awt.Component.processMouseEvent(Component.java:6629)
> at
> java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342)
> at java.desktop/java.awt.Component.processEvent(Component.java:6397)
> at java.desktop/java.awt.Container.processEvent(Container.java:2263)
> at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5008)
> at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
> at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840)
> at
> java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4918)
> at
> java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4544)
> at
> java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4488)
> at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2307)
> at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772)
> at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840)
> at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
> at
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
> at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
> at
> org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136)
> [catch] at
> java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
> at
> java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
> at
> java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
> at
> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
> at
> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
--
This message
[jira] [Comment Edited] (NETBEANS-3769) Cannot rename project and directory
[
https://issues.apache.org/jira/browse/NETBEANS-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030907#comment-17030907
]
Eirik Bakke edited comment on NETBEANS-3769 at 2/5/20 6:47 PM:
---
After some testing, it turns out that the exception from
ImageUtilities$ToolTipImage was a red herring. Even with this one definitively
fixed (in the PR at https://github.com/apache/netbeans/pull/1922 ), the problem
remains:
{code:java}
WARNING
[org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation]
msg
msg
Caused: org.netbeans.modules.masterfs.filebasedfs.utils.FSException: Cannot
rename file JavaApplication21 in C:/Users/ebakke/Deletables to
JavaApplication21tofo.
at
org.netbeans.modules.masterfs.filebasedfs.utils.FSException.io(FSException.java:93)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.rename(BaseFileObj.java:441)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$1.call(BaseFileObj.java:495)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$1.call(BaseFileObj.java:492)
at
org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.runAsInconsistent(FileBasedFileSystem.java:97)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.rename(BaseFileObj.java:499)
at org.openide.filesystems.FileObject.move(FileObject.java:157)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.move(BaseFileObj.java:291)
at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation.doMoveProject(DefaultProjectOperationsImplementation.java:521)
[catch] at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$4.execute(DefaultProjectOperationsImplementation.java:377)
at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$6$1.run(DefaultProjectOperationsImplementation.java:685)
at
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
ALL [null]: Cannot rename file JavaApplication21 in C:/Users/ebakke/Deletables
to JavaApplication21tofo.
ALL [null]: Cannot rename project, reason: Cannot rename file JavaApplication21
in C:/Users/ebakke/Deletables to JavaApplication21tofo.
{code}
The problem does not seem to occur on 11.1.
(Also, I wonder where "msg" is being printed--obviously a logging bug.)
was (Author: ebakke):
After some testing, it turns out that the exception from
ImageUtilities$ToolTipImage was a red herring. Even with this one definitively
fixed (in the PR at https://github.com/apache/netbeans/pull/1922 ), the problem
remains:
{code:java}
WARNING
[org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation]
msg
msg
Caused: org.netbeans.modules.masterfs.filebasedfs.utils.FSException: Cannot
rename file JavaApplication21 in C:/Users/ebakke/Deletables to
JavaApplication21tofo.
at
org.netbeans.modules.masterfs.filebasedfs.utils.FSException.io(FSException.java:93)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.rename(BaseFileObj.java:441)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$1.call(BaseFileObj.java:495)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$1.call(BaseFileObj.java:492)
at
org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.runAsInconsistent(FileBasedFileSystem.java:97)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.rename(BaseFileObj.java:499)
at org.openide.filesystems.FileObject.move(FileObject.java:157)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.move(BaseFileObj.java:291)
at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation.doMoveProject(DefaultProjectOperationsImplementation.java:521)
[catch] at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$4.execute(DefaultProjectOperationsImplementation.java:377)
at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$6$1.run(DefaultProjectOperationsImplementation.java:685)
at
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
ALL [null]: Cannot rename file JavaApplication21 in C:/Users/ebakke/Deletables
to JavaApplication21tofo.
ALL [null]: Cannot rename
[jira] [Comment Edited] (NETBEANS-3769) Cannot rename project and directory
[
https://issues.apache.org/jira/browse/NETBEANS-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030907#comment-17030907
]
Eirik Bakke edited comment on NETBEANS-3769 at 2/5/20 6:46 PM:
---
After some testing, it turns out that the exception from
ImageUtilities$ToolTipImage was a red herring. Even with this one definitively
fixed (in the PR at https://github.com/apache/netbeans/pull/1922 ), the problem
remains:
{code:java}
WARNING
[org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation]
msg
msg
Caused: org.netbeans.modules.masterfs.filebasedfs.utils.FSException: Cannot
rename file JavaApplication21 in C:/Users/ebakke/Deletables to
JavaApplication21tofo.
at
org.netbeans.modules.masterfs.filebasedfs.utils.FSException.io(FSException.java:93)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.rename(BaseFileObj.java:441)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$1.call(BaseFileObj.java:495)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$1.call(BaseFileObj.java:492)
at
org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.runAsInconsistent(FileBasedFileSystem.java:97)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.rename(BaseFileObj.java:499)
at org.openide.filesystems.FileObject.move(FileObject.java:157)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.move(BaseFileObj.java:291)
at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation.doMoveProject(DefaultProjectOperationsImplementation.java:521)
[catch] at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$4.execute(DefaultProjectOperationsImplementation.java:377)
at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$6$1.run(DefaultProjectOperationsImplementation.java:685)
at
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
ALL [null]: Cannot rename file JavaApplication21 in C:/Users/ebakke/Deletables
to JavaApplication21tofo.
ALL [null]: Cannot rename project, reason: Cannot rename file JavaApplication21
in C:/Users/ebakke/Deletables to JavaApplication21tofo.
{code}
The problem does not seem to occur on 11.1.
was (Author: ebakke):
After some testing, it turns out that the exception from CachedHiDPIIcon was a
red herring. Even with this one definitively fixed (in the PR at
https://github.com/apache/netbeans/pull/1922 ), the problem remains:
{code:java}
WARNING
[org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation]
msg
msg
Caused: org.netbeans.modules.masterfs.filebasedfs.utils.FSException: Cannot
rename file JavaApplication21 in C:/Users/ebakke/Deletables to
JavaApplication21tofo.
at
org.netbeans.modules.masterfs.filebasedfs.utils.FSException.io(FSException.java:93)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.rename(BaseFileObj.java:441)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$1.call(BaseFileObj.java:495)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$1.call(BaseFileObj.java:492)
at
org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.runAsInconsistent(FileBasedFileSystem.java:97)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.rename(BaseFileObj.java:499)
at org.openide.filesystems.FileObject.move(FileObject.java:157)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.move(BaseFileObj.java:291)
at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation.doMoveProject(DefaultProjectOperationsImplementation.java:521)
[catch] at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$4.execute(DefaultProjectOperationsImplementation.java:377)
at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$6$1.run(DefaultProjectOperationsImplementation.java:685)
at
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
ALL [null]: Cannot rename file JavaApplication21 in C:/Users/ebakke/Deletables
to JavaApplication21tofo.
ALL [null]: Cannot rename project, reason: Cannot rename file JavaApplication21
in C:/Users/ebakke/Deletables to
[jira] [Assigned] (NETBEANS-3769) Cannot rename project and directory
[
https://issues.apache.org/jira/browse/NETBEANS-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke reassigned NETBEANS-3769:
-
Assignee: (was: Eirik Bakke)
> Cannot rename project and directory
> ---
>
> Key: NETBEANS-3769
> URL: https://issues.apache.org/jira/browse/NETBEANS-3769
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Generic Infrastructure, projects - Generic
> Projects UI
>Affects Versions: 11.3
> Environment: NB 11.3b running on JDK-13.0.2, Win7
>Reporter: Ernie Rael
>Priority: Major
> Labels: pull-request-available
> Fix For: 11.3
>
> Attachments: CannotRenameProject.log.1, CannotRenameProject.log.2,
> ProjRenameAtRename.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> (Attaching log with relevant exceptions)
> To reproduce
> # NewProject > JavaWithAnt > JavaApplication; accept all defaults
> # From context menu on new project, select "Rename..."
> # In dialog change the name
> # Select "Also Rename Project Folder"
> # Click "Rename" button
> Observe error dialog
> {quote}Error
> Cannot rename file JavaApplication8 in F:/j/nb-stuff/NetBeansProjects to
> RenameProject
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3769) Cannot rename project and directory
[
https://issues.apache.org/jira/browse/NETBEANS-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030907#comment-17030907
]
Eirik Bakke commented on NETBEANS-3769:
---
After some testing, it turns out that the exception from CachedHiDPIIcon was a
red herring. Even with this one definitively fixed (in the PR at
https://github.com/apache/netbeans/pull/1922 ), the problem remains:
{code:java}
WARNING
[org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation]
msg
msg
Caused: org.netbeans.modules.masterfs.filebasedfs.utils.FSException: Cannot
rename file JavaApplication21 in C:/Users/ebakke/Deletables to
JavaApplication21tofo.
at
org.netbeans.modules.masterfs.filebasedfs.utils.FSException.io(FSException.java:93)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.rename(BaseFileObj.java:441)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$1.call(BaseFileObj.java:495)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$1.call(BaseFileObj.java:492)
at
org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.runAsInconsistent(FileBasedFileSystem.java:97)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.rename(BaseFileObj.java:499)
at org.openide.filesystems.FileObject.move(FileObject.java:157)
at
org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.move(BaseFileObj.java:291)
at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation.doMoveProject(DefaultProjectOperationsImplementation.java:521)
[catch] at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$4.execute(DefaultProjectOperationsImplementation.java:377)
at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$6$1.run(DefaultProjectOperationsImplementation.java:685)
at
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
ALL [null]: Cannot rename file JavaApplication21 in C:/Users/ebakke/Deletables
to JavaApplication21tofo.
ALL [null]: Cannot rename project, reason: Cannot rename file JavaApplication21
in C:/Users/ebakke/Deletables to JavaApplication21tofo.
{code}
The problem does not seem to occur on 11.1.
> Cannot rename project and directory
> ---
>
> Key: NETBEANS-3769
> URL: https://issues.apache.org/jira/browse/NETBEANS-3769
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Generic Infrastructure, projects - Generic
> Projects UI
>Affects Versions: 11.3
> Environment: NB 11.3b running on JDK-13.0.2, Win7
>Reporter: Ernie Rael
>Assignee: Eirik Bakke
>Priority: Major
> Labels: pull-request-available
> Fix For: 11.3
>
> Attachments: CannotRenameProject.log.1, CannotRenameProject.log.2,
> ProjRenameAtRename.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> (Attaching log with relevant exceptions)
> To reproduce
> # NewProject > JavaWithAnt > JavaApplication; accept all defaults
> # From context menu on new project, select "Rename..."
> # In dialog change the name
> # Select "Also Rename Project Folder"
> # Click "Rename" button
> Observe error dialog
> {quote}Error
> Cannot rename file JavaApplication8 in F:/j/nb-stuff/NetBeansProjects to
> RenameProject
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3769) Cannot rename project and directory
[
https://issues.apache.org/jira/browse/NETBEANS-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030388#comment-17030388
]
Eirik Bakke commented on NETBEANS-3769:
---
Added a PR for this at https://github.com/apache/netbeans/pull/1922/files .
> Cannot rename project and directory
> ---
>
> Key: NETBEANS-3769
> URL: https://issues.apache.org/jira/browse/NETBEANS-3769
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Generic Infrastructure, projects - Generic
> Projects UI
>Affects Versions: 11.3
> Environment: NB 11.3b running on JDK-13.0.2, Win7
>Reporter: Ernie Rael
>Assignee: Eirik Bakke
>Priority: Major
> Labels: pull-request-available
> Fix For: 11.3
>
> Attachments: CannotRenameProject.log.1, CannotRenameProject.log.2,
> ProjRenameAtRename.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> (Attaching log with relevant exceptions)
> To reproduce
> # NewProject > JavaWithAnt > JavaApplication; accept all defaults
> # From context menu on new project, select "Rename..."
> # In dialog change the name
> # Select "Also Rename Project Folder"
> # Click "Rename" button
> Observe error dialog
> {quote}Error
> Cannot rename file JavaApplication8 in F:/j/nb-stuff/NetBeansProjects to
> RenameProject
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3671) IllegalArgumentException CachedHiDPIIcon
[ https://issues.apache.org/jira/browse/NETBEANS-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030390#comment-17030390 ] Eirik Bakke commented on NETBEANS-3671: --- Added a PR for this at https://github.com/apache/netbeans/pull/1922/files . > IllegalArgumentException CachedHiDPIIcon > > > Key: NETBEANS-3671 > URL: https://issues.apache.org/jira/browse/NETBEANS-3671 > Project: NetBeans > Issue Type: Bug > Components: platform - Other >Affects Versions: 11.1 > Environment: Linux: Ubuntu 18.04.3 LTS >Reporter: Thomas >Assignee: Eirik Bakke >Priority: Major > > Now and then I get the following exception when opening the "Tools" menu item > via mouse: > > java.lang.IllegalArgumentException > at org.openide.util.CachedHiDPIIcon.(CachedHiDPIIcon.java:63) > at org.openide.util.FilteredIcon.(FilteredIcon.java:50) > at org.openide.util.FilteredIcon.create(FilteredIcon.java:58) > at > org.openide.util.ImageUtilities.createDisabledIcon(ImageUtilities.java:415) > at org.openide.awt.Actions$MenuBridge.updateButtonIcon(Actions.java:1375) > at org.openide.awt.Actions$MenuBridge.updateState(Actions.java:1324) > at org.openide.awt.Actions$MenuItem.synchMenuPresenters(Actions.java:1667) > at org.openide.awt.DynaMenuModel.checkSubmenu(DynaMenuModel.java:171) > at org.openide.awt.MenuBar$LazyMenu.setPopupMenuVisible(MenuBar.java:722) > at > java.desktop/javax.swing.JPopupMenu.menuSelectionChanged(JPopupMenu.java:1486) > at > java.desktop/javax.swing.MenuSelectionManager.setSelectedPath(MenuSelectionManager.java:129) > at > java.desktop/javax.swing.plaf.basic.BasicMenuUI.appendPath(BasicMenuUI.java:259) > at > java.desktop/javax.swing.plaf.basic.BasicMenuUI$Handler.mousePressed(BasicMenuUI.java:520) > at java.desktop/java.awt.Component.processMouseEvent(Component.java:6629) > at > java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342) > at java.desktop/java.awt.Component.processEvent(Component.java:6397) > at java.desktop/java.awt.Container.processEvent(Container.java:2263) > at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5008) > at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321) > at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840) > at > java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4918) > at > java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4544) > at > java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4488) > at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2307) > at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772) > at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840) > at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at > java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) > at > java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) > at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) > at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at > java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) > at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) > at > org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136) > [catch] at > java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) > at > java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) > at > java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) > at > java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) > at > java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3671) IllegalArgumentException CachedHiDPIIcon
[ https://issues.apache.org/jira/browse/NETBEANS-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029378#comment-17029378 ] Eirik Bakke commented on NETBEANS-3671: --- Will add a patch for this. > IllegalArgumentException CachedHiDPIIcon > > > Key: NETBEANS-3671 > URL: https://issues.apache.org/jira/browse/NETBEANS-3671 > Project: NetBeans > Issue Type: Bug > Components: platform - Other >Affects Versions: 11.1 > Environment: Linux: Ubuntu 18.04.3 LTS >Reporter: Thomas >Assignee: Eirik Bakke >Priority: Major > > Now and then I get the following exception when opening the "Tools" menu item > via mouse: > > java.lang.IllegalArgumentException > at org.openide.util.CachedHiDPIIcon.(CachedHiDPIIcon.java:63) > at org.openide.util.FilteredIcon.(FilteredIcon.java:50) > at org.openide.util.FilteredIcon.create(FilteredIcon.java:58) > at > org.openide.util.ImageUtilities.createDisabledIcon(ImageUtilities.java:415) > at org.openide.awt.Actions$MenuBridge.updateButtonIcon(Actions.java:1375) > at org.openide.awt.Actions$MenuBridge.updateState(Actions.java:1324) > at org.openide.awt.Actions$MenuItem.synchMenuPresenters(Actions.java:1667) > at org.openide.awt.DynaMenuModel.checkSubmenu(DynaMenuModel.java:171) > at org.openide.awt.MenuBar$LazyMenu.setPopupMenuVisible(MenuBar.java:722) > at > java.desktop/javax.swing.JPopupMenu.menuSelectionChanged(JPopupMenu.java:1486) > at > java.desktop/javax.swing.MenuSelectionManager.setSelectedPath(MenuSelectionManager.java:129) > at > java.desktop/javax.swing.plaf.basic.BasicMenuUI.appendPath(BasicMenuUI.java:259) > at > java.desktop/javax.swing.plaf.basic.BasicMenuUI$Handler.mousePressed(BasicMenuUI.java:520) > at java.desktop/java.awt.Component.processMouseEvent(Component.java:6629) > at > java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342) > at java.desktop/java.awt.Component.processEvent(Component.java:6397) > at java.desktop/java.awt.Container.processEvent(Container.java:2263) > at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5008) > at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321) > at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840) > at > java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4918) > at > java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4544) > at > java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4488) > at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2307) > at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772) > at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840) > at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at > java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) > at > java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) > at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) > at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at > java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) > at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) > at > org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136) > [catch] at > java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) > at > java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) > at > java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) > at > java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) > at > java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3769) Cannot rename project and directory
[
https://issues.apache.org/jira/browse/NETBEANS-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029376#comment-17029376
]
Eirik Bakke commented on NETBEANS-3769:
---
I can't reproduce it on my current dev build, but a a patch is easy enough. I
believe icons are serialized so that they can be shown in the "Open Recent
Project" menu.
Will submit a PR the next time I am working on the master branch...
> Cannot rename project and directory
> ---
>
> Key: NETBEANS-3769
> URL: https://issues.apache.org/jira/browse/NETBEANS-3769
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Generic Infrastructure, projects - Generic
> Projects UI
>Affects Versions: 11.3
> Environment: NB 11.3b running on JDK-13.0.2, Win7
>Reporter: Ernie Rael
>Assignee: Eirik Bakke
>Priority: Major
> Fix For: 11.3
>
> Attachments: CannotRenameProject.log.1, CannotRenameProject.log.2,
> ProjRenameAtRename.png
>
>
> (Attaching log with relevant exceptions)
> To reproduce
> # NewProject > JavaWithAnt > JavaApplication; accept all defaults
> # From context menu on new project, select "Rename..."
> # In dialog change the name
> # Select "Also Rename Project Folder"
> # Click "Rename" button
> Observe error dialog
> {quote}Error
> Cannot rename file JavaApplication8 in F:/j/nb-stuff/NetBeansProjects to
> RenameProject
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-338) Find/Replace dialog does not render correctly
[ https://issues.apache.org/jira/browse/NETBEANS-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-338. -- Fix Version/s: 11.3 Resolution: Fixed Should be improved by the previously merged PR. > Find/Replace dialog does not render correctly > - > > Key: NETBEANS-338 > URL: https://issues.apache.org/jira/browse/NETBEANS-338 > Project: NetBeans > Issue Type: Bug > Components: editor - Search >Affects Versions: 9.0, 10.0 > Environment: Product Version: Apache NetBeans IDE Dev (Build > 20180117-unknown-revn) > Java: 9.0.4; Java HotSpot(TM) 64-Bit Server VM 9.0.4+11 > Runtime: Java(TM) SE Runtime Environment 9.0.4+11 > System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb) > User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev > Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev >Reporter: Gili >Assignee: Eirik Bakke >Priority: Trivial > Labels: HiDPI, Java9, Windows, regression > Fix For: 11.3 > > Attachments: screenshot.png > > > In the attached screenshot, notice that the horizontal separator between the > two combo-boxes is cut off. Expanding the combo-box causes the line to > render, but once it is collapsed again the line disappears. This used to work > in Netbeans 8.2 (though this was with JDK 8 while now I am using JDK 9) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-3581) DropDownButton/DropDownToggleButton improvements
[ https://issues.apache.org/jira/browse/NETBEANS-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-3581. --- Resolution: Fixed Merged. > DropDownButton/DropDownToggleButton improvements > > > Key: NETBEANS-3581 > URL: https://issues.apache.org/jira/browse/NETBEANS-3581 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Affects Versions: 11.1 > Environment: Windows, MacOS, and Linux >Reporter: Eirik Bakke >Assignee: Eirik Bakke >Priority: Minor > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Make a few improvements to the dropdown button components returned by > org.openide.awt.DropDownButtonFactory's public static constructors. For > example, fix a bug where a click may be ignored, or where a click may open > the dropdown menu even when the button is supposed to be disabled. > (Creating this issue for an upcoming pull request.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Assigned] (NETBEANS-3671) IllegalArgumentException CachedHiDPIIcon
[ https://issues.apache.org/jira/browse/NETBEANS-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke reassigned NETBEANS-3671: - Assignee: Eirik Bakke > IllegalArgumentException CachedHiDPIIcon > > > Key: NETBEANS-3671 > URL: https://issues.apache.org/jira/browse/NETBEANS-3671 > Project: NetBeans > Issue Type: Bug > Components: platform - Other >Affects Versions: 11.1 > Environment: Linux: Ubuntu 18.04.3 LTS >Reporter: Thomas >Assignee: Eirik Bakke >Priority: Major > > Now and then I get the following exception when opening the "Tools" menu item > via mouse: > > java.lang.IllegalArgumentException > at org.openide.util.CachedHiDPIIcon.(CachedHiDPIIcon.java:63) > at org.openide.util.FilteredIcon.(FilteredIcon.java:50) > at org.openide.util.FilteredIcon.create(FilteredIcon.java:58) > at > org.openide.util.ImageUtilities.createDisabledIcon(ImageUtilities.java:415) > at org.openide.awt.Actions$MenuBridge.updateButtonIcon(Actions.java:1375) > at org.openide.awt.Actions$MenuBridge.updateState(Actions.java:1324) > at org.openide.awt.Actions$MenuItem.synchMenuPresenters(Actions.java:1667) > at org.openide.awt.DynaMenuModel.checkSubmenu(DynaMenuModel.java:171) > at org.openide.awt.MenuBar$LazyMenu.setPopupMenuVisible(MenuBar.java:722) > at > java.desktop/javax.swing.JPopupMenu.menuSelectionChanged(JPopupMenu.java:1486) > at > java.desktop/javax.swing.MenuSelectionManager.setSelectedPath(MenuSelectionManager.java:129) > at > java.desktop/javax.swing.plaf.basic.BasicMenuUI.appendPath(BasicMenuUI.java:259) > at > java.desktop/javax.swing.plaf.basic.BasicMenuUI$Handler.mousePressed(BasicMenuUI.java:520) > at java.desktop/java.awt.Component.processMouseEvent(Component.java:6629) > at > java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342) > at java.desktop/java.awt.Component.processEvent(Component.java:6397) > at java.desktop/java.awt.Container.processEvent(Container.java:2263) > at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5008) > at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321) > at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840) > at > java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4918) > at > java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4544) > at > java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4488) > at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2307) > at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772) > at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840) > at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at > java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) > at > java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) > at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) > at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at > java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) > at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) > at > org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136) > [catch] at > java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) > at > java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) > at > java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) > at > java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) > at > java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-3699) Netbeans not properly working in multiple HiDpi screens
[ https://issues.apache.org/jira/browse/NETBEANS-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3699: -- Labels: HiDPI (was: ) > Netbeans not properly working in multiple HiDpi screens > --- > > Key: NETBEANS-3699 > URL: https://issues.apache.org/jira/browse/NETBEANS-3699 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Affects Versions: 11.2 > Environment: Product Version: Apache NetBeans IDE 11.2 > Java: 11.0.2; OpenJDK 64-Bit Server VM 11.0.2+9 > Runtime: OpenJDK Runtime Environment 11.0.2+9 > System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb) >Reporter: Sammy >Priority: Major > Labels: HiDPI > Fix For: 11.3 > > Attachments: image-2020-01-15-13-40-19-726.png, > image-2020-01-15-13-40-50-746.png, image-2020-01-15-13-43-39-587.png > > > !image-2020-01-15-13-40-19-726.png! > Netbeans doesn't seem to handle per-monitor dpi scaling properly. You can see > the icon pixelated and the tab bar text is cut off. I'm running 3 monitors, > the main one on 125%, the other on 100% scaling. When I drag Netbeans to > Monitor 3 at 100% scaling it looks correct. But main one is wrong. > !image-2020-01-15-13-40-50-746.png! > > > I have this setting enabled to ensure scaling is done based on main monitor: > > !image-2020-01-15-13-43-39-587.png! > this doesn't make a difference. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-3699) Netbeans not properly working in multiple HiDpi screens
[ https://issues.apache.org/jira/browse/NETBEANS-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-3699. --- Fix Version/s: 11.3 Resolution: Fixed Should be fixed in the next NetBeans version; see https://github.com/apache/netbeans/pull/1777 and https://github.com/apache/netbeans/pull/1804. Feel free to report or comment on any issues that remain on 11.3. See https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements for an overview of HiDPI-related work that is being done on NetBeans. > Netbeans not properly working in multiple HiDpi screens > --- > > Key: NETBEANS-3699 > URL: https://issues.apache.org/jira/browse/NETBEANS-3699 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Affects Versions: 11.2 > Environment: Product Version: Apache NetBeans IDE 11.2 > Java: 11.0.2; OpenJDK 64-Bit Server VM 11.0.2+9 > Runtime: OpenJDK Runtime Environment 11.0.2+9 > System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb) >Reporter: Sammy >Priority: Major > Fix For: 11.3 > > Attachments: image-2020-01-15-13-40-19-726.png, > image-2020-01-15-13-40-50-746.png, image-2020-01-15-13-43-39-587.png > > > !image-2020-01-15-13-40-19-726.png! > Netbeans doesn't seem to handle per-monitor dpi scaling properly. You can see > the icon pixelated and the tab bar text is cut off. I'm running 3 monitors, > the main one on 125%, the other on 100% scaling. When I drag Netbeans to > Monitor 3 at 100% scaling it looks correct. But main one is wrong. > !image-2020-01-15-13-40-50-746.png! > > > I have this setting enabled to ensure scaling is done based on main monitor: > > !image-2020-01-15-13-43-39-587.png! > this doesn't make a difference. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-2278) FolderName last character truncating
[ https://issues.apache.org/jira/browse/NETBEANS-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028621#comment-17028621 ] Eirik Bakke commented on NETBEANS-2278: --- This is an issue which occurs on Windows on fractional HiDPI scaling factors (e.g. 150%). > FolderName last character truncating > > > Key: NETBEANS-2278 > URL: https://issues.apache.org/jira/browse/NETBEANS-2278 > Project: NetBeans > Issue Type: Bug >Affects Versions: 9.0, 10.0, 11.0 > Environment: windows >Reporter: Simerdeep Arora >Priority: Critical > Labels: HiDPI > Attachments: image-2019-03-19-16-57-45-526.png > > > The last character of all of my folders, with long names, is truncating. > See the screenshot. > > The issue is in version 9 and 10 and 11..I have not tested in previous > versions. > > See the folder name is abc12345678910 but 0 is truncating. > > From CosmicClasses s is truncating > > !image-2019-03-19-16-57-45-526.png! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-2278) FolderName last character truncating
[ https://issues.apache.org/jira/browse/NETBEANS-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-2278: -- Labels: HiDPI (was: ) > FolderName last character truncating > > > Key: NETBEANS-2278 > URL: https://issues.apache.org/jira/browse/NETBEANS-2278 > Project: NetBeans > Issue Type: Bug >Affects Versions: 9.0, 10.0, 11.0 > Environment: windows >Reporter: Simerdeep Arora >Priority: Critical > Labels: HiDPI > Attachments: image-2019-03-19-16-57-45-526.png > > > The last character of all of my folders, with long names, is truncating. > See the screenshot. > > The issue is in version 9 and 10 and 11..I have not tested in previous > versions. > > See the folder name is abc12345678910 but 0 is truncating. > > From CosmicClasses s is truncating > > !image-2019-03-19-16-57-45-526.png! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-585) Clicking in Output Window places caret in wrong position
[ https://issues.apache.org/jira/browse/NETBEANS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028546#comment-17028546 ] Eirik Bakke commented on NETBEANS-585: -- On Windows, this happens on 150% and 200% scaling modes, including when only one monitor is used. Normally I'd guess it would be related to rounding error in fractional scaling modes (e.g. 150%), but it seems to happen at 200% as well, which is interesting. This bug makes selection in the Output window (e.g. for copying parts of the text to the clipboard) nearly impossible. Does this happen on MacOS on Retina screens as well? I tried it on my old Mac, but can't immediately reproduce it there. Perhaps a Windows-only issue. > Clicking in Output Window places caret in wrong position > > > Key: NETBEANS-585 > URL: https://issues.apache.org/jira/browse/NETBEANS-585 > Project: NetBeans > Issue Type: Bug > Components: platform - Output Window >Affects Versions: 9.0 > Environment: Product Version: Apache NetBeans IDE Dev (Build > incubator-netbeans-release-245-on-20180327) > Java: 9.0.4; Java HotSpot(TM) 64-Bit Server VM 9.0.4+11 > Runtime: Java(TM) SE Runtime Environment 9.0.4+11 > System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb) > User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev > Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev >Reporter: Gili >Priority: Major > Labels: HiDPI > > Repro steps: > 1. Run a Java Maven application that outputs to the console > 2. Click somewhere in a line of text in the Output Window (wrap-text is > disabled) > 3. Notice that the caret lands many characters to the left of where you click > It is extremely difficult to copy/paste text because we cannot control where > the caret begins copy/pasting from. > This issue might be related to NETBEANS-235 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-3785) Make memory gauge look better, especially on HiDPI displays
Eirik Bakke created NETBEANS-3785: - Summary: Make memory gauge look better, especially on HiDPI displays Key: NETBEANS-3785 URL: https://issues.apache.org/jira/browse/NETBEANS-3785 Project: NetBeans Issue Type: Improvement Components: platform - Other Affects Versions: 11.2 Environment: Windows, MacOS, and probably Linux, especially on HiDPI/retina displays Reporter: Eirik Bakke Attachments: gauge.jpg Scott Palmer writes: "Does anyone else see really ugly text in the memory usage widget on the toolbar? This has been an issue for a while and I can’t recall if I have reported it or it is already a known issue. It seems like something that shouldn’t be hard to address. The text showing heap used vs available heap is rendered in such a way that the letters are very puffy and jagged. Almost like any anti-aliasing that would be blending the edges has the alpha channel interpreted as a binary 0% or 100% opacity. I’ve attached an image, not sure if it will are it through. I’m testing NB 11.3-beta 2 with JDK 13.0.2 on macOS 10.15.3 (beta)" Eirik Bakke confirms that this has been an issue for a long time. In particular, the memory gauge should be updated to look good on HiDPI/Retina displays. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3727) Probably a darker color of the desktop background would be good for FlatLaf
[ https://issues.apache.org/jira/browse/NETBEANS-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17025177#comment-17025177 ] Eirik Bakke commented on NETBEANS-3727: --- I think it would be good to make the background color a bit darker, yes. I think the "black hole" screenshot looks good... but if you think it's too intense, we could use a brightness somewhere in between. > Probably a darker color of the desktop background would be good for FlatLaf > --- > > Key: NETBEANS-3727 > URL: https://issues.apache.org/jira/browse/NETBEANS-3727 > Project: NetBeans > Issue Type: Improvement >Reporter: Laszlo Kishalmi >Assignee: Karl Tauber >Priority: Minor > Attachments: image-2020-01-21-16-30-56-282.png, > image-2020-01-23-11-58-16-141.png > > > Well, I'm not entirely convinced that this is an issue at all. > Those rare times when we do not have an editor window open, the IDE might > look strange not having upper/left/right border on the opened tabs. I'd not > put border there, but probably mark the desktop color different (like the > editor default background on FlatLafDark). > [~ebakke] [~DevCharly] what do you think. Of course you are free to drop this > one. > !image-2020-01-21-16-30-56-282.png! > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Assigned] (NETBEANS-3715) Project properties cannot be selected if the taskbar is at the bottom of the screen
[ https://issues.apache.org/jira/browse/NETBEANS-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke reassigned NETBEANS-3715: - Assignee: (was: Eirik Bakke) > Project properties cannot be selected if the taskbar is at the bottom of the > screen > --- > > Key: NETBEANS-3715 > URL: https://issues.apache.org/jira/browse/NETBEANS-3715 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.2 > Environment: RELEASE=19.3 > CODENAME=tricia > EDITION="Cinnamon" > DESCRIPTION="Linux Mint 19.3 Tricia" > DESKTOP=Gnome > TOOLKIT=GTK > NEW_FEATURES_URL=https://www.linuxmint.com/rel_tricia_cinnamon_whatsnew.php > RELEASE_NOTES_URL=https://www.linuxmint.com/rel_tricia_cinnamon.php > USER_GUIDE_URL=https://www.linuxmint.com/documentation.php > GRUB_TITLE=Linux Mint 19.3 Cinnamon >Reporter: Gergely Turi >Priority: Minor > Labels: features > Attachments: Menu_001.jpg, Menu_002.jpg > > > When right-clicking on the project the menu appears but Properties can > neither be selected nor clicked. > The cause of the issue is that the taskbar seems to be somehow "in the way". > If you try to click on Properties it will activate whatever application is > behind it. > But this doesn't occur if the taskbar is moved to either sides (or up). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3715) Project properties cannot be selected if the taskbar is at the bottom of the screen
[ https://issues.apache.org/jira/browse/NETBEANS-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023266#comment-17023266 ] Eirik Bakke commented on NETBEANS-3715: --- Does not happen on Windows or MacOS--it's probably a Linux-specific issue. I don't have a Linux box to try on, unfortunately. Could also be a JDK bug, but determining that would require further experimentation, on Linux. > Project properties cannot be selected if the taskbar is at the bottom of the > screen > --- > > Key: NETBEANS-3715 > URL: https://issues.apache.org/jira/browse/NETBEANS-3715 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.2 > Environment: RELEASE=19.3 > CODENAME=tricia > EDITION="Cinnamon" > DESCRIPTION="Linux Mint 19.3 Tricia" > DESKTOP=Gnome > TOOLKIT=GTK > NEW_FEATURES_URL=https://www.linuxmint.com/rel_tricia_cinnamon_whatsnew.php > RELEASE_NOTES_URL=https://www.linuxmint.com/rel_tricia_cinnamon.php > USER_GUIDE_URL=https://www.linuxmint.com/documentation.php > GRUB_TITLE=Linux Mint 19.3 Cinnamon >Reporter: Gergely Turi >Assignee: Eirik Bakke >Priority: Minor > Labels: features > Attachments: Menu_001.jpg, Menu_002.jpg > > > When right-clicking on the project the menu appears but Properties can > neither be selected nor clicked. > The cause of the issue is that the taskbar seems to be somehow "in the way". > If you try to click on Properties it will activate whatever application is > behind it. > But this doesn't occur if the taskbar is moved to either sides (or up). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-3592) Workarounds for various JDK Windows LAF bugs on HiDPI screens
[ https://issues.apache.org/jira/browse/NETBEANS-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3592: -- Fix Version/s: 11.3 > Workarounds for various JDK Windows LAF bugs on HiDPI screens > - > > Key: NETBEANS-3592 > URL: https://issues.apache.org/jira/browse/NETBEANS-3592 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Affects Versions: 11.1 > Environment: Windows with HiDPI screens >Reporter: Eirik Bakke >Priority: Major > Labels: HiDPI, pull-request-available > Fix For: 11.3 > > Attachments: Problem 1, incorrect font size.png, Problem 2, OS > controls wrong size (after patch).png, Problem 2, OS controls wrong size > (before patch).png, Problem 3, uneven text component borders.png, > WindowsSwingMultiMonitorTest.png > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Provide workarounds to three JDK bugs that caused the Windows LAF to be > unusable on many HiDPI configurations, typically when an external monitor (or > projector) is involved, or is disconnected or connected. > # In certain configurations, the GUI font size would be either way too large > or way too small. (I can't remember exactly which configurations caused this, > but going through the manual test case list below _will_ trigger it several > times.) > # In multi-monitor configurations that involve one HiDPI screen and one > regular screen, the size of controls drawn by the OS, such as checkboxes and > outline expansion handles, will be incorrect unless the HiDPI screen was the > main display at login. I earlier reported this as a JDK bug at > https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few > icons which cannot be fixed using the UIDefaults approach taken here, e.g. > checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously end > up scaling the control images received from the OS using a poor image scaling > interpolation; the supplied patch improves the scaling quality in these cases. > # On non-integral scaling levels, e.g. 150%, borders around text components > will be of uneven thickness due to rounding error. This patch fixes that. > This also happens to JComboBox, but in that case cannot be fixed with a > simple patch, since that one does not take its border from UIDefaults. > I will provide a PR with workarounds. > Below is a manual test plan that I used to test these patches, on Windows 10. > A laptop and one external monitor was used for these tests. After each line > in the test plan, the patch is confirmed to work. In _most_ of these cases > there is some kind of improvement in behavior from the patch--either a > corrected control/font size or at least an improvement in control icon > scaling interpolation quality. > * main display laptop at Windows login (laptop 200%/external 100%) > * change main display to external monitor while running app > * restart app > * change 100% to 150% while running app > * restart app > * log out and in again (of Windows--this makes a difference!) > * change 150% to 100% while running app > * restart app > * main display external monitor at login (laptop 200%/external 100%) > * change main display to laptop while running app > * restart app > * change 100% to 150% while running app > * restart app > * log out and in again > * change 150% to 100% while running app > * restart app > * change 200% to 150% while running app > * restart app > * main display laptop at login (laptop 200%/external 100%), then disconnect > external before running app > * reconnect external while running app > * restart app > * log out, disconnect external, log in > * reconnect external while running app > * restart app > * disconnect external while running app > * main display external monitor at login (laptop 200%/external 100%), then > disconnect external while running app > * reconnect external while running app > * restart app > * log out, disconnect external, log in > * reconnect external while running app > * restart app > * main display laptop at login (laptop 200%/external 150%), then disconnect > external before running > * reconnect external while running app > * log out, disconnect external, log in > * reconnect external while running app > * restart app > * main display external monitor at login (laptop 200%/external 150%), then > disconnect external before running > * reconnect external while running app > * restart app > * log out, disconnect external, log in > * reconnect external while running app > * restart app > * main display external at login (laptop 150%, external 100%) > * change 100% to 150% while running app > * restart app > * change main display to laptop (200%), set external display to 100%,
[jira] [Resolved] (NETBEANS-3592) Workarounds for various JDK Windows LAF bugs on HiDPI screens
[ https://issues.apache.org/jira/browse/NETBEANS-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-3592. --- Resolution: Fixed Pull request was merged; resolving. > Workarounds for various JDK Windows LAF bugs on HiDPI screens > - > > Key: NETBEANS-3592 > URL: https://issues.apache.org/jira/browse/NETBEANS-3592 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Affects Versions: 11.1 > Environment: Windows with HiDPI screens >Reporter: Eirik Bakke >Priority: Major > Labels: HiDPI, pull-request-available > Attachments: Problem 1, incorrect font size.png, Problem 2, OS > controls wrong size (after patch).png, Problem 2, OS controls wrong size > (before patch).png, Problem 3, uneven text component borders.png, > WindowsSwingMultiMonitorTest.png > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Provide workarounds to three JDK bugs that caused the Windows LAF to be > unusable on many HiDPI configurations, typically when an external monitor (or > projector) is involved, or is disconnected or connected. > # In certain configurations, the GUI font size would be either way too large > or way too small. (I can't remember exactly which configurations caused this, > but going through the manual test case list below _will_ trigger it several > times.) > # In multi-monitor configurations that involve one HiDPI screen and one > regular screen, the size of controls drawn by the OS, such as checkboxes and > outline expansion handles, will be incorrect unless the HiDPI screen was the > main display at login. I earlier reported this as a JDK bug at > https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few > icons which cannot be fixed using the UIDefaults approach taken here, e.g. > checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously end > up scaling the control images received from the OS using a poor image scaling > interpolation; the supplied patch improves the scaling quality in these cases. > # On non-integral scaling levels, e.g. 150%, borders around text components > will be of uneven thickness due to rounding error. This patch fixes that. > This also happens to JComboBox, but in that case cannot be fixed with a > simple patch, since that one does not take its border from UIDefaults. > I will provide a PR with workarounds. > Below is a manual test plan that I used to test these patches, on Windows 10. > A laptop and one external monitor was used for these tests. After each line > in the test plan, the patch is confirmed to work. In _most_ of these cases > there is some kind of improvement in behavior from the patch--either a > corrected control/font size or at least an improvement in control icon > scaling interpolation quality. > * main display laptop at Windows login (laptop 200%/external 100%) > * change main display to external monitor while running app > * restart app > * change 100% to 150% while running app > * restart app > * log out and in again (of Windows--this makes a difference!) > * change 150% to 100% while running app > * restart app > * main display external monitor at login (laptop 200%/external 100%) > * change main display to laptop while running app > * restart app > * change 100% to 150% while running app > * restart app > * log out and in again > * change 150% to 100% while running app > * restart app > * change 200% to 150% while running app > * restart app > * main display laptop at login (laptop 200%/external 100%), then disconnect > external before running app > * reconnect external while running app > * restart app > * log out, disconnect external, log in > * reconnect external while running app > * restart app > * disconnect external while running app > * main display external monitor at login (laptop 200%/external 100%), then > disconnect external while running app > * reconnect external while running app > * restart app > * log out, disconnect external, log in > * reconnect external while running app > * restart app > * main display laptop at login (laptop 200%/external 150%), then disconnect > external before running > * reconnect external while running app > * log out, disconnect external, log in > * reconnect external while running app > * restart app > * main display external monitor at login (laptop 200%/external 150%), then > disconnect external before running > * reconnect external while running app > * restart app > * log out, disconnect external, log in > * reconnect external while running app > * restart app > * main display external at login (laptop 150%, external 100%) > * change 100% to 150% while running app > * restart app > * change main display to laptop (200%), set external display to
[jira] [Resolved] (NETBEANS-2546) NetBeans bugzilla may be lost
[ https://issues.apache.org/jira/browse/NETBEANS-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-2546. --- Resolution: Fixed It seems someone migrated the old NetBeans BugZilla to Apache infrastructure already, e.g. https://bz.apache.org/netbeans/show_bug.cgi?id=221781 . Closing this issue. > NetBeans bugzilla may be lost > - > > Key: NETBEANS-2546 > URL: https://issues.apache.org/jira/browse/NETBEANS-2546 > Project: NetBeans > Issue Type: Bug > Components: third-party - Other >Reporter: Antonio Vieiro >Priority: Major > > The current [https://bugzilla.netbeans.org|https://bugzilla.netbeans.org/] > redirects to [https://netbeans.org/bugzilla/query.cgi] , this will be lost if > we reroute [https://netbeans.org|https://netbeans.org/] to > [https://netbeans.apache.org|https://netbeans.apache.org/] > Suggested possible actions: > * Migrate bugzilla content to Apache. > * Assume we'll be losing bugzilla.netbeans.org > * Create a read-only backup of bugzilla.netbeans.org contents. > * Try to see if we can still perform the redirection while the Oracle server > exists. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3468) Make HiDPI (Retina) icons work in MacOS menu bar
[ https://issues.apache.org/jira/browse/NETBEANS-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013573#comment-17013573 ] Eirik Bakke commented on NETBEANS-3468: --- I did some experiments with this. For retina icons to work in the main menu bar on Aqua/MacOS, the icon must be an ImageIcon based on a MultiResolutionImage. Any MultiResolutionImage implementation will do; it does not have to be an instance of BaseMultiResolutionImage. The main challenge is that MultiResolutionImage did not get introduced as a public API until Java 9 (prior to which it was located in sun.awt.image.MultiResolutionImage), and the NetBeans build system requires NetBeans sources to compile on Java 8. That could be solved with some reflection magic. > Make HiDPI (Retina) icons work in MacOS menu bar > > > Key: NETBEANS-3468 > URL: https://issues.apache.org/jira/browse/NETBEANS-3468 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Affects Versions: 11.3 > Environment: MacOS with retina display >Reporter: Eirik Bakke >Priority: Minor > Labels: HiDPI > Attachments: menuicon_retina.png > > > HiDPI icons, introduced in NETBEANS-2614 and NETBEANS-2604, do not yet show > up in the correct resolution when used in the menu bar on MacOS. See the > attached screenshot (from a NetBeans Platform application). This should be > fixed. > Note that we have only so far introduced HiDPI icons for the "Undo" and > "Redo" actions. > Emilian Bold probably figured this out in his earlier experimental Retina > support branch; see RetinaMultiResolutionImage in > https://github.com/emilianbold/nextbeans/commit/0f99dba0c1b3e8e0bc4e7cec407b53d30e85ead1 > . If the solution involves implementing MultiResolutionImage, then make sure > not to do this on Windows (to avoid > https://bugs.openjdk.java.net/browse/JDK-8212226 ). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Resolved] (NETBEANS-2954) Tabs dragging errors on scaled Windows desktop
[ https://issues.apache.org/jira/browse/NETBEANS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-2954. --- Fix Version/s: Next Resolution: Fixed > Tabs dragging errors on scaled Windows desktop > -- > > Key: NETBEANS-2954 > URL: https://issues.apache.org/jira/browse/NETBEANS-2954 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Affects Versions: 11.0, 11.1 > Environment: Windows 10, desktop scale 125% >Reporter: Eugene Pliskin >Priority: Minor > Labels: HiDPI, pull-request-available > Fix For: Next > > Time Spent: 1h > Remaining Estimate: 0h > > On Windows 10 having desktop scaled to 125% I experience difficulties > dragging tabs of two or more opened source files in NetBeans editor. Often > cannot move the second source tab before the first tab. It looks like the > dragged red tab outlines are not aligned with actual tabs widths. At 100% > desktop scale the problem is not experienced. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-378) Font size and splash panel on a high-DPI display on Windows 10.
[ https://issues.apache.org/jira/browse/NETBEANS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004392#comment-17004392 ] Eirik Bakke commented on NETBEANS-378: -- Also added the Illustrator and SVG file versions of the Apache NetBeans logo with the product name included. These were slightly touched-up versions of a file made by David .Schulz. (The touchups were to ensure the edges in the logo were perfectly aligned, preventing rendering artifacts at certain zoom levels.) > Font size and splash panel on a high-DPI display on Windows 10. > --- > > Key: NETBEANS-378 > URL: https://issues.apache.org/jira/browse/NETBEANS-378 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Reporter: Giulio D'Ambrosi >Priority: Major > Labels: HiDPI, pull-request-available > Fix For: 11.1 > > Attachments: Apache NetBeans Logo with Product Name.ai, Apache > NetBeans Logo with Product Name.svg, Installer.PNG, NetBeans HiDPI Splash > Screen Template.ai, Screenshot_Idea.png, Screenshot_Netbeans.png, > Screenshot_Netbeans_Fontsize24.png, keymap.PNG, plugins.PNG, tab.PNG > > Time Spent: 3h 10m > Remaining Estimate: 0h > > I started using NetBeans with the 4K resolution and i cannot see anything > because everything on that JFrame becomes too small and I won't be able to > read anything. > See attached images -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-378) Font size and splash panel on a high-DPI display on Windows 10.
[ https://issues.apache.org/jira/browse/NETBEANS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-378: - Attachment: Apache NetBeans Logo with Product Name.svg Apache NetBeans Logo with Product Name.ai > Font size and splash panel on a high-DPI display on Windows 10. > --- > > Key: NETBEANS-378 > URL: https://issues.apache.org/jira/browse/NETBEANS-378 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Reporter: Giulio D'Ambrosi >Priority: Major > Labels: HiDPI, pull-request-available > Fix For: 11.1 > > Attachments: Apache NetBeans Logo with Product Name.ai, Apache > NetBeans Logo with Product Name.svg, Installer.PNG, NetBeans HiDPI Splash > Screen Template.ai, Screenshot_Idea.png, Screenshot_Netbeans.png, > Screenshot_Netbeans_Fontsize24.png, keymap.PNG, plugins.PNG, tab.PNG > > Time Spent: 3h 10m > Remaining Estimate: 0h > > I started using NetBeans with the 4K resolution and i cannot see anything > because everything on that JFrame becomes too small and I won't be able to > read anything. > See attached images -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-378) Font size and splash panel on a high-DPI display on Windows 10.
[ https://issues.apache.org/jira/browse/NETBEANS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004389#comment-17004389 ] Eirik Bakke commented on NETBEANS-378: -- For future reference, I added the Adobe Illustrator file that was used to generate the current splash screen graphics. > Font size and splash panel on a high-DPI display on Windows 10. > --- > > Key: NETBEANS-378 > URL: https://issues.apache.org/jira/browse/NETBEANS-378 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Reporter: Giulio D'Ambrosi >Priority: Major > Labels: HiDPI, pull-request-available > Fix For: 11.1 > > Attachments: Installer.PNG, NetBeans HiDPI Splash Screen Template.ai, > Screenshot_Idea.png, Screenshot_Netbeans.png, > Screenshot_Netbeans_Fontsize24.png, keymap.PNG, plugins.PNG, tab.PNG > > Time Spent: 3h 10m > Remaining Estimate: 0h > > I started using NetBeans with the 4K resolution and i cannot see anything > because everything on that JFrame becomes too small and I won't be able to > read anything. > See attached images -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-378) Font size and splash panel on a high-DPI display on Windows 10.
[ https://issues.apache.org/jira/browse/NETBEANS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-378: - Attachment: NetBeans HiDPI Splash Screen Template.ai > Font size and splash panel on a high-DPI display on Windows 10. > --- > > Key: NETBEANS-378 > URL: https://issues.apache.org/jira/browse/NETBEANS-378 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Reporter: Giulio D'Ambrosi >Priority: Major > Labels: HiDPI, pull-request-available > Fix For: 11.1 > > Attachments: Installer.PNG, NetBeans HiDPI Splash Screen Template.ai, > Screenshot_Idea.png, Screenshot_Netbeans.png, > Screenshot_Netbeans_Fontsize24.png, keymap.PNG, plugins.PNG, tab.PNG > > Time Spent: 3h 10m > Remaining Estimate: 0h > > I started using NetBeans with the 4K resolution and i cannot see anything > because everything on that JFrame becomes too small and I won't be able to > read anything. > See attached images -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-2954) Tabs dragging errors on scaled Windows desktop
[ https://issues.apache.org/jira/browse/NETBEANS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17001838#comment-17001838 ] Eirik Bakke commented on NETBEANS-2954: --- I figured out how to fix this one; see details in the linked Pull Request. > Tabs dragging errors on scaled Windows desktop > -- > > Key: NETBEANS-2954 > URL: https://issues.apache.org/jira/browse/NETBEANS-2954 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Affects Versions: 11.0, 11.1 > Environment: Windows 10, desktop scale 125% >Reporter: Eugene Pliskin >Priority: Minor > Labels: HiDPI, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > On Windows 10 having desktop scaled to 125% I experience difficulties > dragging tabs of two or more opened source files in NetBeans editor. Often > cannot move the second source tab before the first tab. It looks like the > dragged red tab outlines are not aligned with actual tabs widths. At 100% > desktop scale the problem is not experienced. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-3592) Workarounds for various JDK Windows LAF bugs on HiDPI screens
[ https://issues.apache.org/jira/browse/NETBEANS-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3592: -- Description: Provide workarounds to three JDK bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. # In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) # In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach taken here, e.g. checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously end up scaling the control images received from the OS using a poor image scaling interpolation; the supplied patch improves the scaling quality in these cases. # On non-integral scaling levels, e.g. 150%, borders around text components will be of uneven thickness due to rounding error. This patch fixes that. This also happens to JComboBox, but in that case cannot be fixed with a simple patch, since that one does not take its border from UIDefaults. I will provide a PR with workarounds. Below is a manual test plan that I used to test these patches, on Windows 10. A laptop and one external monitor was used for these tests. After each line in the test plan, the patch is confirmed to work. In _most_ of these cases there is some kind of improvement in behavior from the patch--either a corrected control/font size or at least an improvement in control icon scaling interpolation quality. * main display laptop at Windows login (laptop 200%/external 100%) * change main display to external monitor while running app * restart app * change 100% to 150% while running app * restart app * log out and in again (of Windows--this makes a difference!) * change 150% to 100% while running app * restart app * main display external monitor at login (laptop 200%/external 100%) * change main display to laptop while running app * restart app * change 100% to 150% while running app * restart app * log out and in again * change 150% to 100% while running app * restart app * change 200% to 150% while running app * restart app * main display laptop at login (laptop 200%/external 100%), then disconnect external before running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * disconnect external while running app * main display external monitor at login (laptop 200%/external 100%), then disconnect external while running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display laptop at login (laptop 200%/external 150%), then disconnect external before running * reconnect external while running app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external monitor at login (laptop 200%/external 150%), then disconnect external before running * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external at login (laptop 150%, external 100%) * change 100% to 150% while running app * restart app * change main display to laptop (200%), set external display to 100%, log out, disconnect external, log in, run app * reconnect external while running app (will be 100%) * close laptop lid (will switch to external display) was: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach
[jira] [Updated] (NETBEANS-3592) Workarounds for various JDK Windows LAF bugs on HiDPI screens
[ https://issues.apache.org/jira/browse/NETBEANS-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3592: -- Summary: Workarounds for various JDK Windows LAF bugs on HiDPI screens (was: Fix various Windows LAF bugs on HiDPI screens) > Workarounds for various JDK Windows LAF bugs on HiDPI screens > - > > Key: NETBEANS-3592 > URL: https://issues.apache.org/jira/browse/NETBEANS-3592 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Affects Versions: 11.1 > Environment: Windows with HiDPI screens >Reporter: Eirik Bakke >Priority: Major > Labels: HiDPI, pull-request-available > Attachments: Problem 1, incorrect font size.png, Problem 2, OS > controls wrong size (after patch).png, Problem 2, OS controls wrong size > (before patch).png, Problem 3, uneven text component borders.png, > WindowsSwingMultiMonitorTest.png > > Time Spent: 2h > Remaining Estimate: 0h > > Provide workarounds to various bugs that caused the Windows LAF to be > unusable on many HiDPI configurations, typically when an external monitor (or > projector) is involved, or is disconnected or connected. > 1) In certain configurations, the GUI font size would be either way too large > or way too small. (I can't remember exactly which configurations caused this, > but going through the manual test case list below _will_ trigger it several > times.) > 2) In multi-monitor configurations that involve one HiDPI screen and one > regular screen, the size of controls drawn by the OS, such as checkboxes and > outline expansion handles, will be incorrect unless the HiDPI screen was the > main display at login. I earlier reported this as a JDK bug at > https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few > icons which cannot be fixed using the UIDefaults approach taken here, e.g. > checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously end > up scaling the control images received from the OS using a poor image scaling > interpolation; the supplied patch improves the scaling quality in these cases. > 3) On non-integral scaling levels, e.g. 150%, borders around text components > will be of uneven thickness due to rounding error. This patch fixes that. > This also happens to JComboBox, but in that case cannot be fixed with a > simple patch, since that one does not take its border from UIDefaults. > I will provide a PR with workarounds. > Below is a manual test plan that I used to test these patches, on Windows 10. > A laptop and one external monitor was used for these tests. After each line > in the test plan, the patch is confirmed to work. In _most_ of these cases > there is some kind of improvement in behavior from the patch--either a > corrected control/font size or at least an improvement in control icon > scaling interpolation quality. > * main display laptop at Windows login (laptop 200%/external 100%) > * change main display to external monitor while running app > * restart app > * change 100% to 150% while running app > * restart app > * log out and in again (of Windows--this makes a difference!) > * change 150% to 100% while running app > * restart app > * main display external monitor at login (laptop 200%/external 100%) > * change main display to laptop while running app > * restart app > * change 100% to 150% while running app > * restart app > * log out and in again > * change 150% to 100% while running app > * restart app > * change 200% to 150% while running app > * restart app > * main display laptop at login (laptop 200%/external 100%), then disconnect > external before running app > * reconnect external while running app > * restart app > * log out, disconnect external, log in > * reconnect external while running app > * restart app > * disconnect external while running app > * main display external monitor at login (laptop 200%/external 100%), then > disconnect external while running app > * reconnect external while running app > * restart app > * log out, disconnect external, log in > * reconnect external while running app > * restart app > * main display laptop at login (laptop 200%/external 150%), then disconnect > external before running > * reconnect external while running app > * log out, disconnect external, log in > * reconnect external while running app > * restart app > * main display external monitor at login (laptop 200%/external 150%), then > disconnect external before running > * reconnect external while running app > * restart app > * log out, disconnect external, log in > * reconnect external while running app > * restart app > * main display external at login (laptop 150%, external 100%) > * change 100% to 150% while running app > * restart app
[jira] [Updated] (NETBEANS-3592) Fix various Windows LAF bugs on HiDPI screens
[ https://issues.apache.org/jira/browse/NETBEANS-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3592: -- Description: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach taken here, e.g. checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously end up scaling the control images received from the OS using a poor image scaling interpolation; the supplied patch improves the scaling quality in these cases. 3) On non-integral scaling levels, e.g. 150%, borders around text components will be of uneven thickness due to rounding error. This patch fixes that. This also happens to JComboBox, but in that case cannot be fixed with a simple patch, since that one does not take its border from UIDefaults. I will provide a PR with workarounds. Below is a manual test plan that I used to test these patches, on Windows 10. A laptop and one external monitor was used for these tests. After each line in the test plan, the patch is confirmed to work. In _most_ of these cases there is some kind of improvement in behavior from the patch--either a corrected control/font size or at least an improvement in control icon scaling interpolation quality. * main display laptop at Windows login (laptop 200%/external 100%) * change main display to external monitor while running app * restart app * change 100% to 150% while running app * restart app * log out and in again (of Windows--this makes a difference!) * change 150% to 100% while running app * restart app * main display external monitor at login (laptop 200%/external 100%) * change main display to laptop while running app * restart app * change 100% to 150% while running app * restart app * log out and in again * change 150% to 100% while running app * restart app * change 200% to 150% while running app * restart app * main display laptop at login (laptop 200%/external 100%), then disconnect external before running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * disconnect external while running app * main display external monitor at login (laptop 200%/external 100%), then disconnect external while running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display laptop at login (laptop 200%/external 150%), then disconnect external before running * reconnect external while running app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external monitor at login (laptop 200%/external 150%), then disconnect external before running * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external at login (laptop 150%, external 100%) * change 100% to 150% while running app * restart app * change main display to laptop (200%), set external display to 100%, log out, disconnect external, log in, run app * reconnect external while running app (will be 100%) * close laptop lid (will switch to external display) was: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach
[jira] [Updated] (NETBEANS-3592) Fix various Windows LAF bugs on HiDPI screens
[ https://issues.apache.org/jira/browse/NETBEANS-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3592: -- Description: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach taken here, e.g. checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously end up scaling the control images received from the OS using a poor image scaling interpolation; the supplied patch improves the scaling quality in these cases. 3) On non-integral scaling levels, e.g. 150%, borders around text components will be of uneven thickness due to rounding error. This patch fixes that. This also happens to JComboBox, but in that case cannot be fixed with a simple patch, since that one does not take its border from UIDefaults. I will provide a PR with workarounds. Below is a manual test plan that I used to test these patches, on Windows 10. A laptop and one external monitor was used for these tests. After each line in the test plan, the patch is confirmed to work. In _most_ of these cases there is some kind of improvement in behavior from the patch--either a corrected control/font size or at least an improvement in control icon scaling interpolation quality. * main display laptop at sign-in (laptop 200%/external 100%) * change main display to external monitor while running app * restart app * change 100% to 150% while running app * restart app * log out and in again (of Windows--this makes a difference!) * change 150% to 100% while running app * restart app * main display external monitor at sign-in (laptop 200%/external 100%) * change main display to laptop while running app * restart app * change 100% to 150% while running app * restart app * log out and in again * change 150% to 100% while running app * restart app * change 200% to 150% while running app * restart app * main display laptop at sign-in (laptop 200%/external 100%), then disconnect external before running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * disconnect external while running app * main display external monitor at sign-in (laptop 200%/external 100%), then disconnect external while running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display laptop at sign-in (laptop 200%/external 150%), then disconnect external before running * reconnect external while running app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external monitor at sign-in (laptop 200%/external 150%), then disconnect external before running * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external at sign-in (laptop 150%, external 100%) * change 100% to 150% while running app * restart app * change main display to laptop (200%), set external display to 100%, log out, disconnect external, log in, run app * reconnect external while running app (will be 100%) * close laptop lid (will switch to external display) was: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults
[jira] [Updated] (NETBEANS-3592) Fix various Windows LAF bugs on HiDPI screens
[ https://issues.apache.org/jira/browse/NETBEANS-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3592: -- Description: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach taken here, e.g. checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously end up scaling the control images received from the OS using a poor image scaling interpolation; the supplied patch improves the scaling quality in these cases. 3) On non-integral scaling levels, e.g. 150%, borders around text components will be of uneven thickness due to rounding error. This patch fixes that. This also happens to JComboBox, but in that case cannot be fixed with a simple patch, since that one does not take its border from UIDefaults. I will provide a PR with workarounds. Below is a manual test plan that I used to test these patches, on Windows 10. A laptop and one external monitor was used for these tests. After each line in the test plan, the patch is confirmed to work. In _most_ of these cases there is some kind of improvement in behavior from the patch--either a corrected control/font size or at least an improvement in control icon scaling interpolation quality. * main display laptop at sign-in (laptop 200%/external 100%) * change main display to external monitor while running app * restart app * change 100% to 150% while running app * restart app * log out and in again * change 150% to 100% while running app * restart app * main display external monitor at sign-in (laptop 200%/external 100%) * change main display to laptop while running app * restart app * change 100% to 150% while running app * restart app * log out and in again * change 150% to 100% while running app * restart app * change 200% to 150% while running app * restart app * main display laptop at sign-in (laptop 200%/external 100%), then disconnect external before running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * disconnect external while running app * main display external monitor at sign-in (laptop 200%/external 100%), then disconnect external while running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display laptop at sign-in (laptop 200%/external 150%), then disconnect external before running * reconnect external while running app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external monitor at sign-in (laptop 200%/external 150%), then disconnect external before running * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external at sign-in (laptop 150%, external 100%) * change 100% to 150% while running app * restart app * change main display to laptop (200%), set external display to 100%, log out, disconnect external, log in, run app * reconnect external while running app (will be 100%) * close laptop lid (will switch to external display) was: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach taken here, e.g. checkmarks in
[jira] [Updated] (NETBEANS-3592) Fix various Windows LAF bugs on HiDPI screens
[ https://issues.apache.org/jira/browse/NETBEANS-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3592: -- Description: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach taken here, e.g. checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously end up scaling the control images received from the OS using a poor image scaling interpolation; the supplied patch improves the scaling quality in these cases. 3) On non-integral scaling levels, e.g. 150%, borders around text components will be of uneven thickness due to rounding error. This patch fixes that. This also happens to JComboBox, but in that case cannot be fixed with a simple patch, since that one does not take its border from UIDefaults. I will provide a PR with workarounds. Below is a manual test plan that I used to test these patches, on Windows 10. After each line in the test plan, the patch is confirmed to work. In _most_ of these cases there is some kind of improvement in behavior from the patch--either a corrected control/font size or at least an improvement in control icon scaling interpolation quality. * main display laptop at sign-in (laptop 200%/external 100%) * change main display to external monitor while running app * restart app * change 100% to 150% while running app * restart app * log out and in again * change 150% to 100% while running app * restart app * main display external monitor at sign-in (laptop 200%/external 100%) * change main display to laptop while running app * restart app * change 100% to 150% while running app * restart app * log out and in again * change 150% to 100% while running app * restart app * change 200% to 150% while running app * restart app * main display laptop at sign-in (laptop 200%/external 100%), then disconnect external before running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * disconnect external while running app * main display external monitor at sign-in (laptop 200%/external 100%), then disconnect external while running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display laptop at sign-in (laptop 200%/external 150%), then disconnect external before running * reconnect external while running app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external monitor at sign-in (laptop 200%/external 150%), then disconnect external before running * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external at sign-in (laptop 150%, external 100%) * change 100% to 150% while running app * restart app * change main display to laptop (200%), set external display to 100%, log out, disconnect external, log in, run app * reconnect external while running app (will be 100%) * close laptop lid (will switch to external display) was: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach taken here, e.g. checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously
[jira] [Updated] (NETBEANS-3592) Fix various Windows LAF bugs on HiDPI screens
[ https://issues.apache.org/jira/browse/NETBEANS-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3592: -- Description: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach taken here, e.g. checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously end up scaling the control images received from the OS using a poor image scaling interpolation; the supplied patch improves the scaling quality in these cases. 3) On non-integral scaling levels, e.g. 150%, borders around text components will be of uneven thickness due to rounding error. This patch fixes that. This also happens to JComboBox, but in that case cannot be fixed with a simple patch, since that one does not take its border from UIDefaults. I will provide a PR with workarounds. Below is a manual test plan that I used to test these patches, on Windows 10. After each line in the test plan, the patch is confirmed to work. In _most_ of these cases there is some kind of improvement in behavior from the patch--either a corrected control/font size or at least an improvement in control icon scaling interpolation quality. * main display laptop at sign-in (laptop 200%/external 100%) * change main display to external monitor while running app * restart app * change 100% to 150% while running app * restart app * log out and in again * change 150% to 100% while running app * restart app * main display external monitor at sign-in (laptop 200%/external 100%) * change main display to laptop while running app * restart app * change 100% to 150% while running app * restart app * log out and in again * change 150% to 100% while running app * restart app * change 200% to 150% while running app * restart app * main display laptop at sign-in (laptop 200%/external 100%), then disconnect external before running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * disconnect external while running app * main display external monitor at sign-in (laptop 200%/external 100%), then disconnect external while running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display laptop at sign-in (laptop 200%/external 150%), then disconnect external before running * reconnect external while running app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external monitor at sign-in (laptop 200%/external 150%), then disconnect external before running * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external at sign-in (laptop 150%, external 100%) * change 100% to 150% while running app * restart app * change main display to laptop (200%), set external display to 100%, log out, disconnect external, log in, run app * reconnect external while running app (will be 100%) * close laptop lid (will switch to external display) * was: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach taken here, e.g. checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously
[jira] [Updated] (NETBEANS-3592) Fix various Windows LAF bugs on HiDPI screens
[ https://issues.apache.org/jira/browse/NETBEANS-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3592: -- Description: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach taken here, e.g. checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously end up scaling the control images received from the OS using a poor image scaling interpolation; the supplied patch improves the scaling quality in these cases. 3) On non-integral scaling levels, e.g. 150%, borders around text components will be of uneven thickness due to rounding error. This patch fixes that. This also happens to JComboBox, but in that case cannot be fixed with a simple patch, since that one does not take its border from UIDefaults. I will provide a PR with workarounds. Below is a manual test plan that I used to test these patches, on Windows 10. After each line in the test plan, the patch is confirmed to work. In _most_ of these cases there is some kind of improvement in behavior from the patch--either a corrected control/font size or at least an improvement in control icon scaling interpolation quality. * main display laptop at sign-in (external at 200% HiDPI scaling/main at 100%) * change main display to external monitor while running app * restart app * change 100% to 150% while running app * restart app * log out and in again * change 150% to 100% while running app * restart app * main display external monitor at sign-in (external 200%/main 100%) * change main display to laptop while running app * restart app * change 100% to 150% while running app * restart app * log out and in again * change 150% to 100% while running app * restart app * change 200% to 150% while running app * restart app * main display laptop at sign-in (external 200%/main 100%), then disconnect external before running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * disconnect external while running app * main display external monitor at sign-in (200%/100%), then disconnect external while running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display laptop at sign-in (200%/150%), then disconnect external before running * reconnect external while running app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external monitor at sign-in (200%/150%), then disconnect external before running * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external at sign-in (external 150%, main 100%) * change 100% to 150% while running app * restart app * change main display to laptop (200%), set external display to 100%, log out, disconnect external, log in, run app * reconnect external while running app (will be 100%) * close laptop lid (will switch to external display) was: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach taken here, e.g. checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously end up scaling the control images
[jira] [Updated] (NETBEANS-3593) Make web browser icon in the toolbar take advantage of improved HiDPI scaling
[ https://issues.apache.org/jira/browse/NETBEANS-3593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3593: -- Attachment: browsericon.png > Make web browser icon in the toolbar take advantage of improved HiDPI scaling > - > > Key: NETBEANS-3593 > URL: https://issues.apache.org/jira/browse/NETBEANS-3593 > Project: NetBeans > Issue Type: Improvement >Affects Versions: 11.1 >Reporter: Eirik Bakke >Priority: Minor > Labels: HiDPI > Attachments: browsericon.png > > > This PR ensures that the HiDPI icon scaling improvements made in > NETBEANS-2614 applies to the browser icon in the toolbar. (Created a separate > PR for this one because it requires one API change to expose the > DropDownButton icon.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Created] (NETBEANS-3593) Make web browser icon in the toolbar take advantage of improved HiDPI scaling
Eirik Bakke created NETBEANS-3593: - Summary: Make web browser icon in the toolbar take advantage of improved HiDPI scaling Key: NETBEANS-3593 URL: https://issues.apache.org/jira/browse/NETBEANS-3593 Project: NetBeans Issue Type: Improvement Affects Versions: 11.1 Reporter: Eirik Bakke This PR ensures that the HiDPI icon scaling improvements made in NETBEANS-2614 applies to the browser icon in the toolbar. (Created a separate PR for this one because it requires one API change to expose the DropDownButton icon.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-3196) Calling Children.LEAF.getNodesCount() changes lazy loading behavior globally
[
https://issues.apache.org/jira/browse/NETBEANS-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-3196:
--
Description:
There's a small bug in org.openide.nodes.Node.setChildren(Children). The logic
goes something like this:
{code:java}
protected final void setChildren(final Children ch) {
boolean wasInited = hierarchy.isInitialized();
boolean wasLeaf = hierarchy == Children.LEAF;
// ...
hierarchy = ch;
// ...
if (wasInited && hierarchy != Children.LEAF) {
// init new children if old was inited
hierarchy.getNodesCount();
{code}
If a Node's children was originally Children.LEAF, and is then changed to a
different instance, the resulting behavior now becomes dependent on the result
of Children.LEAF.isInitialized(). The latter is a global piece of state which
may return false for a long time until _any_ module anywhere in the IDE or in a
platform application calls Children.LEAF.getNodesCount(), after which
Children.LEAF.isInitialized() will forever after return true.
Once Children.LEAF.getNodesCount() has been called, from any module, Node
implementations that switch from Children.LEAF to another Children
implementation will no longer get lazy loading behavior.
The fix is simple; the condition should be "wasInited && !wasLeaf && hierarchy
!= Children.LEAF)".
It might be good to ensure that Children.LEAF is always initialized as well, to
prevent accidentally sharing mutable global state. (Actually, I tried calling
Children.LEAF.getNodesCount() on LEAF's initial construction, but this caused a
failure on startup. So don't bother.)
(This bug was found in a NetBeans Platform application that relies heavily on
lazy loading of nodes.)
was:
There's a small bug in org.openide.nodes.Node.setChildren(Children). The logic
goes something like this:
{code:java}
protected final void setChildren(final Children ch) {
boolean wasInited = hierarchy.isInitialized();
boolean wasLeaf = hierarchy == Children.LEAF;
// ...
hierarchy = ch;
// ...
if (wasInited && hierarchy != Children.LEAF) {
// init new children if old was inited
hierarchy.getNodesCount();
{code}
If a Node's children was originally Children.LEAF, and is then changed to a
different instance, the resulting behavior now becomes dependent on the result
of Children.LEAF.isInitialized(). The latter is a global piece of state which
may return false for a long time until _any_ module anywhere in the IDE or in a
platform application calls Children.LEAF.getNodesCount(), after which
Children.LEAF.isInitialized() will forever after return true.
Once Children.LEAF.getNodesCount() has been called, from any module, Node
implementations that switch from Children.LEAF to another Children
implementation will no longer get lazy loading behavior.
The fix is simple; the condition should be "wasInited && !wasLeaf && hierarchy
!= Children.LEAF)". It might be good to ensure that Children.LEAF is always
initialized as well, to prevent accidentally sharing mutable global state. I
will create a patch for this at some point, once I have made sure it doesn't
cause any problems.
(This bug was found in a NetBeans Platform application that relies heavily on
lazy loading of nodes.)
> Calling Children.LEAF.getNodesCount() changes lazy loading behavior globally
>
>
> Key: NETBEANS-3196
> URL: https://issues.apache.org/jira/browse/NETBEANS-3196
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Nodes
>Affects Versions: 11.0
>Reporter: Eirik Bakke
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There's a small bug in org.openide.nodes.Node.setChildren(Children). The
> logic goes something like this:
> {code:java}
> protected final void setChildren(final Children ch) {
> boolean wasInited = hierarchy.isInitialized();
> boolean wasLeaf = hierarchy == Children.LEAF;
> // ...
> hierarchy = ch;
> // ...
> if (wasInited && hierarchy != Children.LEAF) {
> // init new children if old was inited
> hierarchy.getNodesCount();
> {code}
> If a Node's children was originally Children.LEAF, and is then changed to a
> different instance, the resulting behavior now becomes dependent on the
> result of Children.LEAF.isInitialized(). The latter is a global piece of
> state which may return false for a long time until _any_ module anywhere in
> the IDE or in a platform application calls Children.LEAF.getNodesCount(),
> after which Children.LEAF.isInitialized() will forever after return true.
> Once Children.LEAF.getNodesCount() has been called, from any module, Node
> implementations that switch from Children.LEAF to another Children
>
[jira] [Commented] (NETBEANS-338) Find/Replace dialog does not render correctly
[ https://issues.apache.org/jira/browse/NETBEANS-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16995885#comment-16995885 ] Eirik Bakke commented on NETBEANS-338: -- Added a PR at https://github.com/apache/netbeans/pull/1777 . The problem is in the JDK-supplied Windows LAF, though we can make a few improvements by inserting workarounds in UIDefaults. > Find/Replace dialog does not render correctly > - > > Key: NETBEANS-338 > URL: https://issues.apache.org/jira/browse/NETBEANS-338 > Project: NetBeans > Issue Type: Bug > Components: editor - Search >Affects Versions: 9.0, 10.0 > Environment: Product Version: Apache NetBeans IDE Dev (Build > 20180117-unknown-revn) > Java: 9.0.4; Java HotSpot(TM) 64-Bit Server VM 9.0.4+11 > Runtime: Java(TM) SE Runtime Environment 9.0.4+11 > System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb) > User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev > Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev >Reporter: Gili >Assignee: Eirik Bakke >Priority: Trivial > Labels: HiDPI, Java9, Windows, regression > Attachments: screenshot.png > > > In the attached screenshot, notice that the horizontal separator between the > two combo-boxes is cut off. Expanding the combo-box causes the line to > render, but once it is collapsed again the line disappears. This used to work > in Netbeans 8.2 (though this was with JDK 8 while now I am using JDK 9) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-3592) Fix various Windows LAF bugs on HiDPI screens
[ https://issues.apache.org/jira/browse/NETBEANS-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-3592: -- Description: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. I earlier reported this as a JDK bug at https://bugs.openjdk.java.net/browse/JDK-8211715 . (Note that there are a few icons which cannot be fixed using the UIDefaults approach taken here, e.g. checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously end up scaling the control images received from the OS using a poor image scaling interpolation; the supplied patch improves the scaling quality in these cases. 3) On non-integral scaling levels, e.g. 150%, borders around text components will be of uneven thickness due to rounding error. This patch fixes that. This also happens to JComboBox, but in that case cannot be fixed with a simple patch, since that one does not take its border from UIDefaults. I will provide a PR with workarounds. Below is a manual test plan that I used to test these patches, on Windows 10. After each line in the test plan, the patch is confirmed to work. In _most_ of these cases there is some kind of improvement in behavior from the patch--either a corrected control/font size or at least an improvement in control icon scaling interpolation quality. * main display laptop at sign-in (external at 200% HiDPI scaling/main at 100%) * change main display to external monitor while running app * restart app * change 100% to 150% while running app * restart app * log out and in again * change 150% to 100% while running app * restart app * main display external monitor at sign-in (external 200%/main 100%) * change main display to laptop while running app * restart app * change 100% to 150% while running app * restart app * log out and in again * change 150% to 100% while running app * restart app * change 200% to 150% while running app * restart app * main display laptop at sign-in (external 200%/main 100%), then disconnect external before running app * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * disconnect external while running app * main display external monitor at sign-in (200%/100%), then disconnect external while running app (forgot an initial step here; initial data pasted in from step 9) * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display laptop at sign-in (200%/150%), then disconnect external before running * reconnect external while running app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external monitor at sign-in (200%/150%), then disconnect external before running * reconnect external while running app * restart app * log out, disconnect external, log in * reconnect external while running app * restart app * main display external at sign-in (external 150%, main 100%) * change 100% to 150% while running app * restart app * change main display to laptop (200%), set external display to 100%, log out, disconnect external, log in, run app * reconnect external while running app (will be 100%) * close laptop lid (will switch to external display) was: Provide workarounds to various bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. 1) In certain configurations, the GUI font size would be either way too large or way too small. (I can't remember exactly which configurations caused this, but going through the manual test case list below _will_ trigger it several times.) 2) In multi-monitor configurations that involve one HiDPI screen and one regular screen, the size of controls drawn by the OS, such as checkboxes and outline expansion handles, will be incorrect unless the HiDPI screen was the main display at login. (Note that there are a few icons which cannot be fixed using the UIDefaults approach taken here, e.g. checkmarks in JCheckBoxMenuItem.) In some cases, the LAF would previously end up scaling the control images received from the OS using a
