Re: Help with Gcolor3

["Listings - www.majors-welt.net" <listing majors-welt net>]

On 10/25/17 12:28 PM, Emmanuele Bassi wrote:
> On 25 October 2017 at 11:19, Listings - www.majors-welt.net
> <listing majors-welt net> wrote:
> > > > I am a user of a color-picker tool - previously Gcolor2 - that has now
> > > > been
> > > > adopted to Gnome3 -> Gcolor3 -> https://github.com/Hjdskes/gcolor3/
> > > >
> > > > Now while lots of linux distributions are switching to wayland as default
> > > > session the color picking just dont work any more (which breaks the
> > > > workflow
> > > > of web and other developers) - even not in gimp afaik.
> > > Correct; the idea is that only privileged components can access the
> > > contents of the screen, and that applications need an appropriate
> > > privilege escalation mechanism, usually by talking to those components
> > > through a well-defined IPC mechanism, like DBus or a Wayland protocol
> > > extension. Starting from a sandboxed environment and opening it up
> > > appropriately is safer and more secure than having an open system and
> > > closing it down.
> > Yes, i know why this happens and i agree with that.
> >
> > But thinking from my position as user, its is it going to be -> pick color,
> > enter password, -> pick color, enter password, -> pick color, enter
> > password, and so on?
> >
> > this will be 4 times more time consuming at working with colors.
> No, that would of course be ridiculous and would just make people
> angry at their computer. :-)
>
> "Privilege escalation" does not imply "asking for a password"; it
> means that there's a user-noticeable, or a user-initiated step in the
> middle of the operation, and that the operation can be cancelled by
> the user at any time, without leaking information to the application.
>
> For instance, right now, an X application can literally pick any pixel
> from the screen without the user knowing it ever happened, through the
> existing client API. What we want is, instead, to have a (simple) IPC
> mechanism to ask the compositor to start the selection of a pixel on
> the screen; the compositor would now be able to change the cursor and
> deal with the user side of things, tracking the position of the
> pointer, and then pick the pixel at those coordinate. Essentially, to
> enter into a state where it would be clear to the user that there's a
> color selection in progress. It's the same way you take screenshots of
> the desktop: an application asks the compositor to take a screenshot,
> and the compositor deals with the whole user interaction; all that an
> application gets at the end is a file in a specific location.
OK
> > > > The developer of Gcolor3 has no straight idea how to fix this (and maybe
> > > > some "wayland-api" is neccessary?)
> > > You probably want to start with a compositor-specific API, like the
> > > way screenshot and screen recording is performed in GNOME; if you want
> > > more Wayland compositors to follow the same protocol, you will have to
> > > draft the specification and discuss it on wayland-devel in order to
> > > get buy in from all the developers of Wayland compositors out there.
> > Where is a documentation about it?
> Sorry, I'm not sure I understand. Documentation about what, precisely?
I'm also not sure as a user... something about "a compositor-specific 
API, like the way screenshot and screen recording is performed in GNOME"
> Ciao,
>   Emmanuele.
greets, tom