SUMMARY Spectacle doesn't interpret the "<ss>" (seconds?) placeholder put in the filename template setup in Image saving configuration set. STEPS TO REPRODUCE 1. Open Spectacle 2. Go to "Configure" -> "Image Saving" 3. Verify that the "Filename" filed contains the "<ss>" placeholder (is should be there by default) 4. Take a screenshot 5. Open the saving folder OBSERVED RESULT The saved screenshot has "<ss" (without the ">") in the name instead of the number of seconds. EXPECTED RESULT The saved screenshot follows the filename template defined in the configuration. SOFTWARE/OS VERSIONS Kernel Version : 6.7.9.zen1-1 Plasma Version : 6.0.1-3 KDE Version : 24.02.0-1 Frameworks Version : 5.115.0-1 Qt5 Version : 5.15.12+kde+r10-1 Qt6 Version : 6.6.2-4 Wayland Version : 1.22.0-1 XOrg/Wayland Version : 23.2.4-2 Mesa Version : 1:24.0.2-2 LibVA Version : 2.20.0-1 VDPAU Version : 1.5-2 ADDITIONAL INFORMATION This bug makes it impossible to take more than 1 screenshot per minute by overwriting all screenshots taken in the same minute. This is why I labelled it as major: I discovered this when I needed the screenshots!
Not really. Please move this to "Normal": screenshot names are appended a numeric "discriminator".
Fun fact: you cannot take a screenshot of spectacle. I think this is NOT a bug.
I see a lot of confusion in kconf_update/spectacle-24.02.0-change_placeholder_format.cpp and src/ExportManager.cpp files with "hh" and "HH". See attachment. Are those string in the const ValueMap oldNewMap to be passwd to strftime?
Created attachment 167021 [details] Comparison between code and application text I see also what the actual is...
I can now see that it's is the last placeholder to create the problem. I have added now "<t>" and the seconds pop up correctly in the filename. Now I get a trailing "<t" before the ".png".
SUMMARY Spectacle doesn't interpret correctly the last placeholder put in the filename template setup in Image saving configuration set. For example, "<ss>" is read or interpreted as "<ss" and thus not matched into the oldNewMap in kconf_update/spectacle-24.02.0-change_placeholder_format.cpp source file.
(In reply to 0BADC0DE from comment #3) > I see a lot of confusion in > kconf_update/spectacle-24.02.0-change_placeholder_format.cpp and > src/ExportManager.cpp files with "hh" and "HH". See attachment. > Are those string in the const ValueMap oldNewMap to be passwd to strftime? spectacle-24.02.0-change_placeholder_format.cpp is a configuration migration script. It should have no impact on how the program actually works. Only ExportManager.cpp determines the behavior.
(In reply to 0BADC0DE from comment #2) > Fun fact: you cannot take a screenshot of spectacle. > I think this is NOT a bug. Open spectacle from the command line with the `-i` or `--new-instance` option
Unfortunately, I cannot reproduce this bug.
(In reply to Noah Davis from comment #9) > Unfortunately, I cannot reproduce this bug. What is your last placeholder in your configuration? If I have <ss> or <t> I get the weird behavior. I haven't checked all other placeholders, though.
(In reply to Noah Davis from comment #8) > (In reply to 0BADC0DE from comment #2) > > Fun fact: you cannot take a screenshot of spectacle. > > I think this is NOT a bug. > > Open spectacle from the command line with the `-i` or `--new-instance` option (In reply to Noah Davis from comment #7) > (In reply to 0BADC0DE from comment #3) > > I see a lot of confusion in > > kconf_update/spectacle-24.02.0-change_placeholder_format.cpp and > > src/ExportManager.cpp files with "hh" and "HH". See attachment. > > Are those string in the const ValueMap oldNewMap to be passwd to strftime? > > spectacle-24.02.0-change_placeholder_format.cpp is a configuration migration > script. It should have no impact on how the program actually works. Only > ExportManager.cpp determines the behavior. This is where I have found the "<ss>" string.
(In reply to 0BADC0DE from comment #10) > What is your last placeholder in your configuration? > If I have <ss> or <t> I get the weird behavior. I haven't checked all other > placeholders, though. I normally use the default setting (has <ss> at the end), but I also tried putting <t> at the end.
(In reply to Noah Davis from comment #12) > (In reply to 0BADC0DE from comment #10) > > What is your last placeholder in your configuration? > > If I have <ss> or <t> I get the weird behavior. I haven't checked all other > > placeholders, though. > > I normally use the default setting (has <ss> at the end), but I also tried > putting <t> at the end. Are you using the same version? I am attaching a couple of new screenshots. 1. The saving path is not taken into consideration when doing "Save as". Maybe this is intentional. 2. The screenshot of spectacle shows clearly that the dialog is called without the <t> expansion.
Created attachment 167237 [details] Screenshot of Spetacle configuration with template and preview
Created attachment 167238 [details] While using "Save as". Suggested name has an unhandled partial placeholder. Taking a screenshot of spectacle with spectacle itself is not really trivial. You need to add a delay. Please not the filenames of my screenshots.
(In reply to 0BADC0DE from comment #13) > Are you using the same version? I tested with git master and release/24.02 branches. > I am attaching a couple of new screenshots. > 1. The saving path is not taken into consideration when doing "Save as". > Maybe this is intentional. I'm not sure what you're referring to. If I click Save As, go to a folder in the dialog, and save in the dialog, the screenshot is saved there. > 2. The screenshot of spectacle shows clearly that the dialog is called > without the <t> expansion. I cannot reproduce this behavior. <t> is always converted to a timezone abbreviation code for me.
(In reply to Noah Davis from comment #16) > > I am attaching a couple of new screenshots. > > 1. The saving path is not taken into consideration when doing "Save as". > > Maybe this is intentional. > > I'm not sure what you're referring to. If I click Save As, go to a folder in > the dialog, and save in the dialog, the screenshot is saved there. See the proposed file name: it ends with "<t.png" . This clearly shows that "<t>" is not converted into anything due to a 1-off character (">"). > > 2. The screenshot of spectacle shows clearly that the dialog is called > > without the <t> expansion. > > I cannot reproduce this behavior. <t> is always converted to a timezone > abbreviation code for me. But not here. IS there a way to get logs from spectacle? Maybe it is an ArchLinux-introduced issue.
(In reply to 0BADC0DE from comment #17) > IS there a way to get logs from spectacle? Maybe it is an ArchLinux-introduced issue. No, but you can use GDB or LLDB. I doubt that Arch Linux introduced this issue, but that doesn't mean it's impossible.
(In reply to 0BADC0DE from comment #11) > This is where I have found the "<ss>" string. The base keys are defined in ExportManager::filenamePlaceholders. ExportManager::Placeholder makes plain (<key>) and html (<key>) versions of the keys. ExportManager::formattedFilename() turns the placeholders into the real text. tests/FilenameTest.cpp verifies that the placeholder keys are always turned into the real text.
OK. I don't really mind where the error is. One thing is sure: I haven't recompiled/modified any source, still I am getting this error. I even tried to use the "point-and-click" interface to define the file name template, with or without any interleaving "-" between fields. My current template is: SHOT-<yyyy><MM><dd><hh><mm><ss><t><title> And my file names are like: SHOT-20240325123131<t.png
NEWS! It only happens with "Rectangular region" captures (which is my default one). With "Window under the pointer" (with a needed 3 sec delay to move the cursor) it gets the right file name!
OK, I figured out why I couldn't reproduce this. It actually has nothing to do with <t>, <ss> or hyphens, the problem is <title> when there is no actual title.
It looks like this is it. So, unless its is a screenshot of a titled window (a windowshot?), <title> should expand to something like "none" or "no_title" (or even "", the empty string) as that's the only case when we have a title. Full screen or full desktop screenshots also haven't any. TBH, besides "<title>" and "<#>" I would prefer to revert to strftime(3) placeholders as it has more options. Maybe we'd move "<#>" to "%#" and "<title>" to "%!" or anything else (only %i and %q and a few other ones are not used by strftime(3) ).
(In reply to 0BADC0DE from comment #23) > TBH, besides "<title>" and "<#>" I would prefer to revert to strftime(3) > placeholders as it has more options. > Maybe we'd move "<#>" to "%#" and "<title>" to "%!" or anything else (only > %i and %q and a few other ones are not used by strftime(3) ). Strftime was never used internally, the syntax of placeholders just looked similar. It's far easier to determine the start and end of a tag with <> than with % at only the beginning of a tag. This lets us create tags of arbitrary length easily. The <> tag syntax is far more flexible and readable. The next version of spectacle will have a lot more placeholder options, so whether or not strftime is used doesn't matter.
This issue in particular seems to be a side effect of the switch from the percent syntax to the bracket syntax for placeholders in the file name. Since the path removes surrounding non-alphanumeric characters around the window title placeholder if missing, it consumes the bracket where there would be a (for example) %ss preceding it before, stopping at the second chacter s. So either the regex for trimming separators is too aggressive or the substitution happens too early, before other placeholders are substituted
*** Bug 486542 has been marked as a duplicate of this bug. ***
It seems like there's no clear way to determine which kinds of characters count as separators that should be removed and which shouldn't
A possibly relevant merge request was started @ https://invent.kde.org/graphics/spectacle/-/merge_requests/365
Git commit 8d2e0641af5bda4b7684d8d3da176f71e8b5c523 by Noah Davis. Committed on 15/05/2024 at 17:22. Pushed by ndavis into branch 'master'. Fix empty <title> placeholders breaking nearby placeholders M +11 -5 src/ExportManager.cpp M +9 -0 tests/FilenameTest.cpp https://invent.kde.org/graphics/spectacle/-/commit/8d2e0641af5bda4b7684d8d3da176f71e8b5c523
I would revert back to the previous %-based syntax. Honestly this move just broke something that was working fine without adding any extra feature.
(In reply to 0BADC0DE from comment #30) > I would revert back to the previous %-based syntax. > > Honestly this move just broke something that was working fine without adding > any extra feature. Objectively not true. There are a bunch of new placeholders that couldn't be added with the old syntax.
Git commit cac40b6fe828fa71dd3182b2f6839d49e9030dd0 by Noah Davis. Committed on 15/05/2024 at 20:47. Pushed by ndavis into branch 'release/24.05'. Fix empty <title> placeholders breaking nearby placeholders (cherry picked from commit 8d2e0641af5bda4b7684d8d3da176f71e8b5c523) M +11 -5 src/ExportManager.cpp M +9 -0 tests/FilenameTest.cpp https://invent.kde.org/graphics/spectacle/-/commit/cac40b6fe828fa71dd3182b2f6839d49e9030dd0
(In reply to Noah Davis from comment #31) > (In reply to 0BADC0DE from comment #30) > > I would revert back to the previous %-based syntax. > > > > Honestly this move just broke something that was working fine without adding > > any extra feature. > > Objectively not true. There are a bunch of new placeholders that couldn't be > added with the old syntax. Not sure what you are talking about. Besides the window title (which was already there) what will we have new to `strftime(3)` ? Anyway, it's nice it is being fixed: <title> is not working yet.
(In reply to 0BADC0DE from comment #33) > Not sure what you are talking about. > Besides the window title (which was already there) what will we have new to > `strftime(3)` ? > Anyway, it's nice it is being fixed: <title> is not working yet. The new features are in 24.05. Again, strftime was never used. The syntax only looked similar.