I have a question (and I hope I’m in the right place): It happens quite often that I want to save something, but I don’t like the suggested file name.
In other save dialogs (OS or window managers) you select the location and type. The file name is already marked. But instead of focusing on the marked filename, I open a search dialog?
Why?
Maybe I am too stupid… But I don’t understand the ulterior motives of this user interface. Can someone explain it to me?
Instead of having to click in the filename first. That means I lose me mark of the filename (without file suffix). I may mark everything again. This can’t be efficient and so wanted?
Hello, Clemens! No, the save dialog shouldn’t trigger a search by default. On my system the initial keyboard focus is on the filename entry. Can I ask which application / WM has the issue?
So I can actually reproduce this under all programs that use a GKT(Gnome) FileChooser SaveDialog:
Firefox
Evolution
Geany
gnome-text-editor
(with Ubuntu 22.10 / Ubuntu 23.04 I know this for sure… but the behavior could be like this for a longer time).
Here’s how I can always reproduce it on my end:
i start geany
then I select “Save As…”.
i choose the place where i want to save the file. (Click on the location and select the appropriate directory with the mouse).
then I want to change the filename - but the filename doesn’t change - instead a search box opens and grabs my keystrokes…
now I have to click with the mouse on the “wrong” suggested filename… So lose the marker and so on… (especially stupid, if the suggested filename contains a dot - then the double click does not work )
Personally: I can’t do anything with the search field. If I want to save something, what should I search for? I know, yes where I want to save something.
And here I am at my question: What are the reasons to give the search the higher priority? If I really want to use the search, I can always click on the magnifying glass. But changing the file name happens to me much much more often than searching for something in this dialog.
Thanks for the open ear…
PS: I know this problem for a long time. After reading a post in a forum recently that someone else was also complaining about it, I realized that I am not alone. That’s why my request here… only now.
Addendum: If you do it the other way around: First change the filename and then select the destination works.
However, this is usually not so good in practice, because you usually only know in the destination folder, how the file should be called. Because you only know then how the notation of the other files in the destination folder are. E.g. upper or lower case or is there still a counter or is there a date in the file name and what is its format?
There have been various issues about this, and infinite talking back and forth, but no one has accepted a solution. I’m not going to link you to the biggest issue I found about this, because it just ended in a load of pointless arguments… but suffice it to say I have a merge request for the crux of the issue - that clicking outwith the name entry means now keystrokes go to search, but the name entry still seems to have visible focus - here, but that has languished without review.
Thank you for your post. I was beginning to think I was on my own. I also can’t really understand what this search is doing in a save dialog. For the fact that Gnome is known for offering things nice and simple and efficient, the search on this one is completely superfluous.
Suppose I have the dialog open and click on a folder. Why should my next input trigger a search? Especially since if I then click on a file in the search result, its filename is NOT! taken over into the filename field. All this is incomprehensible to me and as long as no one offers me a conclusive explanation for this behavior, I consider the behavior to be completely illogical.
It’s really a pity that I can’t program C of all things, otherwise I would gladly provide a patch.
