Prevent quicksearch from searching special bookmarks
ClosedPublic

Authored by nmel on Mar 23 2018, 8:22 PM.

Details

Summary

Since this was one of the final tasks in nmels email I figured I would submit a patch. I _do not_ feel this should be merged. I have merely submitted it so that we can discuss the merits of searching or not searching the specialbookmarks.

My arguments for why they should be searched are:

  • It is useful to search them. Say I visit 'trash' often or 'local network'. There is no way for me to assign them an accelerator key so being able too type their name to quickly access them without having to take my hand off the keyboard would be nice.
  • Because they are the last items in the menu they will never be highlighted by default, so if the user has a bookmark, trik. Then he can just type 't + enter' to access it instead of the trash bookmark.
  • The rule of least surprise. There are no indications too the user that they are special and will not be searched.
Test Plan

Discuss the merits of the patch

Diff Detail

Repository
R167 Krusader
Branch
arcpatch-D11624
Lint
No Linters Available
Unit
No Unit Test Coverage
rade requested review of this revision.Mar 23 2018, 8:22 PM
rade created this revision.
rade edited the summary of this revision. (Show Details)
rade updated this revision to Diff 30355.Mar 23 2018, 9:02 PM

fixed whitespace

nmel added a comment.Mar 24 2018, 5:43 AM

This should be applied on top of D11623

I added this issue in the email as I collected feedback from different reviews. The discussion of this one started around here:

In D10954#217886, @nmel wrote:
  1. I haven't set my mind regarding special bookmarks (Trash, Lan, Popular, etc). On one hand, they are in the menu and users might want to include them into search results. On the other hand, it may interfere with user desires to fully control search-as-you-type (he/she may setup names so that they quickly searched by one or two letters, however built-in bookmarks will spoil this setup). I'll think more about it and want to hear Martin's opinion. FYI, "Manage bookmarks" also participate in the search, it's not really nice. Grey area, kind of bug-or-feature.

ad 3) and 6) My opinion is we don't search in special bookmarks. They have dedicated shortcuts so that is at least one reason for that.

So these are arguments for this patch.

Given Rade's points, I see that it may be useful for some people, so I suggest we add another config option "Search in special items" for this feature and stop arguing. My only ask is to leave it off by default.

rade added a comment.Mar 24 2018, 7:21 PM

Given Rade's points, I see that it may be useful for some people, so I suggest we add another config option "Search in special items" for this feature and stop arguing. My only ask is to leave it off by default.

Sounds good to me. Would you mind doing the patch for it though? I'm not really sure how the config code works, and you seem to have a good grasp of it.

nmel added a comment.Mar 24 2018, 8:29 PM
In D11624#233131, @rade wrote:

Given Rade's points, I see that it may be useful for some people, so I suggest we add another config option "Search in special items" for this feature and stop arguing. My only ask is to leave it off by default.

Sounds good to me. Would you mind doing the patch for it though? I'm not really sure how the config code works, and you seem to have a good grasp of it.

Yep, no problem.

rade added a comment.Mar 24 2018, 8:37 PM
In D11624#233198, @nmel wrote:
In D11624#233131, @rade wrote:

Given Rade's points, I see that it may be useful for some people, so I suggest we add another config option "Search in special items" for this feature and stop arguing. My only ask is to leave it off by default.

Sounds good to me. Would you mind doing the patch for it though? I'm not really sure how the config code works, and you seem to have a good grasp of it.

Yep, no problem.

Thanks! Should I abandon this revision then and you'll submit a new one?

In D11624#233131, @rade wrote:

Given Rade's points, I see that it may be useful for some people, so I suggest we add another config option "Search in special items" for this feature and stop arguing. My only ask is to leave it off by default.

Sounds good to me. Would you mind doing the patch for it though? I'm not really sure how the config code works, and you seem to have a good grasp of it.

I agree with this approach - config option "Search in special items", off by default. Thanks!

nmel commandeered this revision.Mar 25 2018, 4:02 AM
nmel edited reviewers, added: rade; removed: nmel.

I'm taking over to improve the change as we discussed.

nmel updated this revision to Diff 30463.Mar 25 2018, 4:15 AM
  • Added Konfigurator option for bookmark search: Search in special items
Restricted Application added a subscriber: kde-doc-english. · View Herald TranscriptMar 25 2018, 4:15 AM
nmel updated this revision to Diff 30465.Mar 25 2018, 4:16 AM

Fixed diff.

Sorry, I first pushed diff for the whole branch as I forgot to specify the base.

I found that with the option turned on jump back actions could be searched but don't close the menu when triggered. It's unrelated to this patch, however we need to look into this. For now, it's unclear to me why it's happening — ideas are appreciated.

martinkostolny accepted this revision.Mar 25 2018, 7:32 PM

ideas are appreciated

I think there has to be an explicit menu-close call like in the rest of the actions to close the menu. All the other actions call KrBookmarkHandler::slotActivated which in turn calls _mainBookmarkPopup->close(). There are only 4 actions without this call (please correct me if I'm wrong): set jump back, jump back, add bookmark, manage bookmarks. The last two open new dialog which probably in turn closes popup menu.

Therefore we should handle differently activation of the 2 jump-back actions so that after their work is done, popup is requested to close. Please see my code suggestions.

krusader/BookMan/krbookmarkhandler.cpp
469–470

inside the if:

connect(action, &QAction::triggered, this, [=] {
    if (_mainBookmarkPopup && !_mainBookmarkPopup->isHidden()) {
        _mainBookmarkPopup->close();
    }
});
469–470

same here:

connect(action, &QAction::triggered, this, [=] {
    if (_mainBookmarkPopup && !_mainBookmarkPopup->isHidden()) {
        _mainBookmarkPopup->close();
    }
});
This revision is now accepted and ready to land.Mar 25 2018, 7:32 PM
rade accepted this revision.Mar 25 2018, 8:51 PM

Other then the issue martin pointed out it looks good!

This revision was automatically updated to reflect the committed changes.
nmel marked 2 inline comments as done.Mar 26 2018, 7:07 AM

Thanks Martin and Rade for the review!

Thanks Martin for finding the root cause and for code suggestions. I've seen CONNECT_BM before and completely forgot about it thinking of a closing menu as a standard behavior. I created D11706 separately as I decided to go a little further and remove code dup. Please check it out. If you like it, I can refactor CONNECT_BM the same way some time later.

nmel added a subscriber: yurchor.Mar 29 2018, 6:12 AM

FYI, this change needs a docbook update. Thanks.