I can reproduce the problem : items cannot be selected with mouse, however it works if you select them with keybord arrow-up/down + enter. I am more of a keyboard user than a mouse user, so I had never noticed that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The bug does not show when I hack jPicEdt so that the Preferences pannel is no longer modal. This is a problem connected with modality implementation in jPicEdt.
Well, the preferences dialog is implemented with javax.swing.JInternalFrame, not javax.swing.JDialog. JDialog implements modality right off the box. JInternalFrame does not, so modality is “home-made” implemented in jpicedt.widgets.PEInternalDialog class.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
Just for your information, if you configure jPicEdt to use Gimp-like windowing, then you won't have the problem because the dialogs will use PEDiagog class instead of PEInternalDiagog.
To do that, open the preferences pannel, General Tab, and select Gimp-like for the 1st item (Multiple Document Interface). Do the selection with the keyboard, as the mouse is not working. Then exit jPicEdt for the configuration to take effect.
You can also edit the preference file ~/.jpicedt/preferences and replace in it line ui.mdimgr=child-frames by ui.mdimgr=child-frames by ui.mdimgr=Gimp-like.
OK, this does not solve the problem, but at least, hopefully, this can make it less annoying.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I have made some progress, and I think that I have found some possible work-around to make a javax.swing.JInternalFrame modal.
One way is described in this article. It consists in emulating modality by placing the content pane of the JInternalFrame on a glass pane when the JInternalFrame is constructed. This way seems futureproof because we use only the public methods documented in the Java API, however I need to think it over again, to understand whether it suits our case.
The second way it that java.awt.Container has private methods called startLWModal and stopLWModal. These methods are called using reflexivity by javax.swing.JOptionPane.showInternalOptionDialog method in order to make a modal javax.swing.JInternalFrame. This way is certainly more robust to corner cases, because it would do the same thing as java source code does. However, it is probably also less futureproof because we do some tirck in order to get access to private undocumented methods.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can reproduce the problem : items cannot be selected with mouse, however it works if you select them with keybord arrow-up/down + enter. I am more of a keyboard user than a mouse user, so I had never noticed that.
The bug does not show when I hack jPicEdt so that the Preferences pannel is no longer modal. This is a problem connected with modality implementation in jPicEdt.
Well, the preferences dialog is implemented with
javax.swing.JInternalFrame, notjavax.swing.JDialog. JDialog implements modality right off the box. JInternalFrame does not, so modality is “home-made” implemented injpicedt.widgets.PEInternalDialogclass.To be checked : feature req 22 seems to have the same root cause.
Hello,
Just for your information, if you configure jPicEdt to use Gimp-like windowing, then you won't have the problem because the dialogs will use
PEDiagogclass instead ofPEInternalDiagog.To do that, open the preferences pannel, General Tab, and select Gimp-like for the 1st item (Multiple Document Interface). Do the selection with the keyboard, as the mouse is not working. Then exit jPicEdt for the configuration to take effect.
You can also edit the preference file
~/.jpicedt/preferencesand replace in it lineui.mdimgr=child-framesbyui.mdimgr=child-framesbyui.mdimgr=Gimp-like.OK, this does not solve the problem, but at least, hopefully, this can make it less annoying.
OK, I have made some progress, and I think that I have found some possible work-around to make a
javax.swing.JInternalFramemodal.java.awt.Containerhas private methods calledstartLWModalandstopLWModal. These methods are called using reflexivity byjavax.swing.JOptionPane.showInternalOptionDialogmethod in order to make a modaljavax.swing.JInternalFrame. This way is certainly more robust to corner cases, because it would do the same thing as java source code does. However, it is probably also less futureproof because we do some tirck in order to get access to private undocumented methods.