Due to recent GNOME 41 update, to take screenshot I need to click "Share" EVERY time.

[All3xJ]

Flameshot Version

$ flameshot --version
Flameshot v0.10.1 (167de09b)
Compiled with Qt 5.15.2

Installation Type

User repository (AUR)

Operating System type and version

ArchLinux

Description

Due to this GNOME 41 update: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970
flameshot and other "non-gnome" screenshot tools are forced to ask for permission and break the workflow, because we need to press "Share" EVERY time.
Here is an open issue about it: flatpak/xdg-desktop-portal#649

Steps to reproduce

No response

Screenshots or screen recordings

Here is a video describing the issue: https://www.youtube.com/watch?v=CekLgmVnngY

System Information

[borgmanJeremy]

See the pinned issues. Complain about this upstream there is nothing I can do.

[mmahmoudian]

@All3xJ to be extremely specific, take your complaints to Gnomes devs. Read the following and share your thoughts to them:

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970

[All3xJ]

Ok, I reported to gnome upstream: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970#note_1341047
and here: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4895

[mmahmoudian]

@All3xJ thanks for putting the time into sending those comments and raising concern. They up front refused to do it when we (software devs) asked them. Now it seems there is some movement on their side after one of their users (i.e you) have wrote those posts.

Also they have said

So while your users might complain, you should be confident that other screencast software should have the exact same restrictions.

Which clearly is not true/correct as gnome's own screenshot application is clearly exempted for this "universal" regulation.

Also I personally find it unacceptable to break a working system without proper headsup to devs and also implement the new behaviour in a half-way manner and left and right claim that "it is not implemented":

Note that somebody actually has to do the work though, so until someone (maybe you? ;) ) steps up to actually implement this, the current situation will remain.

Basically imho they officially stated that they have only implemented the parts that give themselves an edge to promote their software and putting the others in disadvantage and just asking people to go way more than an extra mile to do what they intentionally neglected to complete!

Anyhow, I do hope that software users choose their softwares wisely, be it screenshot tool or window manager or desktop environment and software stack. Our intention in Flameshot is to do our best to make screenshotting and annotation as easy, as intuitive, and as accessible as possible to everyone, but we for sure don't have the resources to consider every edge case the DEs or OS throw at us. We prioritize and move forward one bug/feature at a time.

[nielsdg]

Hi @mmahmoudian, I disagree with your conclusion and I hope to clarify some things:

• Flameshot has used an internal GNOME Shell API. There never was a promise of API stability, which is a necessary condition for making an API public in the first place.
• Cross-DE developers (like GNOME/KDE/XFCE/...) are bringing up a cross-DE effort to get common platform for certain API that clients might be interested in: this is where XDG portal comes in. It's an API where each DE provides its own implementation (so that KDE can show Qt-based dialogs and GNOME can show GTK based dialogs for example).
• This XDG portal is the officially supported way for most DEs of grabbing a screenshot in Wayland and X11 sessions. In X11, you can also do it with the X11 API of course, and some DEs might also provide extra APIs (like KDE, who also restricted this with a special key in a desktop file).

So it does not make sense to complain about an API which was internal in the first place, but to solve this in a proper way, which will work across several DEs: XDG-portal, which is where flatpak/xdg-desktop-portal#649 comes in (and is the responsibility of XDG-portal devs, which overlaps with some GNOME devs, but certainly not only them).

Which clearly is not true/correct as gnome's own screenshot application is clearly exempted for this "universal" regulation.

GNOME's own screenshot tool will probably be removed for the new screenshot tool which is actually part of the compositor .The only reason why this API might still exist is for ... the GNOME implementation of XDG portal , which everybody should be using as it makes sure they have actual user consent (which of course _can _ be remembered, but that still needs to be remembered), and allows other components to show the user someone took a screenshot.

They up front refused to do it when we (software devs) asked them

Note that no-one is against adding this functionality in XDG portal (but it needs to be implemented). Suddenly adding API stability to something that never had API guarantees? No.

Finally, please note that ...

but we for sure don't have the resources to consider every edge case the DEs or OS throw at us. We prioritize and move forward one bug/feature at a time.

... also applies to GNOME/XDG-portal devs. I think most (if not all) GNOME/portal devs want to also have this functionality, but we are also completely out of resources here. Complaining to volunteer developers -some (others) even think it's okay to do with a plethora of insults- might nudge some people, but it's in the end also the same thing here: we work on what we can and volunteers are free to prioritize their own tasks.

[mmahmoudian]

@nielsdg I prefer to use a personal account on a better platform to express my personal opinions in details. In the hindsight I should've wrote my previous comment (which was also my personal opinion) on my mastodon account or my blog.

I wrote a lengthy reply to your comment and I might publish it somewhere.

[borgmanJeremy]

I'm going to follow the trend of the other projects and lock this before all the people arguing on those threads come here.

There's not much more to add, the path forward is identified and needs someone to spend time coding it.