change screenshot naming to avoid clashes when moving images

[axd1967]

Is your feature request related to a problem? Please describe. I often have to rename screenshots that have been moved to other folders because Stellarium tends to re-use apparently "vacant" filenames.

Here is a typical scenario: I'm preparing screenshots for presentations by creating them and then move them to the folder where the presentation is done. This works fine as long as I don't move the images before all shots have been taken. If I take a screenshot and later want to get another screenshot, I have to rename the screenshot in the folder where I collect images for the presentation.

Describe the solution you'd like

• Use ISO date/time (YYYY-MM-DD-HH-MM-SS.mmm up to millisecond) in the filename
• or just use some incrementing counter that is set at program startup, rather than before saving the screenshot

Describe alternatives you've considered Manually renaming of moved files

Additional context

[alex-w]

Who forbids you from using separate directories for saving screenshots?

[axd1967]

Who forbids you from using separate directories for saving screenshots?

The fact that changing the base save directory is cumbersome, otherwise I would do it routinely. There is no such thing as a "Save as..." action. Also, that directory needs to be reset after such a use case. All this combined makes this a cumbersome approach. The proposed change solves all this.

[gzotti]

The next will complain about soooo long filenames. So far users just take and rename their screenshots as needed and are happy.

The current way searches for the lowest possible number. You would have to change that to search for the highest existing number.

To make things more general, but much more complicated for many users, we (or rather you!) could develop a solution that allows date-related placeholders, but must fallback to the plain counting when no placeholder is found. A template string may be "stellarium-%4N" or "stellarium%V%U%Y%M%D-%h%m%s%3N" or just "stellarium" as it is now. Of course, characters illegal in filenames (colon etc.) must be force-converted to whatever is allowed.

%Y =YYYY %y=YY %M=MM %D=DD %h=HH %m=mm %s=ss. Each element must be 2 chars in length, except %Y creates 4 digits (with sign where applicable.)

%xN would mean a running number with x digits. %3N->000, 001, 002, ..., 999. How would mixing work? Should %N just be a number to avoid collision, or should there be a reference counter in any case? Would we have to track/reset running number per session? A format like "stellarium-%Y%M%D-%3N" may be useful after all, while time-coded screenshots with seconds may stand by themselves. (Unless you mayke more than 1 screenshot per second.)

%V could then be Stellarium's version number like "0.20.4", %U could be the user's login name.

But few users will understand this complicated format. Don't forget that Stellarium's target audience includes people who are happy that they could install it and run the very basics. Any change that surfaces in the GUI requires a bit of care. Maybe even have some presets and one "free format".

The next idea would be the addition, where the format allows, of EXIF or other metadata: Creator, date of creation, date of scene, various Stellarium settings (add XMP tags?), .... By this, you would argue, you won't lose creation information. Sure, yes, all nice goodies, but have no priority.

[axd1967]

I think you are deliberately complicating matters, especially by stating that the format is "complicated". Anyone looking at the name will recognise the format.

• there is no need to complicate the GUI.
• there is no need to provide placeholders (but a dev could do that)
• there is no need to add "stellarium" to the file name, because that information is part of the file path. It is the responability of the user to add that information if needed
• the proposed YYYY-MM-DD-HHMMSS.mmm format is intuitive, except maybe for a possible confusion between day and month in Anglo-American (and maybe other) cultures. The difference is that the entire world could live with an ISO format, and half the world must throw in brain bytes in decoding the anglo-american date/time formats (07-08-2020: July 8, or August 7? Obvious for anglo-americans, less so for the rest of the world).

But at least we agree that this sounds a bit far fetched. I'm, just looking for a way to solve my problem without too much effort.

Another workaround is to not move files, but copy them. This leads to bloated directories (containing lots of unneeded files).

The current way of numbering is NOT intuitive, because it introduces duplicated names. But it is a simple mode for someone writing the software!

[alex-w]

Sometimes you kill me, Alex. You create a big problem for yourself on the flat place and invent a super complicated solution for your problem. Right now your proposal introduces 4 new problems and does not resolve "your" problem.

[axd1967]

• it's not a "super complicated solution"
• it does solve my problem

Meanwhile I looked in the code and noticed a few things

https://github.com/Stellarium/stellarium/blob/23078c5912cd61129f72e1f4ba7489af38330299/src/StelMainView.cpp#L1680-L1685

• the file index needs 5 digits (... .arg(j, 5, 10 ..., ather than 3) for the field width otherwise inconsistent file names will appear as from stellarium-1000.png|jpeg|....
• a while <flag> + increment of an unsigned int seems more logical than the current for j- assume the counter ever reaches 100000, then tears will flow. Remember Y2K; still this solution will let tears flow once full integer range has been used - which is less likely than reaching 1000.
• Replacing the use of j with a QDateTime::currentDateTime().toString(Qt::ISODateWithMs) is a solution.
• therefore the while is only needed to generate an extra index in case the file does exists and flagOverwriteScreenshots is not set

[gzotti]

Replacing the running number with a date string that includes ms is a solution that suits you, but not everybody. For example, I don't like it. Just make a script that calls core.screenshot(....) with any name that JavaScript can create and that suits you. Assign that script to a hotkey (even Ctrl-S), and you're done.

[axd1967]

Replacing the running number with a date string that includes ms is a solution that suits you, but not everybody. For example, don't like it.

Curous to know your argument? What don't you like about it?

(JS was also an option, indeed.)

But consider replacing the 3-digit by a 5-digit as a minimum. just to avoid surprises.

[gzotti]

Replacing the running number with a date string that includes ms is a solution that suits you, but not everybody. For example, [I] don't like it.

Curous to know your argument? What don't you like about it?

I don't need the date of creation. It just clutters the filename. My file explorer can sort for and display file date if needed.

(JS was also an option, indeed.)

But consider replacing the 3-digit by a 5-digit as a minimum. just to avoid surprises.

I cannot think of a user who would collect more than 1000 screenshots without moving/renaming them to more meaningful names: targets, settings, dates, fov, ... there are just too many options which depend on various motivations. Again, 5 digits of which the first 2 are always 0 are also meaningless clutter. I consider the current solution "good enough", surpassable by the solution outlined above with a few presets for "normal" users. For special applications or current special requests, just use a script and force a filename that suits you.

[axd1967]

I don't need the date of creation. It just clutters the filename. My file explorer can sort for and display file date if needed.

That is correct. But any other scheme that generates unique numbers is also good.

I cannot think of a user who would collect more than 1000 screenshots without moving/renaming them to more meaningful names: targets, settings, dates, fov, ... there are just too many options which depend on various motivations.

That's Y2K thinkging.

Again, 5 digits of which the first 2 are always 0 are also meaningless clutter. I consider the current solution "good enough", surpassable by the solution outlined above with a few presets for "normal" users. For special applications or current special requests, just use a script and force a filename that suits you.

Wrong.

(a) the first '0' digits could by your own logic then also be considered meaningless clutter as browsers can perform natural sorting (b) if 100000 is unlikely to be ever needed, why is it present? why not 10_0001? or 10_000_000?

But far more pressing:

(c) The code is internally contradicting itself (counting to 100000 but limiting to a field width of 3 digits will cause sorting issues) (d) the code will forcibly overwrite an existing screenshot once hitting 100000 (plus cause a sorting problem). a while loop over an unsigned int makes this problem not go away, but far less likely (even if that also is Y2K reasoning).

Let's stop the discussion on the format, as you won't give in there (yet I maintain that your arguments are weak).

But please consider correcting at least (c) and certainly (d), as these are obvious, proven and dormant bugs.

[alex-w]

Your sententions (c) and (a) are contradict each other, and for (d) looks like you fixed limitations of file systems already.

[axd1967]

sigh. edit added: this is a ridiculous discussion. I point at proven bugs in the code, and yet we wind up in these pointless discussions!

[axd1967]

Meanwhile, I wrote the script for the interested:

//
// Name: screenshot with (ISO) date
// Author: AD
// License: Public Domain
// Version: 0.1
// Shortcut: Ctrl+Shift+S
// Description: Creates a screenshot that includes the date/time
//

var today = new Date();

// choose what you prefer

/* intuitive ISO date YYYY-M-D_H_M_S
var date = today.getFullYear()+'-'+(today.getMonth()+1)+'-'+today.getDate();
var time = today.getHours() + "_" + today.getMinutes() + "_" + today.getSeconds();
var dtg = date+'_'+time;
*/

///* ISO date YYYY-MM-DDTHH:MM:SSZ
var dtg = today.toISOString(); 
//*/

//core.debug(dtg)

// use other args if you like; following are currently available
core.screenshot(dtg, invert = false, dir = "", overwrite = true, format="png" )

// NOTE: Stellarium currently appends a (needless) '000'

[axd1967]

for_wishlist