This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[dev nov 12] According to the L&F keybinding docs shipped in JDK 1.3 documentation, under Metal L&F Alt-Spacebar is supposed to active an internal frame's window menu. This does not appear to work in NB, at least not in the Editor window. There is no apparent way using the KB to maximize the Editor frame, e.g.
Assigning it to jmzourek. UI/HIE must look at this issue. This is a hard problem. First off I don't know we disallow this action. However on Windows Alt+<spacebar> is a system shortcut which apps cannot steal. I remember the Windows Emacs porters had a long discussion on this issue on their mailing list some years ago.
Agreed that actually using Alt-Space may not be easy. It does seem there ought to be *some* way to manipulate these frames, though. Does it work in Swing demo apps?
I've tried it. Alt-Space works on Solaris, but doesn't work neither on Linux nor on Win2k. JLF says Ctrl-Space should work, see: http://java.sun.com/products/jlf/ed2/book/Appendix.A3.html#48630 But it doesn't work anywhere (SwingSet too).
Hmm, if it doesn't work in SwingSet then we are surely out of luck; mark WONTFIX if you think that's right. Hopefully there is a JDK bug filed (for Ctrl-Space that is).
> Ctrl-Space this is used to invoke code completion. You want to start a new thread about shortcut on nbui? :-) However I think that the inability to manipulate internal frames using kbd only is a significant A11Y problem. We have to do something.
Ack, no, conflicting with code completion would not be good... I have no useful suggestions here, just noting that it may be a problem.
Dusan, do you have some comments?
I find Alt+Spacebar like shortcut for display window menu on this link: http://java.sun.com/j2se/1.4/docs/api/javax/swing/doc-files/Key- Metal.html#JInternalFrame so in JLF on this link: http://java.sun.com/products/jlf/ed2/book/Appendix.A3.html#48630 is probably mistake Theese shortcuts should wotk: JInternalFrame (Java L&F) Open (Restore)...Ctrl+F5 or Alt+F5 or Enter Close...Ctrl+F4 or Alt+F5 Move...Ctrl+F7 or Alt+F7 Resize...Ctrl+F8 or Alt+F8 Minimize...Ctrl+F9 or Alt+F9 Display window menu...Alt+Spacebar Activate the default button (if defined)...Enter Let's look that really important shortcut for maximize isn't included and could be invoked from window menu only... In Swing theese shorcuts works except Alt+SpaceBar (Win OS) In NB doesn't works from upper shorcuts CTRL+F5(Alt+F5),CTRL+F7 (Alt+F7),CTRL+F8(Alt+F8),Alt+SpaceBar Works in NB: CTRL+F4(Alt+F4),CTRL+F9(only MDI) and CTRL+F5 could be substituted CTRL+number for each view(Not for cloned window) So if Alt+spacebar is free for use, I vote for use this shortcut for invoke window menu of actual view.
> So if Alt+spacebar is free for use, I vote for use this shortcut for > invoke window menu of actual view. it seems you contradict yourself. Alt+spacebar does not work on Windows. So there is no "if" here I am afraid
This problem is OS specific. SDI mode, Solaris 8 (CDE): I'm able to: - Move (Alt-F7) - Size (Alt-F8) - Minimize (Alt-F9) - Maximize (Alt-F10) - Close (Alt-F4) - Alt-Space works too etc. Problem: these shortcuts are "stronger" than the same NB shortcuts. Seems to me that this part (SDI) of issue depends on window system of each OS. MDI mode should works in general on all OS, but there is another problem, shortcuts Ctrl-F5, Ctrl-F7 and Ctrl-F8 are unregistered from Swing in class org.netbeans.core.Main because of conflict with NetBeans "standard" shortcuts that exists before MDI mode. So, are there any ideas what we will do with that?
We need not worry about SDI. Any decent window manager has KB shortcuts for basic operations. But having debugger shortcuts directly conflict with standard Swing MDI shortcuts sounds like a problem.
So, one solution could be to replace standard Swing shortcuts (that are now removed) by some substitution. But in this case we will have different behavior than other Java application. But still better than nothing.
CCing HIE -- we need your feedback. Seems to me that Ctrl-F7 and Ctrl-F8 are not used by debugger anymore so we can enable it for Swing again. But, here is still problem with Ctrl-F5 (open minimized internal window). Any proposal how to solve this problem? Change debugger shortcut or "Swing" shortcut? What will be less paintfull for users?
Target milestone -> 3.3.1.
I retained Ctrl F5 for debuging while designing the shortcuts under the assumption that alt + space would work. Now given that this does not work and there is no way for users to access "Open Window" via keyboard, I would suggest that we should use a non-JLF short cut for this. Dusan mentions that there is no JLF shortcut for maximize. Are these (open and maximize) the only windowing functions that are not accessible by keyboard now? (even if menu does not post others have KB shortcuts ?)
Both Ctrl-F7 and Ctrl-F8 don't work too now, beacuse they are still disabled in the NetBeans code. Gabo, could you fix it? Maya, what substitution for Ctrl-F5 do you propose? Thanks, Jirka
Small note: I found subsequently keyboard combination for invoke internal frame's window menu (in SDI on Window platform only)>> pres ALT and then UP or DOWN On Solaris has the same function key-combination ALT+SPACE
If we can get KB focus on the minimized-window in the IDE(MDI) and click enter - it will open. Enter is one of the shortcuts recommended for this should be enough of a substitute for Ctrl + F5. However, it seems that we cannot actually get the focus on to the minimized window icon. If we have two editor windows open - and window A is fronted while window B is not - going to Windows > Editor > B will front B - but if both A and B are minimized this does not work (focus does not move to the mininized B). I will file a bug for this - but if this bug is fixed and Enter works to open the minimized window that has focus - we do not need another short cut for that.
Ctrl-F7 and Ctrl-F8 shortcuts are enabled for Swing again. Fixed in [release33].
Target milestone -> 3.4
The same problem is in SwingSet. So, changing the status. We should count on this problem.
if this problem is in swing set then it's a jdk problem... has it been filed against the jdk team and do they know about it for 1.4.1 and 1.4.2?
x
Changed because of QA rules.
*** Issue 22341 has been marked as a duplicate of this issue. ***
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.