There is a option in spectacle(spec) that allows you to save to subfolders but the docs in “Help” say nothing of it. I feel it might need a update before KDEOS comes out one day.
I want to know if or how i can use this to make a sub folder for the title or the month year. Yes i realize you can do it manually by making a folder each month an setting it to save there but as a human I am forgetful.
*I did end up figuring it out but i feel a example should be added to the docs or a (i) icon at the end with a hint.
Whatever is before the / ends up being the folder name and everything after ends up being the screenshot info
While it might be good to explain anyway, I personally thought it was fairly obvious since this is the only way it could ever work. Non-folder filenames on Linux/MacOS/Unix cannot have forward slashes. A forward slash at the end of a filename always indicates that it is a folder. It is similar for Windows, except it uses backward slashes.
While defiantly true an something i should have caught on sooner or thought about.
In terms of those not raised using a traditional files system it would still come across as lacking.
At least when I first looked at it I though of it as <#>_<title>_<MMMM>_<yyyy>/.png as it showed. While it looks really weird like that. Having not really had to deal with or think about pathing in about 10 years, I spaced it. And I have been using file systems since the 90s. So I can only imagine someone today who’s only used a iphone or android or not been taught anything on file systems would look at it and wonder.
The main reason I brought it up, was with the upcoming kdeos and possible OEM devices down the line. A kde computer could be given or bought by someone who’s never learned the tech side. Its one of those things that’s not inherently obvious unless you have at least a little knowledge. So a little flavor text or example never hurts.
The great thing about collaborative environments is that individual contributors don’t have to be good at every single detail.
Your contribution could be one or even several well tested examples and somebody else augments them with explanatory text based on notes or comments you provide with the examples.
This happens a lot on the code side: developers, especially those who are not English native speakers, will introduce text that is too technical, misspelled, grammatically incorrect or maybe just “unwieldy”.
These texts then get “fixed” either during review or through follow-up changes by people who’s strength is to come up with good phrasing
