I'm wrong about library jars being included in jvi.jar. Everything in is the jvi-code/dist directory, the libraries are in jvi-code/dist/lib
ran the build again today, it just worked Cool. Note that the jvi build produces jar files that run under jdk-11, but language constructs from jdk-19 can be used (frgaal magic). Note that you can do java -jar dist/jvi.jar to bring up the test window. jvi.jar should have everything needed to link/build against. It contains the jvi-core and jvi-swing jars along with various jars. Depending on your needs you might want to use individual jars, rather than the bundle. To get started, depending on your...
O-kay, so when I ran the build again today, it just worked. I didn't make any changes. It displayed the test window and everything. Thanks for your help.
There's https://sourceforge.net/p/jvi/raelity-gradle/ which is the source I used to build the plugin. But the following would indicate that you can ignore that. I just tried moving aside 1. ~/.gradle 2. <mvn-repo>/com/raelity/namedservices-merge 3, <mvn-repo>/com/raelity/gradle 4. <mvn-repo>/org/frgaal Downloaded fresh source from http://hg.code.sf.net/p/jvi/code into jvi-code did JAVA_HOME=/ref/openjdk/jdk-11 ./gradlew run The first time I tried, I didn't set JAVA_HOME and ran into trouble (but...
That's weird. The plugin, and instructions on how to use it are at https://plugins.gradle.org/plugin/com.raelity.namedservices-merge I'll take a look.
I can't get it to build with openjdk 8, 11, 17, or 21. The README mentions 11 - 15 & 19. The build output mentions 8 & 11. It's not clear what is required to build it. This is the output of the build with 21: [bill@smilodon-gracilis jvi-code]$ ./gradlew run FAILURE: Build failed with an exception. * What went wrong: A problem occurred configuring root project 'jvi'. > Could not resolve all artifacts for configuration ':classpath'. > Could not resolve com.raelity.gradle.namedservicesmerge:namedservices-merge:0.5.0....
Check out the jVi source, see https://sourceforge.net/p/jvi/code/, and in the top level directory do ./gradlew run This brings up a JEditorPane (JTextArea isn't enough) with jVi installed. This is built from the jvi-cmd directory, using the jars from jvi-core and jvi-swing. This is minimal. Also see README.
Convert into simple Swing component
So, a fast update: The setups that exhibit the problems had a custom DPI setting of 160, roughly ~1.7 of the original value which was 96. Dropping this value down to something more reasonable like 118 resolves the problem. However, this made me increase the font size (from the XFCE appearence panel, not inside netbeans), from 10 to 16, at which point, the problem reappears. To me this is conclusive evidence that as soon as the font size increases above a certain level, the bug appears. Can you reproduce...
Thank you for the quick reply! I'm sorry, I meant Normal mode facepalm Activate jVi, exit Insert mode if necessary Tools -> Options Keymap Modify a Shortcut. E.g., Find Tasks..., Ctrl + Shift + A Apply and Ok (The xml file gets created) Deactivate jVi Arrow keys move the editor screen, backspace and Ctrl + V (which I set in jVi's options) don't work. Changing to another Profile in Options solves the issue but going back to the previous one makes it reappear. Delete the xml file Deactivate jVi (activate...
Thank you for the quick reply! I'm sorry, I meant Normal mode facepalm Activate jVi, exit Insert mode if necessary Tools -> Options Keymap Modify a Shortcut. E.g., Find Tasks..., Ctrl + Shift + A Apply and Ok (The xml file gets created) Deactivate jVi Arrow keys move the editor screen, backspace and Ctrl + V (which I set in jVi's options) don't work. Changing to another Profile in Options solves the issue but going back to the previous one makes it reappear. Delete the xml file Deactivate jVi Arrow...
I have encountered this issue as well using Netbeans 16 with jVi 2.0.13 on Windows 10. It happens when you save a new keybinding while in Normal (edited: not Command) mode. Saving in Insert mode does it normally. It seems some keybindings get saved in a xml file in: %appdata%\NetBeans\16\config\Editors\Keybindings\NetBeans\ org-netbeans-modules-editor-settings-CustomKeybindings.xml Renaming (deleting) it seems to solve the issue. I don't know if it's related but the effect is similar to what's described...
Thank you for the quick reply! I'm sorry, I meant Normal mode facepalm Activate jVi, exit Insert mode if necessary Tools -> Options Keymap Modify a Shortcut. E.g., Find Tasks..., Ctrl + Shift + A Apply and Ok (The xml file gets created) Deactivate jVi Arrow keys move the editor screen, backspace and Ctrl + V (which I set in jVi's options) don't work. Changing to another Profile in Options solves the issue but going back to the previous one makes it reappear. Delete the xml file Restart Netbeans (sometimes...
Thank you for the quick reply! I'm sorry, I meant Normal mode facepalm Activate jVi, exit Insert mode if necessary Tools -> Options Keymap Modify a Shortcut. E.g., Find Tasks..., Ctrl + Shift + A Apply and Ok (The xml file gets created) Deactivate jVi Arrow keys move the editor screen, backspace doesn't work. Changing to another Profile in Options solves the issue but going back to the previous one makes it reappear. Delete the xml file Restart Netbeans (sometimes it isn't necessary, reopening a...
If you provide steps to recreate, I'll give it a try. (I don't understand how it happened). Command mode is after ":".
I guess jstack is recommend (there are several ways). See https://www.baeldung.com/java-thread-dump for a pretty good description. similar with the others, except this time it worked Wow, that is intriguing.
I have encountered this issue as well using Netbeans 16 with jVi 2.0.13 on Windows 10. It happens when you save a new keybinding while in Command mode. Saving in Insert mode does it normally. It seems some keybindings get saved in a xml file in: %appdata%\NetBeans\16\config\Editors\Keybindings\NetBeans\ org-netbeans-modules-editor-settings-CustomKeybindings.xml Renaming (deleting) it seems to solve the issue. I don't know if it's related but the effect is similar to what's described here (which is...
I'd be glad to cooperate. Can you give me instructions on how to take the stack trace, set any debug options and all that? One more update: I tested on a third machine, very similar with the others, except this time it worked. The only difference (as far as I can tell right now) with the other machines was the Custom HiDPI scaling provided by xfce; the third machine was set at its default (96), whereas the other ones had a higher scale value (up to 150). I'll try different settings and see if I can...
Thanks for isolating the issue. I'm on gtk, I've tested with those LAFs, 1920x1080. Seems it must be HiDPI I won't have much time for a few days. I'd like to file a NB issue. Would you get get a stack trace while it's going crazy, so I can include it? Might help narrow it down. Hopefully one of the LAF maintainers will be interested, the FlatLaf get a lot of attention right now.
If you do that, let me know so I can subscribe to it.
Oh, I was looking for exactly the same thing, only ten years later.. Time to open a ticket over at NetBeans, and hope that something comes out of it.
messages.log Nothing egregious there. --usedir/--cachedir Used that, did not change anything. However, I found the culprit: Look and Feel. FlatLaf Light, FlatLaf Dark and GTK+ all exhibit the same problem. In contrast, Metal Nimbus, CDE/Motif and their dark variations are ok. So, temporarily switching Look and Feel to one of them in order to make changes is a workaround, at least. I do not know what gtk and flatlaf are doing differently, but you might want to take a closer look at them. I am using...
I'm on recent linux release (popOS). I download the zip; don't use an installer. I'm running 16; I've run all versions, plus build my own on occation. During testing, I install jVi in a variety of ways. Starting up NetBeans with a clean userdir/cachedir using the --userdir/--cachedir options, install the update center, then install jVi is one of the things I do. Did you look into the NetBeans messages.log, maybe there's some exception. $ env|grep -i xdg XDG_CONFIG_DIRS=/etc/xdg/xdg-pop:/etc/xdg XDG_MENU_PREFIX=gnome-...
First machine is a battered development machine, with various netbeans installs (and configs) over the years. The second one though was a brand new installation, just to test it out. I did try resizing the window (also in the attached movie above) and it has no effect. Did it ever work? It did work on another machine, which is probably running an older version of netbeans. I had no time to check that out. Did you import settings? No (not consciously at least). One is a fresh install. What is your...
Did you try resizing the window? 2 machines, that's weird. I can't reproduce it. Did it ever work? Did you import settings? A clean install of both NetBeans and jVi , without importing settings, is something to try.
Thanks for looking into this! I'm attaching a small capture of the desktop demonstrating the problem (attachment desktop.mp4), taken using VLC at 5 fps. A few more details: Tested on two machines, both running debian testing. first machine: java -version openjdk version "11.0.18" 2023-01-17 OpenJDK Runtime Environment (build 11.0.18+10-post-Debian-1) OpenJDK 64-Bit Server VM (build 11.0.18+10-post-Debian-1, mixed mode, sharing) second machine: java -version openjdk version "17.0.6" 2023-01-17 OpenJDK...
This sounds vaguely familiar. Don't remember what the issue is, JDK, MAC, or what. Could you try resizing the options window, for example make it very big? I can't reproduce it. I don't see another bug report about it.
jvi suddenly quit working in Netbeans 12.0
Options window is broken
nb-uc points to NetBeans-11-and-later
specify jdk1.8.
Added tag HAS_ANCIENTS for changeset 78f337c53d56
include config for jar signing, commented out
use jdk1.8, HAS_ANCIENT_NB_HACKS 78f337c53d56, Build nb-uc for 11.0 (not .2).
remove ancient nbm used to hack NB internals.
2.0, jdk11
remove nb-uc from this repository, moved to nbvi
Standalone WindowsProvider for a NB that has proposed changes incorporated.
Fix issue lookup's resultChanged might be called NOT in EDT.
Package patch as modules.
Change to NB license
changes made by IDE
Add <extra-compilation-unit>... so don't see errors on source in editor.
Maven update center. Basically all defaults. Add to pom for maven central.
Clean up structure for windows patch
move stuff to patchsrc directory.
UC post install project
checkpoint the friend hack code
get rid of dummy-suite, use makeupdatedesc directly for single modules.
Update the nbm with "main" from build.xml.
NBMs with windows patch
Get update center module to hack/clear _removed after install.
baby steps to get an NBM to work.
Use default platform.
Build jvi support nbm under a module suite
Add nb70 update center for jVi.
New pin.
jvi global action prototype
move tar file into checkpoint directory
take out useless log statement
Fix bug in weak listener setup
Pin fire an event when clear() for all the Pin to sync their enable.
Added tag WorksShadowOrig for changeset 126f339b5121
Add popup separator, remove unused files
stash tar file of editor.pin experiment
Identified/filed the various NB bugs. Implement simple workarounds
Get rid of PinFactory, general cleanup
Added tag WorksInstanceCreate for changeset cebcb67d792a
Always create an Object if fixupShadow called.
Works. Big bug was filesystem didn't behave as advertised.
Rework to use instanceCreate instead of shadow.
Start the instance file approach
cleanup/refactor file names
fix bug in .hgignore
Provide description and nbm signing.
Make it a red icon.
getting ready to introduce MultiFileSystem
add action to all editor popups.
Removed experimetal action api depend, bump spec ver
add a 24x24 icon
Change package hierarchy
After create project, add action wizard
Clean up, hook up "pin" icon.
works, lots of history/check commented out. Needs icon work.
PublishPlugins namedservices-merge 0.5.0
jvi no cursor on jdk8
Changed the default for the option, so it works out of the box for most people. Also changed the name so doesn't mention MAC.
":w" broken