Community
Participate
Working Groups
Many useful areas of Eclipse do not support text copy: For instance. a1) The Path: value on a Properties.Resource page a2) The "Path:" text on a Properties.Resource page b) The "lists the libraries that make up this plugin's runtime" text on the PDE.Overview page c) A single line from the JUnit test results d) A single line from the Debugger task/stack view
(In reply to comment #0) > Many useful areas of Eclipse do not support text copy: > > For instance. > > a1) The Path: value on a Properties.Resource page This one actually does work for me ... select the text and right-click. > a2) The "Path:" text on a Properties.Resource page You are correct, this one doesn't ... but it's a label, not normally copied out (it doesn't change and doesn't have diagnostic information in it). AFAIK Label's don't support any kind of copy. The fields that do (like the Path value) are read-only Text fields, I think. > b) The "lists the libraries that make up this plugin's runtime" text on the > PDE.Overview page Similar to a2. If there is information that would be useful to copy out, you'll have to open bugs against each component (Platform UI doesn't do JUnit or Debug views). PW
a1) Yes. Right menu works. Ctrl-C doesn't. a2) But sometimes labels are used to display computed context that is never to be changed. This doesn't mean that the user may not want to copy the computed value to some other context. c), d) These are examples of widgets where SWT provides an inadequate default behaviour so that the subsequent consumers provide inadequate behaviour. SWT should support the copy without PDE or JUnit having to add special code.
(In reply to comment #2) > a1) Yes. Right menu works. Ctrl-C doesn't. This works for me ... read-only text widgets will take focus (I tabbed to it) and then SHIFT+ARROW selects (or CTRL+A for Select All) and CTRL+C copies. > a2) But sometimes labels are used to display computed context that is never to > be changed. This doesn't mean that the user may not want to copy the computed > value to some other context. Labels don't take focus (and so can't be copied). This is not likely to change. > > c), d) These are examples of widgets where SWT provides an inadequate default > behaviour so that the subsequent consumers provide inadequate behaviour. SWT > should support the copy without PDE or JUnit having to add special code. > I selected a test in the JUnit view and did CTRL+C ... it copied a line for me. Same with the debugger stack, it copied out a line: testAggregateValidationStatusValueType(org.eclipse.core.tests.databinding.AggregateValidationStatusTest) Method.invoke(Object, Object...) line: 618 Copy in most cases is semantic behaviour that depends on the application. SWT does not interfere with the default menu for most controls (that include copy/cut/paste) unless the application overrides it (which most eclipse views do). b) appears to be a native widget that won't enable copying even though it enables selection (and shows the native widget menu). Something like this can be investigated/fixed by opening a bug against Platform/UA PW
I think Paul's covered this fairly well, I don't think there's much that we as the Platform UI team can do with this, sorry.
Yes. It's wierd the basic copy works for me now. I'll look for a solider repro.
