Bug 106679 - KSnapshot should offer anyname010.png after saving anyname009.png
Summary: KSnapshot should offer anyname010.png after saving anyname009.png
Status: RESOLVED WORKSFORME
Alias: None
Product: ksnapshot
Classification: Unclassified
Component: general (show other bugs)
Version: 0.7
Platform: unspecified Linux
: NOR normal with 51 votes (vote)
Target Milestone: ---
Assignee: Richard Moore
URL:
Keywords:
: 52893 136563 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-06-02 16:55 UTC by Imre Péntek
Modified: 2009-09-21 21:41 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Imre Péntek 2005-06-02 16:55:33 UTC
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
OS:                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.
Comment 1 Albert Astals Cid 2005-06-05 18:13:45 UTC
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?
BUGS: 106679


 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))
     ra->setIcon(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() );
 }
 
Comment 2 Albert Astals Cid 2005-06-05 18:17:54 UTC
Hell, i closed the wrong but number, sorry
Comment 3 Philippe Rigault 2005-06-11 15:09:23 UTC
Dupe of bug 94726
 
Fixed in 3.4 (fix is only partially correct IMO, but it addresses the situation you describe)

Cheers,

Philippe
Comment 4 Imre Péntek 2005-06-11 17:13:08 UTC
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:
http://people.inf.elte.hu/pentek_i/doksik/Linux/source/qsinc.txt
I can offer this code (as it was written by me) to be used in KSnapshot.
Comment 5 Philippe Rigault 2005-06-15 04:35:30 UTC
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.

Philippe 
Comment 6 David 2005-10-08 22:40:19 UTC
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!

David E.
Comment 7 David 2005-10-09 01:16:26 UTC
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.
Comment 8 Janet 2005-10-18 22:00:45 UTC
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.
Comment 9 Peter Paulsen 2006-01-26 05:36:31 UTC
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? 
Comment 10 Frieder Ferlemann 2006-05-23 23:02:55 UTC
Additionally, if you plan to grab say 20 screenshots you might specify filename
  grab_01.png
but instead of proposing grab_02.png ksnapshot would use
  grab_2.png
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")
Comment 11 Janet 2007-01-20 20:57:44 UTC
*** This bug has been confirmed by popular vote. ***
Comment 12 Richard Moore 2007-01-20 23:38:27 UTC
*** Bug 136563 has been marked as a duplicate of this bug. ***
Comment 13 Richard Moore 2007-01-20 23:39:14 UTC
*** Bug 52893 has been marked as a duplicate of this bug. ***
Comment 14 FiNeX 2009-09-21 21:41:40 UTC
This bug has been fixed in the KDE 4 version.