I would argue that most modern GUI users expect to be able to move their
cursor over a UI WIdget and pop up a menu to find options to copy, cut,
and paste the data (text) between that Widget and the system clip board.
But NetBeans provides this in only a very small subset of places where it
should. At the very least, *EVERY* Text Field, Text Area, and Label
should provide this.
When I write a Swing App, I typically use my own extension of JLabel,
for instance, that automatically provides its own Context Menu, with a
property that will turn it on or off. Ditto for JTextField, JTextArea,
etc, etc. (Of course, since JLabel is typically read-only, it allows
It's just weird to right-click on a text-entry field and get... nothing.
Reassigning to form.
You want to use cut-copy-paste actions while editing values inside Properties view. Did I understand your enhancement
No, that's not really what I'm suggesting...
I'm suggesting that *all* widgets on the *entire* UI should have at
least Copy, and any that are editable should also have Cut & Paste.
At the very least all Text Fields. But Labels, Combo Box, Tables, etc,
I am reminded of this need every time I click the "Find" key in the
text editor and then right-click on it to paste text from another
window. And another time is when I roll my cursor over a Tab in
the Text Editor and can't copy the filename into the clip board.
I have my own library of Swing UI Class extensions that pop up a
Context Menu when the user clicks the Popup Trigger. And when I
write a Swing app, I use these classes so that the user can
readily do Cut/Copy/Paste on all JTextFields, for instance,
without having to use keyboard short-cuts or items on the Edit
Menu on the Menu Bar.
I am suggesting that NB might benefit from something similar.
Why the Swing LAFs don't provide this automatically I just do
> I am reminded of this need every time I click the "Find" key in the
> text editor and then right-click on it to paste text from another
> window. And another time is when I roll my cursor over a Tab in
> the Text Editor and can't copy the filename into the clip board.
I agree with you, but this is issue report tool only for netbeans ide, not for jdk and swing.
Please report a bug to http://bugs.sun.com/ (Category: Java SE, Subcategory: classes_swing)
I found something ... http://bugs.sun.com/view_bug.do?bug_id=4634626.
Well you can vote for an existing bug or you can file new one.
Thank you for your response.
First off, I don't know why this was moved from "ide UI" to "form ui".
But Wow! Your reply is truly Amazing, regardless.
That's a very interesting response, just calling it a bug in Swing.
Does that mean that if you find some other "bug" or missing feature
in Swing, you won't bother to program around that, either?
I started writing GUIs using AWT and started programming in Swing when
it first came out, and if I hadn't programmed around the many, many,
many bugs and missing features that those early releases had, I might
as well have just quit programming in Java as well. Imagine what it
was like before Events and Event Listeners came into being!
Swing has never done any context menus of any kind by default. It
merely provides the means for the programmer to do it if they wish.
And I opened this as an enhancement request, not a bug.
It's a flat-out usability issue with any GUI. As a programmer,
I find it my job to make the software I write, at the very least,
to follow standard and/or expected behavior regardless of the
platform or infrastructure. So it means I have to do a little
more programming. I'm writing it to be useful.
Netbeans has a context menu with copy/cut/paste in some places,
and not in others. I wouldn't call that good design.
Saying that Swing doesn't do it for me by default, so it's
just too bad that my software doesn't work the way it should,
is not very responsive to the user needs, to say the least.
That would be like saying Swing isn't Thread-safe, so it's
just too bad that the UI doesn't paint or respond to any
user input while my GUI software is busy running some long-
running process. Why should I bother to create Threads and
update the UI in the Event Queue?
I will just leave my admonishments at that.
Additionally, the bug you cite is itself also an enhancement
request, and it merely asks for the ability to do context menus,
with only the mechanism that pops up the menu decided by the
plaf. Note that the issue was closed as fixed in 1.5. Do you
think perhaps that's when method isPopupTrigger() was added to
> I'm suggesting that *all* widgets on the *entire* UI should have at
> least Copy, and any that are editable should also have Cut & Paste.
> At the very least all Text Fields. But Labels, Combo Box, Tables, etc,
> as well.
I thought that you were talking about UI created using GUI Designer and standard Swing UI widgets. I'm sorry, I didn't
understand it correctly.
> First off, I don't know why this was moved from "ide UI" to "form ui".
Yes, now I see that this issue has nothing to do with GUI Builder. > Reassigning back to ide
Oh, my goodness!!! That's funny. So easy to misunderstand things out of context, no?
Yeah, it's the NetBeans UI *itself* I was asking about.... :-)
*** Issue 157016 has been marked as a duplicate of this issue. ***
No plan to do it in near future
(In reply to comment #9)
> No plan to do it in near future
Fortunately, there's a plugin that does the job: Text Popup Menu