14

Hi,

there is one thing I really like about the GNOME desktop and that is when I type anywhere and I am not in an active input field an "input field" pops up and shows what I have typed.

This is especially useful in e.g. the file browser (Nautilus) as it can be used to find folders by name. I know this is also possible in Dolphin, however, in Nautilus I can then "remove" characters (and also use it kinda like a "filter") or add something at the beginning to find what I was looking for.

The same is possible for contacts in Pidgin etc.

I really would like to see something like this in KDE.

Btw. if I want to propose this as enhancement do I also have to create a bug report or something like this or is it enough to be placed here?

I have never liked that GTK+ feature at all. Especially in the dialogs where by default the typing is focused to that "input field" and not to the file name/location itself. It always forces me to use mouse to get it away and disturbs to get "name:" part with Ctrl+N shortcut if first mistakenly typed the name, believing the focus is on the name input.

Fri13 wrote:I have never liked that GTK+ feature at all. Especially in the dialogs where by default the typing is focused to that "input field" and not to the file name/location itself. It always forces me to use mouse to get it away and disturbs to get "name:" part with Ctrl+N shortcut if first mistakenly typed the name, believing the focus is on the name input.

The GTK+ file dialog always drives me crazy as well...

It visually looks like the file name input field has the focus initially (the text in it is highlighted), so I always start typing the desired file name, only to realise I've actually typed in that "stupid" hovering list view "input field".

So for me, too, the first impulse when reading this idea was to strongly oppose having such a hovering "input field" for list/tree views in KDE, most likely due to this very negative impact its use in the GTK+ file dialog has made on my subconscious.

However, thinking about it consciously, its not the existence of the hovering "input field" that's at fault in the GTK+ file dialog - it's rather the (imo) bad initial focus choice and the even worse visual indication of this focus choice.

KDE shouldn't change regarding in which situations key press events get delegated to a list/tree view, but when they do, showing a visible hovering "input field" might actually not be such a bad idea, compared to the current situation of having to type "in the dark".

Btw. if I want to propose this as enhancement do I also have to create a bug report or something like this or is it enough to be placed here?

Putting it here is enough. If it receives enough attention we will submit it to bugs.kde.org and mention that it's a popular idea among Brainstorm users.

If you submit it to bugs.kde.org yourself, please post the link here and this idea will be marked as "Submitted". This is to avoid having the same discussion in two places.

Regarding the idea itself I prefer the KDE way, i.e. select the matched item. If I want to filter I want to tell it explicitly so, e.g. by using Ctrl-i in Dolphin.

Hans wrote:Regarding the idea itself I prefer the KDE way, i.e. select the matched item.

This is also what GTK+ does... If you type in a list view, the first item that matches what you've typed gets selected.

The difference is that in KDE, you don't get to see what you've typed so far, whereas in Gnome, a hovering input field pops up to show you exactly that (and also lets you modify the text easily).

Hans wrote:If I want to filter I want to tell it explicitly so, e.g. by using Ctrl-i in Dolphin.

True, there is some overlap in functionality between this idea and the existing filter functionality in Dolphin, especially since in GTK+ typing in a list (and hence in the hovering input field) restricts arrow key selection of list items to items that match the currently entered text.

But well, KDE wouldn't have to copy this functionality, just the part that shows you what you've typed so far and lets you modify it with ESCAPE and so on...

EDIT: to "interface" the two features, pressing CTRL+i when something is already written in the list view (and hence shown in the hovering input field) could open up the "filter" bar with that text already pre-entered...

Ok, I thought the GTK+ way also hid items that didn't match, i.e. filter the results. (Fortunately I haven't used a GTK+ dialog in a long time...)

I still stand by what I said, however. I like to type something, realize that's not what I want and just start typing something else, without the need to press Escape. This is generally so fast that an "input field" wouldn't help me. I can see how it could be useful for other persons, but as said, I personally prefer the KDE way.

But well, KDE wouldn't have to copy this functionality, just the part that shows you what you've typed so far and lets you modify it with ESCAPE and so on...

The desktop effect Present Windows actually works like this (except that it also hides mismatches). Just as an example if anyone is interested.

Generally I think that
* If typing affects the results (e.g. Present Windows, Kickoff, KRunner) -> show the inputted text
* If typing only changes the selection -> don't show anything.

Hans wrote:I still stand by what I said, however. I like to type something, realize that's not what I want and just start typing something else, without the need to press Escape.

Hm, good point.

What if the hovering input field would auto-close after a short time, so that your use case would not be affected (or not by much)?

Then at least, for the short time while it's there, it would show what you've typed and let you quickly make modifications with ESCAPE.

But indeed, the question then becomes whether it's worth to implement such a feature for this relatively small benefit...

[PS: To make it less intrusive than the GTK+ solution (which seems to just use a normal text input field), it could be implemented as a "special" input field which doesn't catch LEFT/RIGHT arrow key events, and in which pressing the DELETE key clears the whole field.]

The open/save dialog in KDE Platform is automatically focused to filename field. Just pressing the enter it does automatically the default action (Esc will close the dialog) what is the open or save. Of course the "open" does nothing if user has not typed the filename. Save dialog has by default the same name of the file what was opened so hitting enter will just save the file and as if wanted to overwrite.

The dialog in that part is very well designed as the name input box as well auto-complete the files/folders. User can even use same shortcuts as on command line, like ../name or ~/name. If the user is typing something and there comes drop-downlist suggesting something, user can close it with Esc. Hitting second time the Esc the cancel/close action is inputted. So Esc does logically what is expected with dialogs.

The dolphin itself is little bit different. As already mentioned. We have the filter bar (Ctrl+i. What will be joined with search bar in the future if I remember correctly ) and we have the quicksearch. What goes just by typing the names. No need to close anything. Yes, there can be problem that user is typing something without seeing what. But the quick filter is used same way everywhere. Like in open/save dialog where you select one file and then type one letter and it jumps to that part.

The timeout on that is pretty fast, might be something like 500ms until it starts reading again new letters.

If we would have the input box in dolphin, it would pop-up and draw user contact to itself, from the files. As now user can see right away where the selection jumps while seeing on what part it went etc.

If the input box (what is now suggested) would have a timeout, it would work more like the current, but with the visual information what is typed. But again, if the box is not closed soon enough, the user gets frustrated. If the box is too fast, user gets frustrated. Thats why GNOME developers have choosed to keep the input box open all the time.

I dont use Esc when correcting something what I have written wrong. If it is just 1-2 letters, I simply use backspace. If I made more mistakes, word is short enough or the typo is in the start of the word, I use ctrl+Backspace to delete whole word and I retype it.

The KDE platform function does not demand the Ctrl+Backspace or ESC at all. The timeout is fast enough that I do not even need to wait it to get cleared but I can type few letters to get where wanted.

We do have three different ways to search/filter/locate files.

- The shortcuts (type first letters of the filename) what means the selection jumps where the corresponding is found.

- The filter bar (Ctrl+i and type what wanted) what hides everything else than what match the typed word.

- The search bar (in toolbar) what use nepomuk/strigi to search files. (btw, just noticed that we have two duplicate shortcuts with different names for same function. Ctrl+S and Ctrl+i and both are for filter bar, even that Ctrl+S is for "search bar")

- Search application (Ctrl+F) what use kfind program to search files by the old fashion way.

The Dolphin search bar is going to be joined with the filter bar and/or kfind program. If I have understanded correctly. That means we can easily filter/search files from the current folder, current+subfolders or whole computer, even if the current folder is not included to nepomuk/strigi index.

I just find it strange that if user has a one or multiple files selected and then types something, the focus would move away from the file view to the input box.

My opinion is that the quick search (just typing the first letters of the filename) is for advanced users. While all three others (Nepomuk, Filterbar, KFind) are for basic users.

But I think developers could try that if user starts typing straight away, the filter bar would jump up and take the input. So no need anykind other input-box what would not belong to the Qt/KDE platform look.

ps. Try this, press Ctrl+i and press Esc. Then press Ctrl+i and type something. Then press Esc. What should happend on that case?
Try same with open/save dialog. Nice usability issue

I think more mature search input field is some think, I was waiting.

We should add history support(auto completion) and displaying message 'please esc to exit this mode'.