Version: (using KDE Devel) Installed from: Compiled sources In KWord we have a checkbox saying 'Automatically select filename extention', which turns a usertyped 'foo' into 'foo.kwd'. The check for already existing filename ignores this checkbox, though. - open kword. - type some chars - open save-dialog by pressing ^S - make sure the checkbox is 'on' for automatically add extention - type a filename that itself exists, but the .kwd does not. For example 'cd ~ && touch foo' then you type 'foo' as your filename. - kword pops up a dialog saying: "A document with this name already exists." This is wrong since the check for existing filename should have been 'foo.kwd', not 'foo'. Note that 'foo.kwd' is written if 'foo' did not exist.
Clarence, shouldn't KFileDialog::appendExtension() always append the extension when saving, and use the "if the file doesn't exist" logic only when loading?
On Saturday 20 January 2007 02:47, David Faure wrote: > Clarence, shouldn't KFileDialog::appendExtension() always append the > extension when saving, and use the "if the file doesn't exist" logic only > when loading? IMHO, no, for 3 reasons (in order of decreasing importance): 1. a) If I were to File / Save As and double click on an existing file "moo", I probably really do want to overwrite the file "moo". I think this is the killer argument. b) To extend this argument further, if I were to single click on an existing file "moo" and then press OK, I would probably want to again overwrite the file "moo". This is because what I've done, UI-wise, should be equivalent to a). Notice that the locationEdit contains "moo". c) Now, if I were not to click at all in the file dialog and I simply typed "moo" in the locationEdit and then pressed OK, should I not get equivalent behavior to b), since in both of them the locationEdit contains "moo"? 2. If I were to open a file "foo" and then attempt to File / Save As, without changing any options (e.g. filename, file type) and press OK, I would expect to overwrite the file I opened i.e. it should emulate File / Save. 3. The idea is that you can effectively use KDE for all purposes without ever unchecking that magic checkbox (kind of like Windows but a bit more refined). With this flexibility in mind, with that checkbox enabled, if "foo" already exists, you can choose to save as "foo" or by explicitly stating an extension, save as "foo.kwd". If the request in the bug report were to be implemented, we lose some flexibility - I do not believe it would be possible to save as "foo" anymore. Unchecking the checkbox is a pain because you have to remember to check it back the next time you save. As you can see, I spent quite some hours designing the heuristics for this feature :)
On Saturday 20 January 2007 11:25, Clarence Dang wrote: > 1. a) If I were to File / Save As and double click on an existing file "moo", > I probably really do want to overwrite the file "moo". I think this is the > killer argument. Then we have to handle "clicking" differently from "typing". > c) Now, if I were not to click at all in the file dialog and I simply typed > "moo" in the locationEdit and then pressed OK, should I not get equivalent > behavior to b), since in both of them the locationEdit contains "moo"? No. Because due to filtering, you might not even see that there is a file named "moo"! This is what makes this behavior very unintuitive. I see a bunch of blah.odt files, no moo among them, I type "moo" (to get moo.odt), and instead I overwrite a hidden file named moo! > 2. If I were to open a file "foo" and then attempt to File / Save As, without > changing any options (e.g. filename, file type) and press OK, I would expect > to overwrite the file I opened i.e. it should emulate File / Save. I disagree. The checkbox appends the extension, that's what it says... > 3. The idea is that you can effectively use KDE for all purposes without ever > unchecking that magic checkbox Well, yes, but getting an unexpected behavior which overwrites a file you don't see, doesn't fit into that definition. > With this flexibility in mind, with that checkbox enabled, if "foo" already > exists, you can choose to save as "foo" or by explicitly stating an > extension, save as "foo.kwd". But I don't even see that "foo" already exists, due to the filter... > If the request in the bug report were to be implemented, we lose some > flexibility - I do not believe it would be possible to save as "foo" anymore. > Unchecking the checkbox is a pain because you have to remember to check it > back the next time you save. I agree with keeping the "save as foo" case when _clicking_ on foo. But not when typing foo and foo isn't even visible...
Right, I see the problem now: You're asked to overwrite an extensionless file, that you can't even see, because of the filter. At the same time, solutions would have to be rather cautious in order not to create even more confusion. For instance, I'd be worried if: 1. Clicking acted differently to typing: consider click-selecting a filename, backspacing a character and then, adding the character it back 2. File / Save As, without changing any options, no longer being equivalent to File / Save - given that this is supposed to be an invariant. I think I have a solution to the original bug report (and your Comment #3 rebuttal), while still preserving the properties I want in my Comment #2. I'll get back to you soon. If you've got any ideas for a solution, I'd love to hear them also. Thanks, Clarence
On Tuesday 23 January 2007 00:00, Clarence Dang wrote: > If you've got any ideas for a solution, I'd love to hear them also. My solution is simple; honor what the user types/clicks and don't be smart about it. If the document has a URL that does not have an extention then (plain) saving will not require interaction and thus your features are unneeded. If the user wants to save it under a different name, they are unneeded. I'm still at a loss as to why you think this hack is needed at all. As no usecase or workflow I can come up with actually requires user interaction to pertain the original filename it was opened with. Negating the whole need. I think it boils down to this opinion: > 2. File / Save As, without changing any options, no longer being equivalent > to File / Save - given that this is supposed to be an invariant. There is no requirement at all that its an invariant. Far from it; a users goal of using save-as is there for one reason only; to alter the the name of the document. From a users point of view, and I kind of know something about usability, I disagree with the need for this 'feature'. Mostly because I don't see the need and secondary because the effects are worse then the problem its suppost to cure.
On Tuesday 23 January 2007 00:00, Clarence Dang wrote: > 1. Clicking acted differently to typing: consider click-selecting a filename, > backspacing a character and then, adding the character it back I agree. I think the logic has to be: if the file is visible, don't append extension (that file is meant), but if the file is not visible, then append extension. > 2. File / Save As, without changing any options, no longer being equivalent to > File / Save - given that this is supposed to be an invariant. Thomas wrote: > for one reason only; to alter the the name of the document. That's not really true: Clarence's code also handles the case where you use "save as" in order to modify options in the export filter.
Sorry for the late reply. I agree with David's last Comment #6. David Faure: > I think the logic has to be: if the file is visible, don't append > extension (that file is meant), but if the file is not visible, > then append extension. Yes, I agree with this change but then there is that problem of if you open "moo" and you then "Save As" (say, to change the filter options), "moo" doesn't appear due to the filter. A hacky solution would be to pass the URL of the current document to KFileDialog and make sure that it includes it in the file view, in addition to the files that are shown by the filter. But this is so messy :(
Moving from "kio/kfile" component to "kfile" product, helps sorting out duplicates.
This would have been a bug in KWord, which no longer exists.