file name does not auto increment

Could you please start gscrot with --debug parameter ....

1. open a terminal
2. gscrot --debug > gscrot.debug

... , reproduce this bug and attach the output to this bug report.

I can not reproduce this bug here so maybe further information could help us to investigate on this.

I can reproduce the problem:

- take two screenshots in a row

- GScrot has then three tabs open: the Session and the individual screen shots

- I now close the tab of the last screen shot

- If I take another screen shot, GScrot now asks me whether I want to override the existing screen shot, because by closing the tab it disappeared from the session

For me, it looks as if this is a problem in the handling of the tabs and the session: when I close the tab of the scree nshots after I took them (which I often do), they also disappear completely from the session, but the file still exists. As GScrot incremental updates are based on the session, it starts counting from the beginning, but of course the files already exist.

I think that in the end this problem (maintaining proper incrementation while preventing overriding existing files) is only solvable if GScrot sessions can be saved/restored. Otherwise I might have this problem every time when I start GScrot and want to continue storing screen shots in the same directory as before.

A little off-topic: I'd generally prefer if not every new screenshot would automatically open a new tab - this gets messy after 3-4 screen shots and tempts me to close them. I'd suggest that each new screen shot is by default only added as a thumbnail to the session tab and only shown in full detail with all options when I double-click it. I'll think a bit more about it and probably open a new bug/wishlist report for that when I have more time.

Well that's right.
GScrot counts the number of screenshots in the session and simply auto increments that number for the next screenshots.
If you just close the tab (screenshots will be deleted from session but not from filesystem) and take the next screenshot it'll get the name of the closed one.

I think this is definitely a bug and GScrot should not reset the counter during one session.

What do you think?

I would like it if Gscrot looked in the current target directory identified in the settings and counted from the filenames that are in that directory, instead of using the session information. I believe this is how the auto increment for file names typically works. Although maybe the programs are reading a setting that is saved between sessions in a $HOME/.helper file... One of my problems with the current set-up is the question, "You already have a file by this name, would you like to overwrite it? yes/no" I have no idea if I'd like to overwrite it because I'm not sure what it is....so my preference would be for Gscrot to "never" allow me to overwrite a file. It is cheaper to delete unwanted files later, than to remember what screenshot is missing because I've overwritten it.

For example: yesterday I took four screenshots so I have filename_01, filename_02, filename_03, filename_04. Last night I shut down my computer. Today when I take my screenshots, Gscrot should check the "current" directory and see there is already a filename_04 image and automatically skip to filename_05.

I'm sure this is more of a headache for you to program, but it would be immensely helpful to me as it would prevent me from overwriting yesterday's screenshots by mistake.

Thanks!!

Thanks for your explanations, EmmaJane.

I think this is a quite good solution.
I'll have to find out if it is maybe too "expensive" to read the whole directory just to find out what number to take for auto incrementing. It could possibly take a long time if there are a lot of files in it.

Maybe we should just add a number ( e.g. filename_05(1).png ) to the filename if the file already exists and forget the "You already have a file by this name, would you like to overwrite it? yes/no"-dialog?
In this case you can simply rename it or whatever but no file could ever be lost...

Perl should be REALLY good at sorting file names and then grabbing the largest file in the stack....I wouldn't worry too much about the expense of having perl sort. Maybe if it was Java you could worry about it. ;)

I like the idea of getting rid of the dialogue for overwriting files for new screenshots. The only time I think it makes sense to have this is if I'm renaming a file (and my new name is the same as something else in the directory). For example: maybe the select I did wasn't quite right. I would like to be able to immediately redo the screenshot and overwrite the one that I know is wrong. (I would also like to have a resizable "selection" tool, but that is a feature request for a different day.)

For the automatic file naming: I wonder if it would be better to append a time-stamp instead of filename_05(1).png?

I worked on a solution today and started to integrate a "session save/restore" option to GScrot.

At this point GScrot saves the current session (list of filenames) when exiting the program and automatically restores the files on next startup if they are still existing in the filesystem. Now it should be easy enough to resume any current project.

Next step is to improve the auto incrementing itself and search the filesystem to determine the next number to take. There is no way of overwriting files anymore except the user doesn't use auto incrementing. In this case GScrot should add a number (or timestamp - i am not sure about it right now, e.g. nautilus uses digits for this) to the next filename to prevent overwriting.

Using the File >> Open dialog it is now possible to select and open multiple files at once. This makes it easier to restore files you may have deleted from your session.

Cheers
Mario

I think this sounds great! Thanks, Mario! My only hesitation around numbering is that I don't want to end up with filename(1)(1)(1).png. So you would still need to check the current directory to see if the file exists for each increment of the number. Maybe there's already a hook that does this check for you though?

I'm also going to open a new feature request for dealing with sessions so this bug doesn't get too cluttered. :)

Here is a short explanation on how auto incrementing will work in the next version:

1) User is using auto incrementing
    - check current directory for filenames with a similar pattern
    - reverse sort filenames and extract the number (at position of "counting" wild-card)
    - add one to extracted number and use it for current filename

2) User is NOT using auto incrementing (e.g. using a date or time wild-card)
    - check if file already exits

    >>loop while file exists
    - add counter to filename (e.g. filename(1))
    - add one to counter
    <<end loop

There will be no filenames like filename(1)(1)(1).png because the filename will be filename(2).png if there is already a file filename(1).png and so on...

I think this sounds great!