Set an appplication as 'default' when choosing to "Choose an app to open the capture"

[efstratios]

Feature Description

Hi,

It would be very helpful if the option to "Choose an app to open the capture" would have a 'default' value as an option to set our desired application to open the saved capture every time at the configuration of the application (GUI or File).

Best regards.

[mmahmoudian]

Just to extend the idea, perhaps would be nice if the click opens the default application and the right-click opens the application list.

Pros:

• the right-clicking to open more options would be consistent with the right-clicking on the other buttons

Cons:

• it would break the current behavior
• at the moment for options of other tools we open the sidebar, but for this one it takes the screenshot and opens the window to choose the application

[efstratios]

Hello, just to add a comment to your reply @mmahmoudian, when you press the shortcut (Ctrl + O) it should automatically open the capture with the predefined (default) application.

In my opinion as a user, there is no need to change something in regards to mouse clicks as I think this is not offered in other buttons/options of the flameshot application (as you have already mentioned this is offered by pressing the space key). Please correct me if I am wrong?

[mmahmoudian]

regards to mouse clicks as I think this is not offered in other buttons/options of the flameshot application

It actually does. That was one of the features that was recently added so that users can open settings for each tool by right-clicking on the button of that tool (Basically is equivalent of selecting the tool and pressing space)

[lilalkor]

Just wanted to second that request. I'm using xbackbone to save screenshots, and to upload it uses that "Open with" tool (https://xbackbone.app/clients.html). And it would be very nice to have it set once to save that additional click.

[wd5gnr]

I have a fork that has a similar feature but I didn't do right click because, honestly, I don't know how to capture it yet. But I may attempt it before issuing a pr.

[mmahmoudian]

@wd5gnr The right-click is already implemented for other buttons to bring up settings of those tools. For instance if you right-click on arrow tool, it will open the sidebar with tool settings. Perhaps you can use that part of the code.

[wd5gnr]

@mmahmoudian Yeah I was going to study that and I think it should be pretty easy to integrate.

[wd5gnr]

Well, it turns out the right click mechanism is pretty much wired to the color panel. I made an attempt to get it working and it was major spaghetti and I'm out of time for now. When I get back I may revert and try again.

Here's what I did (for the record):

• in CaptureWidget I modified handleButtonRightClick to call a new tool function rightPressed (like pressed, but returns bool). If this function returns true, we stop processing otherwise things go on as normal. The base class function returns false.
• I also added a tool signal REQ_ADD_EXTERNAL_WIDGETS2 which calls widget(true) instead of widget()
• Capturetool also gets an overload for widget(void), widget(bool) which returns null by default
• The widget(bool) call passes the bool to a changed AppLauncherWidget constructor
• The constructor uses the alt as the logic for default tool or non-default tool
• In rightPressed, I emit REQ_ADD_EXTERNAL_WIDGETS2 instead of REQ_ADD_EXTERNAL_WIDGET

In retrospect, I think tying this in with the widget is a mistake since nothing shows and that's true even in my original code, it just works better. I think some of the changes here but then doing the launch in rightPressed might be smarter.

[wd5gnr]

The right click doing something special needs a total architecture (which would probably be a good idea). The code in CaptureToolButton is OK -- sort of -- but from there the signals fire to CaptureWidget::handleButtonRightClick (and LeftClick). These are all the same for all buttons and it is very hard without coding a specific test in somewhere to identify the magic button.

Because I think this is too big a change, I updated the branch to have the following logic (which is still pretty wacky): By default there is an option set to true. While true, if you click on the tool button, you get the normal launcher for external program. If you Alt+click you get the default program if set. If not set, it is just like before. And you can set the default from the external program launcher.

If the option is set to false, then the logic is reversed. Click opens the default program (if set). If not set or you Alt+click, you get the launch dialog.

https://github.com/wd5gnr/flameshot/tree/default-ext-app

If you want to see which version you like, you can roll back the last commit. That one just always launches the default or not based on the option.

I don't think I am going to take on the right click any time soon. The code to bring up the panel should be in a base class and then you could more easily do something else. But... as it is, I am passing the modifier keys through to the capture context which is fairly ugly.

Thoughts?

[mmahmoudian]

If you Alt+click you get the default program if set

Incorporation of the Alt, Ctrl, and Shift is something I wanted to suggest a while back since the first two are abbreviation of "alternate" and "control". Perhaps this is a topic for another issue but I write the gist of it here as it is related:

I think the following would make sense:

• using Shift to select multiple final actions for flameshot gui
  • addresses:
    • #2750
    • #2231
• using Alt to activate "alternative decision", meaning without Alt it does the user-selected pre-configured action (in the case of this issue default application), and with Alt it opens the window to choose. (if no user-selected settings is found, the window will be shown to user will all the applications. I suggest holding Alt would also change the icon to indicate that the functionality is changed.
• reserving Ctrl for keybindings and potential future use for Ctrlleft-click or Ctrlright-click

The caveat of this approach is that it is not touch-screen friendly as they don't have access to keyboard buttons

This is relatively a big change but I think it is necessary and crucial to make these decisions and implementation before we approach having plugins. I have to turn this into its own issue to get all the feedbacks in one place and pave the way for potential implementation.

If the option is set to false, then the logic is reversed.

I'm all for customization, but I think if we have this option, it should have a very clear and unambiguous text as it can get confusing very fast and cause avalanche of "bug reports". In general I vote for having this toggle button as I can equally understand the logic of having it either way.

[wd5gnr]

I agree there are other places where this could be useful. As for the help text, I would be very happy to have somebody word that in the way that they sense. I was more focused on that logic and I think the wording is unwieldy. I will do a pr for the part that is done soon.

[mmahmoudian]

@wd5gnr I finally found it. This is something similar that have been discussed:

• #1977
• #1876

[danielkrajnik]

could someone please explain why there is no option to set a default application to Ctrl+O or why is it such a problem? couldn't we just add an option to flameshotrc file like so many other programs?

[mmahmoudian]

@danielkrajnik

could someone please explain why there is no option to set a default application to Ctrl+O

Because it is not implemented. But if you look few lines above your own comments you will see that there is a PR for this 😃 :

[danielkrajnik]

Sorry, I should have noticed that. It's soon going to be a year old though, could we please consider adding it? It would be really really helpful.

Flameshot is amazing by the way! Hands down the best screenshoting tool I've used. It checks all the boxes (except for the default application 😬)

[mmahmoudian]

@danielkrajnik

It's soon going to be a year old though, could we please consider adding it?

As you know, anyone who work on this project are volunteers and investing their free times. I asked two devs two days ago to put this and few other PRs in their priority list, but these things take time. Btw, you are also welcome to review the code and give us your opinion. having extra set of eyes on the issue would be good.

About the your usecase, I have the following suggetsion:

1. use pinned screenshots. you can rightclick and save them if you want to keep them
2. you can use the CLI and have something like the following and bind it to keybinding

   flameshot gui --path ~/Pictures/ --raw | imv -
   

[danielkrajnik]

thank you, really appreciate that and sorry, didn't mean to rush anyone. I'm not a C++ developer, so besides a few typos my review wouldn't add any value.

Thanks for the suggestions, I didn't know that you can pipe flameshot's output. The goal was to avoid having to save the screenshot and keep it as a temporary floating window, but this may still come in handy at some point.

[mmahmoudian]

@danielkrajnik

I'm not a C++ developer, so besides a few typos my review wouldn't add any value.

Well, I'm not a C++ dev either 😅 I just read the code and try to spot typos and malicious code. The latter needs knowledge of C++, but still I try and raise flag if something looks weird.

The goal was to avoid having to save the screenshot and keep it as a temporary floating window

Then you can pin the screenshot. It is great as it stays on top, you can change its size by scrolling, and through the rightclick menu you can rotate, change opacity, and save.

I didn't know that you can pipe flameshot's output.

Flameshot has a pretty good CLI. Read more about it here:

https://flameshot.org/docs/advanced/commandline-options/

[danielkrajnik]

A very small review submitted (just one typo), the logic was hard to follow for me, but I'm 90% sure it's nothing malicious. I haven't tried to compile and run it though.

Then you can pin the screenshot

thank you, I didn't know that flameshot can do that. That is really useful - still though ability to choose you own application (by default) would also be helpful. I've noticed that pinned screenshots don't behave like other windows on tiling window manager, which is not a big deal, but an alternative would be great in some edgecases.