| Summary: | GIMP 2.10 internal color picker doesn't work with "Color Picker" effect + OpenGL compositor backend | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Yevhen Popok <xalt7x.service> |
| Component: | scene-opengl | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | jehan |
| Priority: | NOR | Keywords: | usability |
| Version: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Yevhen Popok
2019-05-04 22:43:40 UTC
> OBSERVED RESULT
> GIMP picks color under mouse
>
> EXPECTED RESULT
> GIMP picks some color (black/blue) from Plasma theme
Sorry, EXPECTED/OBSERVED must be vice versa. Unfortunately I'm unable to edit initial message.
Could be a duplicate of bug 172921. Please do not set the flags; they used by developers to request input from the usability team. (In reply to Christoph Feck from comment #2) > Could be a duplicate of bug 172921. > I believe it's not the same bug. Those bugs tells that you can't pick a correct color because other window has been darkened. But here you can't pick any color (GIMP always returns black (#000) on most distributions or blue on Mageia (which has different theme by default). I should have added this to the first post. --- Meanwhile I tried to disable all effects and figured out that the problem is with (surpise-surprise :) ) "Color Picker" effect (hidden under 'Internal Desktop Effects'). After I disable it GIMP even with OpenGL backend gets correct color. A bit stupid question: what tool do you use for color picking? (In reply to Vlad Zagorodniy from comment #4) > A bit stupid question: what tool do you use for color picking? On toolbox on the left, under standard "tool" icons there's 2 colors (foreground/background). Click on one of them, then on the same line as "HTML notation" click on the 'eyedropper' icon. Thanks, I'm surprised that GIMP uses the color picker effect. Will look into it. GIMP spews warnings like this (gimp:23528): GLib-CRITICAL **: 12:00:48.423: the GVariant format string '(u)' has a type of '(u)' but the given value has a type of '((u))' It looks very fishy because the return value has type of (u). In either case, it looks like a GIMP issue. Can you file corresponding bug report? https://gitlab.gnome.org/GNOME/gimp/issues/ (In reply to Vlad Zagorodniy from comment #7) > GIMP spews warnings like this > > (gimp:23528): GLib-CRITICAL **: 12:00:48.423: the GVariant format string > '(u)' has a type of '(u)' but the given value has a type of '((u))' > > It looks very fishy because the return value has type of (u). In either > case, it looks like a GIMP issue. Can you file corresponding bug report? > https://gitlab.gnome.org/GNOME/gimp/issues/ Sorry, I don't understand meaning of that warning. Situation is that probably all X11 compositors except KWin support GIMP. I can file bug report and they may say it's a KWin problem. > Sorry, I don't understand meaning of that warning. It means that GIMP can't unpack color information sent by KWin. > I can file bug report and they may say it's a KWin problem. I doubt that this is a KWin problem. @evgen
Link it here afterwards, I'll help follow it up.
>It looks very fishy because the return value has type of (u).
Our first out argument is (u), but the full message is a structure of all out arguments.
(In reply to Evgen from comment #8) > (In reply to Vlad Zagorodniy from comment #7) > > GIMP spews warnings like this > > > > (gimp:23528): GLib-CRITICAL **: 12:00:48.423: the GVariant format string > > '(u)' has a type of '(u)' but the given value has a type of '((u))' > > > > It looks very fishy because the return value has type of (u). In either > > case, it looks like a GIMP issue. Can you file corresponding bug report? > > https://gitlab.gnome.org/GNOME/gimp/issues/ > Sorry, I don't understand meaning of that warning. > Situation is that probably all X11 compositors except KWin support GIMP. > I can file bug report and they may say it's a KWin problem. This bug has already been reported (sadly, unnoticed) https://gitlab.gnome.org/GNOME/gimp/issues/1878 This was implemented (commit 06bbf3e4, December 8, 2017) based on how the original "pick" method was implemented. Back then, it looks like only a QColor value was returned: https://phabricator.kde.org/D3480 It looks like you may have changed the API, haven't you? If so, I hope you don't plan to do this regularly. I really expect dbus API to be as stable as possible. Also do you have documentation? I could not find any with a quick search. Also if some of you guys wishes to propose a patch (code is in `libgimpwidgets/gimppickbutton-kwin.c` in our tree), you are more than welcome! This would be very helpful. (In reply to Jehan from comment #12) > It looks like you may have changed the API, haven't you? If so, I hope you > don't plan to do this regularly. I really expect dbus API to be as stable as > possible. Not really, the color picker wasn't touched in a while. The last commit dates back to 3/6/2017. > Also do you have documentation? I could not find any with a quick search. D-Bus introspection stuff is the only documentation as far as I know. We probably have to document most of our dbus APIs. |