I'm not sure I fullly understand this issue. It might not be too hard to modify, but a behavioural change like this isn't something to make lightly.

Can you explain why kdialog should make this change to whatever the user enters? This isn't the normal behaviour in the underlying kdelibs - applications may or may implement it.

I'm also a bit concerned that you think kdialog is overwriting the filename. --getsavefilename shouldn't be overwriting anything, just providing a string.

Hi Brad,
ok, sorry for me not beeing descriptive enough...

kdialog --getsavefilename ~ "*.ext" offers a checkbox to automagically add extension (.ext), which is usually checked in kword/kspread/etc.
So i expect i enter "test" as filename and get a file called "test.ext".

This works ok, if there is no file called "test",
But this does not work if a file or dir named "test" does not already exist.

When a file "test" exists, a suggestion of "test" is offered in filenamefield, that is ok, i use it since i want to create "test.ext", so filename = "test" + Add extension (.ext) = checked should do the trick, but it doesnt.
The only way of creating "test.ext" while a "test" already exists is to enter "test.ext" as filename. The Checkbox automatically add extension (.ext) does not work.
And its even worse when "test" is not a file but dir.

I know kdialog does not write files...
I discovered this bug in kword, which overwrote my "test"-file.

Hope this is clearer now.

Typo!

This works ok, if there is no file called "test",
But this does not work if a file or dir named "test" DOES already exist.

sry

I'm even more confused now. Can you explain
1. What works the way you expect?
2. What does not work the way you expect?
3. Exactly what behavioural changes you want?
4. Why that behavioural change is required, and what the consequences both both making the change and not making the change will be.

Based on:
$ kdialog --version
Qt: 4.5.2
KDE: 4.3.3 (KDE 4.3.3)
KDialog: 1.0

using:
$ KDE_LANG=en_US kdialog --getsavefilename "unnamed" "*.txt"

target:
create a file called "named.txt"

1. What works the way you expect?
Creating the file "named.txt" in a directory that does NOT contain a file or dir called "named". Doing it like:
a) In kdialog: Change "Name"-field from "unnamed" to "named"
b) Check "Automatically select file extension (.txt)"-box is checked.
c) Click "Save"
Result is as expected a file called "named.txt"

2. What does not work the way you expect?
Creating the file "named.txt" in a directory that DOES contain a file or dir called "named".
0) touch "named"
a) In kdialog: Change "Name"-field from "unnamed" to "named"
b) Check "Automatically select file extension (.txt)"-box is checked.
c) Click "Save"
Result is NOT as expected, but a file called "named".
To work around this the user has to enter "named.txt" in Name-field manually even though "Automatically select file extension (.txt)"-box is checked!

3. Exactly what behavioural changes you want?
If "Automatically select file extension (.txt)"-box is checked allways append it to content of "Name"-field, no matter file/dir without extension already exists.
(Even though a thought about duplicating extensions needs to be thought.)

4. Why that behavioural change is required, and what the consequences both
making the change and not making the change will be.
Required because the user does not know under wich name a file gets stored.
kdialog does not show the existance of a file called "named".
Will it be stored as "named" or "named.txt"

If this is not changing, a user that writes a draft in a file without extension, then writes formatted text in kword and wants to write it in the same dir under the same name but with extension like .odt will be asked to overwrite the file (without extension). So for "Fast fingered Freddys" there is a serious potential for a massive dataloss.


A workaround for scripters is to supply the extension with filename, like
$ KDE_LANG=en_US kdialog --getsavefilename "unnamed.txt" "*.txt"
But Apps like KWord dont work like this with unnamed documents.

Hope u get it.
Thank you for your efforts,
Ralph.

I'm still confused by the reference to KWord. kdialog is not KWord.

Are you mixing up the dialog shown in KWord, and the application called kdialog?

Hi Brad,

you are correct, kdialog is not kword, but they seem to share same dialog however.

I first recognized this missbehaviour in kword&krita(2.0.2 & 2.1 RC1), then checked with kdialog -> identical behaviour.

So as u have mentioned in #2 it might also be a kdelibs issue...

I was just assuming kdialog was offering its dialogs...

Please bear with me if i was wrong,
Ralph.

with kdelibs as source this could be a duplicate of:
https://bugs.kde.org/show_bug.cgi?id=195823

This "bug" is still valid in 

KDE: 4.3.85 (KDE 4.3.85 (KDE 4.4 Beta2))

*** This bug has been marked as a duplicate of bug 195823 ***