[jira] [Created] (NETBEANS-403) Pressing Home/End scrolls to beginning/end of whole document if tooltip is open
Eirik Bakke created NETBEANS-403: Summary: Pressing Home/End scrolls to beginning/end of whole document if tooltip is open Key: NETBEANS-403 URL: https://issues.apache.org/jira/browse/NETBEANS-403 Project: NetBeans Issue Type: Bug Components: editor - Key bindings Affects Versions: 8.2, 9.0 Reporter: Eirik Bakke Attachments: HomeEndBug.png When a tooltip is shown in the Java editor, for instance because the mouse is hovering over an error indication, pressing the Home or End keys on the keyboard scrolls the entire document all the way to the top or end, respectively instead of to the beginning or end of the current line. This is extremely disruptive, and likely very confusing to users, as it only happens in the stated situation. A workaround is to move the mouse pointer away from the editor to close the popup after examining an error. Most users will not be able to discover this workaround, though--for myself, it took two weeks to discover the correlation between the tooltip being open and the bug occurring. This bug seems to have been introduced in 8.2, and I just confirmed that it is still present on the new Apache NetBeans 9.0 beta release. This issue was first reported as issue #270842 by timothyrheider in the old BugZilla tracker, on 2017-06-09: https://netbeans.org/bugzilla/show_bug.cgi?id=270842 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-404) Javadoc popup is poorly rendered
Eirik Bakke created NETBEANS-404: Summary: Javadoc popup is poorly rendered Key: NETBEANS-404 URL: https://issues.apache.org/jira/browse/NETBEANS-404 Project: NetBeans Issue Type: Bug Components: editor - Completion & Templates, editor - Hints & Annotations Affects Versions: 8.2, 9.0 Reporter: Eirik Bakke Attachments: javadoc.patch, javadocscreenshot.png This is a patch for the old issue 236403 with the same name, see [https://netbeans.org/bugzilla/show_bug.cgi?id=236403] . Since about NetBeans 7.4, the Java editor's Javadoc popup has been rendered with an all-monospace font. There have also been various complaints about the Javadoc's font size (which the monospace font "fixed" because the monospace font looks larger at the same point size). The attached patch makes the Javadoc popup once again use a non-monospace font (as in generated Javadoc HTML), while at the same time increasing the font size to match the editor's own zoom level. See the attached screenshot. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-403) Pressing Home/End scrolls to beginning/end of whole document if tooltip is open
[ https://issues.apache.org/jira/browse/NETBEANS-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-403: - External issue URL: https://netbeans.org/bugzilla/show_bug.cgi?id=270842 > Pressing Home/End scrolls to beginning/end of whole document if tooltip is > open > --- > > Key: NETBEANS-403 > URL: https://issues.apache.org/jira/browse/NETBEANS-403 > Project: NetBeans > Issue Type: Bug > Components: editor - Key bindings >Affects Versions: 8.2, 9.0 >Reporter: Eirik Bakke >Priority: Major > Attachments: HomeEndBug.png > > > When a tooltip is shown in the Java editor, for instance because the mouse is > hovering over an error indication, pressing the Home or End keys on the > keyboard scrolls the entire document all the way to the top or end, > respectively instead of to the beginning or end of the current line. This is > extremely disruptive, and likely very confusing to users, as it only happens > in the stated situation. > A workaround is to move the mouse pointer away from the editor to close the > popup after examining an error. Most users will not be able to discover this > workaround, though--for myself, it took two weeks to discover the correlation > between the tooltip being open and the bug occurring. > This bug seems to have been introduced in 8.2, and I just confirmed that it > is still present on the new Apache NetBeans 9.0 beta release. > This issue was first reported as issue #270842 by timothyrheider in the old > BugZilla tracker, on 2017-06-09: > https://netbeans.org/bugzilla/show_bug.cgi?id=270842 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-406) addPropertyChangeListener w/o matching removePropertyChangeListener
Eirik Bakke created NETBEANS-406:
Summary: addPropertyChangeListener w/o matching
removePropertyChangeListener
Key: NETBEANS-406
URL: https://issues.apache.org/jira/browse/NETBEANS-406
Project: NetBeans
Issue Type: Bug
Components: editor - CSL (API & infrastructure), editor -
Painting & Printing
Affects Versions: 8.2, 9.0
Environment: Product Version: Apache NetBeans IDE Dev (Build
incubator-netbeans-release-205-on-20180202)
Java: 9.0.4.1; OpenJDK 64-Bit Server VM 9.0.4.1+11
Runtime: OpenJDK Runtime Environment 9.0.4.1+11
System: Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb)
Reporter: Eirik Bakke
The following warning appears in the IDE log every now and then in 8.2 and 9.0
beta:
{code:java}
WARNING [org.openide.util.WeakListenerImpl]: Can't remove
java.beans.PropertyChangeListener using method
org.netbeans.modules.editor.NbEditorDocument.removePropertyChangeListener from
org.netbeans.modules.editor.NbEditorDocument@299b063c,
mimeType='text/x-editor-search', kitClass=null, length=9, version=15,
file=null{code}
The warning above can be reproduced by opening a Java editor, closing all
editors, and then invoking a GC with by double-clicking the memory meter in the
"Performance" toolbar item.
This bug was previously discussed in Bugzilla at
[https://netbeans.org/bugzilla/show_bug.cgi?id=196323] . Not sure what priority
to put for this bug; it's a memory leak, but I'm not sure how big of an impact
it has.
*Analysis*
Storing a stacktrace in WeakListenerImpl.ListenerReference on creation and then
printing it on the failed removal shows the place where the problematic
listener is added:
{code:java}
java.lang.Exception
at
org.openide.util.WeakListenerImpl$ListenerReference.(WeakListenerImpl.java:554)
at org.openide.util.WeakListenerImpl.(WeakListenerImpl.java:109)
at org.openide.util.WeakListenerImpl.(WeakListenerImpl.java:99)
at
org.openide.util.WeakListenerImpl$PropertyChange.(WeakListenerImpl.java:187)
at org.openide.util.WeakListeners.propertyChange(WeakListeners.java:282)
at
org.netbeans.modules.editor.lib2.view.DocumentViewOp.checkSettingsInfo(DocumentViewOp.java:937)
at
org.netbeans.modules.editor.lib2.view.DocumentViewOp.checkViewsInited(DocumentViewOp.java:622)
at
org.netbeans.modules.editor.lib2.view.DocumentView.getPreferredSpan(DocumentView.java:251)
at
javax.swing.plaf.basic.BasicTextUI$RootView.getPreferredSpan(BasicTextUI.java:1353)
at javax.swing.plaf.basic.BasicTextUI.getPreferredSize(BasicTextUI.java:919)
at javax.swing.JComponent.getPreferredSize(JComponent.java:1662)
at javax.swing.JEditorPane.getPreferredSize(JEditorPane.java:1333)
at
org.netbeans.modules.editor.NbEditorUI$LayeredEditorPane.getPreferredSize(NbEditorUI.java:475){code}
The problem is on this line of DocumentViewOp:
{code:java}
o.n.modules.editor.lib2.view.DocumentUtilities.addPropertyChangeListener(doc,
WeakListeners.propertyChange(this, doc));{code}
The DocumentUtilities.addPropertyChangeListener is a special API for allowing
property change listeners to be attached to BaseDocument instances (see
#181073). Since it doesn't actually add
addPropertyChangeListener/removePropertyChangeListener methods to BaseDocument,
it doesn't work with WeakListeners.
As far as I can see, the only place that actually uses
DocumentUtilities.addPropertyChangeListener is the single line i DocumentViewOp
above.
I would propose adding a removedPropertyChangeListener method to BaseDocument
that delegates to DocumentUtilities.removePropertyChangeListener (or performs
the equivalent logic itself). This way the WeakListener will find the method it
expects when the listener is due to be removed, and the property change events
will still have the Document instance as the event source instead of the
delegate PropertyChangeSupport, as is probably desired.
An alternative is to make WeakListeners aware of the special setup wrt.
property change listeners on BaseDocument instances. But that seems like an
abstraction violation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-406) addPropertyChangeListener w/o matching removePropertyChangeListener
[
https://issues.apache.org/jira/browse/NETBEANS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-406:
-
Environment: NetBeans 9.0 beta (incubator-netbeans-release-205-on-20180202)
on OpenJDK 64-Bit Server VM 9.0.4.1+11, Mac OS 10.9.5 (was: Product Version:
Apache NetBeans IDE Dev (Build incubator-netbeans-release-205-on-20180202)
Java: 9.0.4.1; OpenJDK 64-Bit Server VM 9.0.4.1+11
Runtime: OpenJDK Runtime Environment 9.0.4.1+11
System: Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb))
> addPropertyChangeListener w/o matching removePropertyChangeListener
> ---
>
> Key: NETBEANS-406
> URL: https://issues.apache.org/jira/browse/NETBEANS-406
> Project: NetBeans
> Issue Type: Bug
> Components: editor - CSL (API & infrastructure), editor -
> Painting & Printing
>Affects Versions: 8.2, 9.0
> Environment: NetBeans 9.0 beta
> (incubator-netbeans-release-205-on-20180202) on OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS 10.9.5
>Reporter: Eirik Bakke
>Priority: Minor
>
> The following warning appears in the IDE log every now and then in 8.2 and
> 9.0 beta:
>
> {code:java}
> WARNING [org.openide.util.WeakListenerImpl]: Can't remove
> java.beans.PropertyChangeListener using method
> org.netbeans.modules.editor.NbEditorDocument.removePropertyChangeListener
> from org.netbeans.modules.editor.NbEditorDocument@299b063c,
> mimeType='text/x-editor-search', kitClass=null, length=9, version=15,
> file=null{code}
>
> The warning above can be reproduced by opening a Java editor, closing all
> editors, and then invoking a GC with by double-clicking the memory meter in
> the "Performance" toolbar item.
> This bug was previously discussed in Bugzilla at
> [https://netbeans.org/bugzilla/show_bug.cgi?id=196323] . Not sure what
> priority to put for this bug; it's a memory leak, but I'm not sure how big of
> an impact it has.
> *Analysis*
> Storing a stacktrace in WeakListenerImpl.ListenerReference on creation and
> then printing it on the failed removal shows the place where the problematic
> listener is added:
> {code:java}
> java.lang.Exception
> at
> org.openide.util.WeakListenerImpl$ListenerReference.(WeakListenerImpl.java:554)
> at org.openide.util.WeakListenerImpl.(WeakListenerImpl.java:109)
> at org.openide.util.WeakListenerImpl.(WeakListenerImpl.java:99)
> at
> org.openide.util.WeakListenerImpl$PropertyChange.(WeakListenerImpl.java:187)
> at org.openide.util.WeakListeners.propertyChange(WeakListeners.java:282)
> at
> org.netbeans.modules.editor.lib2.view.DocumentViewOp.checkSettingsInfo(DocumentViewOp.java:937)
> at
> org.netbeans.modules.editor.lib2.view.DocumentViewOp.checkViewsInited(DocumentViewOp.java:622)
> at
> org.netbeans.modules.editor.lib2.view.DocumentView.getPreferredSpan(DocumentView.java:251)
> at
> javax.swing.plaf.basic.BasicTextUI$RootView.getPreferredSpan(BasicTextUI.java:1353)
> at javax.swing.plaf.basic.BasicTextUI.getPreferredSize(BasicTextUI.java:919)
> at javax.swing.JComponent.getPreferredSize(JComponent.java:1662)
> at javax.swing.JEditorPane.getPreferredSize(JEditorPane.java:1333)
> at
> org.netbeans.modules.editor.NbEditorUI$LayeredEditorPane.getPreferredSize(NbEditorUI.java:475){code}
> The problem is on this line of DocumentViewOp:
> {code:java}
> o.n.modules.editor.lib2.view.DocumentUtilities.addPropertyChangeListener(doc,
> WeakListeners.propertyChange(this, doc));{code}
> The DocumentUtilities.addPropertyChangeListener is a special API for allowing
> property change listeners to be attached to BaseDocument instances (see
> #181073). Since it doesn't actually add
> addPropertyChangeListener/removePropertyChangeListener methods to
> BaseDocument, it doesn't work with WeakListeners.
> As far as I can see, the only place that actually uses
> DocumentUtilities.addPropertyChangeListener is the single line i
> DocumentViewOp above.
> I would propose adding a removedPropertyChangeListener method to BaseDocument
> that delegates to DocumentUtilities.removePropertyChangeListener (or performs
> the equivalent logic itself). This way the WeakListener will find the method
> it expects when the listener is due to be removed, and the property change
> events will still have the Document instance as the event source instead of
> the delegate PropertyChangeSupport, as is probably desired.
> An alternative is to make WeakListeners aware of the special setup wrt.
> property change listeners on BaseDocument instances. But that seems like an
> abstraction violation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail:
[jira] [Updated] (NETBEANS-406) addPropertyChangeListener w/o matching removePropertyChangeListener
[
https://issues.apache.org/jira/browse/NETBEANS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-406:
-
Description:
The following warning appears in the IDE log every now and then in 8.2 and 9.0
beta:
{code:java}
WARNING [org.openide.util.WeakListenerImpl]: Can't remove
java.beans.PropertyChangeListener using method
org.netbeans.modules.editor.NbEditorDocument.removePropertyChangeListener from
org.netbeans.modules.editor.NbEditorDocument@299b063c,
mimeType='text/x-editor-search', kitClass=null, length=9, version=15,
file=null{code}
The warning above can be reproduced by opening a Java editor, closing all
editors, and then invoking a GC with by double-clicking the memory meter in the
"Performance" toolbar item.
This bug was previously discussed in Bugzilla at
[https://netbeans.org/bugzilla/show_bug.cgi?id=196323] . Not sure what priority
to put for this bug; it's a memory leak, but I'm not sure how big of an impact
it has.
*Analysis*
Storing a stacktrace in WeakListenerImpl.ListenerReference on creation and then
printing it on the failed removal shows the place where the problematic
listener is added:
{code:java}
java.lang.Exception
at
org.openide.util.WeakListenerImpl$ListenerReference.(WeakListenerImpl.java:554)
at org.openide.util.WeakListenerImpl.(WeakListenerImpl.java:109)
at org.openide.util.WeakListenerImpl.(WeakListenerImpl.java:99)
at
org.openide.util.WeakListenerImpl$PropertyChange.(WeakListenerImpl.java:187)
at org.openide.util.WeakListeners.propertyChange(WeakListeners.java:282)
at
org.netbeans.modules.editor.lib2.view.DocumentViewOp.checkSettingsInfo(DocumentViewOp.java:937)
at
org.netbeans.modules.editor.lib2.view.DocumentViewOp.checkViewsInited(DocumentViewOp.java:622)
at
org.netbeans.modules.editor.lib2.view.DocumentView.getPreferredSpan(DocumentView.java:251)
at
javax.swing.plaf.basic.BasicTextUI$RootView.getPreferredSpan(BasicTextUI.java:1353)
at javax.swing.plaf.basic.BasicTextUI.getPreferredSize(BasicTextUI.java:919)
at javax.swing.JComponent.getPreferredSize(JComponent.java:1662)
at javax.swing.JEditorPane.getPreferredSize(JEditorPane.java:1333)
at
org.netbeans.modules.editor.NbEditorUI$LayeredEditorPane.getPreferredSize(NbEditorUI.java:475){code}
The problem is on this line of DocumentViewOp:
{code:java}
o.n.modules.editor.lib2.view.DocumentUtilities.addPropertyChangeListener(doc,
WeakListeners.propertyChange(this, doc));{code}
The DocumentUtilities.addPropertyChangeListener is a special API for allowing
property change listeners to be attached to BaseDocument instances (see
Bugzilla [https://netbeans.org/bugzilla/show_bug.cgi?id=181073] ). Since it
doesn't actually add addPropertyChangeListener/removePropertyChangeListener
methods to BaseDocument, it doesn't work with WeakListeners.
As far as I can see, the only place that actually uses
DocumentUtilities.addPropertyChangeListener is the single line i DocumentViewOp
above.
I would propose adding a removedPropertyChangeListener method to BaseDocument
that delegates to DocumentUtilities.removePropertyChangeListener (or performs
the equivalent logic itself). This way the WeakListener will find the method it
expects when the listener is due to be removed, and the property change events
will still have the Document instance as the event source instead of the
delegate PropertyChangeSupport, as is probably desired.
An alternative is to make WeakListeners aware of the special setup wrt.
property change listeners on BaseDocument instances. But that seems like an
abstraction violation.
was:
The following warning appears in the IDE log every now and then in 8.2 and 9.0
beta:
{code:java}
WARNING [org.openide.util.WeakListenerImpl]: Can't remove
java.beans.PropertyChangeListener using method
org.netbeans.modules.editor.NbEditorDocument.removePropertyChangeListener from
org.netbeans.modules.editor.NbEditorDocument@299b063c,
mimeType='text/x-editor-search', kitClass=null, length=9, version=15,
file=null{code}
The warning above can be reproduced by opening a Java editor, closing all
editors, and then invoking a GC with by double-clicking the memory meter in the
"Performance" toolbar item.
This bug was previously discussed in Bugzilla at
[https://netbeans.org/bugzilla/show_bug.cgi?id=196323] . Not sure what priority
to put for this bug; it's a memory leak, but I'm not sure how big of an impact
it has.
*Analysis*
Storing a stacktrace in WeakListenerImpl.ListenerReference on creation and then
printing it on the failed removal shows the place where the problematic
listener is added:
{code:java}
java.lang.Exception
at
org.openide.util.WeakListenerImpl$ListenerReference.(WeakListenerImpl.java:554)
at org.openide.util.WeakListenerImpl.(WeakListenerImpl.java:109)
at org.openide.util.WeakListenerImpl.(WeakListenerImpl.java:99)
at
org.openide.util.WeakListenerImpl$Property
[jira] [Created] (NETBEANS-407) "Dereferencing possible null pointer" after doing instanceof on variable (false positive)
Eirik Bakke created NETBEANS-407:
Summary: "Dereferencing possible null pointer" after doing
instanceof on variable (false positive)
Key: NETBEANS-407
URL: https://issues.apache.org/jira/browse/NETBEANS-407
Project: NetBeans
Issue Type: Bug
Components: java - FindBugs, java - Hints
Affects Versions: 8.2, 9.0
Reporter: Eirik Bakke
In the following example, the "boolean foo = k instanceof Integer" assignment
causes a spurious "Dereferencing possible null pointer" warning to occur on the
"k.doubleValue()" expression. I believe this did not happen in earlier NetBeans
versions (pre-8.2). Note that if the assignment to "boolean foo" is replaced by
an if statement ("if (k instanceof Integer)"), the warning goes away.
{code:java}
public class TestClass {
private Number getFoo() {
return 3;
}
public void testFoo() {
Number k = getFoo();
// The warning only occurs if this assignment is present.
boolean foo = k instanceof Integer;
// Warning on .doubleValue() here: "Dereferencing possible null pointer"
System.out.println(k.doubleValue());
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-407) "Dereferencing possible null pointer" after doing instanceof on variable (false positive)
[
https://issues.apache.org/jira/browse/NETBEANS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-407:
-
Description:
In the following example, the "boolean foo = k instanceof Integer" assignment
causes a spurious "Dereferencing possible null pointer" warning to occur on the
"k.doubleValue()" expression. I believe this did not happen in earlier NetBeans
versions (pre-8.2). Note that if the assignment to "boolean foo" is replaced by
an if statement ("if (k instanceof Integer)"), the warning goes away.
{code:java}
public class TestClass {
private Number getFoo() {
return 3;
}
public void testFoo() {
Number k = getFoo();
// The warning only occurs if this assignment is present.
boolean foo = k instanceof Integer;
// Warning on .doubleValue() here: "Dereferencing possible null pointer"
System.out.println(k.doubleValue());
}
}
{code}
This bug was previously described at
https://netbeans.org/bugzilla/show_bug.cgi?id=269324 .
was:
In the following example, the "boolean foo = k instanceof Integer" assignment
causes a spurious "Dereferencing possible null pointer" warning to occur on the
"k.doubleValue()" expression. I believe this did not happen in earlier NetBeans
versions (pre-8.2). Note that if the assignment to "boolean foo" is replaced by
an if statement ("if (k instanceof Integer)"), the warning goes away.
{code:java}
public class TestClass {
private Number getFoo() {
return 3;
}
public void testFoo() {
Number k = getFoo();
// The warning only occurs if this assignment is present.
boolean foo = k instanceof Integer;
// Warning on .doubleValue() here: "Dereferencing possible null pointer"
System.out.println(k.doubleValue());
}
}
{code}
> "Dereferencing possible null pointer" after doing instanceof on variable
> (false positive)
> -
>
> Key: NETBEANS-407
> URL: https://issues.apache.org/jira/browse/NETBEANS-407
> Project: NetBeans
> Issue Type: Bug
> Components: java - FindBugs, java - Hints
>Affects Versions: 8.2, 9.0
>Reporter: Eirik Bakke
>Priority: Minor
>
> In the following example, the "boolean foo = k instanceof Integer" assignment
> causes a spurious "Dereferencing possible null pointer" warning to occur on
> the "k.doubleValue()" expression. I believe this did not happen in earlier
> NetBeans versions (pre-8.2). Note that if the assignment to "boolean foo" is
> replaced by an if statement ("if (k instanceof Integer)"), the warning goes
> away.
> {code:java}
> public class TestClass {
> private Number getFoo() {
> return 3;
> }
> public void testFoo() {
> Number k = getFoo();
> // The warning only occurs if this assignment is present.
> boolean foo = k instanceof Integer;
> // Warning on .doubleValue() here: "Dereferencing possible null pointer"
> System.out.println(k.doubleValue());
> }
> }
> {code}
> This bug was previously described at
> https://netbeans.org/bugzilla/show_bug.cgi?id=269324 .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-407) "Dereferencing possible null pointer" after doing instanceof on variable (false positive)
[
https://issues.apache.org/jira/browse/NETBEANS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374352#comment-16374352
]
Eirik Bakke commented on NETBEANS-407:
--
> Your code doesn't actually check if k might be null or not.
That's correct. But the general existing policy of the null checking warning is
to only warn if there some positive indication that k may be null, e.g. a
"@Nullable" annotation on the return type on getFoo(), or where the compiler
can see that k might be null due to an earlier assignment. The checker should
not (and currently does not, except for this bug) give a warning simply because
every method _might_ return null.
> If you add the if and the warning goes away, then everything should be fine,
> since instanceof also implies != null.
Sorry, I was a little unclear here. The warning goes away even if the method
invocation on k is outside the if statement. As in the following variation of
the code:
{code:java}
public class TestClass {
private Number getFoo() {
return 3;
}
public void testFoo() {
Number k = getFoo();
if (k instanceof Integer) {
System.out.println("It's an Integer (and thus not null)");
}
// No warning here now.
System.out.println(k.doubleValue());
}
}
{code}
> "Dereferencing possible null pointer" after doing instanceof on variable
> (false positive)
> -
>
> Key: NETBEANS-407
> URL: https://issues.apache.org/jira/browse/NETBEANS-407
> Project: NetBeans
> Issue Type: Bug
> Components: java - FindBugs, java - Hints
>Affects Versions: 8.2, 9.0
>Reporter: Eirik Bakke
>Priority: Minor
>
> In the following example, the "boolean foo = k instanceof Integer" assignment
> causes a spurious "Dereferencing possible null pointer" warning to occur on
> the "k.doubleValue()" expression. I believe this did not happen in earlier
> NetBeans versions (pre-8.2). Note that if the assignment to "boolean foo" is
> replaced by an if statement ("if (k instanceof Integer)"), the warning goes
> away.
> {code:java}
> public class TestClass {
> private Number getFoo() {
> return 3;
> }
> public void testFoo() {
> Number k = getFoo();
> // The warning only occurs if this assignment is present.
> boolean foo = k instanceof Integer;
> // Warning on .doubleValue() here: "Dereferencing possible null pointer"
> System.out.println(k.doubleValue());
> }
> }
> {code}
> This bug was previously described at
> https://netbeans.org/bugzilla/show_bug.cgi?id=269324 .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-403) Pressing Home/End scrolls to beginning/end of whole document if tooltip is open
[
https://issues.apache.org/jira/browse/NETBEANS-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375682#comment-16375682
]
Eirik Bakke commented on NETBEANS-403:
--
Doing a bit of research on this, the problem seems to be that
javax.swing.text.DefaultEditorKit$EndAction.actionPerformed is called instead
of org.netbeans.editor.BaseKit$EndLineAction.actionPerformed whenever a popup
is open when the "End" key is pressed (and presumably the same for the Home
key).
In the normal case, the stack trace is as follows:
{noformat}
at org.netbeans.editor.BaseKit$EndLineAction.actionPerformed(BaseKit.java:3539)
at org.netbeans.editor.BaseAction.actionPerformed(BaseAction.java:347)
at
org.netbeans.spi.editor.AbstractEditorAction.actionPerformed(AbstractEditorAction.java:468)
at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1663)
at javax.swing.JComponent.processKeyBinding(JComponent.java:2882)
at javax.swing.JComponent.processKeyBindings(JComponent.java:2929)
at javax.swing.JComponent.processKeyEvent(JComponent.java:2845)
...standard AWT trace follows...
{noformat}
In the popup case, the stack trace is as follows:
{code:java}
at
javax.swing.text.DefaultEditorKit$EndAction.actionPerformed(DefaultEditorKit.java:2134)
at
org.netbeans.editor.PopupManager$PopupKeyListener.keyPressed(PopupManager.java:514)
at java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:250)
at java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:249)
at java.awt.Component.processKeyEvent(Component.java:6491)
at javax.swing.JComponent.processKeyEvent(JComponent.java:2832)
...standard AWT trace follows, same as in the non-popup case...
{code}
> Pressing Home/End scrolls to beginning/end of whole document if tooltip is
> open
> ---
>
> Key: NETBEANS-403
> URL: https://issues.apache.org/jira/browse/NETBEANS-403
> Project: NetBeans
> Issue Type: Bug
> Components: editor - Key bindings
>Affects Versions: 8.2, 9.0
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: HomeEndBug.png
>
>
> When a tooltip is shown in the Java editor, for instance because the mouse is
> hovering over an error indication, pressing the Home or End keys on the
> keyboard scrolls the entire document all the way to the top or end,
> respectively instead of to the beginning or end of the current line. This is
> extremely disruptive, and likely very confusing to users, as it only happens
> in the stated situation.
> A workaround is to move the mouse pointer away from the editor to close the
> popup after examining an error. Most users will not be able to discover this
> workaround, though--for myself, it took two weeks to discover the correlation
> between the tooltip being open and the bug occurring.
> This bug seems to have been introduced in 8.2, and I just confirmed that it
> is still present on the new Apache NetBeans 9.0 beta release.
> This issue was first reported as issue #270842 by timothyrheider in the old
> BugZilla tracker, on 2017-06-09:
> https://netbeans.org/bugzilla/show_bug.cgi?id=270842
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-403) Pressing Home/End scrolls to beginning/end of whole document if tooltip is open
[
https://issues.apache.org/jira/browse/NETBEANS-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375682#comment-16375682
]
Eirik Bakke edited comment on NETBEANS-403 at 2/24/18 5:10 PM:
---
Doing a bit of research on this, the problem seems to be that
javax.swing.text.DefaultEditorKit$EndAction.actionPerformed is called instead
of org.netbeans.editor.BaseKit$EndLineAction.actionPerformed whenever a popup
is open when the "End" key is pressed (and presumably the same for the Home
key).
In the normal case, the stack trace is as follows:
{noformat}
at org.netbeans.editor.BaseKit$EndLineAction.actionPerformed(BaseKit.java:3539)
at org.netbeans.editor.BaseAction.actionPerformed(BaseAction.java:347)
at
org.netbeans.spi.editor.AbstractEditorAction.actionPerformed(AbstractEditorAction.java:468)
at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1663)
at javax.swing.JComponent.processKeyBinding(JComponent.java:2882)
at javax.swing.JComponent.processKeyBindings(JComponent.java:2929)
at javax.swing.JComponent.processKeyEvent(JComponent.java:2845)
...standard AWT trace follows...
{noformat}
In the popup case, the stack trace is as follows:
{noformat}
at
javax.swing.text.DefaultEditorKit$EndAction.actionPerformed(DefaultEditorKit.java:2134)
at
org.netbeans.editor.PopupManager$PopupKeyListener.keyPressed(PopupManager.java:514)
at java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:250)
at java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:249)
at java.awt.Component.processKeyEvent(Component.java:6491)
at javax.swing.JComponent.processKeyEvent(JComponent.java:2832)
...standard AWT trace follows, same as in the non-popup case...
{noformat}
was (Author: ebakke):
Doing a bit of research on this, the problem seems to be that
javax.swing.text.DefaultEditorKit$EndAction.actionPerformed is called instead
of org.netbeans.editor.BaseKit$EndLineAction.actionPerformed whenever a popup
is open when the "End" key is pressed (and presumably the same for the Home
key).
In the normal case, the stack trace is as follows:
{noformat}
at org.netbeans.editor.BaseKit$EndLineAction.actionPerformed(BaseKit.java:3539)
at org.netbeans.editor.BaseAction.actionPerformed(BaseAction.java:347)
at
org.netbeans.spi.editor.AbstractEditorAction.actionPerformed(AbstractEditorAction.java:468)
at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1663)
at javax.swing.JComponent.processKeyBinding(JComponent.java:2882)
at javax.swing.JComponent.processKeyBindings(JComponent.java:2929)
at javax.swing.JComponent.processKeyEvent(JComponent.java:2845)
...standard AWT trace follows...
{noformat}
In the popup case, the stack trace is as follows:
{code:java}
at
javax.swing.text.DefaultEditorKit$EndAction.actionPerformed(DefaultEditorKit.java:2134)
at
org.netbeans.editor.PopupManager$PopupKeyListener.keyPressed(PopupManager.java:514)
at java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:250)
at java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:249)
at java.awt.Component.processKeyEvent(Component.java:6491)
at javax.swing.JComponent.processKeyEvent(JComponent.java:2832)
...standard AWT trace follows, same as in the non-popup case...
{code}
> Pressing Home/End scrolls to beginning/end of whole document if tooltip is
> open
> ---
>
> Key: NETBEANS-403
> URL: https://issues.apache.org/jira/browse/NETBEANS-403
> Project: NetBeans
> Issue Type: Bug
> Components: editor - Key bindings
>Affects Versions: 8.2, 9.0
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: HomeEndBug.png
>
>
> When a tooltip is shown in the Java editor, for instance because the mouse is
> hovering over an error indication, pressing the Home or End keys on the
> keyboard scrolls the entire document all the way to the top or end,
> respectively instead of to the beginning or end of the current line. This is
> extremely disruptive, and likely very confusing to users, as it only happens
> in the stated situation.
> A workaround is to move the mouse pointer away from the editor to close the
> popup after examining an error. Most users will not be able to discover this
> workaround, though--for myself, it took two weeks to discover the correlation
> between the tooltip being open and the bug occurring.
> This bug seems to have been introduced in 8.2, and I just confirmed that it
> is still present on the new Apache NetBeans 9.0 beta release.
> This issue was first reported as issue #270842 by timothyrheider in the old
> BugZilla tracker, on 2017-06-09:
> https://netbeans.org/bugzilla/show_bug.cgi?id=270842
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
[jira] [Commented] (NETBEANS-403) Pressing Home/End scrolls to beginning/end of whole document if tooltip is open
[
https://issues.apache.org/jira/browse/NETBEANS-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376015#comment-16376015
]
Eirik Bakke commented on NETBEANS-403:
--
It seems this bug was introduced by the following patch for Bugzilla issue
[262311|https://netbeans.org/bugzilla/show_bug.cgi?id=262311] (diff reformatted
for clarity):
[http://hg.netbeans.org/core-main/rev/03b2f960a7c3:]
{noformat}
--- a/editor.lib/src/org/netbeans/editor/PopupManager.java
+++ b/editor.lib/src/org/netbeans/editor/PopupManager.java
//NOI18N ignore ToolTipSupport installed actions
- if (obj != null &&
- !obj.equals("tooltip-no-action") && obj.equals("tooltip-hide-action")) {
+ if (obj != null && !obj.equals("tooltip-no-action")) {
// if yes, gets the popup's action for this keystroke, perform it
// and consume key event
{noformat}
Prior to the patch above, the "if" condition would previously only be true for
the tooltip-hide-action--obviously an earlier bug given the then-irrelevant
check for "tooltip-no-action". So other popup actions were never performed
before. When the patch above was applied, tooltips started capturing various
actions, exposing new bugs.
The prescribed strategy for dealing with the resulting problems seems to be to
add specific actions to be excluded from popup processing to a list in
org.netbeans.editor.ext.ToolTipSupport.filterBindings:
{code:java}
if (actionName.contains("delete") || actionName.contains("insert") || //NOI18N
actionName.contains("paste") || actionName.contains("default") || //NOI18N
actionName.contains("cut") //NOI18N
) {
actionMap.put(key, NO_ACTION);
}
{code}
This seems fragile, though--how do we know which actions should be added here,
and which should not? For instance, "caret-begin" and "caret-end" should be
added to fix the bug for the Home and End keystrokes, but more experimentation
also reveals a similar bug for "selection-begin" and "selection-end". Doing
some logging, there are a grand total of 63 enabled actions in the ActionMap
for which we'd have to choose whether each should go on the list or not, 34 of
which seem to have assigned keyboard shortcuts (on my MacOS setup, at least).
Thoughts on how to best fix this are welcome.
> Pressing Home/End scrolls to beginning/end of whole document if tooltip is
> open
> ---
>
> Key: NETBEANS-403
> URL: https://issues.apache.org/jira/browse/NETBEANS-403
> Project: NetBeans
> Issue Type: Bug
> Components: editor - Key bindings
>Affects Versions: 8.2, 9.0
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: HomeEndBug.png
>
>
> When a tooltip is shown in the Java editor, for instance because the mouse is
> hovering over an error indication, pressing the Home or End keys on the
> keyboard scrolls the entire document all the way to the top or end,
> respectively instead of to the beginning or end of the current line. This is
> extremely disruptive, and likely very confusing to users, as it only happens
> in the stated situation.
> A workaround is to move the mouse pointer away from the editor to close the
> popup after examining an error. Most users will not be able to discover this
> workaround, though--for myself, it took two weeks to discover the correlation
> between the tooltip being open and the bug occurring.
> This bug seems to have been introduced in 8.2, and I just confirmed that it
> is still present on the new Apache NetBeans 9.0 beta release.
> This issue was first reported as issue #270842 by timothyrheider in the old
> BugZilla tracker, on 2017-06-09:
> https://netbeans.org/bugzilla/show_bug.cgi?id=270842
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-404) Javadoc popup is poorly rendered
[ https://issues.apache.org/jira/browse/NETBEANS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-404: - Attachment: darcula-javadoc.png > Javadoc popup is poorly rendered > > > Key: NETBEANS-404 > URL: https://issues.apache.org/jira/browse/NETBEANS-404 > Project: NetBeans > Issue Type: Bug > Components: editor - Completion & Templates, editor - Hints > & Annotations >Affects Versions: 8.2, 9.0 >Reporter: Eirik Bakke >Priority: Minor > Labels: pull-request-available > Attachments: darcula-javadoc.png, javadoc.patch, javadocscreenshot.png > > Time Spent: 10m > Remaining Estimate: 0h > > This is a patch for the old issue 236403 with the same name, see > [https://netbeans.org/bugzilla/show_bug.cgi?id=236403] . > Since about NetBeans 7.4, the Java editor's Javadoc popup has been rendered > with an all-monospace font. There have also been various complaints about the > Javadoc's font size (which the monospace font "fixed" because the monospace > font looks larger at the same point size). > The attached patch makes the Javadoc popup once again use a non-monospace > font (as in generated Javadoc HTML), while at the same time increasing the > font size to match the editor's own zoom level. See the attached screenshot. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-404) Javadoc popup is poorly rendered
[ https://issues.apache.org/jira/browse/NETBEANS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376894#comment-16376894 ] Eirik Bakke commented on NETBEANS-404: -- I just redid the patch as a github pull request. I also verified that there are no problems under the Darcula L&F (avoiding reintroducing bug [231808|https://netbeans.org/bugzilla/show_bug.cgi?id=231808]). > Javadoc popup is poorly rendered > > > Key: NETBEANS-404 > URL: https://issues.apache.org/jira/browse/NETBEANS-404 > Project: NetBeans > Issue Type: Bug > Components: editor - Completion & Templates, editor - Hints > & Annotations >Affects Versions: 8.2, 9.0 >Reporter: Eirik Bakke >Priority: Minor > Labels: pull-request-available > Attachments: darcula-javadoc.png, javadoc.patch, javadocscreenshot.png > > Time Spent: 10m > Remaining Estimate: 0h > > This is a patch for the old issue 236403 with the same name, see > [https://netbeans.org/bugzilla/show_bug.cgi?id=236403] . > Since about NetBeans 7.4, the Java editor's Javadoc popup has been rendered > with an all-monospace font. There have also been various complaints about the > Javadoc's font size (which the monospace font "fixed" because the monospace > font looks larger at the same point size). > The attached patch makes the Javadoc popup once again use a non-monospace > font (as in generated Javadoc HTML), while at the same time increasing the > font size to match the editor's own zoom level. See the attached screenshot. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-96) New PAC Script evaluator
[
https://issues.apache.org/jira/browse/NETBEANS-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377479#comment-16377479
]
Eirik Bakke commented on NETBEANS-96:
-
Is this patch a replacement for the
[NetBeansProxy2|https://bitbucket.org/phansson/netbeansproxy2] project? See
Bugzilla issue [245116|https://netbeans.org/bugzilla/show_bug.cgi?id=245116]).
> New PAC Script evaluator
>
>
> Key: NETBEANS-96
> URL: https://issues.apache.org/jira/browse/NETBEANS-96
> Project: NetBeans
> Issue Type: Improvement
>Reporter: lbruun
>Assignee: lbruun
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.0
>
>
> The current [PAC script|https://en.wikipedia.org/wiki/Proxy_auto-config]
> evaluator (in {{core.network}}) was developed pre-Nashorn and has a few
> problems:
> * It simply fails with Nashorn - but not with Rhino - if the downloaded
> script uses {{isInNet()}}. This was reported in [Bug
> 245116|https://netbeans.org/bugzilla/show_bug.cgi?id=245116]. It fails
> silently in this case and defaults to no proxy. The user will never know the
> reason - not even by looking in the message log - that there was an error.
> * It doesn't implement two mandatory JavaScript helper methods,
> {{dnsResolve()}} and {{myIpAddress()}}. This is a known issue. This causes
> many PAC scripts to silently fail.
> * It doesn't implement Microsoft's IPv6-aware additions to the PAC standard.
> This is a problem in MS shops because they will have designed their PAC
> script to be compatible with MS IE and MS Edge (which unsurprisingly support
> these functions .. as do Chrome).
> * It uses a small JavaScript helper, {{nsProxyAutoConfig.js}}, which uses a
> license which is not compatible with Apache. This is described in NETBEANS-4.
> * Isn't executing the downloaded PAC script in a sandboxed environment. (The
> PAC script should be treated as hostile because the download may have been
> spoofed. Browsers indeed treat the PAC script as hostile and so should
> NetBeans).
> Pull Request with a new implementation is on its way.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-96) New PAC Script evaluator
[
https://issues.apache.org/jira/browse/NETBEANS-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377479#comment-16377479
]
Eirik Bakke edited comment on NETBEANS-96 at 2/26/18 7:47 PM:
--
Is this patch a replacement for the
[NetBeansProxy2|https://bitbucket.org/phansson/netbeansproxy2] project? See
Bugzilla issue [245116|https://netbeans.org/bugzilla/show_bug.cgi?id=245116].
was (Author: ebakke):
Is this patch a replacement for the
[NetBeansProxy2|https://bitbucket.org/phansson/netbeansproxy2] project? See
Bugzilla issue [245116|https://netbeans.org/bugzilla/show_bug.cgi?id=245116]).
> New PAC Script evaluator
>
>
> Key: NETBEANS-96
> URL: https://issues.apache.org/jira/browse/NETBEANS-96
> Project: NetBeans
> Issue Type: Improvement
>Reporter: lbruun
>Assignee: lbruun
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.0
>
>
> The current [PAC script|https://en.wikipedia.org/wiki/Proxy_auto-config]
> evaluator (in {{core.network}}) was developed pre-Nashorn and has a few
> problems:
> * It simply fails with Nashorn - but not with Rhino - if the downloaded
> script uses {{isInNet()}}. This was reported in [Bug
> 245116|https://netbeans.org/bugzilla/show_bug.cgi?id=245116]. It fails
> silently in this case and defaults to no proxy. The user will never know the
> reason - not even by looking in the message log - that there was an error.
> * It doesn't implement two mandatory JavaScript helper methods,
> {{dnsResolve()}} and {{myIpAddress()}}. This is a known issue. This causes
> many PAC scripts to silently fail.
> * It doesn't implement Microsoft's IPv6-aware additions to the PAC standard.
> This is a problem in MS shops because they will have designed their PAC
> script to be compatible with MS IE and MS Edge (which unsurprisingly support
> these functions .. as do Chrome).
> * It uses a small JavaScript helper, {{nsProxyAutoConfig.js}}, which uses a
> license which is not compatible with Apache. This is described in NETBEANS-4.
> * Isn't executing the downloaded PAC script in a sandboxed environment. (The
> PAC script should be treated as hostile because the download may have been
> spoofed. Browsers indeed treat the PAC script as hostile and so should
> NetBeans).
> Pull Request with a new implementation is on its way.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-430) Sporadic "Invalid or deleted file" exceptions during Java editing
[
https://issues.apache.org/jira/browse/NETBEANS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-430:
-
Description:
While editing Java sources in a maven-based multi-module NetBeans Platform
application on NetBeans 9.0 beta, the following IDE exception happens at
irregular intervals, while editing unrelated files in a different module:
{code}
ALL [null]: An error occurred during parsing of
'/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
Please report a bug against java/source and attach dump file
'/Users/ebakke/Library/Application
Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
{code}
See the attached text file for the complete log dump and stack trace (can't
attach the ".dump" file as it contains source code). The source file in
question, FilterPanel.java, is generated in part by the Matisse GUI builder (so
there's also a FilterPanel.form file). I've also got maven Compile-on-Save
enabled.
At other times, occasionally when running the same NetBeans Platform-based
application, the application itself throws the following exception, mentioning
the same file:
{code}
java.lang.ClassFormatError: Absent Code attribute in method that is not native
or abstract in class file com/somepackage/project/filter/FilterPanel$2{code}
See again the attached text file for the complete log dump and stack trace.
was:
While editing Java sources in a maven-based multi-module NetBeans Platform
application on NetBeans 9.0 beta, the following IDE exception happens at
irregular intervals, while editing unrelated files in a different module:
{code:java}
ALL [null]: An error occurred during parsing of
'/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
Please report a bug against java/source and attach dump file
'/Users/ebakke/Library/Application
Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
{code}
See the attached text file for the complete log dump and stack trace (can't
attach the ".dump" file as it contains source code). The source file in
question, FilterPanel.java, is generated in part by the Matisse GUI builder (so
there's also a FilterPanel.form file). I've also got maven Compile-on-Save
enabled.
At other times, occasionally when running the same NetBeans Platform-based
application, the application itself throws the following exception, mentioning
the same file:
{code:java}
java.lang.ClassFormatError: Absent Code attribute in method that is not native
or abstract in class file com/somepackage/project/filter/FilterPanel$2{code}
See again the attached text file for the complete log dump and stack trace.
> Sporadic "Invalid or deleted file" exceptions during Java editing
> -
>
> Key: NETBEANS-430
> URL: https://issues.apache.org/jira/browse/NETBEANS-430
> Project: NetBeans
> Issue Type: Bug
> Components: guibuilder - Code, java - Classfile, java - Source,
> projects - Maven
>Affects Versions: 9.0
> Environment: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-205-on-20180202), OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS X version 10.9.5
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: parseerror.txt
>
>
> While editing Java sources in a maven-based multi-module NetBeans Platform
> application on NetBeans 9.0 beta, the following IDE exception happens at
> irregular intervals, while editing unrelated files in a different module:
>
> {code}
> ALL [null]: An error occurred during parsing of
> '/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
> Please report a bug against java/source and attach dump file
> '/Users/ebakke/Library/Application
> Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
> {code}
> See the attached text file for the complete log dump and stack trace (can't
> attach the ".dump" file as it contains source code). The source file in
> question, FilterPanel.java, is generated in part by the Matisse GUI builder
> (so there's also a FilterPanel.form file). I've also got maven
> Compile-on-Save enabled.
> At other times, occasionally when running the same NetBeans Platform-based
> application, the application itself throws the following exception,
> mentioning the same file:
> {code}
> java.lang.ClassFormatError: Absent Code attribute in method that is not
> native or abstract in class file
> com/somepackage/project/filter/FilterPanel$2{code}
> See again the attached text file for the complete log dump and stack trace.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.ap
[jira] [Created] (NETBEANS-430) Sporadic "Invalid or deleted file" exceptions during Java editing
Eirik Bakke created NETBEANS-430:
Summary: Sporadic "Invalid or deleted file" exceptions during Java
editing
Key: NETBEANS-430
URL: https://issues.apache.org/jira/browse/NETBEANS-430
Project: NetBeans
Issue Type: Bug
Components: guibuilder - Code, java - Classfile, java - Source,
projects - Maven
Affects Versions: 9.0
Environment: Apache NetBeans IDE Dev (Build
incubator-netbeans-release-205-on-20180202), OpenJDK 64-Bit Server VM
9.0.4.1+11, Mac OS X version 10.9.5
Reporter: Eirik Bakke
Attachments: parseerror.txt
While editing Java sources in a maven-based multi-module NetBeans Platform
application on NetBeans 9.0 beta, the following IDE exception happens at
irregular intervals, while editing unrelated files in a different module:
{code:java}
ALL [null]: An error occurred during parsing of
'/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
Please report a bug against java/source and attach dump file
'/Users/ebakke/Library/Application
Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
{code}
See the attached text file for the complete log dump and stack trace (can't
attach the ".dump" file as it contains source code). The source file in
question, FilterPanel.java, is generated in part by the Matisse GUI builder (so
there's also a FilterPanel.form file). I've also got maven Compile-on-Save
enabled.
At other times, occasionally when running the same NetBeans Platform-based
application, the application itself throws the following exception, mentioning
the same file:
{code:java}
java.lang.ClassFormatError: Absent Code attribute in method that is not native
or abstract in class file com/somepackage/project/filter/FilterPanel$2{code}
See again the attached text file for the complete log dump and stack trace.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-430) Sporadic "Invalid or deleted file" exceptions during Java editing
[
https://issues.apache.org/jira/browse/NETBEANS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-430:
-
Description:
While editing Java sources in a maven-based multi-module NetBeans Platform
application on NetBeans 9.0 beta, the following IDE exception happens at
irregular intervals, while editing unrelated files in a different module:
{noformat}
ALL [null]: An error occurred during parsing of
'/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
Please report a bug against java/source and attach dump file
'/Users/ebakke/Library/Application
Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
{noformat}
See the attached text file for the complete log dump and stack trace (can't
attach the ".dump" file as it contains source code). The source file in
question, FilterPanel.java, is generated in part by the Matisse GUI builder (so
there's also a FilterPanel.form file). I've also got maven Compile-on-Save
enabled.
At other times, occasionally when running the same NetBeans Platform-based
application, the application itself throws the following exception, mentioning
the same file:
{noformat}
java.lang.ClassFormatError: Absent Code attribute in method that is not native
or abstract in class file com/somepackage/project/filter/FilterPanel$2
{noformat}
See again the attached text file for the complete log dump and stack trace.
was:
While editing Java sources in a maven-based multi-module NetBeans Platform
application on NetBeans 9.0 beta, the following IDE exception happens at
irregular intervals, while editing unrelated files in a different module:
{code}
ALL [null]: An error occurred during parsing of
'/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
Please report a bug against java/source and attach dump file
'/Users/ebakke/Library/Application
Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
{code}
See the attached text file for the complete log dump and stack trace (can't
attach the ".dump" file as it contains source code). The source file in
question, FilterPanel.java, is generated in part by the Matisse GUI builder (so
there's also a FilterPanel.form file). I've also got maven Compile-on-Save
enabled.
At other times, occasionally when running the same NetBeans Platform-based
application, the application itself throws the following exception, mentioning
the same file:
{code}
java.lang.ClassFormatError: Absent Code attribute in method that is not native
or abstract in class file com/somepackage/project/filter/FilterPanel$2{code}
See again the attached text file for the complete log dump and stack trace.
> Sporadic "Invalid or deleted file" exceptions during Java editing
> -
>
> Key: NETBEANS-430
> URL: https://issues.apache.org/jira/browse/NETBEANS-430
> Project: NetBeans
> Issue Type: Bug
> Components: guibuilder - Code, java - Classfile, java - Source,
> projects - Maven
>Affects Versions: 9.0
> Environment: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-205-on-20180202), OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS X version 10.9.5
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: parseerror.txt
>
>
> While editing Java sources in a maven-based multi-module NetBeans Platform
> application on NetBeans 9.0 beta, the following IDE exception happens at
> irregular intervals, while editing unrelated files in a different module:
> {noformat}
> ALL [null]: An error occurred during parsing of
> '/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
> Please report a bug against java/source and attach dump file
> '/Users/ebakke/Library/Application
> Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
> {noformat}
> See the attached text file for the complete log dump and stack trace (can't
> attach the ".dump" file as it contains source code). The source file in
> question, FilterPanel.java, is generated in part by the Matisse GUI builder
> (so there's also a FilterPanel.form file). I've also got maven
> Compile-on-Save enabled.
> At other times, occasionally when running the same NetBeans Platform-based
> application, the application itself throws the following exception,
> mentioning the same file:
> {noformat}
> java.lang.ClassFormatError: Absent Code attribute in method that is not
> native or abstract in class file com/somepackage/project/filter/FilterPanel$2
> {noformat}
> See again the attached text file for the complete log dump and stack trace.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsu
[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&focusedCommentId=16381734#comment-16381734 ] Eirik Bakke commented on NETBEANS-378: -- These issues on high-resolution displays seem important. Issue https://issues.apache.org/jira/browse/NETBEANS-374 covers the same (but doesn't have screenshots)–maybe one of the issues should be marked as a duplicate of the other. Which JDK version is this? And which Windows version? Consider pasting the info from the NetBeans' "About" panel. > 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 >Reporter: Giulio D'Ambrosi >Priority: Major > Attachments: Installer.PNG, keymap.PNG, plugins.PNG, tab.PNG > > > 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 (v7.6.3#76005) - 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-374) font is too small on high res notebook monitor
[ https://issues.apache.org/jira/browse/NETBEANS-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16381735#comment-16381735 ] Eirik Bakke commented on NETBEANS-374: -- See also https://issues.apache.org/jira/browse/NETBEANS-378 . > font is too small on high res notebook monitor > -- > > Key: NETBEANS-374 > URL: https://issues.apache.org/jira/browse/NETBEANS-374 > Project: NetBeans > Issue Type: Bug >Reporter: Peter >Priority: Major > > font is too small on high res notebook monitor (e.g. macbook pro 15, > 2880x1800). Even i tuned to enlarge the font, all other things : menu, button > are just too small -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-249) Default to antialiased fonts
[ https://issues.apache.org/jira/browse/NETBEANS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16381844#comment-16381844 ] Eirik Bakke commented on NETBEANS-249: -- Which platforms do not currently default to anti-aliased fonts? > Default to antialiased fonts > > > Key: NETBEANS-249 > URL: https://issues.apache.org/jira/browse/NETBEANS-249 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Reporter: Antonio Vieiro >Priority: Trivial > > Enable antialiased fonts by default in all platforms. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-212) Project actions is getting too large
[ https://issues.apache.org/jira/browse/NETBEANS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-212: - Attachment: actions.png > Project actions is getting too large > > > Key: NETBEANS-212 > URL: https://issues.apache.org/jira/browse/NETBEANS-212 > Project: NetBeans > Issue Type: Improvement > Components: projects - Generic Projects UI >Reporter: Antonio Vieiro >Priority: Major > Labels: netbeans-ui > Attachments: actions.png, netbeans-project-menu.png > > > The "Project" menu is way too large, reaching 811 pixels. > I think this should be grouped somehow, leaving less-used options grouped in > menu items. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-212) Project actions is getting too large
[ https://issues.apache.org/jira/browse/NETBEANS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16381845#comment-16381845 ] Eirik Bakke commented on NETBEANS-212: -- Hmm, the screenshot you uploaded seems to be missing the separators, which make the menu a little more readable. See actions.png, which shows what the menu looks like on MacOS. That might be a separate bug. Which OS is the original screenshot from? > Project actions is getting too large > > > Key: NETBEANS-212 > URL: https://issues.apache.org/jira/browse/NETBEANS-212 > Project: NetBeans > Issue Type: Improvement > Components: projects - Generic Projects UI >Reporter: Antonio Vieiro >Priority: Major > Labels: netbeans-ui > Attachments: actions.png, netbeans-project-menu.png > > > The "Project" menu is way too large, reaching 811 pixels. > I think this should be grouped somehow, leaving less-used options grouped in > menu items. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-169) Weird visual artifact on the editor window
[ https://issues.apache.org/jira/browse/NETBEANS-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16381850#comment-16381850 ] Eirik Bakke commented on NETBEANS-169: -- The popup seems to be the one that shows the opening tag of an XML element when the editor cursor is on the end tag. Do you have line wrapping enabled in the editor by any chance? The popup in the screenshot seems to include some line wrapping symbols. > Weird visual artifact on the editor window > -- > > Key: NETBEANS-169 > URL: https://issues.apache.org/jira/browse/NETBEANS-169 > Project: NetBeans > Issue Type: Bug > Components: editor - Other >Affects Versions: 8.2 > Environment: OS: > Linux X 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux > Java: > openjdk version "1.8.0_151" > OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-1~deb9u1-b12) > OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode) > IDE: > Product Version: NetBeans IDE 8.2 (Build 201705191307) > Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2 > Java: 1.8.0_151; OpenJDK 64-Bit Server VM 25.151-b12 > Runtime: OpenJDK Runtime Environment 1.8.0_151-8u151-b12-1~deb9u1-b12 > System: Linux version 4.9.0-4-amd64 running on amd64; UTF-8; es_ES (nb) > User directory: /home/antonio/.netbeans/8.2 > Cache directory: /home/antonio/.cache/netbeans/8.2 > With installed XML Tools plugin: > Version: 6.10 Source: XML PACK > Plugin Description > XML Tools. >Reporter: Antonio Vieiro >Assignee: Antonio Vieiro >Priority: Major > Labels: Java9-IDE > Attachments: netbeans-3.png > > > While scrolling a weird artifact appears on the editor window, blocking a > part of the file. Seems to be some sort of misplaced popup window. > I think I can reproduce it as follows: > - Close all windows. > - Open a medium sized XML File. > - Without clicking on it, just scroll down through the file, the pop-up > window will appear on the top-left area of the editor. > I'm attaching a partial screenshot with the popup window. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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&focusedCommentId=16385424#comment-16385424 ] Eirik Bakke commented on NETBEANS-378: -- It might be worth trying on Java 9 as well, in case the newer JDK has better HiDPI support. > 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 > Attachments: Installer.PNG, keymap.PNG, plugins.PNG, tab.PNG > > > 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 (v7.6.3#76005) - 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-430) "Invalid or deleted file", "Absent Code attribute" exceptions during Java editing and app/test running
[
https://issues.apache.org/jira/browse/NETBEANS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-430:
-
Summary: "Invalid or deleted file", "Absent Code attribute" exceptions
during Java editing and app/test running (was: Sporadic "Invalid or deleted
file" exceptions during Java editing)
> "Invalid or deleted file", "Absent Code attribute" exceptions during Java
> editing and app/test running
> --
>
> Key: NETBEANS-430
> URL: https://issues.apache.org/jira/browse/NETBEANS-430
> Project: NetBeans
> Issue Type: Bug
> Components: guibuilder - Code, java - Classfile, java - Source,
> projects - Maven
>Affects Versions: 9.0
> Environment: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-205-on-20180202), OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS X version 10.9.5
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: parseerror.txt
>
>
> While editing Java sources in a maven-based multi-module NetBeans Platform
> application on NetBeans 9.0 beta, the following IDE exception happens at
> irregular intervals, while editing unrelated files in a different module:
> {noformat}
> ALL [null]: An error occurred during parsing of
> '/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
> Please report a bug against java/source and attach dump file
> '/Users/ebakke/Library/Application
> Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
> {noformat}
> See the attached text file for the complete log dump and stack trace (can't
> attach the ".dump" file as it contains source code). The source file in
> question, FilterPanel.java, is generated in part by the Matisse GUI builder
> (so there's also a FilterPanel.form file). I've also got maven
> Compile-on-Save enabled.
> At other times, occasionally when running the same NetBeans Platform-based
> application, the application itself throws the following exception,
> mentioning the same file:
> {noformat}
> java.lang.ClassFormatError: Absent Code attribute in method that is not
> native or abstract in class file com/somepackage/project/filter/FilterPanel$2
> {noformat}
> See again the attached text file for the complete log dump and stack trace.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-430) "Invalid or deleted file", "Absent Code attribute" exceptions during Java editing and app/test running
[
https://issues.apache.org/jira/browse/NETBEANS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16388191#comment-16388191
]
Eirik Bakke commented on NETBEANS-430:
--
I've gotten many more "Absent Code attribute" errors in various situations
since first reporting this error, including for files not generated by the
Matisse GUI builder. Current situations in which I got the "Absent Code
attribute" error:
1) At irregular intervals when editing unrelated Java files, as initially
reported above.
2) Sometimes while running a NetBeans Platform app, as also mentioned before.
3) When running a test method using the "Run Focused Test Method" action (got
this error on two occasions so far). In this case the error again mentions
another class file than the one containing the test. The error can be "fixed"
by making some arbitrary change in the class mentioned by the error and saving
it. I suspect the error might be related to Compile-on-Save functionality.
I never saw these errors in 8.2.
> "Invalid or deleted file", "Absent Code attribute" exceptions during Java
> editing and app/test running
> --
>
> Key: NETBEANS-430
> URL: https://issues.apache.org/jira/browse/NETBEANS-430
> Project: NetBeans
> Issue Type: Bug
> Components: guibuilder - Code, java - Classfile, java - Source,
> projects - Maven
>Affects Versions: 9.0
> Environment: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-205-on-20180202), OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS X version 10.9.5
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: parseerror.txt
>
>
> While editing Java sources in a maven-based multi-module NetBeans Platform
> application on NetBeans 9.0 beta, the following IDE exception happens at
> irregular intervals, while editing unrelated files in a different module:
> {noformat}
> ALL [null]: An error occurred during parsing of
> '/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
> Please report a bug against java/source and attach dump file
> '/Users/ebakke/Library/Application
> Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
> {noformat}
> See the attached text file for the complete log dump and stack trace (can't
> attach the ".dump" file as it contains source code). The source file in
> question, FilterPanel.java, is generated in part by the Matisse GUI builder
> (so there's also a FilterPanel.form file). I've also got maven
> Compile-on-Save enabled.
> At other times, occasionally when running the same NetBeans Platform-based
> application, the application itself throws the following exception,
> mentioning the same file:
> {noformat}
> java.lang.ClassFormatError: Absent Code attribute in method that is not
> native or abstract in class file com/somepackage/project/filter/FilterPanel$2
> {noformat}
> See again the attached text file for the complete log dump and stack trace.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-430) "Invalid or deleted file", "Absent Code attribute" exceptions during Java editing and app/test running
[
https://issues.apache.org/jira/browse/NETBEANS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16388198#comment-16388198
]
Eirik Bakke commented on NETBEANS-430:
--
Here is the stack trace for the case where the error was seen during a "Run
Focused Test Method" action:
{noformat}
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.418 sec <<<
FAILURE! - in com.somepackage.evaluator.QueryEvaluator1Test
testDeepJoin(com.somepackage.evaluator.QueryEvaluator1Test) Time elapsed: 0.132
sec <<< ERROR!
java.lang.ClassFormatError: Absent Code attribute in method that is not native
or abstract in class file com/somepackage/query/QueryPropertyTypes$1
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at com.somepackage.query.QProp.(QProp.java:48)
at
com.somepackage.evaluator.EvaluatorTestBase.createView(EvaluatorTestBase.java:175)
at
com.somepackage.evaluator.QueryEvaluator1Test.testDeepJoin(QueryEvaluator1Test.java:1272){noformat}
> "Invalid or deleted file", "Absent Code attribute" exceptions during Java
> editing and app/test running
> --
>
> Key: NETBEANS-430
> URL: https://issues.apache.org/jira/browse/NETBEANS-430
> Project: NetBeans
> Issue Type: Bug
> Components: guibuilder - Code, java - Classfile, java - Source,
> projects - Maven
>Affects Versions: 9.0
> Environment: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-205-on-20180202), OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS X version 10.9.5
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: parseerror.txt
>
>
> While editing Java sources in a maven-based multi-module NetBeans Platform
> application on NetBeans 9.0 beta, the following IDE exception happens at
> irregular intervals, while editing unrelated files in a different module:
> {noformat}
> ALL [null]: An error occurred during parsing of
> '/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
> Please report a bug against java/source and attach dump file
> '/Users/ebakke/Library/Application
> Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
> {noformat}
> See the attached text file for the complete log dump and stack trace (can't
> attach the ".dump" file as it contains source code). The source file in
> question, FilterPanel.java, is generated in part by the Matisse GUI builder
> (so there's also a FilterPanel.form file). I've also got maven
> Compile-on-Save enabled.
> At other times, occasionally when running the same NetBeans Platform-based
> application, the application itself throws the following exception,
> mentioning the same file:
> {noformat}
> java.lang.ClassFormatError: Absent Code attribute in method that is not
> native or abstract in class file com/somepackage/project/filter/FilterPanel$2
> {noformat}
> See again the attached text file for the complete log dump and stack trace.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-447) Option for Javadoc to generate simple class names
[
https://issues.apache.org/jira/browse/NETBEANS-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16390126#comment-16390126
]
Eirik Bakke commented on NETBEANS-447:
--
Agree with Niklas.
> Option for Javadoc to generate simple class names
> -
>
> Key: NETBEANS-447
> URL: https://issues.apache.org/jira/browse/NETBEANS-447
> Project: NetBeans
> Issue Type: New Feature
> Components: java - Javadoc
>Reporter: Gili
>Priority: Major
>
> Fielding a feature request from the mailing list:
> {quote}
> -Original Message- From: Thomas Kellerer
> Sent: Monday, March 05, 2018 11:42 PM
> To: NetBeans Users
> Subject: Disabling fully qualified class names in JavDoc completion
> When using code-completion in JavaDocs (e.g. for a @see attribute), NetBeans
> always inserts fully qualifed class names for parameters, e.g.
>@see #someMethod(java.lang.String, java.lang.String)
> Is it possible (in 8.2 or 9.0) to disable this, so that the above is written
> as:
>@see #someMethod(String, String)
> This is not so much a problem with JDK classes, but with our own classes
> which tend to have longer package names. {quote}
> This feature should be configurable using an IDE-level or project-level
> option flag.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-453) "Incorrect number of type arguments" exception during Java editing
Eirik Bakke created NETBEANS-453:
Summary: "Incorrect number of type arguments" exception during
Java editing
Key: NETBEANS-453
URL: https://issues.apache.org/jira/browse/NETBEANS-453
Project: NetBeans
Issue Type: Bug
Components: java - Source
Affects Versions: 9.0
Environment: Apache NetBeans IDE Dev (Build
incubator-netbeans-release-205-on-20180202) on OpenJDK 64-Bit Server VM
9.0.4.1+11, Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb)
Reporter: Eirik Bakke
I got the following Exception while editing a Java file in NetBeans 9.0 Beta:
{noformat}
java.lang.IllegalArgumentException: Incorrect number of type arguments
at com.sun.tools.javac.model.JavacTypes.getDeclaredType0(JavacTypes.java:270)
at com.sun.tools.javac.model.JavacTypes.getDeclaredType(JavacTypes.java:245)
at
org.netbeans.modules.java.hints.errors.Utilities.resolveCapturedTypeInt(Utilities.java:619)
at
org.netbeans.modules.java.hints.errors.Utilities.resolveCapturedType(Utilities.java:538)
at
org.netbeans.modules.java.hints.errors.Utilities.resolveTypeForDeclaration(Utilities.java:519)
at org.netbeans.modules.java.hints.errors.AddCast.computeType(AddCast.java:193)
at org.netbeans.modules.java.hints.errors.AddCast.run(AddCast.java:222)
at
org.netbeans.modules.java.hints.infrastructure.CreatorBasedLazyFixList.compute(CreatorBasedLazyFixList.java:123)
at
org.netbeans.modules.java.hints.infrastructure.LazyHintComputation.run(LazyHintComputation.java:87)
at
org.netbeans.modules.java.hints.infrastructure.LazyHintComputation.run(LazyHintComputation.java:33)
[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.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
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 as a new JIRA issue since the old NetBeans exception reporter no
longer seems to be in use.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-453) "Incorrect number of type arguments" exception during Java editing
[
https://issues.apache.org/jira/browse/NETBEANS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-453:
-
Component/s: java - Compiler
java - Classfile
> "Incorrect number of type arguments" exception during Java editing
> --
>
> Key: NETBEANS-453
> URL: https://issues.apache.org/jira/browse/NETBEANS-453
> Project: NetBeans
> Issue Type: Bug
> Components: java - Classfile, java - Compiler, java - Source
>Affects Versions: 9.0
> Environment: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-205-on-20180202) on OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb)
>Reporter: Eirik Bakke
>Priority: Major
>
> I got the following Exception while editing a Java file in NetBeans 9.0 Beta:
> {noformat}
> java.lang.IllegalArgumentException: Incorrect number of type arguments
> at com.sun.tools.javac.model.JavacTypes.getDeclaredType0(JavacTypes.java:270)
> at com.sun.tools.javac.model.JavacTypes.getDeclaredType(JavacTypes.java:245)
> at
> org.netbeans.modules.java.hints.errors.Utilities.resolveCapturedTypeInt(Utilities.java:619)
> at
> org.netbeans.modules.java.hints.errors.Utilities.resolveCapturedType(Utilities.java:538)
> at
> org.netbeans.modules.java.hints.errors.Utilities.resolveTypeForDeclaration(Utilities.java:519)
> at
> org.netbeans.modules.java.hints.errors.AddCast.computeType(AddCast.java:193)
> at org.netbeans.modules.java.hints.errors.AddCast.run(AddCast.java:222)
> at
> org.netbeans.modules.java.hints.infrastructure.CreatorBasedLazyFixList.compute(CreatorBasedLazyFixList.java:123)
> at
> org.netbeans.modules.java.hints.infrastructure.LazyHintComputation.run(LazyHintComputation.java:87)
> at
> org.netbeans.modules.java.hints.infrastructure.LazyHintComputation.run(LazyHintComputation.java:33)
> [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.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 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 as a new JIRA issue since the old NetBeans exception reporter
> no longer seems to be in use.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-454) AssertionError/"Wrong diagnostic handler ... DeferredDiagnosticHandler" when opening Java autocomplete
Eirik Bakke created NETBEANS-454:
Summary: AssertionError/"Wrong diagnostic handler ...
DeferredDiagnosticHandler" when opening Java autocomplete
Key: NETBEANS-454
URL: https://issues.apache.org/jira/browse/NETBEANS-454
Project: NetBeans
Issue Type: Bug
Components: editor - Completion & Templates, java - Compiler
Affects Versions: 9.0
Environment: Apache NetBeans IDE Dev (Build
incubator-netbeans-release-205-on-20180202) on OpenJDK 64-Bit Server VM
9.0.4.1+11, Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb)
Reporter: Eirik Bakke
Attachments: threaddump.txt
The following exception occurred while opening the autocomplete popup while
editing a Java file:
{noformat}
java.lang.AssertionError: Wrong diagnostic handler:
com.sun.tools.javac.util.Log$DeferredDiagnosticHandler@7f84b389
{noformat}
A long thread dump followed, which is attached. Reporting this as a new JIRA
issue since the old NetBeans exception reporter no longer seems to be in use.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-430) "Invalid or deleted file", "Absent Code attribute" exceptions during Java editing and app/test running
[
https://issues.apache.org/jira/browse/NETBEANS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16390368#comment-16390368
]
Eirik Bakke commented on NETBEANS-430:
--
Here is another variation of the "An error occurred during parsing" error that
I'm getting. Not sure whether this is one or several unrelated bugs.
{noformat}
SEVERE [org.openide.util.Exceptions]
An error occurred during parsing of
'/Users/ebakke/ZRoot/somepackage/Modules/server-evaluator/src/main/java/com/somepackage/evaluator/impl/QueryBlock.java'.
Please report a bug against java/source and attach dump file
'/Users/ebakke/Library/Application
Support/NetBeans/dev/var/log/QueryBlock.dump'.
An error occurred during parsing of
'/Users/ebakke/ZRoot/somepackage/Modules/server-evaluator/src/main/java/com/somepackage/evaluator/impl/QueryBlock.java'.
Please report a bug against java/source and attach dump file
'/Users/ebakke/Library/Application
Support/NetBeans/dev/var/log/QueryBlock.dump'.
Caused: java.lang.ClassCastException:
com.sun.tools.javac.tree.JCTree$JCConditional cannot be cast to
com.sun.tools.javac.tree.JCTree$JCMethodInvocation
at
com.sun.tools.javac.comp.ArgumentAttr$ResolvedMethodType.dup(ArgumentAttr.java:588)
at
com.sun.tools.javac.comp.ArgumentAttr.processArg(ArgumentAttr.java:236)
at
com.sun.tools.javac.comp.ArgumentAttr.processArg(ArgumentAttr.java:215)
at
com.sun.tools.javac.comp.ArgumentAttr.visitConditional(ArgumentAttr.java:251)
at
com.sun.tools.javac.tree.JCTree$JCConditional.accept(JCTree.java:1385)
at
com.sun.tools.javac.comp.ArgumentAttr.attribArg(ArgumentAttr.java:193)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:656)
at com.sun.tools.javac.comp.Attr.attribArgs(Attr.java:767)
at com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2156)
at
org.netbeans.lib.nbjavac.services.NBAttr.visitNewClass(NBAttr.java:74)
at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1689)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:658)
at
com.sun.tools.javac.comp.ArgumentAttr.visitNewClass(ArgumentAttr.java:316)
at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1689)
at
com.sun.tools.javac.comp.ArgumentAttr.attribArg(ArgumentAttr.java:193)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:656)
at com.sun.tools.javac.comp.Attr.attribArgs(Attr.java:767)
at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1953)
at
com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1634)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:658)
at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:711)
at com.sun.tools.javac.comp.Attr.visitExec(Attr.java:1729)
at
com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1452)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:658)
at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:734)
at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:758)
at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1245)
at org.netbeans.lib.nbjavac.services.NBAttr.visitBlock(NBAttr.java:69)
at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1020)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:658)
at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:734)
at com.sun.tools.javac.comp.Attr.visitForeachLoop(Attr.java:1311)
at
com.sun.tools.javac.tree.JCTree$JCEnhancedForLoop.accept(JCTree.java:1160)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:658)
at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:734)
at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:758)
at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1245)
at org.netbeans.lib.nbjavac.services.NBAttr.visitBlock(NBAttr.java:69)
at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1020)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:658)
at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:734)
at
org.netbeans.modules.java.source.nbjavac.parsing.PartialReparserService.reattrMethodBody(PartialReparserService.java:178)
[catch] at
org.netbeans.modules.java.source.nbjavac.parsing.PartialReparserImpl.reparseMethod(PartialReparserImpl.java:164)
at
org.netbeans.modules.java.source.parsing.JavacParser.parseImpl(JavacParser.java:397)
at
org.netbeans.modules.java.source.parsing.JavacParser.parse(JavacParser.java:330)
at
org.netbeans.modules.parsing.impl.TaskProcessor.callParse(TaskProcessor.java:598)
at
org.netbeans.modules.parsing.impl.SourceCache.getResult(SourceCache.java:228)
at
org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.run(Task
[jira] [Created] (NETBEANS-455) "The bytes do not represent a valid class" error while invoking the "Apply Code Changes" action
Eirik Bakke created NETBEANS-455:
Summary: "The bytes do not represent a valid class" error while
invoking the "Apply Code Changes" action
Key: NETBEANS-455
URL: https://issues.apache.org/jira/browse/NETBEANS-455
Project: NetBeans
Issue Type: Bug
Components: debugger - Java, java - Classfile
Affects Versions: 9.0
Environment: Apache NetBeans IDE Dev (Build
incubator-netbeans-release-205-on-20180202) on OpenJDK 64-Bit Server VM
9.0.4.1+11, Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb)
Reporter: Eirik Bakke
I got the following exception while invoking the "Apply Code Changes" action in
the Java debugger:
{noformat}
INFO [org.netbeans.modules.maven.debug.DebuggerChecker]: The bytes do not
represent a valid class. class not in class file format
java.lang.ClassFormatError: class not in class file format
at
jdk.jdi/com.sun.tools.jdi.VirtualMachineImpl.redefineClasses(VirtualMachineImpl.java:332)
at
org.netbeans.modules.debugger.jpda.jdi.VirtualMachineWrapper.redefineClasses(VirtualMachineWrapper.java:3138)
at
org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.fixClasses(JPDADebuggerImpl.java:471)
[catch] at
org.netbeans.modules.maven.debug.DebuggerChecker.reload(DebuggerChecker.java:401)
at
org.netbeans.modules.maven.debug.DebuggerChecker.doReload(DebuggerChecker.java:206)
at
org.netbeans.modules.maven.debug.DebuggerChecker.checkRunConfig(DebuggerChecker.java:145)
at
org.netbeans.modules.maven.execute.PrereqCheckerMerger$Impl.checkRunConfig(PrereqCheckerMerger.java:64)
at org.netbeans.modules.maven.api.execute.RunUtils.run(RunUtils.java:65)
at
org.netbeans.modules.maven.ActionProviderImpl.invokeAction(ActionProviderImpl.java:262)
at
org.netbeans.modules.maven.ActionProviderImpl.access$000(ActionProviderImpl.java:111)
at
org.netbeans.modules.maven.ActionProviderImpl$1.run(ActionProviderImpl.java:235)
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}
This is a Maven-based NetBeans Platform module project. The module project is
using JDK8 while the IDE is running on JDK9.
Reporting this as a new JIRA issue since the old NetBeans exception reporter no
longer seems to be in use.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-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 updated NETBEANS-346: - Attachment: linewidth.png > 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 > Fix For: 9.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 > > > 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 (v7.6.3#76005) - 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-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:comment-tabpanel&focusedCommentId=16391263#comment-16391263 ] Eirik Bakke commented on NETBEANS-346: -- I can confirm the margin line issue. I set the Right Margin at 100 characters, which is the standard for the project I'm working on, yet NetBeans draws the line at 102 characters. Very annoying--people are unlikely to notice and will check in code formatted slightly wrong. > 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 > Fix For: 9.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 > > > 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 (v7.6.3#76005) - 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-67) Replace Java SplashScreen with a custom window.
[ https://issues.apache.org/jira/browse/NETBEANS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16393812#comment-16393812 ] Eirik Bakke commented on NETBEANS-67: - If work is done on the splash screen code it would be good to make sure it works with HiDPI/retina screens. This should not be difficult; since JDK8, any ImageIcon loaded via "new ImageIcon(URL)" will pick up double-resolution "@2x"-suffixed images as well (e.g. "spl...@2x.png" when the URL is "splash.png"), for instance. Note that NetBeans' ImageUtilities.loadImageIcon does _not_ yet support this as far as I know. I agree with Emilian's comment that the splash screen should really just be a static image--it's less work, less code, and has the advantage of loading the splash screen fast. > Replace Java SplashScreen with a custom window. > --- > > Key: NETBEANS-67 > URL: https://issues.apache.org/jira/browse/NETBEANS-67 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Reporter: Laszlo Kishalmi >Priority: Minor > Labels: MultiMonitor > Attachments: NetBeans_SplashScreen.png > > > Unfortunately the Java SplashScreen feature is not well maintained. It looks > really odd on Linux multi-monitor displays trying to arrange the screen on > the middle of the two monitors. I think the intention of this Java feature > was to create prompt response to the user on opening a Java application. Well > disk and hardware get quicker and Java get leaner on load (with Java 9). > This feature could be replaced by using a custom window instead. > This would improve on two things: > - Placement of the Splash Screen could be really multi-monitor aware > - There is a flicker on startup for those who are upgrading from dev/release > candidate to final release. The first image says developer version then it > updates to release > I'm trying to work something out. Though there is some chance to have some > interference with the platform branding. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-67) Replace Java SplashScreen with a custom window.
[ https://issues.apache.org/jira/browse/NETBEANS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-67: Attachment: blanksplash.png > Replace Java SplashScreen with a custom window. > --- > > Key: NETBEANS-67 > URL: https://issues.apache.org/jira/browse/NETBEANS-67 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Reporter: Laszlo Kishalmi >Priority: Minor > Labels: MultiMonitor > Attachments: NetBeans_SplashScreen.png, blanksplash.png > > > Unfortunately the Java SplashScreen feature is not well maintained. It looks > really odd on Linux multi-monitor displays trying to arrange the screen on > the middle of the two monitors. I think the intention of this Java feature > was to create prompt response to the user on opening a Java application. Well > disk and hardware get quicker and Java get leaner on load (with Java 9). > This feature could be replaced by using a custom window instead. > This would improve on two things: > - Placement of the Splash Screen could be really multi-monitor aware > - There is a flicker on startup for those who are upgrading from dev/release > candidate to final release. The first image says developer version then it > updates to release > I'm trying to work something out. Though there is some chance to have some > interference with the platform branding. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-67) Replace Java SplashScreen with a custom window.
[ https://issues.apache.org/jira/browse/NETBEANS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16394272#comment-16394272 ] Eirik Bakke commented on NETBEANS-67: - Another comment on the existing splash screen code is that it takes too long for the splash image to actually appear--in my own NetBeans Platform application, for instance, 32% of the time that the splash screen window is open before it disappears, the window is just gray (see blanksplash.png, attached). It would be nice to somehow get the loaded image to show immediately as the splash screen opens. Though not sure if there's an easy way to do that. > Replace Java SplashScreen with a custom window. > --- > > Key: NETBEANS-67 > URL: https://issues.apache.org/jira/browse/NETBEANS-67 > Project: NetBeans > Issue Type: Improvement > Components: platform - Other >Reporter: Laszlo Kishalmi >Priority: Minor > Labels: MultiMonitor > Attachments: NetBeans_SplashScreen.png, blanksplash.png > > > Unfortunately the Java SplashScreen feature is not well maintained. It looks > really odd on Linux multi-monitor displays trying to arrange the screen on > the middle of the two monitors. I think the intention of this Java feature > was to create prompt response to the user on opening a Java application. Well > disk and hardware get quicker and Java get leaner on load (with Java 9). > This feature could be replaced by using a custom window instead. > This would improve on two things: > - Placement of the Splash Screen could be really multi-monitor aware > - There is a flicker on startup for those who are upgrading from dev/release > candidate to final release. The first image says developer version then it > updates to release > I'm trying to work something out. Though there is some chance to have some > interference with the platform branding. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-531) "Duplicate method name&signature in class" when running maven app with CoS enabled
Eirik Bakke created NETBEANS-531: Summary: "Duplicate method name&signature in class" when running maven app with CoS enabled Key: NETBEANS-531 URL: https://issues.apache.org/jira/browse/NETBEANS-531 Project: NetBeans Issue Type: Bug Components: java - Classfile, java - Compiler, projects - Maven Affects Versions: 9.0 Environment: Apache NetBeans IDE Dev (Build incubator-netbeans-release-205-on-20180202) on OpenJDK 64-Bit Server VM 9.0.4.1+11, Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb) Reporter: Eirik Bakke Attachments: duplicatenamesig.txt On several occasions, when running a Maven-based NetBeans Platform app from the IDE, the app fails with the exception "java.lang.ClassFormatError: Duplicate method name&signature in class file com/somepackage/project/actions/SomeClass$1". I suspect this might be related to the Compile-on-Save infrastructure. See attached log. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-531) "Duplicate method name&signature in class" when running maven app with CoS enabled
[ https://issues.apache.org/jira/browse/NETBEANS-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-531: - Description: On several occasions, when running a Maven-based NetBeans Platform app from the IDE, the app fails with the exception "java.lang.ClassFormatError: Duplicate method name&signature in class file com/somepackage/project/actions/SomeClass$1". I suspect this might be related to the Compile-on-Save infrastructure. See attached log. A clean build of the entire project is then required in order to make the application runnable again. Previous versions of NetBeans required a clean build after changing annotations (see Bugzilla bug [221781|https://netbeans.org/bugzilla/show_bug.cgi?id=221781]). However, this new error appears even when no annotations have been changed. The specific error message shown here is also new to me--it did not appear in previous NetBeans versions. was:On several occasions, when running a Maven-based NetBeans Platform app from the IDE, the app fails with the exception "java.lang.ClassFormatError: Duplicate method name&signature in class file com/somepackage/project/actions/SomeClass$1". I suspect this might be related to the Compile-on-Save infrastructure. See attached log. > "Duplicate method name&signature in class" when running maven app with CoS > enabled > -- > > Key: NETBEANS-531 > URL: https://issues.apache.org/jira/browse/NETBEANS-531 > Project: NetBeans > Issue Type: Bug > Components: java - Classfile, java - Compiler, projects - Maven >Affects Versions: 9.0 > Environment: Apache NetBeans IDE Dev (Build > incubator-netbeans-release-205-on-20180202) on OpenJDK 64-Bit Server VM > 9.0.4.1+11, Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb) >Reporter: Eirik Bakke >Priority: Major > Attachments: duplicatenamesig.txt > > > On several occasions, when running a Maven-based NetBeans Platform app from > the IDE, the app fails with the exception "java.lang.ClassFormatError: > Duplicate method name&signature in class file > com/somepackage/project/actions/SomeClass$1". I suspect this might be related > to the Compile-on-Save infrastructure. See attached log. A clean build of the > entire project is then required in order to make the application runnable > again. > Previous versions of NetBeans required a clean build after changing > annotations (see Bugzilla bug > [221781|https://netbeans.org/bugzilla/show_bug.cgi?id=221781]). However, this > new error appears even when no annotations have been changed. The specific > error message shown here is also new to me--it did not appear in previous > NetBeans versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-453) "Incorrect number of type arguments" exception during Java editing
[
https://issues.apache.org/jira/browse/NETBEANS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16417347#comment-16417347
]
Eirik Bakke commented on NETBEANS-453:
--
Thanks, Dusan. I will try to gather more information the next time the bug
occurs.
> "Incorrect number of type arguments" exception during Java editing
> --
>
> Key: NETBEANS-453
> URL: https://issues.apache.org/jira/browse/NETBEANS-453
> Project: NetBeans
> Issue Type: Bug
> Components: java - Hints
>Affects Versions: 9.0
> Environment: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-205-on-20180202) on OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb)
>Reporter: Eirik Bakke
>Priority: Major
>
> I got the following Exception while editing a Java file in NetBeans 9.0 Beta:
> {noformat}
> java.lang.IllegalArgumentException: Incorrect number of type arguments
> at com.sun.tools.javac.model.JavacTypes.getDeclaredType0(JavacTypes.java:270)
> at com.sun.tools.javac.model.JavacTypes.getDeclaredType(JavacTypes.java:245)
> at
> org.netbeans.modules.java.hints.errors.Utilities.resolveCapturedTypeInt(Utilities.java:619)
> at
> org.netbeans.modules.java.hints.errors.Utilities.resolveCapturedType(Utilities.java:538)
> at
> org.netbeans.modules.java.hints.errors.Utilities.resolveTypeForDeclaration(Utilities.java:519)
> at
> org.netbeans.modules.java.hints.errors.AddCast.computeType(AddCast.java:193)
> at org.netbeans.modules.java.hints.errors.AddCast.run(AddCast.java:222)
> at
> org.netbeans.modules.java.hints.infrastructure.CreatorBasedLazyFixList.compute(CreatorBasedLazyFixList.java:123)
> at
> org.netbeans.modules.java.hints.infrastructure.LazyHintComputation.run(LazyHintComputation.java:87)
> at
> org.netbeans.modules.java.hints.infrastructure.LazyHintComputation.run(LazyHintComputation.java:33)
> [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.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 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 as a new JIRA issue since the old NetBeans exception reporter
> no longer seems to be in use.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-531) "Duplicate method name&signature in class" when running maven app with CoS enabled
[ https://issues.apache.org/jira/browse/NETBEANS-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16417352#comment-16417352 ] Eirik Bakke commented on NETBEANS-531: -- The error is intermittent--I will try to gather a little more information next time, and see if the class/java files can be shared. Thanks! > "Duplicate method name&signature in class" when running maven app with CoS > enabled > -- > > Key: NETBEANS-531 > URL: https://issues.apache.org/jira/browse/NETBEANS-531 > Project: NetBeans > Issue Type: Bug > Components: java - Classfile, java - Compiler, projects - Maven >Affects Versions: 9.0 > Environment: Apache NetBeans IDE Dev (Build > incubator-netbeans-release-205-on-20180202) on OpenJDK 64-Bit Server VM > 9.0.4.1+11, Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb) >Reporter: Eirik Bakke >Priority: Major > Attachments: duplicatenamesig.txt > > > On several occasions, when running a Maven-based NetBeans Platform app from > the IDE, the app fails with the exception "java.lang.ClassFormatError: > Duplicate method name&signature in class file > com/somepackage/project/actions/SomeClass$1". I suspect this might be related > to the Compile-on-Save infrastructure. See attached log. A clean build of the > entire project is then required in order to make the application runnable > again. > Previous versions of NetBeans required a clean build after changing > annotations (see Bugzilla bug > [221781|https://netbeans.org/bugzilla/show_bug.cgi?id=221781]). However, this > new error appears even when no annotations have been changed. The specific > error message shown here is also new to me--it did not appear in previous > NetBeans versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-454) AssertionError/"Wrong diagnostic handler ... DeferredDiagnosticHandler" when opening Java autocomplete
[
https://issues.apache.org/jira/browse/NETBEANS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16417354#comment-16417354
]
Eirik Bakke commented on NETBEANS-454:
--
Will do--thanks!
> AssertionError/"Wrong diagnostic handler ... DeferredDiagnosticHandler" when
> opening Java autocomplete
> --
>
> Key: NETBEANS-454
> URL: https://issues.apache.org/jira/browse/NETBEANS-454
> Project: NetBeans
> Issue Type: Bug
> Components: editor - Completion & Templates, java - Compiler
>Affects Versions: 9.0
> Environment: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-205-on-20180202) on OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb)
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: threaddump.txt
>
>
> The following exception occurred while opening the autocomplete popup while
> editing a Java file:
> {noformat}
> java.lang.AssertionError: Wrong diagnostic handler:
> com.sun.tools.javac.util.Log$DeferredDiagnosticHandler@7f84b389
> {noformat}
>
> A long thread dump followed, which is attached. Reporting this as a new JIRA
> issue since the old NetBeans exception reporter no longer seems to be in use.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-430) "Invalid or deleted file", "Absent Code attribute" exceptions during Java editing and app/test running
[
https://issues.apache.org/jira/browse/NETBEANS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16417353#comment-16417353
]
Eirik Bakke commented on NETBEANS-430:
--
Will do. Thank you!
> "Invalid or deleted file", "Absent Code attribute" exceptions during Java
> editing and app/test running
> --
>
> Key: NETBEANS-430
> URL: https://issues.apache.org/jira/browse/NETBEANS-430
> Project: NetBeans
> Issue Type: Bug
> Components: guibuilder - Code, java - Classfile, java - Source,
> projects - Maven
>Affects Versions: 9.0
> Environment: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-205-on-20180202), OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS X version 10.9.5
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: parseerror.txt
>
>
> While editing Java sources in a maven-based multi-module NetBeans Platform
> application on NetBeans 9.0 beta, the following IDE exception happens at
> irregular intervals, while editing unrelated files in a different module:
> {noformat}
> ALL [null]: An error occurred during parsing of
> '/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
> Please report a bug against java/source and attach dump file
> '/Users/ebakke/Library/Application
> Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
> {noformat}
> See the attached text file for the complete log dump and stack trace (can't
> attach the ".dump" file as it contains source code). The source file in
> question, FilterPanel.java, is generated in part by the Matisse GUI builder
> (so there's also a FilterPanel.form file). I've also got maven
> Compile-on-Save enabled.
> At other times, occasionally when running the same NetBeans Platform-based
> application, the application itself throws the following exception,
> mentioning the same file:
> {noformat}
> java.lang.ClassFormatError: Absent Code attribute in method that is not
> native or abstract in class file com/somepackage/project/filter/FilterPanel$2
> {noformat}
> See again the attached text file for the complete log dump and stack trace.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-430) "Invalid or deleted file", "Absent Code attribute" exceptions during Java editing and app/test running
[
https://issues.apache.org/jira/browse/NETBEANS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-430:
-
Attachment: Class Files causing Trouble.zip
> "Invalid or deleted file", "Absent Code attribute" exceptions during Java
> editing and app/test running
> --
>
> Key: NETBEANS-430
> URL: https://issues.apache.org/jira/browse/NETBEANS-430
> Project: NetBeans
> Issue Type: Bug
> Components: guibuilder - Code, java - Classfile, java - Source,
> projects - Maven
>Affects Versions: 9.0
> Environment: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-205-on-20180202), OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS X version 10.9.5
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: Class Files causing Trouble.zip, parseerror.txt
>
>
> While editing Java sources in a maven-based multi-module NetBeans Platform
> application on NetBeans 9.0 beta, the following IDE exception happens at
> irregular intervals, while editing unrelated files in a different module:
> {noformat}
> ALL [null]: An error occurred during parsing of
> '/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
> Please report a bug against java/source and attach dump file
> '/Users/ebakke/Library/Application
> Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
> {noformat}
> See the attached text file for the complete log dump and stack trace (can't
> attach the ".dump" file as it contains source code). The source file in
> question, FilterPanel.java, is generated in part by the Matisse GUI builder
> (so there's also a FilterPanel.form file). I've also got maven
> Compile-on-Save enabled.
> At other times, occasionally when running the same NetBeans Platform-based
> application, the application itself throws the following exception,
> mentioning the same file:
> {noformat}
> java.lang.ClassFormatError: Absent Code attribute in method that is not
> native or abstract in class file com/somepackage/project/filter/FilterPanel$2
> {noformat}
> See again the attached text file for the complete log dump and stack trace.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-430) "Invalid or deleted file", "Absent Code attribute" exceptions during Java editing and app/test running
[
https://issues.apache.org/jira/browse/NETBEANS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16418222#comment-16418222
]
Eirik Bakke commented on NETBEANS-430:
--
The error occurred again today when I was starting my NetBeans Platform app:
"java.lang.ClassFormatError: Absent Code attribute in method that is not native
or abstract in class file com/sieuferd/datamodel/ViewPropertyTypes$3".
This is a Maven-based NetBeans platform application with Compile-on-Save
enabled, so there are two different versions of the ViewPropertyTypes.class and
ViewPropertyTypes$3.class files: one pair in the JAR file that was built on the
last clean build (with last-modified-date March 21), and one pair in the
"common-datamodel/target/classes/com/sieuferd/datamodel" directory that were
generated by Compile-on-Save (with last-modified-date March 23).
Note that I have never edited the ViewPropertyTypes source since the last
Compile-on-Save, but Compile-on-Save has regenerated it for some reason. If I
do edit the source file, the class files are indeed regenerated with a
last-modified-date of today. The error still occurs, until the next clean build.
The pairs of class files are attached, along with the console output.
> "Invalid or deleted file", "Absent Code attribute" exceptions during Java
> editing and app/test running
> --
>
> Key: NETBEANS-430
> URL: https://issues.apache.org/jira/browse/NETBEANS-430
> Project: NetBeans
> Issue Type: Bug
> Components: guibuilder - Code, java - Classfile, java - Source,
> projects - Maven
>Affects Versions: 9.0
> Environment: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-205-on-20180202), OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS X version 10.9.5
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: Class Files causing Trouble.zip, parseerror.txt
>
>
> While editing Java sources in a maven-based multi-module NetBeans Platform
> application on NetBeans 9.0 beta, the following IDE exception happens at
> irregular intervals, while editing unrelated files in a different module:
> {noformat}
> ALL [null]: An error occurred during parsing of
> '/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
> Please report a bug against java/source and attach dump file
> '/Users/ebakke/Library/Application
> Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
> {noformat}
> See the attached text file for the complete log dump and stack trace (can't
> attach the ".dump" file as it contains source code). The source file in
> question, FilterPanel.java, is generated in part by the Matisse GUI builder
> (so there's also a FilterPanel.form file). I've also got maven
> Compile-on-Save enabled.
> At other times, occasionally when running the same NetBeans Platform-based
> application, the application itself throws the following exception,
> mentioning the same file:
> {noformat}
> java.lang.ClassFormatError: Absent Code attribute in method that is not
> native or abstract in class file com/somepackage/project/filter/FilterPanel$2
> {noformat}
> See again the attached text file for the complete log dump and stack trace.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-430) "Invalid or deleted file", "Absent Code attribute" exceptions during Java editing and app/test running
[
https://issues.apache.org/jira/browse/NETBEANS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16418229#comment-16418229
]
Eirik Bakke commented on NETBEANS-430:
--
Also tried editing the file after the clean build to force a Compile-on-Save.
The class file was regenerated, but the error does _not_ show up merely as a
result of doing a save. So I'm still not quite sure how to reproduce it.
> "Invalid or deleted file", "Absent Code attribute" exceptions during Java
> editing and app/test running
> --
>
> Key: NETBEANS-430
> URL: https://issues.apache.org/jira/browse/NETBEANS-430
> Project: NetBeans
> Issue Type: Bug
> Components: guibuilder - Code, java - Classfile, java - Source,
> projects - Maven
>Affects Versions: 9.0
> Environment: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-205-on-20180202), OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS X version 10.9.5
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: Class Files causing Trouble.zip, parseerror.txt
>
>
> While editing Java sources in a maven-based multi-module NetBeans Platform
> application on NetBeans 9.0 beta, the following IDE exception happens at
> irregular intervals, while editing unrelated files in a different module:
> {noformat}
> ALL [null]: An error occurred during parsing of
> '/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
> Please report a bug against java/source and attach dump file
> '/Users/ebakke/Library/Application
> Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
> {noformat}
> See the attached text file for the complete log dump and stack trace (can't
> attach the ".dump" file as it contains source code). The source file in
> question, FilterPanel.java, is generated in part by the Matisse GUI builder
> (so there's also a FilterPanel.form file). I've also got maven
> Compile-on-Save enabled.
> At other times, occasionally when running the same NetBeans Platform-based
> application, the application itself throws the following exception,
> mentioning the same file:
> {noformat}
> java.lang.ClassFormatError: Absent Code attribute in method that is not
> native or abstract in class file com/somepackage/project/filter/FilterPanel$2
> {noformat}
> See again the attached text file for the complete log dump and stack trace.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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&focusedCommentId=16419197#comment-16419197 ] Eirik Bakke commented on NETBEANS-378: -- Michal--it seems you're on Linux (Guilio is on Windows), but it's still interesting. When you use GDK_SCALE=2, does the editor font look blurry, or is it still sharp? Maybe you could post a screenshot next to IntelliJ for comparison. > 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 > Attachments: Installer.PNG, keymap.PNG, plugins.PNG, tab.PNG > > > 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 (v7.6.3#76005) - 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&focusedCommentId=16424124#comment-16424124 ] Eirik Bakke commented on NETBEANS-378: -- Hmm, the "--fontsize 24" options seem to have more problems--icons become much smaller than the surrounding text. But maybe you prefer that? Yeah, it would be nice to do some tuning for HiDPI on Linux, too--though at least the text renders properly and the UI isn't unusable as it was on previous JDK versions. > 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 > Attachments: Installer.PNG, Screenshot_Idea.png, > Screenshot_Netbeans.png, Screenshot_Netbeans_Fontsize24.png, keymap.PNG, > plugins.PNG, tab.PNG > > > 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 (v7.6.3#76005) - 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-564) Opening .form/.java file raises exception from java parser
[
https://issues.apache.org/jira/browse/NETBEANS-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16429096#comment-16429096
]
Eirik Bakke commented on NETBEANS-564:
--
I can confirm that the error occurs when opening
org.netbeans.modules.subversion.util.NotifyHtmlPanel (and many other form files
in other projects). A similar bug was reported at
https://issues.apache.org/jira/browse/NETBEANS-430 , but the interesting thing
in this one is that the error has been reproduced in a project that's _not_ a
maven project.
> Opening .form/.java file raises exception from java parser
> --
>
> Key: NETBEANS-564
> URL: https://issues.apache.org/jira/browse/NETBEANS-564
> Project: NetBeans
> Issue Type: Bug
> Components: java - Source
>Affects Versions: 9.0
>Reporter: Matthias Bläsing
>Priority: Major
> Attachments: NotifyHtmlPanel.dump
>
>
> h2. Error
> When opening a .form/.java file combination I get an exception, that is
> raised from the java parser:
> {noformat}
> Annotation: An error occurred during parsing of
> '/tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java'. Please
> report a bug against java/source and attach dump file
> '/home/matthias/src/incubator-netbeans/nbbuild/testuserdir/var/log/NotifyHtmlPanel.dump'.
> Annotation: An error occurred during parsing of
> '/tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java'. Please
> report a bug against java/source and attach dump file
> '/home/matthias/src/incubator-netbeans/nbbuild/testuserdir/var/log/NotifyHtmlPanel.dump'.
> Annotation: An error occurred during parsing of
> '/tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java'. Please
> report a bug against java/source and attach dump file
> '/home/matthias/src/incubator-netbeans/nbbuild/testuserdir/var/log/NotifyHtmlPanel.dump'.
> Annotation: An error occurred during parsing of
> '/tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java'. Please
> report a bug against java/source and attach dump file
> '/home/matthias/src/incubator-netbeans/nbbuild/testuserdir/var/log/NotifyHtmlPanel.dump'.
> An error occurred during parsing of
> '/tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java'. Please
> report a bug against java/source and attach dump file
> '/home/matthias/src/incubator-netbeans/nbbuild/testuserdir/var/log/NotifyHtmlPanel.dump'.
> An error occurred during parsing of
> '/tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java'. Please
> report a bug against java/source and attach dump file
> '/home/matthias/src/incubator-netbeans/nbbuild/testuserdir/var/log/NotifyHtmlPanel.dump'.
> Caused:
> org.netbeans.modules.java.source.parsing.FileObjects$InvalidFileException:
> Invalid or deleted file:
> /tmp/vcs-1522660054567/vcs-1522660054568/NotifyHtmlPanel.java
> at
> org.netbeans.modules.java.source.parsing.FileObjects.sourceFileObject(FileObjects.java:354)
> at
> org.netbeans.modules.java.source.parsing.FileObjects.sourceFileObject(FileObjects.java:334)
> Caused: java.lang.IllegalArgumentException
> at
> org.netbeans.modules.java.source.parsing.FileObjects.sourceFileObject(FileObjects.java:337)
> at
> org.netbeans.modules.java.source.parsing.JavacParser.createJavacTask(JavacParser.java:730)
> at
> org.netbeans.modules.java.source.parsing.CompilationInfoImpl.getJavacTask(CompilationInfoImpl.java:374)
> [catch] at
> org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(JavacParser.java:580)
> at
> org.netbeans.modules.java.source.parsing.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:361)
> at
> org.netbeans.api.java.source.CompilationController.toPhase(CompilationController.java:84)
> at
> org.netbeans.modules.java.JavaNode$IconTask$SourceIcon$1.run(JavaNode.java:443)
> at
> org.netbeans.modules.java.JavaNode$IconTask$SourceIcon$1.run(JavaNode.java:440)
> 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(DataObjectEnvFactor
[jira] [Commented] (NETBEANS-430) "Invalid or deleted file", "Absent Code attribute" exceptions during Java editing and app/test running
[
https://issues.apache.org/jira/browse/NETBEANS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16429098#comment-16429098
]
Eirik Bakke commented on NETBEANS-430:
--
A similar error is reported at
https://issues.apache.org/jira/browse/NETBEANS-564 , with confirmed steps to
reproduce. In the latter case the file is in an Ant project as opposed to a
Maven project.
> "Invalid or deleted file", "Absent Code attribute" exceptions during Java
> editing and app/test running
> --
>
> Key: NETBEANS-430
> URL: https://issues.apache.org/jira/browse/NETBEANS-430
> Project: NetBeans
> Issue Type: Bug
> Components: guibuilder - Code, java - Classfile, java - Source,
> projects - Maven
>Affects Versions: 9.0
> Environment: Apache NetBeans IDE Dev (Build
> incubator-netbeans-release-205-on-20180202), OpenJDK 64-Bit Server VM
> 9.0.4.1+11, Mac OS X version 10.9.5
>Reporter: Eirik Bakke
>Priority: Major
> Attachments: Class Files causing Trouble.zip, parseerror.txt
>
>
> While editing Java sources in a maven-based multi-module NetBeans Platform
> application on NetBeans 9.0 beta, the following IDE exception happens at
> irregular intervals, while editing unrelated files in a different module:
> {noformat}
> ALL [null]: An error occurred during parsing of
> '/var/folders/38/g_r_gdts0wx49_kbz5sjfj30gn/T/vcs-1518825448194/vcs-1519673427266/FilterPanel.java'.
> Please report a bug against java/source and attach dump file
> '/Users/ebakke/Library/Application
> Support/NetBeans/dev/var/log/FilterPanel_8.dump'.
> {noformat}
> See the attached text file for the complete log dump and stack trace (can't
> attach the ".dump" file as it contains source code). The source file in
> question, FilterPanel.java, is generated in part by the Matisse GUI builder
> (so there's also a FilterPanel.form file). I've also got maven
> Compile-on-Save enabled.
> At other times, occasionally when running the same NetBeans Platform-based
> application, the application itself throws the following exception,
> mentioning the same file:
> {noformat}
> java.lang.ClassFormatError: Absent Code attribute in method that is not
> native or abstract in class file com/somepackage/project/filter/FilterPanel$2
> {noformat}
> See again the attached text file for the complete log dump and stack trace.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-673) Add support for MariaDB JDBC driver in Add Connection dialog
Eirik Bakke created NETBEANS-673: Summary: Add support for MariaDB JDBC driver in Add Connection dialog Key: NETBEANS-673 URL: https://issues.apache.org/jira/browse/NETBEANS-673 Project: NetBeans Issue Type: Bug Components: db - Code Affects Versions: 9.0 Reporter: Eirik Bakke The "Add Connection" wizard does not currently recognize the MariaDB JDBC driver; this means that the "host", "port", and "database" fields do not end up being shown in the connection panel. Instead, the user has to manually construct the JDBC URL to insert this information. The fix is simple; a new entry needs to be added in org.netbeans.modules.db.util.DriverListUtil , recognizing the driver class "org.mariadb.jdbc.Driver" (instead of "com.mysql.jdbc.Driver" for MySQL). The MariaDB driver uses the exact same format for its JDBC URLs as MySQL, except allows the protocol name "mariadb" to be used instead of "mysql". (MariaDB and its driver aims to be completely compatible with MySQL--either driver can be used to connect to either database. The MariaDB JDBC driver is LGPL while MySQL's driver is GPL, however, making only the MariaDB one suitable for bundling with commercial software.) See also https://issues.apache.org/jira/browse/NETBEANS-170, which deals with simplifying the JDBC driver download process. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-673) Add support for MariaDB JDBC driver in Add Connection dialog
[ https://issues.apache.org/jira/browse/NETBEANS-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-673: - Attachment: NETBEANS-673 Patch Screenshot.png > Add support for MariaDB JDBC driver in Add Connection dialog > > > Key: NETBEANS-673 > URL: https://issues.apache.org/jira/browse/NETBEANS-673 > Project: NetBeans > Issue Type: Bug > Components: db - Code >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Minor > Labels: pull-request-available > Attachments: NETBEANS-673 Patch Screenshot.png > > Time Spent: 10m > Remaining Estimate: 0h > > The "Add Connection" wizard does not currently recognize the MariaDB JDBC > driver; this means that the "host", "port", and "database" fields do not end > up being shown in the connection panel. Instead, the user has to manually > construct the JDBC URL to insert this information. > The fix is simple; a new entry needs to be added in > org.netbeans.modules.db.util.DriverListUtil , recognizing the driver class > "org.mariadb.jdbc.Driver" (instead of "com.mysql.jdbc.Driver" for MySQL). The > MariaDB driver uses the exact same format for its JDBC URLs as MySQL, except > allows the protocol name "mariadb" to be used instead of "mysql". > (MariaDB and its driver aims to be completely compatible with MySQL--either > driver can be used to connect to either database. The MariaDB JDBC driver is > LGPL while MySQL's driver is GPL, however, making only the MariaDB one > suitable for bundling with commercial software.) > See also https://issues.apache.org/jira/browse/NETBEANS-170, which deals with > simplifying the JDBC driver download process. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-673) Add support for MariaDB JDBC driver in Add Connection dialog
[ https://issues.apache.org/jira/browse/NETBEANS-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16440277#comment-16440277 ] Eirik Bakke commented on NETBEANS-673: -- I've submitted a pull request on GitHub; see the attached screenshot for how it works after the patch is applied. > Add support for MariaDB JDBC driver in Add Connection dialog > > > Key: NETBEANS-673 > URL: https://issues.apache.org/jira/browse/NETBEANS-673 > Project: NetBeans > Issue Type: Bug > Components: db - Code >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Minor > Labels: pull-request-available > Attachments: NETBEANS-673 Patch Screenshot.png > > Time Spent: 10m > Remaining Estimate: 0h > > The "Add Connection" wizard does not currently recognize the MariaDB JDBC > driver; this means that the "host", "port", and "database" fields do not end > up being shown in the connection panel. Instead, the user has to manually > construct the JDBC URL to insert this information. > The fix is simple; a new entry needs to be added in > org.netbeans.modules.db.util.DriverListUtil , recognizing the driver class > "org.mariadb.jdbc.Driver" (instead of "com.mysql.jdbc.Driver" for MySQL). The > MariaDB driver uses the exact same format for its JDBC URLs as MySQL, except > allows the protocol name "mariadb" to be used instead of "mysql". > (MariaDB and its driver aims to be completely compatible with MySQL--either > driver can be used to connect to either database. The MariaDB JDBC driver is > LGPL while MySQL's driver is GPL, however, making only the MariaDB one > suitable for bundling with commercial software.) > See also https://issues.apache.org/jira/browse/NETBEANS-170, which deals with > simplifying the JDBC driver download process. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-673) Add support for MariaDB JDBC driver in Add Connection dialog
[ https://issues.apache.org/jira/browse/NETBEANS-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-673: - Attachment: (was: NETBEANS-673 Patch Screenshot.png) > Add support for MariaDB JDBC driver in Add Connection dialog > > > Key: NETBEANS-673 > URL: https://issues.apache.org/jira/browse/NETBEANS-673 > Project: NetBeans > Issue Type: Bug > Components: db - Code >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Minor > Labels: pull-request-available > Attachments: NETBEANS-673 Patch Screenshot Updated.png > > Time Spent: 10m > Remaining Estimate: 0h > > The "Add Connection" wizard does not currently recognize the MariaDB JDBC > driver; this means that the "host", "port", and "database" fields do not end > up being shown in the connection panel. Instead, the user has to manually > construct the JDBC URL to insert this information. > The fix is simple; a new entry needs to be added in > org.netbeans.modules.db.util.DriverListUtil , recognizing the driver class > "org.mariadb.jdbc.Driver" (instead of "com.mysql.jdbc.Driver" for MySQL). The > MariaDB driver uses the exact same format for its JDBC URLs as MySQL, except > allows the protocol name "mariadb" to be used instead of "mysql". > (MariaDB and its driver aims to be completely compatible with MySQL--either > driver can be used to connect to either database. The MariaDB JDBC driver is > LGPL while MySQL's driver is GPL, however, making only the MariaDB one > suitable for bundling with commercial software.) > See also https://issues.apache.org/jira/browse/NETBEANS-170, which deals with > simplifying the JDBC driver download process. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-673) Add support for MariaDB JDBC driver in Add Connection dialog
[ https://issues.apache.org/jira/browse/NETBEANS-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-673: - Attachment: NETBEANS-673 Patch Screenshot Updated.png > Add support for MariaDB JDBC driver in Add Connection dialog > > > Key: NETBEANS-673 > URL: https://issues.apache.org/jira/browse/NETBEANS-673 > Project: NetBeans > Issue Type: Bug > Components: db - Code >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Minor > Labels: pull-request-available > Attachments: NETBEANS-673 Patch Screenshot Updated.png > > Time Spent: 10m > Remaining Estimate: 0h > > The "Add Connection" wizard does not currently recognize the MariaDB JDBC > driver; this means that the "host", "port", and "database" fields do not end > up being shown in the connection panel. Instead, the user has to manually > construct the JDBC URL to insert this information. > The fix is simple; a new entry needs to be added in > org.netbeans.modules.db.util.DriverListUtil , recognizing the driver class > "org.mariadb.jdbc.Driver" (instead of "com.mysql.jdbc.Driver" for MySQL). The > MariaDB driver uses the exact same format for its JDBC URLs as MySQL, except > allows the protocol name "mariadb" to be used instead of "mysql". > (MariaDB and its driver aims to be completely compatible with MySQL--either > driver can be used to connect to either database. The MariaDB JDBC driver is > LGPL while MySQL's driver is GPL, however, making only the MariaDB one > suitable for bundling with commercial software.) > See also https://issues.apache.org/jira/browse/NETBEANS-170, which deals with > simplifying the JDBC driver download process. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-403) Pressing Home/End scrolls to beginning/end of whole document if tooltip is open
[ https://issues.apache.org/jira/browse/NETBEANS-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16441038#comment-16441038 ] Eirik Bakke commented on NETBEANS-403: -- I've added a pull request on GitHub. Looking further into this, o.n.editor.ext.ToolTipSupport.filterBindings is _not_ the right place to fix this. The latter method removes certain actions unconditionally from the popup whether or not it has focus (originally to prevent the user from being able to cut text from the popup; see https://netbeans.org/bugzilla/show_bug.cgi?id=220942 ). Adding for instance "caret-end" to the filterBindings list is confirmed to prevent the caret-end action from working even when the popup has focus. Instead, the patch tweaks the keystroke forwarding logic in o.n.editor.PopupManager. A comment there already states the intention of the previous logic, namely to "ignore ToolTipSupport installed actions". Presumably the comment refers to actions of the kinds of popups created by ToolTipSupport.setToolTipText or ToolTipSupport.createDefaultTooltip. The previous logic falls short of this intention, only avoiding forwarding for the actions listed in filterBindings (as well as the default action). Instead, the proposed new logic simply checks if the popup component is a JTextComponent. This covers the standard text tooltips created by ToolTipSupport.setToolTipText/createDefaultTooltip--and arguably any other similar JTextComponent tooltips should not have text actions forwarded to them either. The original motivation for forwarding actions into tooltips was for use in the debugger; see https://netbeans.org/bugzilla/show_bug.cgi?id=262311 . In that case, the tooltip is an instance of o.n.spi.debugger.ui.ToolTipUI.ExpandableTooltip (set via ToolTipSupport.setToolTip), which is not an instance of JTextComponent. It should thus be unaffected by this patch. > Pressing Home/End scrolls to beginning/end of whole document if tooltip is > open > --- > > Key: NETBEANS-403 > URL: https://issues.apache.org/jira/browse/NETBEANS-403 > Project: NetBeans > Issue Type: Bug > Components: editor - Key bindings >Affects Versions: 8.2, 9.0 >Reporter: Eirik Bakke >Priority: Major > Labels: pull-request-available > Attachments: HomeEndBug.png > > Time Spent: 10m > Remaining Estimate: 0h > > When a tooltip is shown in the Java editor, for instance because the mouse is > hovering over an error indication, pressing the Home or End keys on the > keyboard scrolls the entire document all the way to the top or end, > respectively instead of to the beginning or end of the current line. This is > extremely disruptive, and likely very confusing to users, as it only happens > in the stated situation. > A workaround is to move the mouse pointer away from the editor to close the > popup after examining an error. Most users will not be able to discover this > workaround, though--for myself, it took two weeks to discover the correlation > between the tooltip being open and the bug occurring. > This bug seems to have been introduced in 8.2, and I just confirmed that it > is still present on the new Apache NetBeans 9.0 beta release. > This issue was first reported as issue #270842 by timothyrheider in the old > BugZilla tracker, on 2017-06-09: > https://netbeans.org/bugzilla/show_bug.cgi?id=270842 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-673) Add support for MariaDB JDBC driver in Add Connection dialog
[ https://issues.apache.org/jira/browse/NETBEANS-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16442632#comment-16442632 ] Eirik Bakke commented on NETBEANS-673: -- Hi, Christian--this change does _not_ actually add a "MariaDB" entry to any part of the GUI, unless the user explicitly on their own adds the MariaDB JDBC driver. If you look at [DriverListUtil|https://github.com/eirikbakke/incubator-netbeans/blob/7e88b0562cff8bc450f6d339af9ed535c92ce739/db/src/org/netbeans/modules/db/util/DriverListUtil.java], it's a huge list of current and historical JDBC drivers that never appear anywhere unless a user at some points add the relevant driver JAR. You'll see more and more users adding the MariaDB driver instead of the MySQL driver in the future, in which case this patch becomes necessary. The MySQL driver cannot be downloaded anymore without signing up for an Oracle account, and Apache won't be able to distribute either driver with NetBeans in the future. (My own particular use case is to bundle the MariaDB driver with a commercial NetBeans Platform application. The MySQL driver cannot be bundled this way, since it's GPL.) > Add support for MariaDB JDBC driver in Add Connection dialog > > > Key: NETBEANS-673 > URL: https://issues.apache.org/jira/browse/NETBEANS-673 > Project: NetBeans > Issue Type: Bug > Components: db - Code >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Minor > Labels: pull-request-available > Attachments: NETBEANS-673 Patch Screenshot Updated.png > > Time Spent: 50m > Remaining Estimate: 0h > > The "Add Connection" wizard does not currently recognize the MariaDB JDBC > driver; this means that the "host", "port", and "database" fields do not end > up being shown in the connection panel. Instead, the user has to manually > construct the JDBC URL to insert this information. > The fix is simple; a new entry needs to be added in > org.netbeans.modules.db.util.DriverListUtil , recognizing the driver class > "org.mariadb.jdbc.Driver" (instead of "com.mysql.jdbc.Driver" for MySQL). The > MariaDB driver uses the exact same format for its JDBC URLs as MySQL, except > allows the protocol name "mariadb" to be used instead of "mysql". > (MariaDB and its driver aims to be completely compatible with MySQL--either > driver can be used to connect to either database. The MariaDB JDBC driver is > LGPL while MySQL's driver is GPL, however, making only the MariaDB one > suitable for bundling with commercial software.) > See also https://issues.apache.org/jira/browse/NETBEANS-170, which deals with > simplifying the JDBC driver download process. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-673) Add support for MariaDB JDBC driver in Add Connection dialog
[ https://issues.apache.org/jira/browse/NETBEANS-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16442697#comment-16442697 ] Eirik Bakke commented on NETBEANS-673: -- The pull request on https://github.com/apache/incubator-netbeans/pull/506 was accepted--closing this issue. The issue of bundling JDBC drivers is covered on this separate issue: https://issues.apache.org/jira/browse/NETBEANS-170 > Add support for MariaDB JDBC driver in Add Connection dialog > > > Key: NETBEANS-673 > URL: https://issues.apache.org/jira/browse/NETBEANS-673 > Project: NetBeans > Issue Type: Bug > Components: db - Code >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Minor > Labels: pull-request-available > Attachments: NETBEANS-673 Patch Screenshot Updated.png > > Time Spent: 50m > Remaining Estimate: 0h > > The "Add Connection" wizard does not currently recognize the MariaDB JDBC > driver; this means that the "host", "port", and "database" fields do not end > up being shown in the connection panel. Instead, the user has to manually > construct the JDBC URL to insert this information. > The fix is simple; a new entry needs to be added in > org.netbeans.modules.db.util.DriverListUtil , recognizing the driver class > "org.mariadb.jdbc.Driver" (instead of "com.mysql.jdbc.Driver" for MySQL). The > MariaDB driver uses the exact same format for its JDBC URLs as MySQL, except > allows the protocol name "mariadb" to be used instead of "mysql". > (MariaDB and its driver aims to be completely compatible with MySQL--either > driver can be used to connect to either database. The MariaDB JDBC driver is > LGPL while MySQL's driver is GPL, however, making only the MariaDB one > suitable for bundling with commercial software.) > See also https://issues.apache.org/jira/browse/NETBEANS-170, which deals with > simplifying the JDBC driver download process. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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] [Closed] (NETBEANS-673) Add support for MariaDB JDBC driver in Add Connection dialog
[ https://issues.apache.org/jira/browse/NETBEANS-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke closed NETBEANS-673. Resolution: Fixed Pull request at https://github.com/apache/incubator-netbeans/pull/506 was accepted; closing the issue. > Add support for MariaDB JDBC driver in Add Connection dialog > > > Key: NETBEANS-673 > URL: https://issues.apache.org/jira/browse/NETBEANS-673 > Project: NetBeans > Issue Type: Bug > Components: db - Code >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Minor > Labels: pull-request-available > Attachments: NETBEANS-673 Patch Screenshot Updated.png > > Time Spent: 50m > Remaining Estimate: 0h > > The "Add Connection" wizard does not currently recognize the MariaDB JDBC > driver; this means that the "host", "port", and "database" fields do not end > up being shown in the connection panel. Instead, the user has to manually > construct the JDBC URL to insert this information. > The fix is simple; a new entry needs to be added in > org.netbeans.modules.db.util.DriverListUtil , recognizing the driver class > "org.mariadb.jdbc.Driver" (instead of "com.mysql.jdbc.Driver" for MySQL). The > MariaDB driver uses the exact same format for its JDBC URLs as MySQL, except > allows the protocol name "mariadb" to be used instead of "mysql". > (MariaDB and its driver aims to be completely compatible with MySQL--either > driver can be used to connect to either database. The MariaDB JDBC driver is > LGPL while MySQL's driver is GPL, however, making only the MariaDB one > suitable for bundling with commercial software.) > See also https://issues.apache.org/jira/browse/NETBEANS-170, which deals with > simplifying the JDBC driver download process. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-404) Javadoc popup is poorly rendered
[ https://issues.apache.org/jira/browse/NETBEANS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447240#comment-16447240 ] Eirik Bakke commented on NETBEANS-404: -- Yup--thanks! > Javadoc popup is poorly rendered > > > Key: NETBEANS-404 > URL: https://issues.apache.org/jira/browse/NETBEANS-404 > Project: NetBeans > Issue Type: Bug > Components: editor - Completion & Templates, editor - Hints > & Annotations >Affects Versions: 8.2, 9.0 >Reporter: Eirik Bakke >Assignee: Eirik Bakke >Priority: Minor > Labels: pull-request-available > Fix For: 9.0 > > Attachments: darcula-javadoc.png, javadoc.patch, javadocscreenshot.png > > Time Spent: 2.5h > Remaining Estimate: 0h > > This is a patch for the old issue 236403 with the same name, see > [https://netbeans.org/bugzilla/show_bug.cgi?id=236403] . > Since about NetBeans 7.4, the Java editor's Javadoc popup has been rendered > with an all-monospace font. There have also been various complaints about the > Javadoc's font size (which the monospace font "fixed" because the monospace > font looks larger at the same point size). > The attached patch makes the Javadoc popup once again use a non-monospace > font (as in generated Javadoc HTML), while at the same time increasing the > font size to match the editor's own zoom level. See the attached screenshot. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-712) On Aqua, sub-tabs in "Output" tab have vertically off-center text and close buttons
Eirik Bakke created NETBEANS-712:
Summary: On Aqua, sub-tabs in "Output" tab have vertically
off-center text and close buttons
Key: NETBEANS-712
URL: https://issues.apache.org/jira/browse/NETBEANS-712
Project: NetBeans
Issue Type: Bug
Components: platform - Window System
Affects Versions: 8.2, 9.0
Reporter: Eirik Bakke
Attachments: xalignment251441-patch-illustration.png
On MacOS/Aqua, the text and close ("X") buttons of sub-tabs in the "Output"
TopComponents such as "Debugger Console" and "Run", are vertically off-center.
The attached screenshot shows the problem, and what it looks like after the
patch I'm about to propose.
Originally bugzilla issue 251441. Creating an issue here to associate with an
upcoming pull request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-712) On Aqua, sub-tabs in "Output" tab have vertically off-center text and close buttons
[
https://issues.apache.org/jira/browse/NETBEANS-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Bakke updated NETBEANS-712:
-
Priority: Minor (was: Major)
> On Aqua, sub-tabs in "Output" tab have vertically off-center text and close
> buttons
> ---
>
> Key: NETBEANS-712
> URL: https://issues.apache.org/jira/browse/NETBEANS-712
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Window System
>Affects Versions: 8.2, 9.0
>Reporter: Eirik Bakke
>Priority: Minor
> Attachments: xalignment251441-patch-illustration.png
>
>
> On MacOS/Aqua, the text and close ("X") buttons of sub-tabs in the "Output"
> TopComponents such as "Debugger Console" and "Run", are vertically
> off-center. The attached screenshot shows the problem, and what it looks like
> after the patch I'm about to propose.
> Originally bugzilla issue 251441. Creating an issue here to associate with an
> upcoming pull request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-713) HighlightingManager does not track changes to HighlightsLayerExcludes correctly
Eirik Bakke created NETBEANS-713: Summary: HighlightingManager does not track changes to HighlightsLayerExcludes correctly Key: NETBEANS-713 URL: https://issues.apache.org/jira/browse/NETBEANS-713 Project: NetBeans Issue Type: Bug Affects Versions: 8.2, 9.0 Reporter: Eirik Bakke (Copied from Bugzilla bug [248664|https://netbeans.org/bugzilla/show_bug.cgi?id=248664]:) The editor API defines the JEditorPane client properties [HighlightsLayerExcludes and HighlightsLayerIncludes|http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor-lib2/index.html?org/netbeans/spi/editor/highlighting/package-summary.html] to allow clients to show/hide specific highlight layers on demand. The bug is that modifications to these properties are not reflected properly in the editor. The bug seems to be in o.n.modules.editor.lib2.highlighting.HighlightingManager.Highlighting. In the constructor, the paneFilter variable is initialized once from the HighlightsLayerExcludes/HighlightsLayerIncludes client properties, right above where the propertyChangeListener that is supposed to track changes to it is added. The PropertyChangeListener reacts to changes to the client properties by calling rebuildAllLayers(), which calls rebuildAllLayersImpl(), which always just uses the value of paneFilter set in the constructor. Adding this as a JIRA issue to associate with a pull request that I'm about to open. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-713) HighlightingManager does not track changes to HighlightsLayerExcludes correctly
[ https://issues.apache.org/jira/browse/NETBEANS-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-713: - Description: (Copied from Bugzilla bug [248664|https://netbeans.org/bugzilla/show_bug.cgi?id=248664] ) The editor API defines the JEditorPane client properties [HighlightsLayerExcludes and HighlightsLayerIncludes|http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor-lib2/index.html?org/netbeans/spi/editor/highlighting/package-summary.html] to allow clients to show/hide specific highlight layers on demand. The bug is that modifications to these properties are not reflected properly in the editor. The bug seems to be in o.n.modules.editor.lib2.highlighting.HighlightingManager.Highlighting. In the constructor, the paneFilter variable is initialized once from the HighlightsLayerExcludes/HighlightsLayerIncludes client properties, right above where the propertyChangeListener that is supposed to track changes to it is added. The PropertyChangeListener reacts to changes to the client properties by calling rebuildAllLayers(), which calls rebuildAllLayersImpl(), which always just uses the value of paneFilter set in the constructor. Adding this as a JIRA issue to associate with a pull request that I'm about to open. was: (Copied from Bugzilla bug [248664|https://netbeans.org/bugzilla/show_bug.cgi?id=248664]:) The editor API defines the JEditorPane client properties [HighlightsLayerExcludes and HighlightsLayerIncludes|http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor-lib2/index.html?org/netbeans/spi/editor/highlighting/package-summary.html] to allow clients to show/hide specific highlight layers on demand. The bug is that modifications to these properties are not reflected properly in the editor. The bug seems to be in o.n.modules.editor.lib2.highlighting.HighlightingManager.Highlighting. In the constructor, the paneFilter variable is initialized once from the HighlightsLayerExcludes/HighlightsLayerIncludes client properties, right above where the propertyChangeListener that is supposed to track changes to it is added. The PropertyChangeListener reacts to changes to the client properties by calling rebuildAllLayers(), which calls rebuildAllLayersImpl(), which always just uses the value of paneFilter set in the constructor. Adding this as a JIRA issue to associate with a pull request that I'm about to open. > HighlightingManager does not track changes to HighlightsLayerExcludes > correctly > --- > > Key: NETBEANS-713 > URL: https://issues.apache.org/jira/browse/NETBEANS-713 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2, 9.0 >Reporter: Eirik Bakke >Priority: Minor > > (Copied from Bugzilla bug > [248664|https://netbeans.org/bugzilla/show_bug.cgi?id=248664] ) > The editor API defines the JEditorPane client properties > [HighlightsLayerExcludes and > HighlightsLayerIncludes|http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor-lib2/index.html?org/netbeans/spi/editor/highlighting/package-summary.html] > to allow clients to show/hide specific highlight layers on demand. The bug > is that modifications to these properties are not reflected properly in the > editor. > The bug seems to be in > o.n.modules.editor.lib2.highlighting.HighlightingManager.Highlighting. In the > constructor, the paneFilter variable is initialized once from the > HighlightsLayerExcludes/HighlightsLayerIncludes client properties, right > above where the propertyChangeListener that is supposed to track changes to > it is added. The PropertyChangeListener reacts to changes to the client > properties by calling rebuildAllLayers(), which calls rebuildAllLayersImpl(), > which always just uses the value of paneFilter set in the constructor. > Adding this as a JIRA issue to associate with a pull request that I'm about > to open. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-713) HighlightingManager does not track changes to HighlightsLayerExcludes correctly
[ https://issues.apache.org/jira/browse/NETBEANS-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-713: - Description: The editor API defines the JEditorPane client properties [HighlightsLayerExcludes and HighlightsLayerIncludes|http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor-lib2/index.html?org/netbeans/spi/editor/highlighting/package-summary.html] to allow clients to show/hide specific highlight layers on demand. The bug is that modifications to these properties are not reflected properly in the editor. The use case here is for a NetBeans Platform application that needs to modify the client properties depending on user action (e.g. keyboard focus state). The bug seems to be in o.n.modules.editor.lib2.highlighting.HighlightingManager.Highlighting. In the constructor, the paneFilter variable is initialized once from the HighlightsLayerExcludes/HighlightsLayerIncludes client properties, right above where the propertyChangeListener that is supposed to track changes to it is added. The PropertyChangeListener reacts to changes to the client properties by calling rebuildAllLayers(), which calls rebuildAllLayersImpl(), which always just uses the value of paneFilter set in the constructor. Originally reported as Bugzilla bug [248664|https://netbeans.org/bugzilla/show_bug.cgi?id=248664]. Adding this as a JIRA issue to associate with a pull request that I'm about to open. was: (Copied from Bugzilla bug [248664|https://netbeans.org/bugzilla/show_bug.cgi?id=248664] ) The editor API defines the JEditorPane client properties [HighlightsLayerExcludes and HighlightsLayerIncludes|http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor-lib2/index.html?org/netbeans/spi/editor/highlighting/package-summary.html] to allow clients to show/hide specific highlight layers on demand. The bug is that modifications to these properties are not reflected properly in the editor. The bug seems to be in o.n.modules.editor.lib2.highlighting.HighlightingManager.Highlighting. In the constructor, the paneFilter variable is initialized once from the HighlightsLayerExcludes/HighlightsLayerIncludes client properties, right above where the propertyChangeListener that is supposed to track changes to it is added. The PropertyChangeListener reacts to changes to the client properties by calling rebuildAllLayers(), which calls rebuildAllLayersImpl(), which always just uses the value of paneFilter set in the constructor. Adding this as a JIRA issue to associate with a pull request that I'm about to open. > HighlightingManager does not track changes to HighlightsLayerExcludes > correctly > --- > > Key: NETBEANS-713 > URL: https://issues.apache.org/jira/browse/NETBEANS-713 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2, 9.0 >Reporter: Eirik Bakke >Priority: Minor > > The editor API defines the JEditorPane client properties > [HighlightsLayerExcludes and > HighlightsLayerIncludes|http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor-lib2/index.html?org/netbeans/spi/editor/highlighting/package-summary.html] > to allow clients to show/hide specific highlight layers on demand. The bug > is that modifications to these properties are not reflected properly in the > editor. > The use case here is for a NetBeans Platform application that needs to modify > the client properties depending on user action (e.g. keyboard focus state). > The bug seems to be in > o.n.modules.editor.lib2.highlighting.HighlightingManager.Highlighting. In the > constructor, the paneFilter variable is initialized once from the > HighlightsLayerExcludes/HighlightsLayerIncludes client properties, right > above where the propertyChangeListener that is supposed to track changes to > it is added. The PropertyChangeListener reacts to changes to the client > properties by calling rebuildAllLayers(), which calls rebuildAllLayersImpl(), > which always just uses the value of paneFilter set in the constructor. > Originally reported as Bugzilla bug > [248664|https://netbeans.org/bugzilla/show_bug.cgi?id=248664]. Adding this as > a JIRA issue to associate with a pull request that I'm about to open. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-712) On Aqua, sub-tabs in "Output" tab have vertically off-center text and close buttons
[
https://issues.apache.org/jira/browse/NETBEANS-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16457790#comment-16457790
]
Eirik Bakke commented on NETBEANS-712:
--
Thanks!
> On Aqua, sub-tabs in "Output" tab have vertically off-center text and close
> buttons
> ---
>
> Key: NETBEANS-712
> URL: https://issues.apache.org/jira/browse/NETBEANS-712
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Window System
>Affects Versions: 8.2, 9.0
>Reporter: Eirik Bakke
>Assignee: Eirik Bakke
>Priority: Minor
> Labels: pull-request-available
> Fix For: 9.0
>
> Attachments: xalignment251441-patch-illustration.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> On MacOS/Aqua, the text and close ("X") buttons of sub-tabs in the "Output"
> TopComponents such as "Debugger Console" and "Run", are vertically
> off-center. The attached screenshot shows the problem, and what it looks like
> after the patch I'm about to propose.
> Originally bugzilla issue 251441. Creating an issue here to associate with an
> upcoming pull request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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-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:comment-tabpanel&focusedCommentId=16463951#comment-16463951 ] Eirik Bakke commented on NETBEANS-346: -- Beware that changing the default editor font is a huge change that affects every user, and people will have strong opinions about it. I, for one, tried changing the font to Lucida Sans Typewriter, and I don't think it looks as good as the default Monospace font on MacOS (Lucida Sans Typewriter has too much air between the letters). > 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 > 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 > > > 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 (v7.6.3#76005) - 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-977) Improve text layout in word wrap mode
Eirik Bakke created NETBEANS-977: Summary: Improve text layout in word wrap mode Key: NETBEANS-977 URL: https://issues.apache.org/jira/browse/NETBEANS-977 Project: NetBeans Issue Type: Improvement Components: editor - Formatting & Indentation, editor - Painting & Printing Affects Versions: 9.0 Reporter: Eirik Bakke Attachments: wrappingdiff.png The NetBeans editor's word wrap feature, which can be enabled via Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few quirks that makes wrapped text hard to read. I have prepared a patch which makes the following improvements, as illustrated in the attached before/after screenshot: 1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to split text instead of the previous hand-coded text wrapping logic (this was in fact suggested as a TODO in the previous code). This, in particular, avoids putting spaces and punctuation at the beginning of a wrap line, making the NetBeans editor work more like other editors. This fixes the BugZilla bug [242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113]. 2) Handle words that are longer than the preferred maximum width properly. The long word still won't be broken, but at least the rest of the paragraph will--previously the entire rest of the paragraph would remain unbroken in this case. 3) Allow whitespace at the end of a wrap line to extend beyond the preferred viewport width (like in jEdit and other editors, including the in-browser editor I'm typing this JIRA issue description in). This usually saves one character of horizontal space for regular text paragraphs. 4) Don't display a "line continuation character" to indicate that a line has been wrapped. It clutters the display, takes up an extra character of horizontal space, and does not work well with rule (3) above. This fixes the BugZilla bug [213829|https://netbeans.org/bugzilla/show_bug.cgi?id=213829]. Besides improving the word wrap feature for use in the NetBeans editor, this patch also makes NetBeans' EditorKit more useful for standalone use in a JEditorPane, e.g. in NetBeans Platform applications. For instance, my own platform application uses NetBeans' EditorKit to provide editing of text paragraphs and spreadsheet formulas in a spreadsheet-like table widget, where horizontal space is at a premium. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-977) Improve text layout in word wrap mode
[ https://issues.apache.org/jira/browse/NETBEANS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-977: - Description: The NetBeans editor's word wrap feature, which can be enabled via Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few quirks that makes wrapped text hard to read. I have prepared a patch which makes the following improvements, as illustrated in the attached before/after screenshot: 1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to split text instead of the previous hand-coded text wrapping logic (this was in fact suggested as a TODO in the previous code). This, in particular, avoids putting spaces and punctuation at the beginning of a wrap line, making the NetBeans editor work more like other editors. This fixes the BugZilla bug [242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113]. 2) Handle words that are longer than the preferred maximum width properly. The long word still won't be broken, but at least the rest of the paragraph will--previously the entire rest of the paragraph would remain unbroken in this case. 3) Allow whitespace at the end of a wrap line to extend beyond the preferred viewport width (like in jEdit and other editors, including the in-browser editor I'm typing this JIRA issue description in). This usually saves one character of horizontal space for regular text paragraphs. 4) Don't display a "line continuation character" to indicate that a line has been wrapped. It clutters the display, takes up an extra character of horizontal space, and does not work well with rule (3) above. Besides, in the NetBeans code editor, the equivalent information is already communicated to the user by the line numbering to the left. This fixes the BugZilla bug [213829|https://netbeans.org/bugzilla/show_bug.cgi?id=213829]. Besides improving the word wrap feature for use in the NetBeans editor, this patch also makes NetBeans' EditorKit more useful for standalone use in a JEditorPane, e.g. in NetBeans Platform applications. For instance, my own platform application uses NetBeans' EditorKit to provide editing of text paragraphs and spreadsheet formulas in a spreadsheet-like table widget, where horizontal space is at a premium. was: The NetBeans editor's word wrap feature, which can be enabled via Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few quirks that makes wrapped text hard to read. I have prepared a patch which makes the following improvements, as illustrated in the attached before/after screenshot: 1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to split text instead of the previous hand-coded text wrapping logic (this was in fact suggested as a TODO in the previous code). This, in particular, avoids putting spaces and punctuation at the beginning of a wrap line, making the NetBeans editor work more like other editors. This fixes the BugZilla bug [242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113]. 2) Handle words that are longer than the preferred maximum width properly. The long word still won't be broken, but at least the rest of the paragraph will--previously the entire rest of the paragraph would remain unbroken in this case. 3) Allow whitespace at the end of a wrap line to extend beyond the preferred viewport width (like in jEdit and other editors, including the in-browser editor I'm typing this JIRA issue description in). This usually saves one character of horizontal space for regular text paragraphs. 4) Don't display a "line continuation character" to indicate that a line has been wrapped. It clutters the display, takes up an extra character of horizontal space, and does not work well with rule (3) above. This fixes the BugZilla bug [213829|https://netbeans.org/bugzilla/show_bug.cgi?id=213829]. Besides improving the word wrap feature for use in the NetBeans editor, this patch also makes NetBeans' EditorKit more useful for standalone use in a JEditorPane, e.g. in NetBeans Platform applications. For instance, my own platform application uses NetBeans' EditorKit to provide editing of text paragraphs and spreadsheet formulas in a spreadsheet-like table widget, where horizontal space is at a premium. > Improve text layout in word wrap mode > - > > Key: NETBEANS-977 > URL: https://issues.apache.org/jira/browse/NETBEANS-977 > Project: NetBeans > Issue Type: Improvement > Components: editor - Formatting & Indentation, editor - Painting > & Printing >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Minor > Attachments: wrappingdiff.png > > > The NetBeans editor's word wrap feature, which can be enabled via > Preferences->Editor->Formatting->Line Wrap->After Words, currentl
[jira] [Updated] (NETBEANS-977) Improve text layout in word wrap mode
[ https://issues.apache.org/jira/browse/NETBEANS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-977: - Description: The NetBeans editor's word wrap feature, which can be enabled via Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few quirks that makes wrapped text hard to read. I have prepared a patch which makes the following improvements, as illustrated in the attached before/after screenshot: 1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to split text instead of the previous hand-coded text wrapping logic (this was in fact suggested as a TODO in the previous code). This, in particular, avoids putting spaces and punctuation at the beginning of a wrap line, making the NetBeans editor work more like other editors. This fixes the BugZilla bug [242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113]. 2) Handle words that are longer than the preferred maximum width properly. The long word still won't be broken, but at least the rest of the paragraph will--previously the entire rest of the paragraph would remain unbroken in this case. 3) Allow whitespace at the end of a wrap line to extend beyond the preferred viewport width (like in jEdit and other editors, including the in-browser editor I'm typing this JIRA issue description in). This usually saves one character of horizontal space for regular text paragraphs. 4) Don't display a "line continuation character" to indicate that a line has been wrapped. It clutters the display, takes up an extra character of horizontal space, and does not work well with rule (3) above. Besides, in the NetBeans code editor, the equivalent information is already communicated to the user by the line numbering to the left. This fixes the BugZilla bug [213829|https://netbeans.org/bugzilla/show_bug.cgi?id=213829]. Besides improving the word wrap feature for use in the NetBeans editor, this patch also makes NetBeans' EditorKit more useful for standalone use in a JEditorPane, e.g. in NetBeans Platform applications. For instance, my own platform application uses NetBeans' EditorKit to provide editing of text paragraphs and spreadsheet formulas in a spreadsheet-like table widget, where horizontal space is at a premium. Note that word wrapping boundary computation logic exists in two different places in the editor.lib2 module: in o.n.modules.editor.lib2.view.HighlightViewUtils.breakView , and in o.n.modules.editor.lib2.view.WrapInfoUpdater.getWordInfo. The logic changed in this patch is that of HighlightViewUtils.breakView. The WrapInfoUpdater.getWordInfo routine seems to be a fall-back path that is only used for View implementations that do not use HighlightViewUtils.breakView, or when the latter fails. I was never able to make WrapInfoUpdater.getWordInfo return non-null , having tried word wrapping in Java source files, including with collapsed methods (which I know involves a special kind of View), and selected text (to try to trigger the old BugZilla bugs [183219|https://netbeans.org/bugzilla/show_bug.cgi?id=183219] and [189554|https://netbeans.org/bugzilla/show_bug.cgi?id=189554], which were mentioned in the commits around the related code in WrapInfoUpdater). To avoid breaking things, I have _not_ changed the logic in WrapInfoUpdater.getWordInfo. Miloslav Metelka might be able to tell whether the latter is really "dead code" or not. was: The NetBeans editor's word wrap feature, which can be enabled via Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few quirks that makes wrapped text hard to read. I have prepared a patch which makes the following improvements, as illustrated in the attached before/after screenshot: 1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to split text instead of the previous hand-coded text wrapping logic (this was in fact suggested as a TODO in the previous code). This, in particular, avoids putting spaces and punctuation at the beginning of a wrap line, making the NetBeans editor work more like other editors. This fixes the BugZilla bug [242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113]. 2) Handle words that are longer than the preferred maximum width properly. The long word still won't be broken, but at least the rest of the paragraph will--previously the entire rest of the paragraph would remain unbroken in this case. 3) Allow whitespace at the end of a wrap line to extend beyond the preferred viewport width (like in jEdit and other editors, including the in-browser editor I'm typing this JIRA issue description in). This usually saves one character of horizontal space for regular text paragraphs. 4) Don't display a "line continuation character" to indicate that a line has been wrapped. It clutters the display, takes up an extra character of horizontal space, and does not wo
[jira] [Updated] (NETBEANS-977) Improve text layout in word wrap mode
[ https://issues.apache.org/jira/browse/NETBEANS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-977: - Description: The NetBeans editor's word wrap feature, which can be enabled via Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few quirks that makes wrapped text hard to read. I have prepared a patch which makes the following improvements, as illustrated in the attached before/after screenshot: 1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to split text instead of the previous hand-coded text wrapping logic (this was in fact suggested as a TODO in the previous code). This, in particular, avoids putting spaces and punctuation at the beginning of a wrap line, making the NetBeans editor work more like other editors. This fixes the BugZilla bug [242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113]. 2) Handle words that are longer than the preferred maximum width properly. The long word still won't be broken, but at least the rest of the paragraph will--previously the entire rest of the paragraph would remain unbroken in this case. 3) Allow whitespace at the end of a wrap line to extend beyond the preferred viewport width (like in jEdit and other editors, including the in-browser editor I'm typing this JIRA issue description in). This usually saves one character of horizontal space for regular text paragraphs. 4) Don't display a "line continuation character" to indicate that a line has been wrapped. It clutters the display, takes up an extra character of horizontal space, and does not work well with rule (3) above. Besides, in the NetBeans code editor, the equivalent information is already communicated to the user by the line numbering to the left. This fixes the BugZilla bug [213829|https://netbeans.org/bugzilla/show_bug.cgi?id=213829]. Besides improving the word wrap feature for use in the NetBeans editor, this patch also makes NetBeans' EditorKit more useful for standalone use in a JEditorPane, e.g. in NetBeans Platform applications. For instance, my own platform application uses NetBeans' EditorKit to provide editing of text paragraphs and spreadsheet formulas in a spreadsheet-like table widget, where horizontal space is at a premium. Note that word wrapping boundary computation logic exists in two different places in the editor.lib2 module: in o.n.modules.editor.lib2.view.HighlightViewUtils.breakView , and in o.n.modules.editor.lib2.view.WrapInfoUpdater.getWordInfo. The logic changed in this patch is that of HighlightViewUtils.breakView. The WrapInfoUpdater.getWordInfo routine seems to be a fall-back path that is only used for View implementations that do not use HighlightViewUtils.breakView, or when the latter fails. I was never able to make WrapInfoUpdater.getWordInfo return non-null during a real editor session, having tried word wrapping in Java source files, including with collapsed methods (which I know involves a special kind of View), and selected text (to try to trigger the old BugZilla bugs [183219|https://netbeans.org/bugzilla/show_bug.cgi?id=183219] and [189554|https://netbeans.org/bugzilla/show_bug.cgi?id=189554], which were mentioned in the commits around the related code in WrapInfoUpdater). To avoid breaking things, I have _not_ changed the logic in WrapInfoUpdater.getWordInfo. Miloslav Metelka might be able to tell whether the latter is really "dead code" or not. was: The NetBeans editor's word wrap feature, which can be enabled via Preferences->Editor->Formatting->Line Wrap->After Words, currently has a few quirks that makes wrapped text hard to read. I have prepared a patch which makes the following improvements, as illustrated in the attached before/after screenshot: 1) In HighlightsViewUtils.breakView, use a proper java.text.BreakIterator to split text instead of the previous hand-coded text wrapping logic (this was in fact suggested as a TODO in the previous code). This, in particular, avoids putting spaces and punctuation at the beginning of a wrap line, making the NetBeans editor work more like other editors. This fixes the BugZilla bug [242113|https://netbeans.org/bugzilla/show_bug.cgi?id=242113]. 2) Handle words that are longer than the preferred maximum width properly. The long word still won't be broken, but at least the rest of the paragraph will--previously the entire rest of the paragraph would remain unbroken in this case. 3) Allow whitespace at the end of a wrap line to extend beyond the preferred viewport width (like in jEdit and other editors, including the in-browser editor I'm typing this JIRA issue description in). This usually saves one character of horizontal space for regular text paragraphs. 4) Don't display a "line continuation character" to indicate that a line has been wrapped. It clutters the display, takes up an extra character of horiz
[jira] [Created] (NETBEANS-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead
Eirik Bakke created NETBEANS-979: Summary: With line wrap enabled, cursor at end of line is painted at beginning of next line instead Key: NETBEANS-979 URL: https://issues.apache.org/jira/browse/NETBEANS-979 Project: NetBeans Issue Type: Bug Components: editor - Painting & Printing Reporter: Eirik Bakke Fix For: 9.0 In an editor with line wrap enabled, the cursor is shown at the wrong physical location whenever it is supposed to be located at the end of a wrap line. Instead of being painted at the end of the wrap line, it is painted at the beginning of the following line. This causes the behavior of keyboard shortcuts like "End" and "Up" to seem nonsensical to the user, although they might well be behaving correctly wrt. the physical location of the cursor (the character offset). To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and open it in the editor. 3) Type some gibberish into the editor on a single line that is long enough to be broken into several break lines. 4) With the cursor on the first break line, press the "End" key (Command+Right on MacBook keyboards). The cursor appears to move one line down, which is unexpected. From looking at this situation, the user would now assume that they could press the "Up" key to move the cursor back to the previous break line, but this will not change the cursor position (because the cursor is logically on the previous line). Originally reported in BugZilla at https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on NetBeans 9.0 rc2. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-978) Visual cursor position not updated when editor resized under line wrap
Eirik Bakke created NETBEANS-978: Summary: Visual cursor position not updated when editor resized under line wrap Key: NETBEANS-978 URL: https://issues.apache.org/jira/browse/NETBEANS-978 Project: NetBeans Issue Type: Bug Components: editor - Painting & Printing Affects Versions: 9.0 Reporter: Eirik Bakke If line wrap is enabled, and the editor window is resized, the text is re-wrapped correctly to the new width of the editor. However, the cursor ends up in weird places, still blinking. To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and open it in the editor. Type a couple of long lines (with some spaces in them)--they will correctly be broken when the line reaches the end of the editor window. 3) Now resize the editor window in the horizontal direction, back and forth a couple of times. Observe that while the text is re-broken to the new width, the cursor tends to end up in non-sensical places (it may seem as if its position is only updated if it needs to end up on a new physical line, but not if it needs to end up in a different column position). However, as soon as a character is typed or an arrow key is pressed, the cursor re-appears in the correct place. Originally reported in BugZilla at https://netbeans.org/bugzilla/show_bug.cgi?id=241953 . Still reproducible on NetBeans 9.0 rc2. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead
[ https://issues.apache.org/jira/browse/NETBEANS-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-979: - Description: In an editor with line wrap enabled, the cursor is shown at the wrong physical location whenever it is supposed to be located at the end of a wrap line. Instead of being painted at the end of the wrap line, it is painted at the beginning of the following line. This causes the behavior of keyboard shortcuts like "End" and "Up" to seem nonsensical to the user, although they might well be behaving correctly wrt. the physical location of the cursor (the character offset). To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and open it in the editor. 3) Type some gibberish into the editor on a single line that is long enough to be broken into several break lines. 4) With the cursor on the first break line, press the "End" key (Command+Right on MacBook keyboards). The cursor appears to move one line down, which is unexpected. From looking at this situation, the user would now assume that they could press the "Up" key to move the cursor back to the previous break line, but this will not change the cursor position (because the cursor is logically on the previous line). 5) Another unexpected example: Pressing End with cursor before the first character of any wrapped paragraph moves cursor down instead of to the end of the line. 6) Another unexpected example: Pressing Home anywhere in a paragraph will move the cursor to the first character on the paragraph rather than at the first character of the wrap line. Originally reported in BugZilla at https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on NetBeans 9.0 rc2. was: In an editor with line wrap enabled, the cursor is shown at the wrong physical location whenever it is supposed to be located at the end of a wrap line. Instead of being painted at the end of the wrap line, it is painted at the beginning of the following line. This causes the behavior of keyboard shortcuts like "End" and "Up" to seem nonsensical to the user, although they might well be behaving correctly wrt. the physical location of the cursor (the character offset). To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and open it in the editor. 3) Type some gibberish into the editor on a single line that is long enough to be broken into several break lines. 4) With the cursor on the first break line, press the "End" key (Command+Right on MacBook keyboards). The cursor appears to move one line down, which is unexpected. From looking at this situation, the user would now assume that they could press the "Up" key to move the cursor back to the previous break line, but this will not change the cursor position (because the cursor is logically on the previous line). Originally reported in BugZilla at https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on NetBeans 9.0 rc2. > With line wrap enabled, cursor at end of line is painted at beginning of next > line instead > -- > > Key: NETBEANS-979 > URL: https://issues.apache.org/jira/browse/NETBEANS-979 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting & Printing >Reporter: Eirik Bakke >Priority: Major > Fix For: 9.0 > > > In an editor with line wrap enabled, the cursor is shown at the wrong > physical location whenever it is supposed to be located at the end of a wrap > line. Instead of being painted at the end of the wrap line, it is painted at > the beginning of the following line. This causes the behavior of keyboard > shortcuts like "End" and "Up" to seem nonsensical to the user, although they > might well be behaving correctly wrt. the physical location of the cursor > (the character offset). > To reproduce: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and open it in the editor. > 3) Type some gibberish into the editor on a single line that is long enough > to be broken into several break lines. > 4) With the cursor on the first break line, press the "End" key > (Command+Right on MacBook keyboards). The cursor appears to move one line > down, which is unexpected. From looking at this situation, the user would now > assume that they could press the "Up" key to move the cursor back to the > previous break line, but this will not change the cursor position (because > the cursor is logically on the previous
[jira] [Created] (NETBEANS-980) Cannot arrow up/down to shorter word-wrapped line in editor
Eirik Bakke created NETBEANS-980: Summary: Cannot arrow up/down to shorter word-wrapped line in editor Key: NETBEANS-980 URL: https://issues.apache.org/jira/browse/NETBEANS-980 Project: NetBeans Issue Type: Bug Components: editor - Other, editor - Painting & Printing Affects Versions: 9.0 Reporter: Eirik Bakke If line wrap is enabled, and the text caret is located in a wrapped paragraph, the up/down arrow keys cannot be used to move the caret up/down to another wrap line if the target wrap line is shorter than the current caret position. Either nothing happens, or the caret may skip the shorter wrap lines and step multiple wrap lines up/down. To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into three wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) Position the cursor right after "...ONG" 5) Press the "Up" arrow. Nothing happens (expected would be to the caret to move up to the end of the previous wrap line). 6) Press the "Down" arrow. This moves the caret _two_ wrap lines down instead of to the end of the next wrap line. Tested in NetBeans 9.0 rc2. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead
[ https://issues.apache.org/jira/browse/NETBEANS-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-979: - Description: In an editor with line wrap enabled, the cursor is shown at the wrong physical location whenever it is supposed to be located at the end of a wrap line. Instead of being painted at the end of the wrap line, it is painted at the beginning of the following line. This causes the behavior of keyboard shortcuts like "End" and "Up" to seem nonsensical to the user, although they might well be behaving correctly wrt. the physical location of the cursor (the character offset). To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and open it in the editor. 3) Type some gibberish into the editor on a single line that is long enough to be broken into several break lines. 4) With the cursor before the first character of any wrap line in the paragraph except the last, press the "End" key (Command+Right on MacBook keyboards). The cursor appears to move one line down, which is unexpected. From looking at this situation, the user would now assume that they could press the "Up" key to move the cursor back to the previous break line, but this will not change the cursor position (because the cursor is logically on the previous line). 5) Another unexpected example: Pressing Home anywhere in a paragraph will move the cursor to the first character on the paragraph rather than at the first character of the wrap line. (This might indicate that the problem is more than just a paint bug, though.) Originally reported in BugZilla at https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on NetBeans 9.0 rc2. See also https://issues.apache.org/jira/browse/NETBEANS-980 . was: In an editor with line wrap enabled, the cursor is shown at the wrong physical location whenever it is supposed to be located at the end of a wrap line. Instead of being painted at the end of the wrap line, it is painted at the beginning of the following line. This causes the behavior of keyboard shortcuts like "End" and "Up" to seem nonsensical to the user, although they might well be behaving correctly wrt. the physical location of the cursor (the character offset). To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and open it in the editor. 3) Type some gibberish into the editor on a single line that is long enough to be broken into several break lines. 4) With the cursor on the first break line, press the "End" key (Command+Right on MacBook keyboards). The cursor appears to move one line down, which is unexpected. From looking at this situation, the user would now assume that they could press the "Up" key to move the cursor back to the previous break line, but this will not change the cursor position (because the cursor is logically on the previous line). 5) Another unexpected example: Pressing End with cursor before the first character of any wrapped paragraph moves cursor down instead of to the end of the line. 6) Another unexpected example: Pressing Home anywhere in a paragraph will move the cursor to the first character on the paragraph rather than at the first character of the wrap line. Originally reported in BugZilla at https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on NetBeans 9.0 rc2. > With line wrap enabled, cursor at end of line is painted at beginning of next > line instead > -- > > Key: NETBEANS-979 > URL: https://issues.apache.org/jira/browse/NETBEANS-979 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting & Printing >Reporter: Eirik Bakke >Priority: Major > Fix For: 9.0 > > > In an editor with line wrap enabled, the cursor is shown at the wrong > physical location whenever it is supposed to be located at the end of a wrap > line. Instead of being painted at the end of the wrap line, it is painted at > the beginning of the following line. This causes the behavior of keyboard > shortcuts like "End" and "Up" to seem nonsensical to the user, although they > might well be behaving correctly wrt. the physical location of the cursor > (the character offset). > To reproduce: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and open it in the editor. > 3) Type some gibberish into the editor on a single line that is long enough > to be broken into several break lines. > 4) With the cursor before the first cha
[jira] [Updated] (NETBEANS-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead
[ https://issues.apache.org/jira/browse/NETBEANS-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-979: - Description: In an editor with line wrap enabled, the cursor is shown at the wrong physical location whenever it is supposed to be located at the end of a wrap line. Instead of being painted at the end of the wrap line, it is painted at the beginning of the following line. This causes the behavior of keyboard shortcuts like "End" and "Up" to seem nonsensical to the user, although they might well be behaving correctly wrt. the physical location of the cursor (the character offset). To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and open it in the editor. 3) Type some gibberish into the editor on a single line that is long enough to be broken into several break lines. 4) With the cursor before the first character of the first wrap line in the paragraph, press the "End" key (Command+Right on MacBook keyboards). The cursor appears to move one line down, which is unexpected. From looking at this situation, the user would now assume that they could press the "Up" key to move the cursor back to the previous break line, but this will not change the cursor position (because the cursor is logically on the previous line). 5) Another unexpected example: Pressing Home anywhere in a paragraph will move the cursor to the first character on the paragraph rather than at the first character of the wrap line. (This might indicate that the problem is more than just a paint bug, though.) Originally reported in BugZilla at https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on NetBeans 9.0 rc2. See also https://issues.apache.org/jira/browse/NETBEANS-980 . was: In an editor with line wrap enabled, the cursor is shown at the wrong physical location whenever it is supposed to be located at the end of a wrap line. Instead of being painted at the end of the wrap line, it is painted at the beginning of the following line. This causes the behavior of keyboard shortcuts like "End" and "Up" to seem nonsensical to the user, although they might well be behaving correctly wrt. the physical location of the cursor (the character offset). To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and open it in the editor. 3) Type some gibberish into the editor on a single line that is long enough to be broken into several break lines. 4) With the cursor before the first character of any wrap line in the paragraph except the last, press the "End" key (Command+Right on MacBook keyboards). The cursor appears to move one line down, which is unexpected. From looking at this situation, the user would now assume that they could press the "Up" key to move the cursor back to the previous break line, but this will not change the cursor position (because the cursor is logically on the previous line). 5) Another unexpected example: Pressing Home anywhere in a paragraph will move the cursor to the first character on the paragraph rather than at the first character of the wrap line. (This might indicate that the problem is more than just a paint bug, though.) Originally reported in BugZilla at https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on NetBeans 9.0 rc2. See also https://issues.apache.org/jira/browse/NETBEANS-980 . > With line wrap enabled, cursor at end of line is painted at beginning of next > line instead > -- > > Key: NETBEANS-979 > URL: https://issues.apache.org/jira/browse/NETBEANS-979 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting & Printing >Reporter: Eirik Bakke >Priority: Major > Fix For: 9.0 > > > In an editor with line wrap enabled, the cursor is shown at the wrong > physical location whenever it is supposed to be located at the end of a wrap > line. Instead of being painted at the end of the wrap line, it is painted at > the beginning of the following line. This causes the behavior of keyboard > shortcuts like "End" and "Up" to seem nonsensical to the user, although they > might well be behaving correctly wrt. the physical location of the cursor > (the character offset). > To reproduce: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and open it in the editor. > 3) Type some gibberish into the editor on a single line that is long enough > to be broken into several break lines. > 4) With the curso
[jira] [Commented] (NETBEANS-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead
[ https://issues.apache.org/jira/browse/NETBEANS-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520920#comment-16520920 ] Eirik Bakke commented on NETBEANS-979: -- Doing a few more experiments with this, especially comparing to the behavior in other editors, I think the caret might actually be painted in the correct position--this should rather be regarded as a bug in the up/down/home/end actions. > With line wrap enabled, cursor at end of line is painted at beginning of next > line instead > -- > > Key: NETBEANS-979 > URL: https://issues.apache.org/jira/browse/NETBEANS-979 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting & Printing >Reporter: Eirik Bakke >Priority: Major > Fix For: 9.0 > > > In an editor with line wrap enabled, the cursor is shown at the wrong > physical location whenever it is supposed to be located at the end of a wrap > line. Instead of being painted at the end of the wrap line, it is painted at > the beginning of the following line. This causes the behavior of keyboard > shortcuts like "End" and "Up" to seem nonsensical to the user, although they > might well be behaving correctly wrt. the physical location of the cursor > (the character offset). > To reproduce: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and open it in the editor. > 3) Type some gibberish into the editor on a single line that is long enough > to be broken into several break lines. > 4) With the cursor before the first character of the first wrap line in the > paragraph, press the "End" key (Command+Right on MacBook keyboards). The > cursor appears to move one line down, which is unexpected. From looking at > this situation, the user would now assume that they could press the "Up" key > to move the cursor back to the previous break line, but this will not change > the cursor position (because the cursor is logically on the previous line). > 5) Another unexpected example: Pressing Home anywhere in a paragraph will > move the cursor to the first character on the paragraph rather than at the > first character of the wrap line. (This might indicate that the problem is > more than just a paint bug, though.) > Originally reported in BugZilla at > https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on > NetBeans 9.0 rc2. > See also https://issues.apache.org/jira/browse/NETBEANS-980 . -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-978) Visual cursor position not updated when editor resized under line wrap
[ https://issues.apache.org/jira/browse/NETBEANS-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-978: - Description: If line wrap is enabled, and the editor window is resized, the text is re-wrapped correctly to the new width of the editor. However, the cursor ends up in weird places, still blinking. To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and open it in the editor. Type a couple of long lines (with some spaces in them)--they will correctly be broken when the line reaches the end of the editor window. 3) Now resize the editor window in the horizontal direction, back and forth a couple of times. Observe that while the text is re-broken to the new width, the cursor tends to end up in non-sensical places (it may seem as if its position is only updated if it needs to end up on a new physical line, but not if it needs to end up in a different column position). However, as soon as a character is typed or an arrow key is pressed, the cursor re-appears in the correct place. Originally reported in BugZilla at https://netbeans.org/bugzilla/show_bug.cgi?id=241953 . Still reproducible on NetBeans 9.0 rc1. was: If line wrap is enabled, and the editor window is resized, the text is re-wrapped correctly to the new width of the editor. However, the cursor ends up in weird places, still blinking. To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and open it in the editor. Type a couple of long lines (with some spaces in them)--they will correctly be broken when the line reaches the end of the editor window. 3) Now resize the editor window in the horizontal direction, back and forth a couple of times. Observe that while the text is re-broken to the new width, the cursor tends to end up in non-sensical places (it may seem as if its position is only updated if it needs to end up on a new physical line, but not if it needs to end up in a different column position). However, as soon as a character is typed or an arrow key is pressed, the cursor re-appears in the correct place. Originally reported in BugZilla at https://netbeans.org/bugzilla/show_bug.cgi?id=241953 . Still reproducible on NetBeans 9.0 rc2. > Visual cursor position not updated when editor resized under line wrap > -- > > Key: NETBEANS-978 > URL: https://issues.apache.org/jira/browse/NETBEANS-978 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting & Printing >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Minor > > If line wrap is enabled, and the editor window is resized, the text is > re-wrapped correctly to the new width of the editor. However, the cursor ends > up in weird places, still blinking. > To reproduce: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and open it in the editor. Type a couple of > long lines (with some spaces in them)--they will correctly be broken when the > line reaches the end of the editor window. > 3) Now resize the editor window in the horizontal direction, back and forth a > couple of times. Observe that while the text is re-broken to the new width, > the cursor tends to end up in non-sensical places (it may seem as if its > position is only updated if it needs to end up on a new physical line, but > not if it needs to end up in a different column position). However, as soon > as a character is typed or an arrow key is pressed, the cursor re-appears in > the correct place. > Originally reported in BugZilla at > https://netbeans.org/bugzilla/show_bug.cgi?id=241953 . Still reproducible on > NetBeans 9.0 rc1. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead
[ https://issues.apache.org/jira/browse/NETBEANS-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-979: - Description: In an editor with line wrap enabled, the cursor is shown at the wrong physical location whenever it is supposed to be located at the end of a wrap line. Instead of being painted at the end of the wrap line, it is painted at the beginning of the following line. This causes the behavior of keyboard shortcuts like "End" and "Up" to seem nonsensical to the user, although they might well be behaving correctly wrt. the physical location of the cursor (the character offset). To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and open it in the editor. 3) Type some gibberish into the editor on a single line that is long enough to be broken into several break lines. 4) With the cursor before the first character of the first wrap line in the paragraph, press the "End" key (Command+Right on MacBook keyboards). The cursor appears to move one line down, which is unexpected. From looking at this situation, the user would now assume that they could press the "Up" key to move the cursor back to the previous break line, but this will not change the cursor position (because the cursor is logically on the previous line). 5) Another unexpected example: Pressing Home anywhere in a paragraph will move the cursor to the first character on the paragraph rather than at the first character of the wrap line. (This might indicate that the problem is more than just a paint bug, though.) Originally reported in BugZilla at https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on NetBeans 9.0 rc1. See also https://issues.apache.org/jira/browse/NETBEANS-980 . was: In an editor with line wrap enabled, the cursor is shown at the wrong physical location whenever it is supposed to be located at the end of a wrap line. Instead of being painted at the end of the wrap line, it is painted at the beginning of the following line. This causes the behavior of keyboard shortcuts like "End" and "Up" to seem nonsensical to the user, although they might well be behaving correctly wrt. the physical location of the cursor (the character offset). To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and open it in the editor. 3) Type some gibberish into the editor on a single line that is long enough to be broken into several break lines. 4) With the cursor before the first character of the first wrap line in the paragraph, press the "End" key (Command+Right on MacBook keyboards). The cursor appears to move one line down, which is unexpected. From looking at this situation, the user would now assume that they could press the "Up" key to move the cursor back to the previous break line, but this will not change the cursor position (because the cursor is logically on the previous line). 5) Another unexpected example: Pressing Home anywhere in a paragraph will move the cursor to the first character on the paragraph rather than at the first character of the wrap line. (This might indicate that the problem is more than just a paint bug, though.) Originally reported in BugZilla at https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on NetBeans 9.0 rc2. See also https://issues.apache.org/jira/browse/NETBEANS-980 . > With line wrap enabled, cursor at end of line is painted at beginning of next > line instead > -- > > Key: NETBEANS-979 > URL: https://issues.apache.org/jira/browse/NETBEANS-979 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting & Printing >Reporter: Eirik Bakke >Priority: Major > Fix For: 9.0 > > > In an editor with line wrap enabled, the cursor is shown at the wrong > physical location whenever it is supposed to be located at the end of a wrap > line. Instead of being painted at the end of the wrap line, it is painted at > the beginning of the following line. This causes the behavior of keyboard > shortcuts like "End" and "Up" to seem nonsensical to the user, although they > might well be behaving correctly wrt. the physical location of the cursor > (the character offset). > To reproduce: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and open it in the editor. > 3) Type some gibberish into the editor on a single line that is long enough > to be broken into several break lines. > 4) With the cursor before t
[jira] [Updated] (NETBEANS-980) Cannot arrow up/down to shorter word-wrapped line in editor
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Description: If line wrap is enabled, and the text caret is located in a wrapped paragraph, the up/down arrow keys cannot be used to move the caret up/down to another wrap line if the target wrap line is shorter than the current caret position. Either nothing happens, or the caret may skip the shorter wrap lines and step multiple wrap lines up/down. To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into three wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) Position the cursor right after "...ONG" 5) Press the "Up" arrow. Nothing happens (expected would be to the caret to move up to the end of the previous wrap line). 6) Press the "Down" arrow. This moves the caret _two_ wrap lines down instead of to the end of the next wrap line. Tested in NetBeans 9.0 rc1. was: If line wrap is enabled, and the text caret is located in a wrapped paragraph, the up/down arrow keys cannot be used to move the caret up/down to another wrap line if the target wrap line is shorter than the current caret position. Either nothing happens, or the caret may skip the shorter wrap lines and step multiple wrap lines up/down. To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into three wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) Position the cursor right after "...ONG" 5) Press the "Up" arrow. Nothing happens (expected would be to the caret to move up to the end of the previous wrap line). 6) Press the "Down" arrow. This moves the caret _two_ wrap lines down instead of to the end of the next wrap line. Tested in NetBeans 9.0 rc2. > Cannot arrow up/down to shorter word-wrapped line in editor > --- > > Key: NETBEANS-980 > URL: https://issues.apache.org/jira/browse/NETBEANS-980 > Project: NetBeans > Issue Type: Bug > Components: editor - Other, editor - Painting & Printing >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Major > > If line wrap is enabled, and the text caret is located in a wrapped > paragraph, the up/down arrow keys cannot be used to move the caret up/down to > another wrap line if the target wrap line is shorter than the current caret > position. Either nothing happens, or the caret may skip the shorter wrap > lines and step multiple wrap lines up/down. > To reproduce: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and paste in the paragraph "SHORTWORD > LONGWORD SHORTWORD LUUUNGWORD". > 3) Resize the editor window so that the paragraph gets split into three wrap > lines (one word on each wrap line--i.e. make the editor a little wider than > the long word). > 4) Position the cursor right after "...ONG" > 5) Press the "Up" arrow. Nothing happens (expected would be to the caret to > move up to the end of the previous wrap line). > 6) Press the "Down" arrow. This moves the caret _two_ wrap lines down instead > of to the end of the next wrap line. > Tested in NetBeans 9.0 rc1. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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] [Closed] (NETBEANS-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead
[ https://issues.apache.org/jira/browse/NETBEANS-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke closed NETBEANS-979. Resolution: Duplicate Fix Version/s: (was: 9.0) Having done a little work on this, the underlying issue is the same as for NETBEANS-980, so I'm closing this one and making all new comments on that one. > With line wrap enabled, cursor at end of line is painted at beginning of next > line instead > -- > > Key: NETBEANS-979 > URL: https://issues.apache.org/jira/browse/NETBEANS-979 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting & Printing >Reporter: Eirik Bakke >Priority: Major > > In an editor with line wrap enabled, the cursor is shown at the wrong > physical location whenever it is supposed to be located at the end of a wrap > line. Instead of being painted at the end of the wrap line, it is painted at > the beginning of the following line. This causes the behavior of keyboard > shortcuts like "End" and "Up" to seem nonsensical to the user, although they > might well be behaving correctly wrt. the physical location of the cursor > (the character offset). > To reproduce: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and open it in the editor. > 3) Type some gibberish into the editor on a single line that is long enough > to be broken into several break lines. > 4) With the cursor before the first character of the first wrap line in the > paragraph, press the "End" key (Command+Right on MacBook keyboards). The > cursor appears to move one line down, which is unexpected. From looking at > this situation, the user would now assume that they could press the "Up" key > to move the cursor back to the previous break line, but this will not change > the cursor position (because the cursor is logically on the previous line). > 5) Another unexpected example: Pressing Home anywhere in a paragraph will > move the cursor to the first character on the paragraph rather than at the > first character of the wrap line. (This might indicate that the problem is > more than just a paint bug, though.) > Originally reported in BugZilla at > https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on > NetBeans 9.0 rc1. > See also https://issues.apache.org/jira/browse/NETBEANS-980 . -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-980) Home/end/up/down does not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Summary: Home/end/up/down does not work properly when word wrapping is enabled (was: Cannot arrow up/down to shorter word-wrapped line in editor) > Home/end/up/down does not work properly when word wrapping is enabled > - > > Key: NETBEANS-980 > URL: https://issues.apache.org/jira/browse/NETBEANS-980 > Project: NetBeans > Issue Type: Bug > Components: editor - Other, editor - Painting & Printing >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Major > > If line wrap is enabled, and the text caret is located in a wrapped > paragraph, the up/down arrow keys cannot be used to move the caret up/down to > another wrap line if the target wrap line is shorter than the current caret > position. Either nothing happens, or the caret may skip the shorter wrap > lines and step multiple wrap lines up/down. > To reproduce: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and paste in the paragraph "SHORTWORD > LONGWORD SHORTWORD LUUUNGWORD". > 3) Resize the editor window so that the paragraph gets split into three wrap > lines (one word on each wrap line--i.e. make the editor a little wider than > the long word). > 4) Position the cursor right after "...ONG" > 5) Press the "Up" arrow. Nothing happens (expected would be to the caret to > move up to the end of the previous wrap line). > 6) Press the "Down" arrow. This moves the caret _two_ wrap lines down instead > of to the end of the next wrap line. > Tested in NetBeans 9.0 rc1. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-980) Home/end/up/down does not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Description: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is longer). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix (don't allow Utilities.getRowFirstNonWhite to move cursor before lineStartPos) and is unrelated to the others. Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap line. With NetBeans' current behavior, this space corresponds to a caret position directly following the last character of a wrap line. This caret position, however, is physically mapped (and painted) on the beginning of the following wrap line, which confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then bugs 2-4 might "fix themselves" as well. For bug 5, I think the best solution when clicking the space beyond the end of a wrap line would be to move the caret to right _before_ the last character on the wrap line. This character is usually a space (in word wrap mode), though it could also be a hyphen or such if a more advanced word wrapping algorithm is used (proposed in the pull request for NETBEANS-977). This behavior would be similar to that of a default JTextArea, or jEdit (neither which break words on anything else than a space). Another solution would be to do like the TextEdit app on MacOS, where the cursor is placed _after_ the last character on the wrap line, but with a backwards bias such that the cursor is painted on the end of the current wrap line instead of on the beginning of the next wrap line. The latter is probably harder to implement, and is not really necessary. To test the above bugs: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into four wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) For each bugs 1-4 listed above, position the caret right after "...ONG", then press the relevant key to test. 5) To test bug 5 above, click the mouse to the right of the first, second, or third wrap line. Tested in NetBeans 9.0 rc1. was: If line wrap is enabled, and the text caret is located in a wrapped paragraph, the up/down arrow keys cannot be used to move the caret up/down to another wrap line if the target wrap line is shorter than the current caret position. Either nothing happens, or the caret may skip the shorter wrap lines and step multiple wrap lines up/down. To reproduce: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into three wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) Position the cursor right after "...ONG" 5) Press the "Up" arrow. Nothing happens (expected would be to the caret to move up to the end of the previous wrap line). 6) Press the "Down" arrow. This moves the caret _two_ wrap lines down instead of to the end of the next wrap line. Tested in NetBeans 9.0 rc1. > Home/end/up/down does not work properly when word wrapping is enabled > - > > Key: NETBEANS-980 > URL: https://issues.apache.org/jira/browse/NETBEANS-980 > Project: NetBeans > Issue Type: Bug > Compon
[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Summary: Home/end/up/down do not work properly when word wrapping is enabled (was: Home/end/up/down does not work properly when word wrapping is enabled) > Home/end/up/down do not work properly when word wrapping is enabled > --- > > Key: NETBEANS-980 > URL: https://issues.apache.org/jira/browse/NETBEANS-980 > Project: NetBeans > Issue Type: Bug > Components: editor - Other, editor - Painting & Printing >Affects Versions: 9.0 >Reporter: Eirik Bakke >Priority: Major > > Caret movements via Home/End and arrow Up/Down keys do not work properly when > text wrap (especially in "after words" mode) is enabled in the NetBeans > editor. > Specific bugs: > 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the > beginning of the paragraph rather than to the beginning of the current wrap > line (physical line). > 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the > beginning of the next wrap line instead of to the end of the current wrap > line. > 3) Pressing Up has no effect if the preceding wrap line ended before the > caret's current X position. > 4) Pressing Down will move the caret down _two_ lines if the following wrap > line ended before the caret's current X position (and assuming the wrap line > two lines down is longer). > 5) Left-clicking the mouse to the right of the end of a wrap line puts the > caret on the beginning of the next wrap line rather than at the end of the > current (clicked) wrap line. > The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit > (UpAction/DownAction/BeginLineAction/EndLineAction). > Bug number 1 above, for the Home action (BeginLineAction), is easy to fix > (don't allow Utilities.getRowFirstNonWhite to move cursor before > lineStartPos) and is unrelated to the others. > Bugs 2-5 above all relate to what caret position is mapped to the "infinite" > horizontal space that follows each wrap line. With NetBeans' current > behavior, this space corresponds to a caret position directly following the > last character of a wrap line. This caret position, however, is physically > mapped (and painted) on the beginning of the following wrap line, which > confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 > is fixed, then bugs 2-4 might "fix themselves" as well. > For bug 5, I think the best solution when clicking the space beyond the end > of a wrap line would be to move the caret to right _before_ the last > character on the wrap line. This character is usually a space (in word wrap > mode), though it could also be a hyphen or such if a more advanced word > wrapping algorithm is used (proposed in the pull request for NETBEANS-977). > This behavior would be similar to that of a default JTextArea, or jEdit > (neither which break words on anything else than a space). Another solution > would be to do like the TextEdit app on MacOS, where the cursor is placed > _after_ the last character on the wrap line, but with a backwards bias such > that the cursor is painted on the end of the current wrap line instead of on > the beginning of the next wrap line. The latter is probably harder to > implement, and is not really necessary. > To test the above bugs: > 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and > set "Line Wrap" to "After words". Click OK. > 2) Create a new plain text file and paste in the paragraph "SHORTWORD > LONGWORD SHORTWORD LUUUNGWORD". > 3) Resize the editor window so that the paragraph gets split into four wrap > lines (one word on each wrap line--i.e. make the editor a little wider than > the long word). > 4) For each bugs 1-4 listed above, position the caret right after > "...ONG", then press the relevant key to test. > 5) To test bug 5 above, click the mouse to the right of the first, second, or > third wrap line. > Tested in NetBeans 9.0 rc1. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-980) Home/end/up/down do not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Description: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix (don't allow Utilities.getRowFirstNonWhite to move cursor before lineStartPos) and is unrelated to the others. Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap line. With NetBeans' current behavior, this space corresponds to a caret position directly following the last character of a wrap line. This caret position, however, is physically mapped (and painted) on the beginning of the following wrap line, which confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then bugs 2-4 might "fix themselves" as well. For bug 5, I think the best solution when clicking the space beyond the end of a wrap line would be to move the caret to right _before_ the last character on the wrap line. This character is usually a space (in word wrap mode), though it could also be a hyphen or such if a more advanced word wrapping algorithm is used (proposed in the pull request for NETBEANS-977). This behavior would be similar to that of a default JTextArea, or jEdit (neither which break words on anything else than a space). Another solution would be to do like the TextEdit app on MacOS, where the cursor is placed _after_ the last character on the wrap line, but with a backwards bias such that the cursor is painted on the end of the current wrap line instead of on the beginning of the next wrap line. The latter is probably harder to implement, and is not really necessary. To test the above bugs: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into four wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) For each bugs 1-4 listed above, position the caret right after "...ONG", then press the relevant key to test. 5) To test bug 5 above, click the mouse to the right of the first, second, or third wrap line. Tested in NetBeans 9.0 rc1. was: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is longer). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix (don't allow Utilities.getRowFirstNonWhite to move cursor before lineStartPos) and is unrelated to the others. Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap line. With
[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Description: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move the caret before lineStartPos.) Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap line. With NetBeans' current behavior, this space corresponds to a caret position directly following the last character of a wrap line. This caret position, however, is physically mapped (and painted) on the beginning of the following wrap line, which confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then bugs 2-4 might "fix themselves" as well. For bug 5, I think the best solution when clicking the space beyond the end of a wrap line would be to move the caret to right _before_ the last character on the wrap line. This character is usually a space (in word wrap mode), though it could also be a hyphen or such if a more advanced word wrapping algorithm is used (proposed in the pull request for NETBEANS-977). This behavior would be similar to that of a default JTextArea, or jEdit (neither which break words on anything else than a space). Another solution would be to do like the TextEdit app on MacOS, where the cursor is placed _after_ the last character on the wrap line, but with a backwards bias such that the cursor is painted on the end of the current wrap line instead of on the beginning of the next wrap line. The latter is probably harder to implement, and is not really necessary. To test the above bugs: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into four wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) For each bugs 1-4 listed above, position the caret right after "...ONG", then press the relevant key to test. 5) To test bug 5 above, click the mouse to the right of the first, second, or third wrap line. Tested in NetBeans 9.0 rc1. was: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix (don't allow Utilities.getRowFirstNonWhite to move cursor before lineStartPos) and is unrelated to the others. Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap l
[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Description: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move the caret before lineStartPos.) Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap line. With NetBeans' current behavior, this space corresponds to a caret position directly following the last character of a wrap line. This caret position, however, is physically mapped (and painted) on the beginning of the following wrap line, which confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then bugs 2-4 might "fix themselves" as well. For bug 5, I think the best solution when clicking the space beyond the end of a wrap line would be to move the caret to right _before_ the last character on the wrap line. This character is usually a space (in word wrap mode), though it could also be a hyphen or such if a more advanced word wrapping algorithm is used (proposed in the pull request for NETBEANS-977). The resulting behavior would be similar to that of a default JTextArea, or jEdit (though these never break words on anything else than a space). Another solution would be to do like the TextEdit app on MacOS, where the cursor is placed _after_ the last character on the wrap line, but with a backwards bias such that the cursor is painted on the end of the current wrap line instead of on the beginning of the next wrap line. The latter is probably harder to implement, and is not really necessary. To test the above bugs: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into four wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) For each bugs 1-4 listed above, position the caret right after "...ONG", then press the relevant key to test. 5) To test bug 5 above, click the mouse to the right of the first, second, or third wrap line. Tested in NetBeans 9.0 rc1. was: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move the caret before lineStartPos.) Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that
[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled
[ https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-980: - Description: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move the caret before lineStartPos.) Bugs 2-5 above all relate to what caret position is mapped to the "infinite" horizontal space that follows each wrap line. With NetBeans' current behavior, this space corresponds to a caret position directly following the last character of a wrap line. This caret position, however, is physically mapped (and painted) on the beginning of the following wrap line, which confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then bugs 2-4 might "fix themselves" as well. For bug 5, I think the best solution when clicking the space beyond the end of a wrap line would be to move the caret to right _before_ the last character on the wrap line. This character is usually a space (in word wrap mode), though it could also be a hyphen or such if a more advanced word wrapping algorithm is used (proposed in the pull request for NETBEANS-977). The resulting behavior would be similar to that of a default JTextArea, or jEdit (though these never break words on anything else than a space). Another solution would be to do like the TextEdit app on MacOS, where the cursor is placed _after_ the last character on the wrap line, like NetBeans currently does, but with a backwards bias such that the cursor is painted on the end of the current wrap line instead of on the beginning of the next wrap line. The latter is probably harder to implement, and is not really necessary. To test the above bugs: 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and set "Line Wrap" to "After words". Click OK. 2) Create a new plain text file and paste in the paragraph "SHORTWORD LONGWORD SHORTWORD LUUUNGWORD". 3) Resize the editor window so that the paragraph gets split into four wrap lines (one word on each wrap line--i.e. make the editor a little wider than the long word). 4) For each bugs 1-4 listed above, position the caret right after "...ONG", then press the relevant key to test. 5) To test bug 5 above, click the mouse to the right of the first, second, or third wrap line. Tested in NetBeans 9.0 rc1. was: Caret movements via Home/End and arrow Up/Down keys do not work properly when text wrap (especially in "after words" mode) is enabled in the NetBeans editor. Specific bugs: 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the beginning of the paragraph rather than to the beginning of the current wrap line (physical line). 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the beginning of the next wrap line instead of to the end of the current wrap line. 3) Pressing Up has no effect if the preceding wrap line ended before the caret's current X position. 4) Pressing Down will move the caret down _two_ lines if the following wrap line ended before the caret's current X position (and assuming the wrap line two lines down is long enough). 5) Left-clicking the mouse to the right of the end of a wrap line puts the caret on the beginning of the next wrap line rather than at the end of the current (clicked) wrap line. The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit (UpAction/DownAction/BeginLineAction/EndLineAction). Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move the caret before lineStartPos.) Bugs 2-5 above all relate to what caret position is mapped to the "inf
[jira] [Commented] (NETBEANS-765) HiDPI resolution of 3840x2160 results in tiny icons and text fields that are too small for the text within
[ https://issues.apache.org/jira/browse/NETBEANS-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16564540#comment-16564540 ] Eirik Bakke commented on NETBEANS-765: -- I've now used NetBeans for about three weeks on a Windows-based HiDPI screen (2560x1440, tried with the OS-level scaling setting set to both 150% and 200%). This actually works quite well! There are plenty of small bugs, especially when connecting and disconnecting an external non-HiDPI monitor, or when moving windows between HiDPI and non-HiDPI screens, but I could usually figure out ways to work around these. It's essential to run the IDE on a recent JDK version, though. I used OpenJDK 10.0.0.1+9. I also tried to use Java 8; in the latter case NetBeans became much less usable, with a mix of tiny and regular-sized controls, controls that don't fit in their dialog box, and such. I also observed that even even the latest version of Microsoft Office--which we should expect to be the "gold standard" of Windows applications--also has a few similar HiDPI-related bugs. > HiDPI resolution of 3840x2160 results in tiny icons and text fields that are > too small for the text within > -- > > Key: NETBEANS-765 > URL: https://issues.apache.org/jira/browse/NETBEANS-765 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Affects Versions: 9.0 >Reporter: Sidney Lins >Priority: Major > Labels: HiDPI > Attachments: Screenshot from 2018-05-28 19-29-19.png, Screenshot from > 2018-05-28 19-29-19.png, Screenshot from 2018-05-28 19-40-36.png, Screenshot > from 2018-07-07 21-21-32.jpg > > > Please, refer to [https://netbeans.org/bugzilla/show_bug.cgi?id=252452] to > get more information. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-765) HiDPI resolution of 3840x2160 results in tiny icons and text fields that are too small for the text within
[ https://issues.apache.org/jira/browse/NETBEANS-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16564540#comment-16564540 ] Eirik Bakke edited comment on NETBEANS-765 at 8/1/18 12:18 AM: --- I've now used NetBeans for about three weeks on a Windows-based HiDPI screen (2560x1440, tried with the OS-level scaling setting set to both 150% and 200%). This actually works quite well! There are plenty of small bugs, especially when connecting and disconnecting an external non-HiDPI monitor, or when moving windows between HiDPI and non-HiDPI screens, but I could usually figure out ways to work around these. It's essential to run the IDE on a recent JDK version, though. I used OpenJDK 10.0.0.1+9. I also tried to use Java 8; in the latter case NetBeans became much less usable, with a mix of tiny and regular-sized controls, controls that don't fit in their dialog box, and such. I also observed that even even the latest version of Microsoft Office, which we should expect to be the "gold standard" of Windows applications, also has a few similar HiDPI-related bugs. was (Author: ebakke): I've now used NetBeans for about three weeks on a Windows-based HiDPI screen (2560x1440, tried with the OS-level scaling setting set to both 150% and 200%). This actually works quite well! There are plenty of small bugs, especially when connecting and disconnecting an external non-HiDPI monitor, or when moving windows between HiDPI and non-HiDPI screens, but I could usually figure out ways to work around these. It's essential to run the IDE on a recent JDK version, though. I used OpenJDK 10.0.0.1+9. I also tried to use Java 8; in the latter case NetBeans became much less usable, with a mix of tiny and regular-sized controls, controls that don't fit in their dialog box, and such. I also observed that even even the latest version of Microsoft Office--which we should expect to be the "gold standard" of Windows applications--also has a few similar HiDPI-related bugs. > HiDPI resolution of 3840x2160 results in tiny icons and text fields that are > too small for the text within > -- > > Key: NETBEANS-765 > URL: https://issues.apache.org/jira/browse/NETBEANS-765 > Project: NetBeans > Issue Type: Bug > Components: ide - UI >Affects Versions: 9.0 >Reporter: Sidney Lins >Priority: Major > Labels: HiDPI > Attachments: Screenshot from 2018-05-28 19-29-19.png, Screenshot from > 2018-05-28 19-29-19.png, Screenshot from 2018-05-28 19-40-36.png, Screenshot > from 2018-07-07 21-21-32.jpg > > > Please, refer to [https://netbeans.org/bugzilla/show_bug.cgi?id=252452] to > get more information. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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] [Reopened] (NETBEANS-1238) HiDPI icons in tabcontrol and openide.awt modules for Windows LAF
[ https://issues.apache.org/jira/browse/NETBEANS-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke reopened NETBEANS-1238: --- > HiDPI icons in tabcontrol and openide.awt modules for Windows LAF > - > > Key: NETBEANS-1238 > URL: https://issues.apache.org/jira/browse/NETBEANS-1238 > Project: NetBeans > Issue Type: Bug > Components: platform - Window System >Affects Versions: 9.0 > Environment: Windows 8.1 and Windows 10 with high-density displays or > accessibility scaling >Reporter: Eirik Bakke >Priority: Major > Labels: HiDPI, pull-request-available > Fix For: Next > > Attachments: NETBEANS-1238 After patch.png, NETBEANS-1238 Before > patch.png, VectorIconTester output.png > > Time Spent: 20m > Remaining Estimate: 0h > > On Windows 10, each monitor may be configured with an arbitrary scaling > factor, such as 125%, 150%, 200%, or even 300%. For instance, high-density > laptop displays are typically set to a scaling of 200% by default. On Java 9 > and 10, Swing handles this "HiDPI" scaling automatically, making the UI take > up more pixels without looking smaller, and without any changes in the client > application. This makes bitmap icons blurry or ragged, however. > To look good on HiDPI displays on Windows 10, the various icons that are part > of NetBeans' window system must be made scalable to arbitrary resolutions. > This includes, for instance, the "X" button that is used to close tabs, the > "_" button that collapses a sidebar, or the ">>" button that shows hidden > toolbar icons. These icons reside in the tabcontrol and openide.awt modules. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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] [Reopened] (NETBEANS-1260) HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF
[ https://issues.apache.org/jira/browse/NETBEANS-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke reopened NETBEANS-1260: --- > HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF > -- > > Key: NETBEANS-1260 > URL: https://issues.apache.org/jira/browse/NETBEANS-1260 > Project: NetBeans > Issue Type: Bug > Components: platform - Window System >Affects Versions: 9.0 > Environment: MacOS with retina screens (e.g. MacBook Pro) >Reporter: Eirik Bakke >Priority: Major > Labels: HiDPI, pull-request-available > Fix For: Next > > Attachments: NETBEANS-1260 MacOS Retina After Patch.png, > NETBEANS-1260 MacOS Retina Before Patch.png, VectorIconTest Output with Aqua > and Windows vector icons.png > > > To look good on MacBook Pro and other Apple computers with Retina screens, > the various icons that are part of NetBeans' window system must be made > available in both 100% and 200% sizes. This includes, for instance, the "X" > button that is used to close tabs, the "_" button that collapses a sidebar, > or the ">>" button that shows hidden toolbar icons. These icons reside in the > tabcontrol and openide.awt modules. > I'll soon submit a pull request that fixes this by providing vectorized > versions of the relevant window system icons. The approach is the same as is > taken for the Windows LAF, in NETBEANS-1238. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-1238) HiDPI icons in tabcontrol and openide.awt modules for Windows LAF
[ https://issues.apache.org/jira/browse/NETBEANS-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-1238. --- Resolution: Fixed Fix Version/s: (was: Next) 11.0 > HiDPI icons in tabcontrol and openide.awt modules for Windows LAF > - > > Key: NETBEANS-1238 > URL: https://issues.apache.org/jira/browse/NETBEANS-1238 > Project: NetBeans > Issue Type: Bug > Components: platform - Window System >Affects Versions: 9.0 > Environment: Windows 8.1 and Windows 10 with high-density displays or > accessibility scaling >Reporter: Eirik Bakke >Priority: Major > Labels: HiDPI, pull-request-available > Fix For: 11.0 > > Attachments: NETBEANS-1238 After patch.png, NETBEANS-1238 Before > patch.png, VectorIconTester output.png > > Time Spent: 20m > Remaining Estimate: 0h > > On Windows 10, each monitor may be configured with an arbitrary scaling > factor, such as 125%, 150%, 200%, or even 300%. For instance, high-density > laptop displays are typically set to a scaling of 200% by default. On Java 9 > and 10, Swing handles this "HiDPI" scaling automatically, making the UI take > up more pixels without looking smaller, and without any changes in the client > application. This makes bitmap icons blurry or ragged, however. > To look good on HiDPI displays on Windows 10, the various icons that are part > of NetBeans' window system must be made scalable to arbitrary resolutions. > This includes, for instance, the "X" button that is used to close tabs, the > "_" button that collapses a sidebar, or the ">>" button that shows hidden > toolbar icons. These icons reside in the tabcontrol and openide.awt modules. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-1658) Switch to NIO based file access causes regression
[ https://issues.apache.org/jira/browse/NETBEANS-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-1658: -- Fix Version/s: 11.0 > Switch to NIO based file access causes regression > - > > Key: NETBEANS-1658 > URL: https://issues.apache.org/jira/browse/NETBEANS-1658 > Project: NetBeans > Issue Type: Bug >Affects Versions: 9.0 >Reporter: Matthias Bläsing >Assignee: Matthias Bläsing >Priority: Major > Fix For: 11.0 > > > With the git commit: > [https://github.com/apache/incubator-netbeans/commit/4b82e6adb31e294c74fd2fa99779ce9e27ae6184] > several file accesses were switched from FileInputStream to NIO based input > streams. These new stream differ in behavior. On Thread#interrupt the new > streams raise a ClosedByInterruptException. At most places this exception is > not handled and thus causes unexpected behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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-1260) HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF
[ https://issues.apache.org/jira/browse/NETBEANS-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke resolved NETBEANS-1260. --- Resolution: Fixed Fix Version/s: (was: Next) 11.0 > HiDPI icons in tabcontrol and openide.awt modules for Aqua (MacOS) LAF > -- > > Key: NETBEANS-1260 > URL: https://issues.apache.org/jira/browse/NETBEANS-1260 > Project: NetBeans > Issue Type: Bug > Components: platform - Window System >Affects Versions: 9.0 > Environment: MacOS with retina screens (e.g. MacBook Pro) >Reporter: Eirik Bakke >Priority: Major > Labels: HiDPI, pull-request-available > Fix For: 11.0 > > Attachments: NETBEANS-1260 MacOS Retina After Patch.png, > NETBEANS-1260 MacOS Retina Before Patch.png, VectorIconTest Output with Aqua > and Windows vector icons.png > > > To look good on MacBook Pro and other Apple computers with Retina screens, > the various icons that are part of NetBeans' window system must be made > available in both 100% and 200% sizes. This includes, for instance, the "X" > button that is used to close tabs, the "_" button that collapses a sidebar, > or the ">>" button that shows hidden toolbar icons. These icons reside in the > tabcontrol and openide.awt modules. > I'll soon submit a pull request that fixes this by providing vectorized > versions of the relevant window system icons. The approach is the same as is > taken for the Windows LAF, in NETBEANS-1238. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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) 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&focusedCommentId=16797834#comment-16797834 ] Eirik Bakke commented on NETBEANS-1901: --- I can reproduce it on Windows 10 on NetBeans 10.0 (Java 11.0.1). (I just pasted the example into a Java file.) Not sure why it happens, though. > 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 > Environment: MacOS Mojave, Netbeans 10, iMac 5k, PHP7.1 >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. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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
