On 25 October 2017 at 11:19, Listings - www.majors-welt.net <list...@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. >>> 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? Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
