GNOME Bugzilla – Bug 708124
Paths should be visible by default
Last modified: 2018-05-24 13:52:07 UTC
This is bad because I did not know where the paths stroke to path is so I went to the menu and it looks like a dialog might open up. Nope, my paths are gone.
We don't maintain 2.6.x anymore. Does the same happen in 2.8.x? And are you sure that the path is set visible in the paths dialog?
The bug is easy to reproduce. Create a path, two points what ever. Then go to the menu "tools" and select path. All of the current paths are removed. ALL of them including the paths on separate images. I recreated the paths that I lost the first time. Then in response to your email I opened a new image to see if I could check the visibility. Created a path and selected "path" from the tool menu. The path on the newly opened window was removed AND the path on the other image was removed.
All the paths I've created when trying to recreate this in 2.8.6 remain with the image, but they are not visible (because paths are set to be invisible). Do you know what the paths dialog is, and how to set the visibility of a path?
No, I thought I could open a "Paths" dialog by selecting paths from the "Tools" menu. The only thing close to a paths dialog is the options below the tools. Since you mentioned it, I went to the menu "Windows", "Dockable Dialog", and "Paths" and you are correct. The paths are still there in the "Paths Dialog."
Maybe this should be an enhancement then. Either A) Not change the visibility of the current path when "path" is selected from the menu or B) Open the paths dialog when paths is selected from the tools menu and the path tool is alread in use. You are completely correct. My paths were still present, and they were present in the saved versions to. I just never found the paths dialog. Thank you.
Bugs with the newcomers keyword should be in state NEW.
Hi, I'd like to give a try on this bug, as a potential first contribution :)
Probably a very good first contribution. We'd have to discuss the proper solution for this first though. Actually I am thinking: why are new paths not visible by default? This is the expected behavior IMO. If I create something new, I expect it to be visible (even though I have the possibility to hide it later on purpose).
@Jehan Great! Do I contact you on IRC or mail? (or anything else)
Kevin > you can always send me an email (https://wiki.gnome.org/JehanPages). That's part of what I accepted as newcomers mentor. But a good bet for the long run is IRC. I'm not connected right now, but most of the devs are hanging there around, and you can always ask things. For the decision about having paths visible by default, I have just sent an email on the gimp-gui mailing list: https://mail.gnome.org/mailman/listinfo/gimp-gui-list
OK, I've subscribed to the mailing list so I'll wait for the answers before asking, until then I will try to change random things in the code for testing :)
Created attachment 336856 [details] [review] Change visibility Here is a proposition of correction :)
Thanks for the patch! :-) I think we will need mitch to come into the discussion. Copy from my last message on gimp-gui: That would be a very good solution IMO. Now there has been some discusion about this on IRC yesterday, and nomis in particular was not into this (for information, nomis is the main author of all things paths-related in GIMP! You can say thank you). His main problem with making paths visible by default is that his main workflow is to make a path very temporarily, for instance to stroke it, then forget about it. So typically he doesn't want them in the way of the image as soon as he is done with it. That makes sense too, especially since GIMP is not a vector editor. So vector usage often stays simple. Now playing more with the paths, I realize the main problem is that when you come back on the path tool, you don't get back control on the paths you were editing just now. It feels like once made, paths are forever gone or non-editable. Actually they are editable, but you have to double-click on the small preview image in the paths dock! This is like completely hidden non-discoverable feature, counter-intuitive and worse it makes path creation non consistent (since clicking the same way on the canvas has different behavior over time). So I think we can get rid of this behavior while still keeping paths invisible by default, and that could satisfy everyone. Here is the proposition: - When no paths exist, the first time you click the canvas with the Paths tool, a path is created. But that's the only time where a path is automatically created. - When paths exist and if the Paths tool is selected, the last active path is shown and editable. Clicking on canvas allows to create new paths points, move points, etc. No new path is created. - To start a new path, you have to explicitly click the "new path" in the dock. This new path gets selected, and you can start editing it directly with the Paths tool. This way, you never have the feeling to "lose" paths since you see at least and always the active one (in the "edit" wireframe way) as soon as you select the Paths tool. But in the same time, as soon as you select another tool, the path preview gets out of your way (unless you set a path visible, which is still not on by default). It feels like a good in-between of all worlds. Of course that's just a proposition which popped-up in my mind during the discussion. It feels good to me right now, but I may miss things and I may be wrong. Counter-propositions are welcome.
If you are working on the path tool you could have a look into bug #300663 too.
Jehan, I've never had the need to double-click anywhere when working with paths. To me, the only issue here is that inactive paths are invisible by default. Can you explain why you need to double-click?
Michael > here are steps. - Click the Paths tool; - Create a path on canvas (path is visible as some kind of wireframe style); - Click any other tool => the path is invisible; - Click the Paths tool again (last created path is still invisible); - Click on canvas => it creates another path! - Open the Paths dock; - Select (single click) your previous path and you can edit it. So to edit an existing path after unselecting then selecting back the paths tool, you *have to* create a new path first? Actually this is where the double click comes in: - Click the Paths tool; - Create a path on canvas (path is visible as some kind of wireframe mode); - Click any other tool => the path is invisible; - Click the Paths tool again (last created path is still invisible); - Open the Paths dock; - Double click your previous path => path is visible (wireframe style) and clicking on canvas now edits the path instead of creating a new one. So yes that feature is completely non-discoverable, and this is why I think it is not good user experience. For most people, the only way possible to edit an existing path seems to be to create a new one (even if you don't need it) first, which is absurd. Double-click is the way out of it, but nobody knows about it. This is why I think by default, clicking on canvas should simply edit the currently selected path (except the first time, when there is none yet), and anyone who wants a new path would simply click explicitly the "Create a new path" button. Basically same as painting on a layer: when you unselect then select back the brush tool, then click on canvas, it does not (fortunately) create a new layer! It paints in the currently selected layer.
Jehan: I never knew about that feature for double-clicking. I just tried and yes it seems pretty obvious that the last selected path should be visible and editable by default. Then we can even remove IMHO this double-clicking feature as it would not be useful anymore :)
Comment on attachment 336856 [details] [review] Change visibility Makring as reviewed as per the comments about it. Remaining is the decision how GIMP should behave.
-- 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/496.