GNOME Bugzilla – Bug 791859
On-canvas dialogs should be movable/hidable
Last modified: 2018-05-24 18:54:56 UTC
On-canvas dialogs are fancy but have a lot of usability and stability issues. - They are often brokens with tablets: bug 791689. - They even crash GIMP in weird circonstances: bug 791447. - They are sometimes not visible when you zoom in on your image (for instance, zooming-in while doing a transformation to do it with details): bug 791797. - Often the GUI is in your way on the canvas so you have to detach it to see the image well. In the end, usability experience is poort and one often ends up detaching it into a dialog; and it has also many bugs. On bug 791447, comment 9, Massimo suggests that we may want to disable some of the most problematic on-canvas dialogs for 2.10. This bug report is a reminder so that we can see the state of the various bugs by 2.10 release and decide what to do.
Oh, yes, please please disable these dialogs :) and if they ever come back, it would be nice to have the option to disable all the on-canvas dialogs, and especially the on-canvas color picker dialog.
I have just started a discussion on the GUI mailing list about the topic for a longer-term decision too: https://mail.gnome.org/archives/gimp-gui-list/2017-December/msg00016.html Aryeom also deeply dislikes these and find them annoying. I am starting to wonder if anyone actually appreciate these on-canvas widgets. Also even the current ability to detach them is not necessarily that discoverable (you have to be curious and try to click the little buttons to understand they are here to detach the dialog) and no preferences is currently saved indeed. Longer term, maybe we should just get rid of them. That's sad for the code which already went in but if that is just a cumbersome feature…
Totally agree. It's hard to work on an image when there's something unmovable blocking it. I've had that problem with the text tool OCD forever.
(In reply to Jehan from comment #0) > > In the end, usability experience is poort and one often ends up detaching it > into a dialog; and it has also many bugs. On bug 791447, comment 9, Massimo > suggests that we may want to disable some of the most problematic on-canvas > dialogs for 2.10. > I meant to say that during the gimp-2.7/2.8 development cycle these on canvas dialogs were disabled because considered an experimental hack https://bugzilla.gnome.org/show_bug.cgi?id=645120 My doubt is: the problems experienced then have been solved during this development cycle?
(In reply to Jehan from comment #2) > I have just started a discussion on the GUI mailing list about the topic for > a longer-term decision too: > https://mail.gnome.org/archives/gimp-gui-list/2017-December/msg00016.html Out of curiosity - how will we avoid having two diverging discussions about this topic now, one here and one on the list?
They have been disabled for GEGL filters because their dialogs can be of arbitrary size. Regarding crashes, I was under the impression these are gone, at least I didn't get any myself in ages.
(In reply to Michael Natterer from comment #6) > Regarding crashes, I was under the impression these > are gone, at least I didn't get any myself in ages. They need some specific conditions but still exist. See bug 791447. There are also bugs which don't crash GIMP but break the on-canvas dialogs (clicking the widgets in them don't work or is pass-through). See bug 791689.
Ok it looks like disabling on-canvas dialogs will not happen for 2.10, after various discussions in mailing list and IRC. Basically what needs to happen is for the on-canvas dialogs to be: (1) easily repositionnable on canvas (2) put out of the way (disappear) and easily reappear on demand. Point (2), hiding, is already possible but cancels the tool operation in progress so that's not good. We need to be able to hide the on-canvas dialog while still seeing the preview of a transformation (which is exactly the reason we hid the dialog for). I am rewording the title and removing the 2.10 blocker, because such an improvement won't likely happen for 2.10 but may happen for a 2.10.x.
Oh and also the detaching feature should be revertable (right now the only way to re-attach a dialog to canvas is to change tool and come back) and also sticky: if someone wants to always have the dialog detached, one does not want to always have to click the detach button every time you pick a tool.
Re-attaching is a matter of one function call. but I could not find a nice generic place in the dialog to put a button. Also, we need proper "detach" and "attach" icons...
(In reply to Michael Natterer from comment #10) > Re-attaching is a matter of one function call. but I could not find > a nice generic place in the dialog to put a button. What if we simply reattached when one closed the dialog (hit the cross icon, or whatever the window manager uses as GUI to close a window)? I mean, right now, it just cancels any operation in-progress. We already have a button for this, as well as the "Esc" key. > Also, we need proper "detach" and "attach" icons... Indeed.
(In reply to Michael Natterer from comment #10) > Re-attaching is a matter of one function call. but I could not find > a nice generic place in the dialog to put a button. > > Also, we need proper "detach" and "attach" icons... We now have proper "gimp-detach" and "gimp-attach" icons with dedicated icons, as of today.
commit a542bb1e8fbbd9fc1d09ce198ec586042a59a573 Author: Aryeom Han <aryeom@girinstud.io> Date: Sat Feb 24 00:53:03 2018 +0100 icons: new symbolic icons gimp-attach and gimp-detach. These are simple on purpose since the smaller size they are displayed at is 12 px (in overlay dialogs) so it needs to be simple shapes. Note by Jehan: gimpicons.h and Makefile.am not updated yet. Waiting for the color icons first. commit 7d354e8aa3fa4698aa0800e92f9aa3b5fdf425bd Author: Aryeom Han <aryeom@girinstud.io> Date: Sat Feb 24 01:04:06 2018 +0100 icons: now color version for gimp-attach and gimp-detach. commit 6a9c4f8ef1309c41fc35c2446c269ab9bf5f4adf (HEAD -> master, origin/master, origin/HEAD) Author: Jehan <jehan@girinstud.io> Date: Sat Feb 24 01:27:56 2018 +0100 icons, libgimpwidgets: now with proper gimp-attach + gimp-detach icons. "gimp-detach" does not just use "gtk-convert" anymore and has its own design. As for "gimp-attach", this is not used anywhere (yet), but it could be soon as reverse action of gimp-detach. For instance, this icon can be used for bug 791859 when we implement re-attaching overlay dialogs.
Yay, thanks, will patch things up over the weekend :)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1262.