Run without background process when -r or -p is passed (also allows not using dbus)

[deliciouslytyped]

Flameshot currently requires starting a separate background process, with the rationale that this is required to handle the clipboard.
Currently flameshot is the only screenshot application that I was able to find, that works on gnome3 with wayland. gnome-screenshot doesn't do what I want, so I need to use flameshot.

I want to output a screenshot on stdout, and this is possible with the -r option, however, needing to run a background process for flameshot gui to work, is awkward.

flameshot gui starting a proper flameshot process, taking a screenshot, and then returning the output, is the desired behaviour.
Having this all done in one process context would also allow flameshot to work properly without dbus.

My current solution is this awkward mess:

set +m; mkfifo wat; { ( flameshot & flame_pid="$!" ; cat wat; kill -9 "$flame_pid" ) & sleep 5 } 2>/dev/null; flameshot gui -r | display `#do stuff here`; echo > wat; rm wat; set -m;

which could be reduced to:

flameshot gui -r | display `#do stuff here`

#1468 (comment) is related to making this process less awkward as well.

[deliciouslytyped]

Here is a oneliner for OCR-ing screenshots:

This is what it would look like if it supported what I'm asking for:

nix-shell -p flameshot tesseract imagemagick --run \
  "flameshot gui -r | convert -modulate 100,0 -resize 400% - - | tesseract - - 2>/dev/null;"

This is what it currently looks like:

nix-shell -p flameshot tesseract imagemagick --run "set +m; mkfifo wat; { ( flameshot & flame_pid="$!" ; cat wat; kill -9 "$flame_pid" ) & sleep 5; } 2>/dev/null; flameshot gui -r | convert -modulate 100,0 -resize 400% - - | tesseract - - 2>/dev/null; echo > wat; rm wat; set -m;"

Breakdown:

nix-shell -p flameshot tesseract imagemagick --run `# on NixOS we can get a shell with our dependencies.` " \
  set +m; `# Temporarily disable some job management messages.` \
  mkfifo wat; `# we wait on a named pipe to know when to kill the background process...` \
  { ( flameshot & flame_pid="$!" ; cat wat; kill -9 "$flame_pid" ) & sleep 5; } 2>/dev/null; `# The wrapping is to suppress the new PID message.` \
  flameshot gui -r | convert -modulate 100,0 -resize 400% - - | tesseract - - 2>/dev/null; \
  echo > wat; rm wat; set -m; `# cleanup` \
  "

[mmahmoudian]

@deliciouslytyped I don't this this dbus is going away anytime soon, but your "feature request" imho has nothing to do with the dbus but rather having an override on saving to the file when -r is specified.

Perhaps the more complete solution is that Flameshot respects all flags (-c, -r, and -p) if the user has specifically specified them. Would that satisfy your needs?

[deliciouslytyped]

The dbus stuff was a side-issue.
The key thing is to not need to start a background process.
Using -r and -p are just the general contexts where this makes sense.
You can keep the dbus stuff even if you aren't running a separate background process, it just isn't needed anymore in that specific case, because the output target is not the X11 clipboard.

[mmahmoudian]

@borgmanJeremy @ZetaoYang @Martin-Eckleben @lupoDharkael
What do you think?

I personally think that:

1. there is no necessity for Flameshot to do one single action and it can send the output in different routes sequentially (e.g flameshot screen -r -c -p img.png).

2. Regarding the dbus, I don't have proper understanding on what are the use cases of it, so the only comment I can give is that it make sense to not have the dbus whenuser has specifically asked for -p and -r iff its only purpose of dbus is to handle the clipboard.

[migzamudior3]

La verdad es la primera vez que analizo esto y pues se me terminó el tiempo, pero me esforzare por mejorar mi lógica mental y comprender mejor el ingles ya que sólo se poquito y esta activad apenas hace una hora y media supe que existia. Gracias:) El lun., 15 de marzo de 2021 11:47 p. m., deliciouslytyped < ***@***.***> escribió:

…

The dbus stuff was a side-issue. The key thing is to not need to start a background process. Using -r and -p are just the general contexts where this makes sense. You can keep the dbus stuff even if you aren't running a separate background process, it just isn't *needed* anymore in that specific case, because the output target is not the X11 clipboard. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1480 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATH6ONLEXBD6A7MVIPOCPT3TD35JTANCNFSM4ZH3TX3Q> .

[holazt]

@borgmanJeremy @ZetaoYang @Martin-Eckleben @lupoDharkael
What do you think?

I personally think that:

1. there is no necessity for Flameshot to do one single action and it can send the output in different routes sequentially (e.g flameshot screen -r -c -p img.png).
2. Regarding the dbus, I don't have proper understanding on what are the use cases of it, so the only comment I can give is that it make sense to not have the dbus whenuser has specifically asked for -p and -r iff its only purpose of dbus is to handle the clipboard.

@deliciouslytyped

The following should work.

flameshot full -r | display `#do stuff here` 

or

flameshot screen -n 1 -r | display `#do stuff here` 

or
Via flameshot gui

[mmahmoudian]

@ZetaoYang

This works (raw to stdout and copied to clipboard):

flameshot screen -n 2 -r -c | display

This does not work:

flameshot screen -n 2 -r -c -p ~/test.png | display

does not save the screenshot to \\test.ong, does not copy to clipboard and also produces:

display: no decode delegate for this image format `' @ error/constitute.c/ReadImage/572.

[deliciouslytyped]

@mmahmoudian @ZetaoYang: None of these work without the background flameshot process running. Please check that you don't have any flameshot processes running in the background when you test these, or you can probaby kill it with echo Killed: $(kill -9 $(pgrep -f '/flameshot$')).

[mmahmoudian]

@deliciouslytyped

None of these work without the background flameshot process running. Please check that you don't have any flameshot processes running in the background when you test these

I changes the background of my monitors to be different make it easier to see what is screenshot and what is not. I'm recording from my 3rd monitor (with Manjaro background) and I took screenshot from my 2nd monitor (with dark camouflage-patterned background).

[deliciouslytyped]

Hm. Ok, I'm not sure what's going on.
I'll try to take a closer look later.

[l29ah]

Do i get it right that i need to explicitly killall flameshotafter every time i run flameshot to avoid the process running in the background indefinitely and eating my battery while listening to my key presses?

[mmahmoudian]

@l29ah You got the concept awfully wrong. Flameshot does not listen to your keys. To put it in simple terms, Flameshot has 2 parts:

1. The main process which listens to org.flameshot.Flameshot dbus. your system already has tons of dbus which you can list using qdbus command. To count the number of dbus running on your computer you can do qdbus | wc -l (I have 131 on my computer).
2. the flameshot command (e.g flameshot gui) which sends the command to the main process and asks it to do a specific thing (in case of my example, the gui command).

Flameshot main process does NOT listen to your key presses.

On my computer it uses 145KB of memory. So imho no one should be worried about saving that much memory:

if you want to try it yourself:

ps --pid $(pgrep flameshot) -o pid,%cpu,%mem,vsz,rss,command | numfmt --header --to=iec --field 4-5

The numfmt command is number formatter and it converts the numbers in column 4 and 5 from Bytes to Kilobyte or Megabyte to make it more human readable.

For more information about dbus read the following:

• https://unix.stackexchange.com/questions/46301/a-list-of-available-d-bus-services
• https://en.wikipedia.org/wiki/D-Bus
• https://wiki.archlinux.org/index.php/D-Bus

[l29ah]

Flameshot does not listen to your keys.

strace says it does, as it wakes up and syscalls every time i hit a key in my X session.

your system already has tons of dbus

‰ qdbus | wc -l
qdbus: could not find a Qt installation of ''
0

The numfmt command is number formatter and it converts the numbers in column 4 and 5 from Bytes to Kilobyte or Megabyte to make it more human readable.

No, your script (or in fact your interpretation of its output) is incorrect, and in your example it consumes 145MB of RAM (and being 0.4% of your 32GB installed), as ps outputs sizes in kilobytes.

[mmahmoudian]

@l29ah you are right about the ps. For other who are on the same wrong wagon as I was, I just checked the documentation again and:

Regarding the qdbus, i think you need to have qt-dev installed. but according to a post I found on How to identify what processes are consuming dbus sockets the following should work to some extent:

sudo lsof -u dbus | grep -i socket | wc -l

About the listening to keystokes, perhaps @borgmanJeremy or @ThePurple can provide better answer.

[veracioux]

#2003 is the solution to all our problems :) If you are up for it, you can help us with testing.