Enhanced Save Options for Flexibility in File Management

[Lonniebiz]

Current Situation

The current "Save" button effectively caters to the most common use-case scenarios. However, it lacks the flexibility needed for saving files with customized names or to alternate locations other than those specified in user configuration settings.

Proposed Solutions

1. Add a "Save As" Button: Introduce a new button alongside the existing "Save" button, dedicated to the "Save As" function, allowing users to choose their desired filename and save location.

2. Enhanced "Save" Button with Shortcut: Modify the existing "Save" button to accommodate an additional function where holding down Ctrl+Click enables a "Save As" dialog box.

3. Right-Click Context Menu: Add a context menu to the "Save" button that presents both "Save" and "Save As" options upon a right-click action.

4. Dropdown Arrow: Introduce a small dropdown arrow next to the "Save" button. Clicking this would reveal options such as "Save," "Save As," and maybe even "Save and Share."

5. Toolbar Customization: Allow users to add or remove buttons, including the "Save As" button, from the toolbar to suit their workflow.

6. Keyboard Shortcut: Implement a dedicated keyboard shortcut, such as Ctrl+Alt+S, to trigger the "Save As" function directly.

7. Toggle in Settings: Provide an option within the settings to toggle between simple and advanced save modes, thereby preserving interface simplicity for users who prefer fewer buttons.

8. Tool Tip Enhancement: As a simple yet informative approach, update the tooltip for the existing "Save" button to indicate that holding Ctrl+Click will activate custom saving options.

By implementing one or more of these solutions, users can more easily save files according to their specific needs without having to resort to renaming and moving files post-saving.

Thank you for considering these enhancements to make Flameshot even more user-friendly and functional.

[toadkarter]

Hi there, I would love to have a look at one of these as part of Hacktoberfest. I think I can make a start with the "Save As" button if that works?

[mmahmoudian]

@Lonniebiz At the moment with "correct" config, the Flameshot should ask for filename while suggesting the file name based on your config. Basically you should keep the checkbox unchecked.

@Lonniebiz @toadkarter Regarding the proposed idea, I personally like it as a general concept. We need to ask other devs' (@veracioux, @panpuchkov, @ZetaoYang, @hosiet, @Martin-Eckleben ) opinion, but as for me, my suggestion is to be implemented as a separate function but:

1. in the same button, Shiftclick triggers this "save as" function
2. the CtrlShifts should call this "save as" function
3. this function should ignore the checkbox that I pointed out above.

[toadkarter]

Great! Well in that case if the other devs agree please feel free to assign any / all of this issue to me, I would be happy to look into it.

[mmahmoudian]

@toadkarter there are other issues that you can take if you are interested. Anything that is labeled with "Good first issue", "high priority", or is in v13 milestone 🤓

Regarding this issue, I post it also on the devs matrix channel so that we get a consensus faster

[panpuchkov]

Looks good, I like this idea. Just to be clear with bullet 3, are we talking about the context menu on the right-click on the "Save" button only? I would like to be able to open Color Picker on right-click as we have right now. Also, it would be great not to forget about the default hotkey for MacOS.

[Lonniebiz]

@mmahmoudian Thanks for illustrating that work-around. The only downside of that approach is that it adds one little step to my most common workflow (which is to simply save immediately using the location and filename prescribed in my configuration). Ideally, though, on the occasion that I need a custom path and file name for a screenshot, it would be nice if I only had to endure that additional little step during those specific times (versus all the time).

@panpuchkov The right-click color selecting feature could still happen the same, as long as the right-click doesn't happen while hovering over the save button. When right-clicking the save button, you could provide a context menu for both "Save" and "Save As", but personally, I'd be happy if a right-click just immediately displayed the same "File/Path Chooser" dialog (pointed out by mmahmoudian) that gets displayed when the "Use fixed path for screenshot to save" checkbox is not checked in the configuration. Given that this dialog already pre-selects the default path and filename (prescribed in the configuration), and it offers both "The ability to save as usual" and "The ability choose a custom a path and filename", I don't think a context menu is even necessary: Left-Click saves as usual, and right-click produces the "File/Path Chooser" dialog at the default path and filename, but with the added flexibility to customize path and file name if desired.

[mmahmoudian]

I believe we should not change the default behavior of right-click. Any change in the current behavior will cause backlash from users (after two years I still get life threat emails). I suggest we

1. Have a separate function for "save as"
2. Ctrl+Shift+s triggers "save as" (this is on par with major software out there)
3. Shift+left-click or Alt+left-click on the current save button triggers "save as"
4. Ctrl+left-click on the save button opens a menu to let the user select the preferred save action

Basically I think we should agree on a framework about what each key in general would do. For example:

• Shift+left-click on buttons trigger secondary action
• Ctrl+left-click on buttons opens a menu to select related actions
• long press (long left-click) opens the menu as well (useful for those who use touch screens and tablets)

This way we can add additional functionalities using the same keys without cluttering the UI

[Lonniebiz]

@mmahmoudian In web development, a right-click event can detect the element where the right-click was performed and act based off of this. So, a right-click on a save button wouldn't mean the same thing as a right-click on the screenshot itself. Surely users don't expect to be able to change color if they right-click on a save button; they'd expect that when right-clicking on the screenshot itself, while using a drawing tool of some sort.

In the event that detects the right-click, you should be able to detect whether or not the mouse is hovered over the save button or not. If its not on the the save button, change color as usual. If it is on the save button, display "File/Path" Chooser. Then you're done; request granted perfectly.

[mmahmoudian]

@Lonniebiz At the moment, the right-click on buttons does perform and action: opening the sidebar for settings of that tool. If we use right-click to trigger secondary function, it means that we should either break an existing workflow for tools, or we should have double behavior for right-click (opening settings for tools, and performing secondary action for save). For this reason I vote against the right-click. Best case scenario, the right-click can trigger opening a menu (either in the sidebar or as an overlay menu).

[Lonniebiz]

@mmahmoudian Currently, what happens if you right-click the save button? On Flameshot v12.1.0 (Debian 12.1.0-2), it does nothing when you right-click the save button. I do see that sidebar you're talking about though; when I right-click a drawing tool, I see it.

I've always thought of a right-click as something that answers the question: "What can I do with this thing I'm right-clicking?". As long as a right-click answers that question, that's what I expect (whether it be via a sidebar or a dialog, either is fine with me).

A right-click is contextual, it shouldn't have to abide by another button's expectations in my opinion; it should do what is best for that button in particular.

I'm also quick to notice additional steps and effort. Right-Clicking is the least effort because it only requires the mouse, which is less effort and coordination than a click that requires the keyboard too.

Step-wise, a single right-click on the save button, producing that File Chooser you indicated, is the least steps I can think of.

However, keyboard people will prefer a hotkey combination. I'm strict about that too; I consider each key held down as its own step.

Anyway, you guys will figure it out, but that's my 2 cents.

void SaveButton::mousePressEvent(QMouseEvent *event) {
    if (event->button() == Qt::LeftButton) {
        // Immediately save screenshot to path and location specified in the configuration
    } else if (event->button() == Qt::RightButton) {
        // Open File Chooser dialog at location and filename specified in configuration, but allow changing.
    }
}

[Crunchbits]

Just as an additional comment, if implemented I think both Save and Save as should have the following options:

• Custom path text field
• Checkbox to use fixed path screenshots

I know that currently the Save options have both of these, but I want to highlight the idea that when split into Save and Save as they should both continue to have the 2 same options. I can't stress how useful this would be. Here are a couple of configurations and why they would be useful:

1. Both Save and Save as have fixed path unchecked. This means that the Save as dialog opens the last saved to folder and can change folders & Save can be used to quickly save to last saved to folder without a dialog. This is useful for projects where you want to screenshot multiple times quickly in the same folder via Save but want to have the ability to change to a different project folder every so often via Save as where you can do more batch screenshotting to the new folder location via Save.
2. Both Save and Save as have custom paths. This would just be useful for those who don't like to tinker that much with screenshots. They almost always Save/Save as to the same path.
3. Save has fixed path unchecked and Save as has custom path. Not sure about how useful this one would be to be honest. Seems to function differently, perhaps someone could find it useful.

Personally, I would be more than happy if simply configuration 1 was possible. It's actually the reason why I'm still stuck using Lightshot as my primary screenshotting program, because it's the only program I've seen that can quickly screenshot and change between project folders for batch screenshotting. Again, I can't stress how useful this would be. I would get rid of Lightshot so fast if this was implemented.