Help with Gcolor3

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Help with Gcolor3

Listings - www.majors-welt.net
Hi folks,

i write here, because i dont know where it may fit.

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.

The developer of Gcolor3 has no straight idea how to fix this (and maybe
some "wayland-api" is neccessary?)

Is there someone to help out the dev of this little tool to make it
useable in wayland - maybe toghether with gimp as well?

Here are the issues:

  * https://github.com/Hjdskes/gcolor3/issues/38
  * https://github.com/Hjdskes/gcolor3/issues/65

I also would love to see Gcolor3 as a default color picker application,
but thats another point.

greets

tom

_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Help with Gcolor3

Emmanuele Bassi
On 25 October 2017 at 09:40, Listings - www.majors-welt.net
<[hidden email]> wrote:
> Hi folks,
>
> i write here, because i dont know where it may fit.

You probably want to start a discussion on wayland-devel:
  https://lists.freedesktop.org/mailman/listinfo/wayland-devel

This list is for developing GTK applications.

> 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.

> 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.

Ciao,
 Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Help with Gcolor3

Listings - www.majors-welt.net

On 10/25/17 12:05 PM, Emmanuele Bassi wrote:
> On 25 October 2017 at 09:40, Listings - www.majors-welt.net
> <[hidden email]> wrote:
>> Hi folks,
>>
>> i write here, because i dont know where it may fit.
> You probably want to start a discussion on wayland-devel:
>    https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
> This list is for developing GTK applications.
Thanks, i will consider it.

>
>> 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.

>
>> 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?
>
> Ciao,
>   Emmanuele.
>

greets, Tom

_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Help with Gcolor3

Emmanuele Bassi
On 25 October 2017 at 11:19, Listings - www.majors-welt.net
<[hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Help with Gcolor3

Listings - www.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
> <[hidden email]> 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
_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Help with Gcolor3

Emmanuele Bassi
On 25 October 2017 at 12:50, Listings - www.majors-welt.net
<[hidden email]> wrote:

>>>> 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"

You can look at the DBus API provided by GNOME for taking screenshots:

  https://git.gnome.org/browse/gnome-shell/tree/data/org.gnome.Shell.Screenshot.xml

and for taking screencasts:

  https://git.gnome.org/browse/gnome-shell/tree/data/org.gnome.Shell.Screencast.xml

A "pick a color" interface would probably look something like this:

  org.gnome.Shell.ColorPicker
  - pick() → (success: boolean, color: ai)

where the `pick()` method would tell the compositor to initiate the
selection of the color. The `color` return value would contain an
array of 3 integers, with the values of the RGB channels. As you can
see, there is no leakage of information on the application or content,
and since the compositor is responsible for the user interaction, the
application would never be able to call this method multiple times
behind the user's back.

You would need to talk to the GNOME Shell developers for implementing
this functionality; you'd have to start by opening a bug:

  https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-shell

Then, once it's available, you'd have to call it from GColor3.

Alternatively, you'd have to talk to the Wayland developers and
various compositor developers, and describe a Wayland protocol to
achieve the same result.

Ciao,
 Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Help with Gcolor3

Listings - www.majors-welt.net
Thanks for the help, maybe this can be a good starting point now.

greets, tom


_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list