[jira] [Commented] (NETBEANS-646) Keyboard lag in 8.2 under macOS 10.13 High Sierra?
[ https://issues.apache.org/jira/browse/NETBEANS-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520975#comment-16520975 ] Laszlo Kishalmi commented on NETBEANS-646: -- Does it still happen? These are usual symptoms of an overloaded hardware/os/event queue. Does a reboot fix this issue? > Keyboard lag in 8.2 under macOS 10.13 High Sierra? > -- > > Key: NETBEANS-646 > URL: https://issues.apache.org/jira/browse/NETBEANS-646 > Project: NetBeans > Issue Type: Bug > Environment: MacBook Pro, NB 8.2, JDK 1.8.? >Reporter: Bob Alei >Priority: Critical > > A student of mine is having big trouble with newly installed NB 8.2 on a > Macbook pro (?) running with JDK 1.8.? In the source editor, he can type a > few characters then the cursor jumps around, very erratically. I think it's a > keyboard lag issue, if he waits a half second between keypresses, it seems to > be OK. But it could be something else. Are there any known configurations > that cause bizarre keyboard behavior? Anything else that I could check? All > other programs on his computer work fine. TIA, > Bob Alei > PS. MY apologies if this is the wrong forum for this kind of question. > Please advise if so. -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520964#comment-16520964 ] Laszlo Kishalmi commented on NETBEANS-798: -- Well, could you be more specific please? What OS do you use? What kind of snipping tools you experienced the problem with. > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Attachments: b0.PNG > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-816) Netbeans inline JSX Variable
[ https://issues.apache.org/jira/browse/NETBEANS-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laszlo Kishalmi updated NETBEANS-816: - Component/s: javascript - Editor > Netbeans inline JSX Variable > > > Key: NETBEANS-816 > URL: https://issues.apache.org/jira/browse/NETBEANS-816 > Project: NetBeans > Issue Type: Bug > Components: javascript - Editor >Affects Versions: 8.2 >Reporter: Wagner Silva >Priority: Critical > Attachments: image-2018-05-18-15-28-30-210.png > > > Netbeans is not being able to interpret a variable inside of a style tag in > JSX. > React is very popular right now, and this kind of usage is very important. > > !image-2018-05-18-15-28-30-210.png! -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laszlo Kishalmi updated NETBEANS-798: - Component/s: javascript - Editor > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Attachments: b0.PNG > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laszlo Kishalmi updated NETBEANS-798: - Component/s: (was: javascript - Editor) > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Attachments: b0.PNG > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-798) Netbeans crashes after closing snipping tools
[ https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laszlo Kishalmi updated NETBEANS-798: - Affects Version/s: 8.2 > Netbeans crashes after closing snipping tools > - > > Key: NETBEANS-798 > URL: https://issues.apache.org/jira/browse/NETBEANS-798 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Eduard Fekete >Priority: Critical > Attachments: b0.PNG > > > I opened the dialog to create a new project because I wanted to take a > screenshot of it for a bug report, by using snipping tools. Ironically I > found another bug, after taking the screenshot and closing snipping tools, > NetBeans crashed. I was able to reproduce this many times. > > -- 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-816) Netbeans inline JSX Variable
[ https://issues.apache.org/jira/browse/NETBEANS-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520963#comment-16520963 ] Laszlo Kishalmi commented on NETBEANS-816: -- Well, I guess it is filed against 8.2. We've just got the second code drop which covers the Java EE, JS, etc. > Netbeans inline JSX Variable > > > Key: NETBEANS-816 > URL: https://issues.apache.org/jira/browse/NETBEANS-816 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Wagner Silva >Priority: Critical > Attachments: image-2018-05-18-15-28-30-210.png > > > Netbeans is not being able to interpret a variable inside of a style tag in > JSX. > React is very popular right now, and this kind of usage is very important. > > !image-2018-05-18-15-28-30-210.png! -- 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-816) Netbeans inline JSX Variable
[ https://issues.apache.org/jira/browse/NETBEANS-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laszlo Kishalmi updated NETBEANS-816: - Affects Version/s: 8.2 > Netbeans inline JSX Variable > > > Key: NETBEANS-816 > URL: https://issues.apache.org/jira/browse/NETBEANS-816 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2 >Reporter: Wagner Silva >Priority: Critical > Attachments: image-2018-05-18-15-28-30-210.png > > > Netbeans is not being able to interpret a variable inside of a style tag in > JSX. > React is very popular right now, and this kind of usage is very important. > > !image-2018-05-18-15-28-30-210.png! -- 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-866) Platform "Resolve" button for libraries broken out of the box.
[ https://issues.apache.org/jira/browse/NETBEANS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520962#comment-16520962 ] Laszlo Kishalmi commented on NETBEANS-866: -- Hi [~pajansen], Have Geertjan's hints resolved your problem? We either have to mark this issue resolved, or demoted from critical in order to cut our final release. > Platform "Resolve" button for libraries broken out of the box. > -- > > Key: NETBEANS-866 > URL: https://issues.apache.org/jira/browse/NETBEANS-866 > Project: NetBeans > Issue Type: Bug > Components: platform - JDK Problems >Affects Versions: 8.2 >Reporter: Peter Jansen >Priority: Critical > Attachments: netbeans_issue_javafx.jpg > > > I've just started trying to develop a GUI using the Netbeans Platform using > the NetBeans Platform for Beginners and JavaFX RCP for the Netbeans Platform > books recommended as part of the official documentation on the platform > website. > The very first examples in the book appear to break, as the Project > Properties > Libraries dialog throws the following error: > "Module FX WebView Bootstrap in platform requests the token > javafx.application but there are no known providers." > The resolve button is red, but can't be clicked. > 1) Ignoring and attempting to add modules without being able to resolve their > dependencies means the program will throw and error and modules will be > disabled upon startup. > 2) Deselecting the offending modules (FX Webview Bootstrap in platform, and > so on through other FX-depending modules, until the resolve button works > again) appears to allow the code to compile and dependencies to be > automatically resolved – but only a few pages in the book, adding the 'XML > Text Editor' and resolving the dependencies for this causes the program to > crash when running: > java.lang.NoClassDefFoundError: Could not initialize class > org.netbeans.api.project.ProjectManager > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > ... > It seems that this is a major issue reported several years ago on other > venues with 8.x, and I've checked and also appears to be present on the > development and 9.0rc1 builds, but still hasn't been fixed? This appears to > be a major issue in even beginning to write new software using the netbeans > platform? My apologies if this is a simple error or oversight on my part. -- 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-931) OutOfMemory after a night of stand-by
[ https://issues.apache.org/jira/browse/NETBEANS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520960#comment-16520960 ] Laszlo Kishalmi commented on NETBEANS-931: -- Could you compress the dump? Also you can upload the compressed dump to Telegram [https://t.me/lkishalmi] or https://t.me/apache_netbeans > OutOfMemory after a night of stand-by > - > > Key: NETBEANS-931 > URL: https://issues.apache.org/jira/browse/NETBEANS-931 > Project: NetBeans > Issue Type: Bug >Affects Versions: 9.0 >Reporter: Luca Mambretti >Priority: Critical > Attachments: messages.log, uigestures.xml > > > After a full day of work I left the system running (it had manifested the > errors described in NETBEANS-901). > > The day after it was out of commission with OOM. > > attached IDE logs and gestures, I also have the heap dump but it's 1.5 gigs > so I doubt I'll be able to attach it (sent it thru a WeTransfer link for now) -- 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-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=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-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
[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
[jira] [Assigned] (NETBEANS-965) does not load GlassFish
[ https://issues.apache.org/jira/browse/NETBEANS-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kron22 reassigned NETBEANS-965: --- Assignee: (was: Kron22) > does not load GlassFish > --- > > Key: NETBEANS-965 > URL: https://issues.apache.org/jira/browse/NETBEANS-965 > Project: NetBeans > Issue Type: Bug > Components: serverplugins - GlassFish > Environment: OS: Manjaro 17.1.10 Hakoila > Kernel: x86_64 Linux 4.14.48-2-MANJARO > DE: Xfce4 > WM: Xfwm4 >Reporter: Kron22 >Priority: Major > Attachments: error-glassfish.png > > > does not load GlassFish server -- 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-981) the Java_ME_platform_SDK_8.3 platform is not defined
Kron22 created NETBEANS-981: --- Summary: the Java_ME_platform_SDK_8.3 platform is not defined Key: NETBEANS-981 URL: https://issues.apache.org/jira/browse/NETBEANS-981 Project: NetBeans Issue Type: Bug Components: platform - JDK Problems Affects Versions: 8.2 Reporter: Kron22 Attachments: platform.png In Netbeans 8.2 I tried to add a Platform for Java ME SDK 8.3 without success the error message is Platform detection failed what goes wrong? -- 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] [Assigned] (NETBEANS-965) does not load GlassFish
[ https://issues.apache.org/jira/browse/NETBEANS-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kron22 reassigned NETBEANS-965: --- Assignee: Kron22 > does not load GlassFish > --- > > Key: NETBEANS-965 > URL: https://issues.apache.org/jira/browse/NETBEANS-965 > Project: NetBeans > Issue Type: Bug > Components: serverplugins - GlassFish > Environment: OS: Manjaro 17.1.10 Hakoila > Kernel: x86_64 Linux 4.14.48-2-MANJARO > DE: Xfce4 > WM: Xfwm4 >Reporter: Kron22 >Assignee: Kron22 >Priority: Major > Attachments: error-glassfish.png > > > does not load GlassFish server -- 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-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 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-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] [Resolved] (NETBEANS-971) Can't open tools/options
[ https://issues.apache.org/jira/browse/NETBEANS-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laszlo Kishalmi resolved NETBEANS-971. -- Resolution: Information Provided Well, NetBeans 8.2 goes well with Java 8. NetBeans 9.0 is in a quite good shape we are cooking the RC-s now. Though it hasonly Java SE support. > Can't open tools/options > > > Key: NETBEANS-971 > URL: https://issues.apache.org/jira/browse/NETBEANS-971 > Project: NetBeans > Issue Type: Bug > Components: editor - Actions/Menu/Toolbar >Affects Versions: 8.2 > Environment: Product Version: NetBeans IDE 8.2 (Build 201609300101) > Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2 > Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10 > Runtime: Java(TM) SE Runtime Environment 10.0.1+10 > System: Windows 10 version 10.0 running on amd64; Cp1252; en_GB (nb) > User directory: C:\Users\bob\AppData\Roaming\NetBeans\8.2 > Cache directory: C:\Users\bob\AppData\Local\NetBeans\Cache\8.2 >Reporter: Bob Findlay >Priority: Blocker > Attachments: netbeans.log > > > If I select tools config I get no window appear. On another computer I've > installed the same version of netbeans and it works fine. > I didn't have an api.properties so I tried creating one in > C:\Users\bob\AppData\Roaming\NetBeans\8.2\config\Preferences\org\netbeans\modules\options > containing > > OptionsHeight = 500 > OptionsWidth = 871 > OptionsX = 100 > OptionsY = 117 > > but it didn't help > log file attached -- 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 ] ASF GitHub Bot updated NETBEANS-977: Labels: pull-request-available (was: ) > 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 > Labels: pull-request-available > 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. 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. -- 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. 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
[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
[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, currently
[jira] [Commented] (NETBEANS-971) Can't open tools/options
[ https://issues.apache.org/jira/browse/NETBEANS-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520322#comment-16520322 ] Bob Findlay commented on NETBEANS-971: -- yes, netbeans 9 doesn't have a problem. what version of JDK should I use if I don't want to use the beta of 9, but 8.2? > Can't open tools/options > > > Key: NETBEANS-971 > URL: https://issues.apache.org/jira/browse/NETBEANS-971 > Project: NetBeans > Issue Type: Bug > Components: editor - Actions/Menu/Toolbar >Affects Versions: 8.2 > Environment: Product Version: NetBeans IDE 8.2 (Build 201609300101) > Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2 > Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10 > Runtime: Java(TM) SE Runtime Environment 10.0.1+10 > System: Windows 10 version 10.0 running on amd64; Cp1252; en_GB (nb) > User directory: C:\Users\bob\AppData\Roaming\NetBeans\8.2 > Cache directory: C:\Users\bob\AppData\Local\NetBeans\Cache\8.2 >Reporter: Bob Findlay >Priority: Blocker > Attachments: netbeans.log > > > If I select tools config I get no window appear. On another computer I've > installed the same version of netbeans and it works fine. > I didn't have an api.properties so I tried creating one in > C:\Users\bob\AppData\Roaming\NetBeans\8.2\config\Preferences\org\netbeans\modules\options > containing > > OptionsHeight = 500 > OptionsWidth = 871 > OptionsX = 100 > OptionsY = 117 > > but it didn't help > log file attached -- 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-975) Template Wizard does not create files on config FS
[
https://issues.apache.org/jira/browse/NETBEANS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated NETBEANS-975:
Labels: pull-request-available (was: )
> Template Wizard does not create files on config FS
> --
>
> Key: NETBEANS-975
> URL: https://issues.apache.org/jira/browse/NETBEANS-975
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Data Systems
>Reporter: Svatopluk Dedic
>Assignee: Svatopluk Dedic
>Priority: Major
> Labels: pull-request-available
>
> I wanted to use the
> {noformat}
> o.o.loaders.TemplateWizard{noformat}
> to create some files on config FS. I have vound that when the Wizard
> completes, the resulting FileObject is placed correctly, but comes from the
> underlying physical filesystem. Then checks like the following fail:
>
> {code:java}
> wizard.setTargetFolder(DataFolder.findFolder(FileUtil.getConfigFile("scripts"));
> Set result = wizard.instantiate();
> FileObject fo = result.iterator().next().getPrimaryFile();
> FileObject cfRoot = FileUtil.getConfigRoot();
> if (FileUtil.isParentOf(cfRoot, fo)) {
> // never reached
> }
> {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-811) Screen doesn't scroll on shortcut key after change from Chinese input method back to English
[ https://issues.apache.org/jira/browse/NETBEANS-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chu updated NETBEANS-811: -- Summary: Screen doesn't scroll on shortcut key after change from Chinese input method back to English (was: Screen does scroll on shortcut key after change from Chinese input method back to English) > Screen doesn't scroll on shortcut key after change from Chinese input method > back to English > > > Key: NETBEANS-811 > URL: https://issues.apache.org/jira/browse/NETBEANS-811 > Project: NetBeans > Issue Type: Bug >Reporter: Paul Chu >Priority: Major > > Product Version = NetBeans IDE 8.2 (Build 201609300101) > Operating System = Linux version 4.13.0-41-generic running on amd64 > Java; VM; Vendor = 1.8.0_171 > Runtime = Java HotSpot(TM) 64-Bit Server VM 25.171-b11 > STEPS: > * Change to Chinese input method and type something. > * Change back to English input method > * Key End, Ctrl-Home not work, screen will not scroll to cursor position. > ACTUAL: > nothing happens > EXPECTED: > Screen scroll to cursor position -- 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-976) Template wizard does not work well for virtual folders on config fs
Svatopluk Dedic created NETBEANS-976:
Summary: Template wizard does not work well for virtual folders on
config fs
Key: NETBEANS-976
URL: https://issues.apache.org/jira/browse/NETBEANS-976
Project: NetBeans
Issue Type: Bug
Components: platform - Data Systems
Reporter: Svatopluk Dedic
Suppose the wizard is configured with a folder in config fs:
{code:java}
wizard.setTargetFolder(DataFolder.findFolder(FileUtil.getConfigFile("scripts"));
{code}
and that the "scripts" folder is empty and present only in the XML layers of
some module.
The Wizard is unable to create files in such on config FS; it converts
FileObject to File quite early and if the target folder is not yet materialized
on disk, the Wizard behaves as if no target folder was specified.
--
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-975) Template Wizard does not create files on config FS
Svatopluk Dedic created NETBEANS-975:
Summary: Template Wizard does not create files on config FS
Key: NETBEANS-975
URL: https://issues.apache.org/jira/browse/NETBEANS-975
Project: NetBeans
Issue Type: Bug
Components: platform - Data Systems
Reporter: Svatopluk Dedic
Assignee: Svatopluk Dedic
I wanted to use the
{noformat}
o.o.loaders.TemplateWizard{noformat}
to create some files on config FS. I have vound that when the Wizard completes,
the resulting FileObject is placed correctly, but comes from the underlying
physical filesystem. Then checks like the following fail:
{code:java}
wizard.setTargetFolder(DataFolder.findFolder(FileUtil.getConfigFile("scripts"));
Set result = wizard.instantiate();
FileObject fo = result.iterator().next().getPrimaryFile();
FileObject cfRoot = FileUtil.getConfigRoot();
if (FileUtil.isParentOf(cfRoot, fo)) {
// never reached
}
{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-860) Proposed new hint "Convert Lambda to Use 'var' Parameter Types" for Lambda expression
[ https://issues.apache.org/jira/browse/NETBEANS-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated NETBEANS-860: Labels: JDK11-VarInLambda pull-request-available (was: JDK11-VarInLambda) > Proposed new hint "Convert Lambda to Use 'var' Parameter Types" for Lambda > expression > -- > > Key: NETBEANS-860 > URL: https://issues.apache.org/jira/browse/NETBEANS-860 > Project: NetBeans > Issue Type: Improvement >Reporter: ARUNAVA SINHA >Assignee: vikas kumar prabhakar >Priority: Minor > Labels: JDK11-VarInLambda, pull-request-available > > Hint "Convert Lambda to Use 'var' Parameter Types" should be enable for below > expressions. > IntBinaryOperator cal c= (int x, int y) -> x + y; > IntBinaryOperator cal c= (x, y) -> x + y; > Proposed fix : > IntBinaryOperator calc = (var x, var y) -> x + y; -- 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] [Assigned] (NETBEANS-691) Cannot undo conversion of constructor to factory when refactoring in calling class.
[ https://issues.apache.org/jira/browse/NETBEANS-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ARUNAVA SINHA reassigned NETBEANS-691: -- Assignee: ARUNAVA SINHA > Cannot undo conversion of constructor to factory when refactoring in calling > class. > > > Key: NETBEANS-691 > URL: https://issues.apache.org/jira/browse/NETBEANS-691 > Project: NetBeans > Issue Type: Bug > Components: java - Refactoring >Affects Versions: 9.0 >Reporter: Manikantan Narender Nath >Assignee: ARUNAVA SINHA >Priority: Major > > Test Spec: > [http://netbeans-vm.apache.org/synergy/client/app/#/specification/351] > Test Suite: > [http://netbeans-vm.apache.org/synergy/client/app/#/suite/2034/v/1] > Test Case: > http://netbeans-vm.apache.org/synergy/client/app/#/case/5158/suite/2034/v/1 > Environment > *Product Version:* Apache NetBeans IDE Dev (Build > incubator-netbeans-linux-408-on-20180417) > *Java:* 10; Java HotSpot(TM) 64-Bit Server VM 10+46 > *Runtime:* Java(TM) SE Runtime Environment 10+46 > *System:* Mac OS X version 10.12.6 running on x86_64; UTF-8; en_IN (nb) > > > Steps to reproduce > # OPen Project Java refactoring (attached to test spec) > # Open replace_constructor.ClassB > # Place caret on constructor call on line ClassA ca2 = new Clas|sA(10, 5) > (| is caret position) > # From menu choose Refactor|Replace Constructor With Factory > # Provide name for factory > # Click Refactor > # Click undo-redo-undo > Expected results > Able to run step 7 Undo/Redo button is enabled and clickable > Actual Result > Cannot run Step 7 as Undo button is disabled. -- 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] [Assigned] (NETBEANS-813) Debugging Java web application - unable to view variable value
[ https://issues.apache.org/jira/browse/NETBEANS-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ARUNAVA SINHA reassigned NETBEANS-813: -- Assignee: ARUNAVA SINHA > Debugging Java web application - unable to view variable value > -- > > Key: NETBEANS-813 > URL: https://issues.apache.org/jira/browse/NETBEANS-813 > Project: NetBeans > Issue Type: Bug > Components: debugger - Java >Affects Versions: 9.0 > Environment: Product Version: Apache NetBeans IDE Dev (Build > incubator-netbeans-release-299-on-20180512) > Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10 > Runtime: Java(TM) SE Runtime Environment 10.0.1+10 > System: Windows 7 version 6.1 running on amd64; Cp1250; cs_CZ (nb) >Reporter: Vít Suchánek >Assignee: ARUNAVA SINHA >Priority: Major > Attachments: NB90_opening_variable_value.png > > > Could not open a value of a variable. Resulted in following error: > java.lang.AssertionError: Debugger lock taken in AWT Event Queue! > at > org.netbeans.modules.debugger.jpda.JPDADebuggerImpl$DebuggerReentrantReadWriteLock$DebuggerReadLock.lock(JPDADebuggerImpl.java:2675) > at > org.netbeans.modules.debugger.jpda.models.JPDAThreadImpl$ThreadReentrantReadWriteLock$ThreadWriteLock.lock(JPDAThreadImpl.java:2555) > at > org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.invokeMethod(JPDADebuggerImpl.java:1066) > at > org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.invokeMethod(JPDADebuggerImpl.java:1008) > at > org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:496) > at > org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:460) > at > org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:424) > at > org.netbeans.modules.debugger.jpda.ui.models.VariablesFormatterFilter.getValueAt(VariablesFormatterFilter.java:498) > at > org.netbeans.modules.debugger.jpda.ui.models.VariablesFormatterFilter.getValueAt(VariablesFormatterFilter.java:425) > at > org.netbeans.modules.debugger.jpda.ui.models.VariablesTreeModelFilter.getValueAt(VariablesTreeModelFilter.java:532) > at > org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1439) > at > org.netbeans.modules.debugger.jpda.ui.models.PendingActionsFilter.getValueAt(PendingActionsFilter.java:108) > at > org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1439) > at > org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1441) > at > org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1441) > at > org.netbeans.spi.viewmodel.Models$CompoundModel.getValueAt(Models.java:4566) > at > org.netbeans.modules.viewmodel.TreeModelNode$MyProperty.updateShortDescription(TreeModelNode.java:2102) > at > org.netbeans.modules.viewmodel.TreeModelNode$MyProperty.getShortDescription(TreeModelNode.java:2084) > at > org.openide.explorer.propertysheet.CustomEditorAction.actionPerformed(CustomEditorAction.java:287) > at > org.openide.explorer.propertysheet.PropertyPanel$CustomEditorProxyAction.actionPerformed(PropertyPanel.java:1183) > at > org.openide.explorer.view.OutlineView$OutlineViewOutline.editCellAt(OutlineView.java:2103) > at > java.desktop/javax.swing.plaf.basic.BasicTableUI$Handler.adjustSelection(BasicTableUI.java:1127) > at > java.desktop/javax.swing.plaf.basic.BasicTableUI$Handler.mousePressed(BasicTableUI.java:1057) > at > java.desktop/java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:288) > at > java.desktop/java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:287) > at > java.desktop/java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:287) > at > java.desktop/java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:287) > at java.desktop/java.awt.Component.processMouseEvent(Component.java:6586) > at > java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342) > at org.netbeans.swing.outline.Outline.processMouseEvent(Outline.java:1014) > at java.desktop/java.awt.Component.processEvent(Component.java:6354) > at java.desktop/java.awt.Container.processEvent(Container.java:2261) > at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4966) > at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2319) > at java.desktop/java.awt.Component.dispatchEvent(Component.java:4798) > at > java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4914) > at >
[jira] [Commented] (NETBEANS-971) Can't open tools/options
[ https://issues.apache.org/jira/browse/NETBEANS-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520099#comment-16520099 ] ARUNAVA SINHA commented on NETBEANS-971: It seems you are trying to run JDK-10 in NetBeans-8.2 Please try running JDK-10 in NetBeans-9 One can download it from below link . [https://netbeans.apache.org/download/nb90/nb90-beta.html] I ran NetBeans-9 with Open JDK10, tools–>options windows came up properly > Can't open tools/options > > > Key: NETBEANS-971 > URL: https://issues.apache.org/jira/browse/NETBEANS-971 > Project: NetBeans > Issue Type: Bug > Components: editor - Actions/Menu/Toolbar >Affects Versions: 8.2 > Environment: Product Version: NetBeans IDE 8.2 (Build 201609300101) > Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2 > Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10 > Runtime: Java(TM) SE Runtime Environment 10.0.1+10 > System: Windows 10 version 10.0 running on amd64; Cp1252; en_GB (nb) > User directory: C:\Users\bob\AppData\Roaming\NetBeans\8.2 > Cache directory: C:\Users\bob\AppData\Local\NetBeans\Cache\8.2 >Reporter: Bob Findlay >Priority: Blocker > Attachments: netbeans.log > > > If I select tools config I get no window appear. On another computer I've > installed the same version of netbeans and it works fine. > I didn't have an api.properties so I tried creating one in > C:\Users\bob\AppData\Roaming\NetBeans\8.2\config\Preferences\org\netbeans\modules\options > containing > > OptionsHeight = 500 > OptionsWidth = 871 > OptionsX = 100 > OptionsY = 117 > > but it didn't help > log file attached -- 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-971) Can't open tools/options
[ https://issues.apache.org/jira/browse/NETBEANS-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16520047#comment-16520047 ] Bob Findlay commented on NETBEANS-971: -- I haven't installed any plugins. The first thing I did after installation was to try to go into options. > Can't open tools/options > > > Key: NETBEANS-971 > URL: https://issues.apache.org/jira/browse/NETBEANS-971 > Project: NetBeans > Issue Type: Bug > Components: editor - Actions/Menu/Toolbar >Affects Versions: 8.2 > Environment: Product Version: NetBeans IDE 8.2 (Build 201609300101) > Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2 > Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10 > Runtime: Java(TM) SE Runtime Environment 10.0.1+10 > System: Windows 10 version 10.0 running on amd64; Cp1252; en_GB (nb) > User directory: C:\Users\bob\AppData\Roaming\NetBeans\8.2 > Cache directory: C:\Users\bob\AppData\Local\NetBeans\Cache\8.2 >Reporter: Bob Findlay >Priority: Blocker > Attachments: netbeans.log > > > If I select tools config I get no window appear. On another computer I've > installed the same version of netbeans and it works fine. > I didn't have an api.properties so I tried creating one in > C:\Users\bob\AppData\Roaming\NetBeans\8.2\config\Preferences\org\netbeans\modules\options > containing > > OptionsHeight = 500 > OptionsWidth = 871 > OptionsX = 100 > OptionsY = 117 > > but it didn't help > log file attached -- 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
