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.
The terminal window could be treated as an editor window. By that I mean, it would not be a "side window", but the 1st-class window, which listens to shortcuts like "next tab", "maximize window" etc. (For example, "Help > Report Issue..." opens such 1st-class window.) That way would make much better user experience than having an extra side window type for it where these shortcuts don't work. Not sure about the shortcut collisions though. Perhaps there could be some "escape" sequence to allow sending the shortcut to the terminal instead of IDE UI. Product Version = NetBeans IDE Dev (Build 201112150600) Operating System = Linux version 2.6.24-30-server running on i386 Java; VM; Vendor = 1.6.0_24 Runtime = Java HotSpot(TM) Client VM 19.1-b02
patch is welcome...
As I understand it you want the Terminal window to honor global NB keyboard accelerators. This is fundamentally not doable. The reason is that the terminal window is used to run applications like, say bash, vi or emacs, where all kinds of keyboard sequences mean something specific to the application being run in the terminal. This is already a problem with common accelerators. Take the Copy action for example. The accelerator for it is Ctrl-C. But in unix shells Ctrl-C usually means "interrupt". This why why the terminal uses, yes the awkward, Shift-Ctrl-C. Which is what the gnome terminal uses. As another example consider MaximizeWindow which is is Shift-ESC under NB. This is an interesting example. vi users use ESC _all the time_. Often, because of hasty typing they end up typing Shift-ESC instead of ESC, so overloading Shift-ESC is not a good idea. Under Gnome maximizing a window is Alt-F10 which doesn't conflict with the usual crop of applications running in a terminal. In short, the Terminal window is an escape out of netbeans and now you want to escape from that escape. However, one _can_ come up with an escape sequence that the terminal would honor and interpret them according to the global keymap. The $100,000,000 question is, what should that escape be such that it doesn't conflict with vi, emacs, bash etc ...