Heiko Tietze wrote:

colomar wrote:Yes, cross-linking is important, especially since we do include the shortcut for starting the search as such in the search pattern HIG.

I just changed it to "Use Ctrl+H to show/hide the input, and F3/Shift+F3 for the next/previous item (cf. HIG about [http://techbase.kde.org/Projects/Usability/HIG/Keyboard_Shortcuts short-cuts])." but it makes no sense in case of the filter. So I added it only to the highlighter:

* Active the control and focus it on ctrl+F, and use F3/Shift+F3 to go to the next/previous item (cf. HIG about [http://techbase.kde.org/Projects/Usability/HIG/Keyboard_Shortcuts short-cuts]).

Yes, only for the highlighter.

Heiko Tietze wrote:

colomar wrote:Yes, cross-linking is important, especially since we do include the shortcut for starting the search as such in the search pattern HIG.

I just changed it to "Use Ctrl+H to show/hide the input, and F3/Shift+F3 for the next/previous item (cf. HIG about [http://techbase.kde.org/Projects/Usability/HIG/Keyboard_Shortcuts short-cuts])." but it makes no sense in case of the filter. So I added it only to the highlighter:

* Active the control and focus it on ctrl+F, and use F3/Shift+F3 to go to the next/previous item (cf. HIG about [http://techbase.kde.org/Projects/Usability/HIG/Keyboard_Shortcuts short-cuts]).

Most applications I use actually have the F3/Shift+F3 shortcuts alongside with DOWN and UP keys, but you are right, some just have the first pair of shortcuts.

In the filter method, it would be great to have something describing the navigation too. If the focus is on the search input, how do you navigate between the results? If you need to get back to the results list, how do you do that? An additional ENTER? Just press the UP key (if search field is on the bottom) or the DOWN key (if search field is on top - Krunner's behavior)?

I'd really like to Ctrl+F, start typing, see my results filtering and just navigate through the results with arrow keys. It is about not trying to guess what is the additional step to re-focus the list, where most users will just use the mouse (which is horrible).

The easier way to achieve this integrated navigation is not focusing the search field on Ctrl+F, keeping the focus on the list, and delegating some key events from the results list to the search field instead. However, these key strokes should not conflict with the highlight method described with the "search as you type". Oh, and this exact filter behavior is on the review request I submitted to KDE Telepathy, so it's possible and even easy to implement.

What Dolphin does on Ctrl+I currently is: start typing, it filter the results, typing UP and DOWN keys does nothing, typing ENTER focus the results list but there's no visual feedback that it happened.

renatoatilio wrote:In the filter method, it would be great to have something describing the navigation too. If the focus is on the search input, how do you navigate between the results? If you need to get back to the results list, how do you do that? An additional ENTER? Just press the UP key (if search field is on the bottom) or the DOWN key (if search field is on top - Krunner's behavior)?

How about both up and down arrow keys to navigate the list (down selects top, up selects bottom entry), and another Ctrl+I to focus the filter field again?

GreatEmerald wrote:How about both up and down arrow keys to navigate the list (down selects top, up selects bottom entry), and another Ctrl+I to focus the filter field again?

The problem with this approach is Dolphin again, which has horizontal navigation too (if I correctly understood what you meant).

This is the reason I proposed the focus to be on the results, so while filtering, the first occurrence is already selected and you navigate with any arrow key, press ENTER to open something you need (for instance), and any printable character typed is appended to the filter search and the results are filtered once again.

Another thing that came to my mind about highlight search is that another very common shortcut for "Next Occurrence" is just hitting ENTER (Kate, IntelliJ IDEA, Sublime Text, Chromium, Firefox, etc).

renatoatilio wrote:The problem with this approach is Dolphin again, which has horizontal navigation too (if I correctly understood what you meant).

Oh, right, I hadn't thought of that. Hmm.

renatoatilio wrote:Another thing that came to my mind about highlight search is that another very common shortcut for "Next Occurrence" is just hitting ENTER (Kate, IntelliJ IDEA, Sublime Text, Chromium, Firefox, etc).

I don't think that works with file highlighting. I'd expect Enter when a file is highlighted (no matter the circumstances) to open the file.

GreatEmerald wrote:I don't think that works with file highlighting. I'd expect Enter when a file is highlighted (no matter the circumstances) to open the file.

Okay, it seems like we'll have to clarify the HIG further: What we meant with "Highlighting" is the text highlighting within the currently opened document (like in browsers, text editors, etc.), not the highlighting of items in lists such as Dolphin. The highlighting in Dolphin is not triggered by Ctrl-F, but by simply typing a character while the file list has focus.

colomar wrote:Okay, it seems like we'll have to clarify the HIG further: What we meant with "Highlighting" is the text highlighting within the currently opened document (like in browsers, text editors, etc.), not the highlighting of items in lists such as Dolphin. The highlighting in Dolphin is not triggered by Ctrl-F, but by simply typing a character while the file list has focus.

Yes, but there's a discussion on the blog post about the possible merge of these two search methods. I personally consider the Qt keyboardSearch() (used by Dolphin OOTB) kind of broken by current standards, plus it is something that doesn't work for every Qt's QAbstractItemView subclass [1].

Anyway, what I found confusing about your last assertion is: would Dolphin have a highlighting feature in addition to the filter feature? It is really not clear on the HIG, and although it may not make sense at first glance, I think it does when we look at GTK with its default interactive search [2] on some view components that would be a natural replacement for the current Qt (4 and 5) keyboardSearch(). I don't like most things on GTK, but IMHO this is something we should seriously consider.

The other way around is not clear on the document too, but I'm assuming that "browsers, text editors, etc" like you mentioned won't have filtering, only highlighting, right?

[1] https://qt.gitorious.org/qt/qt/merge_requests/1003
[2] https://developer.gnome.org/gtk3/stable ... ble-search

colomar wrote:Okay, it seems like we'll have to clarify the HIG further: What we meant with "Highlighting" is the text highlighting within the currently opened document (like in browsers, text editors, etc.), not the highlighting of items in lists such as Dolphin. The highlighting in Dolphin is not triggered by Ctrl-F, but by simply typing a character while the file list has focus.

I understood that renatoatilio was referring to file highlighting. Which is also highlighting, and is not mentioned in the HIG (it's both similar and different from text highlighting at the same time...). Maybe we need a separate term for this as well, or something, before this gets even more confusing

GreatEmerald wrote:I understood that renatoatilio was referring to file highlighting. Which is also highlighting, and is not mentioned in the HIG (it's both similar and different from text highlighting at the same time...). Maybe we need a separate term for this as well, or something, before this gets even more confusing

In my understanding, the correct term for the item selection on an item view is... well, an item selection.

As commented on the blog post:
"The highlighting from keyboardSearch() is not the same as the “highlight method” described on this HIG.
While the first just selects the first occurrence, the latter does this in addition to highlighting every occurrence of the search pattern."

The text in bold is something I assumed considering this as solution for a quick navigation like the one in GTK, but is also not present on the HIG.

renatoatilio wrote:Anyway, what I found confusing about your last assertion is: would Dolphin have a highlighting feature in addition to the filter feature? It is really not clear on the HIG, and although it may not make sense at first glance, I think it does when we look at GTK with its default interactive search [2] on some view components that would be a natural replacement for the current Qt (4 and 5) keyboardSearch(). I don't like most things on GTK, but IMHO this is something we should seriously consider.

The other way around is not clear on the document too, but I'm assuming that "browsers, text editors, etc" like you mentioned won't have filtering, only highlighting, right?

Indeed, the idea was that the filter would be used on lists whereas the highlight would be used on documents. We're still open for ideas, though, so keep them coming!

colomar wrote:Indeed, the idea was that the filter would be used on lists whereas the highlight would be used on documents. We're still open for ideas, though, so keep them coming!

Uh, I assume by "lists" you mean file managers in general, by "highlight" you meant "text highlight" and by "documents" you meant "in text editors", right? Because as it is, your sentence could totally be interpreted the wrong way ("only the filter would be used in file managers in list view – not tree, icons or details – and except for files that are .odt or other 'document'-type files, in which case file highlight would be used instead")

GreatEmerald wrote:

colomar wrote:Indeed, the idea was that the filter would be used on lists whereas the highlight would be used on documents. We're still open for ideas, though, so keep them coming!

Uh, I assume by "lists" you mean file managers in general, by "highlight" you meant "text highlight" and by "documents" you meant "in text editors", right? Because as it is, your sentence could totally be interpreted the wrong way ("only the filter would be used in file managers in list view – not tree, icons or details – and except for files that are .odt or other 'document'-type files, in which case file highlight would be used instead")

This is all pretty difficult to communicate clearly, and we'll definitely have to iterate on the wording, but yes, your assumptions are pretty close to what I meant

Though by "lists" I don't only mean file managers, but everything which shows a set of items (that includes emails in a folder, audio files in a playlist, etc.), regardless of the way it presents them. By "document" I mean "A currently opened document". This does not necessarily have to be a text editor, but anything which displays a file that contains text (which includes browsers, PDF viewers, presentation editors, etc.). I hope this made it clear? If so, the next step would be to turn this into something we can write in the HIG

I've just added "If a Plasmoid or Plasma dialog has a filter capability, always show the filter bar since there is no menu to show or hide it." to the HIG draft.
I think this is self explanatory.