Search plugin: Extend tooltip for the Regular Expressions switch
Needs ReviewPublic

Authored by gregormi on Mon, Jan 7, 11:25 PM.

Details

Reviewers
mwolff
Group Reviewers
Kate
Summary

OLD (will be deleted):
This adds a table which explains some metacharacters.
The short description is placed In the first column, then the
metacharacter and then additional hints.
It is intended for users who know that certain things (like word
boundary or non-whitespace) exist but cannot quite remember the exact
metacharater.
See also https://en.wikipedia.org/wiki/Regular_expression

NEW:
Makes the actions to insert special characters which are currently only available via context menu to side buttons in the search and replace comboboxes. The context menu will still be available.

Screenshot with regular expressions off:

Screenshot with regular expressions on:

Test Plan

Will probably removed after feedback from reviewers:

Diff Detail

Repository
R40 Kate
Branch
arcpatch-D18083
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 7051
Build 7069: arc lint + arc unit
gregormi created this revision.Mon, Jan 7, 11:25 PM
Restricted Application added a project: Kate. · View Herald TranscriptMon, Jan 7, 11:25 PM
Restricted Application added a subscriber: kwrite-devel. · View Herald Transcript
gregormi requested review of this revision.Mon, Jan 7, 11:25 PM
gregormi edited the test plan for this revision. (Show Details)Mon, Jan 7, 11:26 PM
gregormi added a reviewer: Kate.
gregormi edited the summary of this revision. (Show Details)
sars added a subscriber: sars.Tue, Jan 8, 10:44 AM

I really like the idea! :)

Can you make the RegExp tool-tip available only when we are in RegExp mode? It means that you have to update the tool-tip whenever the mode changes.

A small comment on the text itself. I'm afraid that a beginner would not understand: "same as (^\w|\w$\W\w|\w\W)"
I think the same goes for all the ones with "same as"

IMO the help/insert list in the "Add.." sub-menu of the search-context menu is quite good. Could you maybe use (a subset of) that?

It would also be great to get this same into the builtin search combo in RegExp mode :)

Can you make the RegExp tool-tip available only when we are in RegExp mode?

Not sure if that's a so good request.

I'm afraid that a beginner would not understand: "same as...

I wouldn't care too much of quizzically beginner. However, I'm asking me if that "same as info" has some benefit. So I would it also remove. It's from that wiki and IIRC you read it "everywhere". How about a note where you can find more?

However, in generally I'm often annoyed by tooltips, and that is pretty big.

IMO the help/insert list in the "Add.." sub-menu of the search-context menu is quite good.

Indeed! Is that not the same info? How about only to add a tool tip to the input field that there is handy stuff in the context menu?
(BTW It would be more handy to have that "Add..." menu on top of that list)

I'm sorry gregormi for no positive comment, you spend for sure a couple of time in doing it :-/

Usually such detailed information is in the Kate handbook (which does / should explain all this).

What I usually try when adding tool tips is to make them short: Sometimes, the mouse randomly can stop at a location where a tooltip pops up. In that case, you then get a delayed info which in this case now will be huge, meaning you have to move the mouse again. For exactly this reason the status bar entries all have no tooltip, since you'd run into this annoyance all the time (yes, we tried it and it sucked).

If you really want this additional info, would a What's This tip help as well?

Can you make the RegExp tool-tip available only when we are in RegExp mode?

This makes sense. I also thought of that because accidentally hovering would always show such a big tooltip even when the user does not want to enable the regex option.

I think the same goes for all the ones with "same as"

Yes, I was also unsure. I'll change that.

IMO the help/insert list in the "Add.." sub-menu of the search-context menu is quite good. Could you maybe use (a subset of) that?

I didn't know this menu existed! This deserves a more accessible place which is only one (left) click away. I would say a button on the right side of the text box or so.

It would also be great to get this same into the builtin search combo in RegExp mode :)

Hmm. What exactly where?

I'm sorry gregormi for no positive comment, you spend for sure a couple of time in doing it :-/

Don't worry. I will spend some more time to make this a nice change.

Usually such detailed information is in the Kate handbook (which does / should explain all this).

This kind of information should be quick to find: "Tooltip faster than Web Search faster than Kate handbook" :-)

What I usually try when adding tool tips is to make them short: Sometimes, the mouse randomly can stop at a location where a tooltip pops up. [...]

I think with Kare's proposal to show the info only if the button is enabled (or even make the "Add..." menu better accessible) this can be resolved. Let's wait for the next iteration.

If you really want this additional info, would a What's This tip help as well?

What I miss at "What's This" is a hint (preferably directly in the tooltip) which makes clear that a additional Whats-This-entry is available. Currently, it is so tedious to move the mouse around to find hidden What-This entries.

I didn't know this menu existed!

IIRC It's new, thanks to Kåre

What I miss at "What's This" is a hint (preferably directly in the tooltip) which makes clear that a additional Whats-This-entry is available.

+1 Qt has the nice feature to show info text in a QStatusBar IIRC, unfortunately has Kate a different concept. It would be great to have such a bar in Kate/Every-KDE-Application where you can somehow redirect all tool-tips. I used this in my wpaCute to avoid tool-tips. The only drawback is that the text may not fit into the too narrow window.

It would also be great to get this same into the builtin search combo in RegExp mode :)

Hmm. What exactly where?

I would say a button on the right side of the text box or so.

Such button sounds to me not bad.
Because regex search boxes are often used may that best to have a KSearchWidget with such a button. If that's asking too much may your button at least added to KTexteditor and also used in this plugin. This button should of cause not only show the info, but a window which stays open and where you can select stuff like from the context menu.

gregormi updated this revision to Diff 49391.EditedSun, Jan 13, 3:41 PM
  • Add line edit action icons which makes the tooltip obsolete

(Screenshots in the description)

Plus: needed refactoring

Plus: From the tooltip I added

[.] - "Literal dot"

to available actions.
If there is something more we can use from the tooltip, please say so, otherwise I will remove it again.

gregormi edited the summary of this revision. (Show Details)Sun, Jan 13, 3:45 PM
gregormi edited the test plan for this revision. (Show Details)Sun, Jan 13, 3:56 PM

The shots are looking to me great! :-)
As said, that should be available at KDE scope, not only this plugin!

At the code I'm confused about the pointer instead of reference use, but that's will other known even better than me.

Off Topic: I'm always annoyed to have the "Clear-Button" inside the edit fields at the right side instead of left.

sars added a comment.Sun, Jan 13, 4:44 PM

My personal taste would be to only have a small tool-tip saying: See the "Add.." context menu entry for regular expression help.

The search plugin is already cluttered with a lot of buttons...

addons/search/plugin_search.cpp
58

I prefer static functions over unnamed namespaces as you immediately see the static declaration, while functions in a namespace can be far away from the namespace keyword.

Besides this change is unrelated to the functionality change.

461

Note that this icon is not available with gnome icon theme. you need to specify that Kate depends on Breeze icon theme and actually have it installed to get this icon...

Patch looks interesting, didn't know about http://doc.qt.io/qt-5/qlineedit.html#addAction eith TrailingPosition.

addons/search/plugin_search.cpp
97

An empty QStringLiteral should always be a simple QString().

461

A solution is to use the overload with a fallback: if the icon is not found, use a more generic one that at least exists. See:
http://doc.qt.io/qt-5/qicon.html#fromTheme-1

More so, the concept of fallback themes was introduced for 5.12 to address this as well, see: http://doc.qt.io/qt-5/qicon.html#setFallbackThemeName

Probably not applicable here, though.

In D18083#392525, @sars wrote:

My personal taste would be to only have a small tool-tip saying: See the "Add.." context menu entry for regular expression help.

The search plugin is already cluttered with a lot of buttons...

I would agree but for me the context menu way is one bit too long ("right-click, go down to Add..., click or wait to open, select item" instead of "left-click, select item"). And harder to discover.

Would it help to add an option in the context menu to hide the new line edit buttons? :-) Or to somehow remove contrast from the icons?

addons/search/plugin_search.cpp
58

I'll change that accordingly.

461

I looked at the Regex toggle button code:

QIcon useRegExpIcon = QIcon::fromTheme(QStringLiteral("code-context"), QIcon::fromTheme(QStringLiteral("edit-find-replace")));

and didn't know that the second parameter is a fallback. I'll copy that.

mwolff resigned from this revision.Tue, Jan 15, 2:05 PM

The search plugin is already cluttered with a lot of buttons...

Yes it is, that's why I like this solution

My personal taste would be to only have a small tool-tip saying: See the "Add.." context menu entry for regular expression help.

Didn't look at the code, but I guess it's not only a help page but actions which replace the original context menu way