Should this be extended or forked for recording support?

[cjshearer]

I liked how easy this was to integrate into my binds for hypr, so I made a personal version of it for screen recording, Hyprec, and now I'm curious how this could be contributed upstream.

Changes made:

• replaced grim with wl-screenrec to initiate screen recording
• removed options for --clipboard-only and --raw, since neither of these seemed applicable to recordings
• made clicking the notification open the $SAVEDIR
• everything else, the vast majority of changes, were made to satisfy shellcheck

To contribute, I see a few strategies, roughly in order of decreasing duplication and increasing complexity:

1. Maintain a separate fork: this would result in a lot of duplicated effort, as ~95% of code is shared (most of the changes I made were to satisfy shellcheck).
2. Rework the changes and upstream them into Hyprshot: this may violate the principle of "do one thing, do it well". The name Hypershot also doesn't really imply screen recording, but this may just be me.
3. Fork and extract the geometry selection flow into a simpler program, call it Hyperselect, whose only purpose is to take a mode (e.g. region) and print the geometry. Create a Hyprec fork and update both it and Hyprshot to depend on Hyperselect.

I think 2) is probably the best option, since it avoids creating any new projects that could divide community efforts. While Hypershot certainly wasn't created with the intention of supporting recording, I don't think its a stretch to say that anyone who wants an easy screenshot utility is likely to want a similar utility for screen recording.

[Gustash]

Considering that Gnome uses the same keybinding and UI for screenshots and screen recording (print screen), I think it might be worth integrating that functionality in Hyprshot. In the end, what are screen recordings if not animated screenshots? 😛

[cjshearer]

Okay, if recording support was added, do you think it would be worth maintaining backwards compatibility with the current API? I've been thinking about how to expose the underlying options of wl-screenrec, and the best option I can think of would be to replace the current usage of --, by passing through any provided arguments/flags to the underlying program (be it wl-screenrec or grim). For anyone that wants the old functionality of opening the generated screenshot/recording, --print-path could be introduced, such that opening the file with mirage could be achieved by:

# before
hyprshot -m window -- mirage
# after
mirage $(hyprshot -m window --print-path)

Here is a working draft of my thoughts on how the API might be changed to support this functionality:

< Usage: hyprshot [options ..] [-m [mode] ..] -- [command]
> Usage: hyprshot [options ..] [-m [mode] ..] -- [pass-through options]
< Hyprshot is an utility to easily take screenshot in Hyprland using your mouse.
< 
< It allows taking screenshots of windows, regions and monitors which are saved to a folder of your choosing and copied to your clipboard.
> Hyprshot - capture recordings and screenshots in Hyprland.

  Examples:
    capture a window                      \`hyprshot -m window\`
>   record a window                       \`hyprshot -m window -t record\`
>   record a window with audio            \`hyprshot -m window -t record -- --audio\`
    capture active window to clipboard    \`hyprshot -m window -m active --clipboard-only\`
    capture selected monitor              \`hyprshot -m output -m DP-1\`

Options:
    -h, --help                show help message
>   -t, --type                screenshot or record (default screenshot)
    -m, --mode                one of: output, window, region, active, OUTPUT_NAME
<   -o, --output-folder       directory in which to save screenshot
>   -o, --output-folder       directory in which to save the file
<   -f, --filename            the file name of the resulting screenshot
>   -f, --filename            name of the output file
    -d, --debug               print debug information
<   -s, --silent              don't send notification when screenshot is saved
>   -s, --silent              silence notifications of file being saved
<   -r, --raw                 output raw image data to stdout
>   -r, --raw                 send output to stdout [--type must be screenshot]
>   -p, --print-path          print path of saved file to stdout
    -t, --notif-timeout       notification timeout in milliseconds (default 5000)
<   --clipboard-only          copy screenshot to clipboard and don't save image in disk
>   --clipboard-only          copy screenshot to clipboard, without saving to disk
<   -- [command]              open screenshot with a command of your choosing. e.g. hyprshot -m window -- mirage
>   -- [pass-through options] pass options through to grim/wl-screenrec

Modes:
<   output        take screenshot of an entire monitor
>   output        capture entire monitor
<   window        take screenshot of an open window
>   window        capture open window
<   region        take screenshot of selected region
>   region        capture selected region
<   active        take screenshot of active window|output
>   active        capture active window|output
<   OUTPUT_NAME   take screenshot of output with OUTPUT_NAME
>   OUTPUT_NAME   capture output with OUTPUT_NAME

[Gustash]

I don't like the passthrough solution. It might be better to have a screenrec-flags (or a better name, that one is quite shitty) flag, where you can send a string of flags for wl-screenrec.