| Summary: | save dialog: redesign the workflow when canceling overwrite | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | Maciej Pilichowski <bluedzins> |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs-null> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | wishlist | CC: | andresbajotierra |
| Priority: | NOR | ||
| Version First Reported In: | 4.2 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Unspecified | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Maciej Pilichowski
2009-02-26 11:12:11 UTC
Something about this: If the application use the default KFileDialog overwrite prompt (KFileDialog::setConfirmOverwrite()), if you select an already existing file, the "Overwrite" message box appears over the file dialog, *without closing it*; so if you cancel the Overwrite, you will be again on the dialog. This is the expectable and what you are asking for. However, if the application do not use this default overwrite prompt and implements its own version; at first it will launch the save dialog, then when the file was selected, the dialog will close and the application will do the check for existing file and it will launch the overwrite dialog if needed. Of course in this case, canceling the overwrite you won't get the save dialog again. So, this is not a kdelibs issue, but a issue on every Kde app implementation. Kate/KWrite is an example of this behaviour. The best approach will be: - File a bug report for every app which shows this behaviour. - May be close this report (or not, and use it to centralize all the other issues) What do you think? Regards You are right, but before closing this one I think it should be handled in general. Two issues: a) can you name an app which behaves correctly? b) is it good that kdelibs let application to run save dialog without overwrite confirmation? Can you (or anyone) describe the case when save dialog w/o confirmation is good UI? ad.b) if there is no such case it is kdelibs issue, to remove the ability to run save dialog in such mode (w/o overwrite confirmation) a) KFind results save dialog. I have not yet searched for another apps b) Probably not... the file dialog should always be launched with this confirm overwrite setting enabled. But some applications may need something special with this overwrite action and they will need to use their custom procedure. BTW: we are discussing how to address this issue (both on kdelibs and on kde-apps) on: http://lists.kde.org/?l=kde-devel&m=124441282615654&w=2 http://lists.kde.org/?l=kde-core-devel&m=124441472417551&w=2 We can't change the behaviour of the current functions(nor modify its parameters), but we can add new functions and encourage the developers to use them and to avoid the custom overwrite file procedure if it is not needed at all. Regards a) I mean -- app which uses kdelibs confirmation mechanism, kfind simply overwrites file (two new reports filled, so thank you for the hint :-D) b) thank you for the link, ok, so let's keep this one open as a report for new function and I post reports for apps which misbehave right now anyway I fixed a) some time ago on 4.3 during a major redesign. (actually KFind needs a maintainer) Thanks Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have implemented this wish. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann |