It made me think about D17595.
Would it make sense to upstream this to KIO and unify behavior with Open/Save Dialog (it currently has a folder name check using popups).
This is a different matter so it should not stop progress here.

In D21907#482087, @meven wrote:

It made me think about D17595.
Would it make sense to upstream this to KIO and unify behavior with Open/Save Dialog (it currently has a folder name check using popups).
This is a different matter so it should not stop progress here.

This is already in KIO. :)

Have not looked at the patch, just the gif: I am rather sceptical if instant feedback is a good idea here. First, having an empty line edit will happen a lot, usually without the user wanting to press OK. That means the user will already get feedback in the middle of the workflow even though he did not yet have the intention to click OK yet.
The same may hold true for the other cases. Too much on-the-fly feedback may be annoying and stress the user unnecessarily.

Finally, resizing the dialog depending on the error message also looks rather hard on my eyes.

The much better fix would be: create the folder "New Folder" inline in the list view and immediately switch to edit mode, this way you do not need a dialog at all but don't loose anything. If the folder already exists, name it "New Folder (i)". Yes, that's how it's done in Windows as well, but I think it makes a lot of sense.

Comments? :)

The gif depicts a rather extreme case where you're deliberately trying to test all the feedback modes in quick succession. :) At @meven's request, I've already removed the red error message when the text field is empty.

Do the warnings need to below the buttons? I feel like they are kinda out of place there.

In D21907#482146, @dhaumann wrote:

The much better fix would be: create the folder "New Folder" inline in the list view and immediately switch to edit mode, this way you do not need a dialog at all but don't loose anything. If the folder already exists, name it "New Folder (i)". Yes, that's how it's done in Windows as well, but I think it makes a lot of sense.

Comments? :)

Unfortunately we cannot do this for the dialogs from KNewFileMenu because KIO has no knowledge of the client's view. This dialog is invoked not only from Dolphin, but in the file dialogs and many other places. Dolphin itself could implement this as it already has a "rename inline" mode, but it would be a lot of extra code. And KDirOperator which is used for the file dialogs does not have that feature so it would have to gain it first.

In D21907#482146, @dhaumann wrote:

Finally, resizing the dialog depending on the error message also looks rather hard on my eyes.

In D21907#482169, @squeakypancakes wrote:

Do the warnings need to below the buttons? I feel like they are kinda out of place there.

I experimented with putting the warnings elsewhere, but then the problem is that they cause items in the user interface below them to jump around as they appear and disappear. I know from experience that many people really hate this.

Any more comments?

If there are no formal objections, I'd like to land this.

These two points were not discussed anymore:

1. Isn't there a better solution by creating the folder and immediately select it + change to edit mode?
2. Resizing dialogs are usually not preferred.

If everyone else thinks this change is a good idea - then fine. I sm rather sceptical ;)

In D21907#484197, @dhaumann wrote:

These two points were not discussed anymore:

I addressed them in https://phabricator.kde.org/D21907#482181:

1. Isn't there a better solution by creating the folder and immediately select it + change to edit mode?

Not really. The proposed behavior would need to be implemented in every single app rather than in KIO, because KIO doesn't know about the view that will hold the new file or folder that's being created. Even if we did do add view-specifric behavior to every app, then we would still have the problem here in KIO's new file/folder dialog, which is app- and view-agnostic. I think it's nicer to have it here in KIO, and have every app use the same component, rather than re-implement the same set of features in many places for different views.

2. Resizing dialogs are usually not preferred.

Yeah, I can understand this concern. In general I find that people get upset when the window or the window content changes when a KMessageWidget appears, which is a legitimate criticism. However this is a general problem with the KMessageWidget's visual design itself, not really with this specific patch. I would be in favor of making a "popover" version that shows the message in a little pop-up frame that doesn't resize the window or its content. GNOME and macOS do this and it's really quite nice.

Of course someone would need to write that component. :)

So it boils down to "let's try this and improve later if necessary" - well then :)