KDevelop: word wrapping the problem text in the Problem Reporter (WIP)
AbandonedPublic

Authored by rjvbb on Jul 29 2018, 7:41 PM.

Details

Reviewers
mwolff
Group Reviewers
KDevelop
Summary

This patch aims to introduce a "clever" way to wrap the message ("error") column in the Problem Reporter toolview, something that I have often missed (e.g. because of very long file messages).

Activating text wrapping isn't very difficult, getting the rows at the appropriate height isn't because I haven't been able to get a reliable indicator that text is indeed being wrapped (= displayed on more than a single line). I'm thus guessing it by comparing the standard delegate sizeHint to the width that will actually be used; if larger wrapping will result.

Ideally that rendering width will be the width selected by the user or else 2/3 of the toolview width (which works well for me but can be another value of course).

Annoyingly I haven't been able to figure out how to detect *user* induced changes to the column width (hence the approximation of waiting for the 1st column redraw). In addition, the delegate's sizeHint() method isn't re-called when the user is or has finished resizing the column.

Finally, the calculated height for wrapped text is sometimes a bit too low (or the sizeHint is ignored?) but is usually much too high initially when starting KDevelop with the Problem view open.

This is thus very much a work in process; I'm putting it here because I think it is potentially useful and hope to get a few nudges to get the glitches out of my code.

Test Plan

Apply patch and open any document where the parser gives diagnostic output.
One can set the default width to 1/3 of the toolview to cause wrapping in almost any text.

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped
Build Status
Buildable 1341
Build 1359: arc lint + arc unit
rjvbb requested review of this revision.Jul 29 2018, 7:41 PM
rjvbb created this revision.
mwolff requested changes to this revision.Jan 15 2019, 7:49 PM
mwolff added a subscriber: mwolff.

-2, I don't want to have tables with word wrapping. Hover the entry to get a tooltip that shows the full message instead. That would be a much better feature addition btw - I just checked and we don't seem to show the same problem tooltips when hovering an entry in the problems view as we do in the editor. We totally should!

This revision now requires changes to proceed.Jan 15 2019, 7:49 PM
rjvbb added a comment.Jan 23 2019, 4:08 PM

I completely forgot about this one, for some reason the patch was moved out of my active set (possibly because of lineheight calculation issues).

Maybe this week's work on the detailed treeview file widget allows me to improve the patch (and then I'll attach screenshots so it's easier to see what we're talking about.

I have nothing against popping up the same tooltip as shown in the editor but IMHO that's not a complete solution (and I'm thus not going to spend time on it). Two reasons:

  • the tooltips already tend to get in the way in the editor (requiring an extra keystroke or mouse action before you can continue typing)
  • they're not persistent. We already get transient, in-situ reports through the in-editor tooltips; the problem reporter toolview is there for reference while you're addressing the errors. You should thus be able to see entire error messages while typing, and you ideally should be able to copy (parts of) them to the clipboard.

tooltips don't take keyboard focus, so I don't understand your first note. also the tooltip only shows up (in the editor) while you keep ALT pressed.

the data for the tooltips is persisted, or should be. you can also select stuff in them with the mouse to copy it

rjvbb added a comment.Feb 1 2019, 1:41 PM

What I meant is that tooltips in the problem reporter appear when you hover the mouse over an entry, and disappear again when you move the mouse back to the text editor (and certainly when you need to scroll the editor window because the tooltip covers the area where you need to be). But for some reason I'm not getting any tooltips in that reporter at all at the moment.

I do notice there's a "copy problem" context action, so that's something.

also the tooltip only shows up (in the editor) while you keep ALT pressed.

That's *not* my experience. Certainly not lately; very often I need to disrupt my typing flow to hit Esc or even move the mouse to get rid of a tooltip which is taking focus. I cannot at this moment affirm whether that's limited to Mac or Linux (X11).
5.3 branch, btw.

Sometimes I have to press Alt in order to get a tooltip in the editor, but most of the time it will appear by itself.

the data for the tooltips is persisted, or should be. you can also select stuff in them with the mouse to copy it

Persisting the data is one thing, persisting the tooltip another, I guess. I also guess that you're talking about the problem tooltips you can get in the editor.

How technically feasible would it be to show these as a floating window (possibly only when you hit Alt), so that you can move them and they're maybe a bit less likely to disappear when you make just the wrong move?

mwolff added a comment.Feb 1 2019, 4:49 PM

But for some reason I'm not getting any tooltips in that reporter at all at the moment.

yes this needs to be fixed

That's *not* my experience. Certainly not lately; very often I need to disrupt my typing flow to hit Esc or even move the mouse to get rid of a tooltip which is taking focus. I cannot at this moment affirm whether that's limited to Mac or Linux (X11).

never seen this, please investigate and fix it

Persisting the data is one thing, persisting the tooltip another, I guess. I also guess that you're talking about the problem tooltips you can get in the editor.

I don't understand this.

How technically feasible would it be to show these as a floating window (possibly only when you hit Alt), so that you can move them and they're maybe a bit less likely to disappear when you make just the wrong move?

No, they are tooltips - you don't move tooltips. and you shouldn't need to use the mouse for manual movement, it should be positioned properly automatically. if that doesn't happen for you, then investigate the reason for that and fix this!

Also: you aren't confusing tooltips with the code completion popup, are you?

rjvbb added a comment.Feb 1 2019, 7:54 PM
never seen this, please investigate and fix it

If it becomes enough of an annoyance I might try.

No, they are tooltips - you don't move tooltips. and you shouldn't need to use the mouse for manual movement, it should be positioned properly automatically. if that doesn't happen for you, then investigate the reason for that and fix this!

I don't know if I believe you can guarantee perfect automatic positioning in all situation, and I am not convinced these messages can only be shown contextually as tooltips. I'm pretty certain I've already seen IDEs where messages like this are pinnable, in Qt something similar to a context menu with the tear-off property enabled could work.

I'd be more tempted to disable automatic problem reporter popups in the editor because they also take precedence over the context browser popups. I can no longer count the number of times where I had to get contextual help for fixing an error on an error-free line. I'd much rather have a floating window that I can resize and move according to my needs and resources, showing just a single problem corresponding to the line that has the text or is under the mouse cursor.

Also: you aren't confusing tooltips with the code completion popup, are you?

Tooltips, popups and what have you, they all look alike and behave in similar fashion. How could a user not confuse them when not intimately familiar with the implementation?
The code completion thingies usually do popup in an appropriate position (I'm guessing it's easier to determine one) and position requirements are probably much less strict for context browser ("intellisense") widgets.

rjvbb abandoned this revision.Feb 4 2019, 9:32 AM