Version: 0.7 (using KDE KDE 3.3.2)
Installed from: Unlisted Binary Package
Compiler: gcc version 3.3.4 Configured with: /var/uhubuild/work/compile/configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,objc,java,f77,pascal --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --host=i586-uhu-linux
KSnapshot should offer anyname010.png as default filename (e.g. in save file dialog) after saving anyname009.png. Currently KSnapshot offers anyname0010.png in this situation.
same goes to anyname099.png and anyname0009.png and so on.
SVN commit 422487 by aacid:
Fix bug 106679
To konsole developers: hope you don't mind i commited without asking you first but this is a one liner so i doubt i can screw it up, would you like that i backport it?
M +2 -1 konsole.cpp
--- trunk/KDE/kdebase/konsole/konsole/konsole.cpp #422486:422487
@@ -2066,7 +2066,8 @@
KRadioAction *ra = session2action.find(se);
if (ra && (ra->icon() != icon))
- if (b_matchTabWinTitle && m_tabViewMode != ShowIconOnly)
+ if (m_tabViewMode == ShowIconOnly) tabwidget->changeTab( se->widget(), QString::null );
+ else if (b_matchTabWinTitle)
tabwidget->changeTab( se->widget(), se->fullTitle() );
Hell, i closed the wrong but number, sorry
Dupe of bug 94726
Fixed in 3.4 (fix is only partially correct IMO, but it addresses the situation you describe)
If this bug has only a "partially" correct fix, maybe I can give you a (hopefully) complete solution. This was written by me. A very simple KDEvelop QT based hello world project. Here is the main.cpp file:
I can offer this code (as it was written by me) to be used in KSnapshot.
Well, if you look at bug 94726, you'll see that the problem is not _how_ to correct it in a better way (I submitted a patch for that), but that there wasn't a consensus on what is "a better way" beyond fixing the simple 19->110 problem.
Not only is 19 followed by 110, but 119 is followed by 1110 and so on. 83rd snapshot is numbered 111111113. It wouldn't be bad if we could manually reset the numbering scheme, but where is the little file that remembers the current number-to-use-next? That should be documented in the Handbook. Also would be nice if we could vary the stemname as we choose from the Ksnapshot window. No need to try to protect us from ever re-using a number -- just check on each save that no file in the current directory is being overwritten. Otherwise, a dandy little screen saver. Thanks for programming it for all us poor users!
I'm sorry, you CAN reset the number sequence and the stem name from the ksnapshot window, since it DOES remember your overwrite of the suggested default. However, the 19 -> 110 bug still exists (SUSE Linux 9.2 but updated at least once a week). Thanks -- David E.
And how about this? When I save e.g. 20051018_1.png (the date of the screenshot + my desktopnumber) - the next proposed name kscreenshot gives isn't 20051018-2.png, no, it gives me a 20050119-1.png... That's very illogical. I would expect the very last number to be increased.
The behaviour comment #8 describes is extremely annoying, I agree. With this behaviour kscreenshot really can dump the counting up completely for I have to change *every* file name. It's worse than not counting up at all.
If this should be an intended behaviour then please make it configurable which number to count up.
Is it the same bug as mentioned in the original post or is it necessary to open an extra report for that?
Additionally, if you plan to grab say 20 screenshots you might specify filename
but instead of proposing grab_02.png ksnapshot would use
for the next screenshot.
This is extremely annoying, as you'll end up renaming about half of the files (if you need the filenames ASCII sortable).
I'm surprised that this bug seems to persist in KDE 3.5.2 (the bug https://bugs.kde.org/show_bug.cgi?id=52893 which was filed 2003 seems to be related and f.e. xsane just "does it right")
*** This bug has been confirmed by popular vote. ***
*** Bug 136563 has been marked as a duplicate of this bug. ***
*** Bug 52893 has been marked as a duplicate of this bug. ***
This bug has been fixed in the KDE 4 version.