Bug 106679

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() );
 }
 

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)

Cheers,

Philippe

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.

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 

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.

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
  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")

*** 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.