Community
Participate
Working Groups
Bug 564535 has replaced the Text control used for error / info messages in TitleAreaDialog with a Label. This has UX implications as it is now impossible to copy error messages from such dialogs. The ability to copy such messages is often crucial. I propose to revert the change and switch back to Text. The situation where a curser can be placed in the Text when no message is displayed, can be solved by disabling the control in updateMessage(String) in case the message is empty.
+1
+-0. I see both points of view. I can't remember anyone tried to copy/paste the text from a dialog - in most cases users create screenshots anyway (even from text log entries). I also haven't tried to right click the dialog title area because that is not common in any UI to provide a menu in such areas. I believe it it would be always a Label, no one would ever notice that and report a bug to convert it to a selectable Text.
Created attachment 286544 [details] example dialog where selectable message is important (In reply to Andrey Loskutov from comment #2) > I can't remember anyone tried to copy/paste the text from a dialog - in most > cases users create screenshots anyway (even from text log entries). We have many places in our IDE where users would like to copy text from such error messages (I have attached an example). The move from Text to Label made this quite painful. > I believe it it would be always a Label, no one would ever notice that and > report a bug to convert it to a selectable Text. Agreed. Such UX interaction flows as the one in the example would probably not have been built if it would have been a Label to begin with.
yes. let's revert.
@Karsten : any comments? The change was merhed in 4.18, and we had no complains till now, but probably not many users are on 4.18-4.20 anyway. So one bug per 9 months. On the other side, we had the "Text" probably since ever, and one bug report too. So ome bug per 10 years. With that, probably reverting the change would be more convenient. Note also bug 564535 comment 6 proposal: should we use read-only StyledText with setCaret(null)?
*** Bug 574260 has been marked as a duplicate of this bug. ***
(In reply to Andrey Loskutov from comment #5) > @Karsten : any comments? > > The change was merhed in 4.18, and we had no complains till now, but > probably not many users are on 4.18-4.20 anyway. So one bug per 9 months. I have raised multiple bugs about missing Copy from text areas but they are usually wontfixed. In Bug Bug 574260 I observe that surely all text areas should be copy by default.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/182170
(In reply to Andrey Loskutov from comment #5) > Note also bug 564535 comment 6 proposal: should we use read-only StyledText > with setCaret(null)? I tried that: Problem, then we lose the default context menu (with e.g. select-all + copy actions), see bug 73685. We also would have to re-implement Ctrl-A support (important if text is cut off). I think having that context menu is important for accessibility. Same goes for the Caret thing: If it is a Text, it probably should behave like a Text - including showing a caret. I prepared a change: - Revert back to old behavior - Keep using Text - Improve that if the message is completely blank, the Text control gets disabled
(In reply to Sebastian Ratz from comment #9) > I prepared a change: > - Revert back to old behavior > - Keep using Text > - Improve that if the message is completely blank, the Text control gets > disabled +1
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/182170 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a43240d58eebb2015c48a4957859bb944a432a6e
Verified in I20210704-1800.
(In reply to Andrey Loskutov from comment #2) > I can't remember anyone tried to copy/paste the text from a dialog - in most > cases users create screenshots anyway (even from text log entries). See Bug 575964 and Bug 575992
