Version: 4.4.1 (using KDE 4.4.1) OS: Linux Installed from: Ubuntu Packages Apart from the fact that Kolourpaint always presents the "Save as..." dialog even if you just want to do a normal save (without changing name) it also very often suggests the wrong file name. It has happened on countless occasions that I just want to save my last update to an image and I press "Save". Instead of just doing a silent save operation, it presents the "Save as" dialog, and also suggests the wrong file name: - Sometimes a file name from one of the other files in the same directory - Sometimes a completely different name (that I have recently worked with). I have had to restore files from backup because I have overwritten a file I didn't want to touch, because of this problem.
can not reproduce with current SVN (~4.6)
I should perhaps update this bug description. I have realized that this happens only when I click on the close button in the upper right corner of the window, while having unsaved changes. The "Save as.." dialog is then presented, and often with another name than the picture currently edited as suggested file name.
I still can not reproduce this. Can you give me your steps to reproduce it, please ?
Hey, thanks for trying! Admittedly, I find it hard to present the actual steps that will produce this error reapeatedly. It occurs on a very erratic basis, so I have seen no real pattern to it so far. It happens perhaps every 20 times I save an image, and only when I save by exiting the app by clicking the close-icon in the upper-right corner of the kde window. I shall try to narrow down the use-cases where this happens, but there is no way to force the error to occur that I know of.
I can now reproduce it, but I did not currently find the real reason: in ~/.kde4/share/config/kolourpaintrc I have [KFileDialog Settings] Recent Files[$e]=/tmp/pic.jpeg,/tmp/pic.jpg,$HOME/pictures/Bild8.jpeg,$HOME/pictures/Bild8.jpg,$HOME/pictures/Bild6.jpg,$HOME/pictures/Bild4.jpg,$HOME/pictures/Bild1.jpg,$HOME/bla.jpeg,test1.jpeg,pic.jpeg When I now run kolourpaint ~/test1.jpeg and press "save", it opens the saveAs dialog with the filename in the line edit being "/home/kdetrunk/bla.jpeg" (which you see is the file in "Recent Files" _before_ the given file test1.jpeg Note to me: It is triggered in kolourpaint mainWindow/kpMainWindow_File.cpp when doing: fd.locationEdit()->setUrl(KUrl(startURL).fileName()); although startURL is "file:///home/kdetrunk/test1.jpeg" I assume a bug in kdelibs/KFileDialog ... to be investigated
The problem was introduced when trying to fix bug 193339. Setting the filename directly into the KUrlComboBox of KFileDialog does not play nicely with KFileWidget (which inserts an item at position 0 (KFileWidgetPrivate::setDummyHistoryEntry) and therefore garbling the index found by KUrlComboBox::setUrl), which is then 1 position too low and therefore showing a wrong filename. The original problem is in KFileDialog, which is created (constructor) with a startURL, but during settings it up to be in Save-Mode etc. and when "auto-select-extension" is checked, the given filename of the startURL is changed to have the main extension of the selected mimetype, which leads to loading a .jpg but having .jpeg as extension when the saveAd dialog opens. So the solution for this problem is: - Somehow fix KFileDialog so that it does not change the extension when the dialog shall be used for saving an existing file - get rid of the workaround from bug 193339
Knock on wood.... Seems to have been solved in KDE/Kolourpaint 4.7.3. Have not occurred all evening, while editing 10-20 pictures. Great work, whoever did it! Applause!!! :-)
Git commit 8c58543b2f65c8b6ff5f4c1097d20d463e4e5bda by Martin Koller. Committed on 10/12/2011 at 17:39. Pushed by mkoller into branch 'KDE/4.7'. keep current extension if possible BUG: 229547 M +23 -6 kfile/kfilewidget.cpp http://commits.kde.org/kdelibs/8c58543b2f65c8b6ff5f4c1097d20d463e4e5bda
Git commit 44db5ada362b47f53e1bd7f118292f974b028646 by Martin Koller. Committed on 10/12/2011 at 17:45. Pushed by mkoller into branch 'master'. revert workaround from bug 193339 as it's now fixed correctly in kdelibs BUG: 229547 M +0 -5 mainWindow/kpMainWindow_File.cpp http://commits.kde.org/kolourpaint/44db5ada362b47f53e1bd7f118292f974b028646