Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Screenshot: Allow selecting the type of screenshot #1415

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

leolost2605
Copy link

This option allows to select the type (screen, window, area) of screenshot to be taken. Useful for apps that want to do the interactive parts themselves but still allow the user these different types of screenshots.
This is only a hint, backends may not implement all of these.

The use case I'm coming from is that at elementary we would like our screenshot app to have app actions for screen, window and area that bypass any UI (given that permission was granted previously) and just take the screenshot when launched.

pantheon (elementary OS) backend implementation: elementary/portals#105

If this receives some positive feedback I will do the GNOME implementation as well and libportal too I guess.

Fixes #1065

src/screenshot.c Outdated
GVariant *options,
GError **error)
{
uint32_t type = g_variant_get_uint32 (value);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This returns a guint32. Please use that.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've actually to some degree been migrating away from glib types that have standard equivalent variants, like gint guint32, gint64 to int, uint32_t and int64_t, etc. They are for all intents and purposes equivalent, but there is no reason to avoid the standard ones. They also have a higher chance of resulting in looking more sensible in editors syntax highlighting.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed in the rest of the file the glib types are used so maybe keep that for consistency but you tell me what to use 🤷

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What we've been doing, as @jadahl mentioned, is that new code should use standard types (uint32_t) instead of GLib types, so I think this PR should use uint32_t etc

src/screenshot.c Outdated Show resolved Hide resolved
src/screenshot.c Outdated Show resolved Hide resolved
This option allows to select the type (screen, window, area) of screenshot
to be taken. Useful for apps that want to do the interactive parts
themselves but still allow the user these different types of screenshots.
This is only a hint, backends may not implement all of these.
@Mikenux
Copy link

Mikenux commented Aug 10, 2024

How is this supposed to work with non-interactive mode?

I think the ability for apps to check which values ​​are supported would be useful so they can gray out actions (e.g. menu items).

@leolost2605
Copy link
Author

leolost2605 commented Aug 12, 2024

How is this supposed to work with non-interactive mode?

It would take a screenshot of the requested kind right away and send it, allowing to take more sophisticated screenshots without having to go through additional UI, like the interactive dialog. All of that of course given that permission was granted by the user.
So with screen it would behave like it currently does by default, with window it would, depending on the backend implementation, just take a screenshot of the active window and send it or allow the user to choose one and with area it would allow the user to select an area then screenshot that and send it.

I think the ability for apps to check which values ​​are supported would be useful so they can gray out actions (e.g. menu items).

Yeah that would certainly be useful but AFAICT it would require some more severe API breakage since the best way I can think of would probably be a bit mask dbus property. Not sure how this should be handled/was handled in other cases but I'll look into it :)

@Mikenux
Copy link

Mikenux commented Aug 13, 2024

I took a look at previous issues regarding the addition of the automatic permission. It seems it has been added for having:

  • One less step. Before, including for interactive, and in GNOME it was: select screenshot method > take screenshot > share. Now it is, with interactive: select screenshot method > take and share screenshot.
  • Allow screenshot tools like Flameshot to draw their custom interface.

That makes one reason to not have selecting the type of screenshot for the automatic permission. Also:

  • For "window", this needs to be predictive so it can"t really depend on backend implementation. Currently, the interactive method does a better job by allowing to select which window to screenshot, plus allowing the user to validate this shot (take and share the screenshot).
  • For "area", if it is using the system-side area selector anyway, why having it without screenshot validation as users can decide to change at any time the area?

Copy link
Member

@GeorgesStavracas GeorgesStavracas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the current code is alright, but incomplete: usually for features like this, it's important that we expose to apps which screenshot types the system supports. This can be done by adding a new property AvailableModes to the Screenshot portal.

You can look at the ScreenCast portal's AvailableSourceTypes for a reference code

static XdpOptionKey screenshot_options[] = {
{ "modal", G_VARIANT_TYPE_BOOLEAN, NULL },
{ "interactive", G_VARIANT_TYPE_BOOLEAN, NULL }
{ "interactive", G_VARIANT_TYPE_BOOLEAN, NULL },
{ "type", G_VARIANT_TYPE_UINT32, validate_type }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick:

Suggested change
{ "type", G_VARIANT_TYPE_UINT32, validate_type }
{ "type", G_VARIANT_TYPE_UINT32, validate_type },

@@ -50,6 +50,17 @@
Hint whether the dialog should offer customization before taking a screenshot.
Defaults to no.

* ``type`` (``u``)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think type is not very descriptive, because many parts of D-Bus and GLib and etc already use "type" for other things. When it comes to screenshots, I feel like mode fits better. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Needs Triage
Development

Successfully merging this pull request may close these issues.

Bring non-interactive screenshot options to parity with interactive ones
5 participants