SUMMARY When use a brush, line, curve either other tool with snapping to the guides, while guides are visible they are wants to be moved over the canvas, against snapping to it. STEPS TO REPRODUCE 1. Set View->Snap->Snap to guides 2. Set View->Show guides 3. Add two or more guides 4. Select line tool 5. Try to draw a line with snapping to the guide OBSERVED RESULT Can't snap to the guide, selecting and move the guide otherwise. EXPECTED RESULT Guides must be moved only with move tool, like Adobe Photoshop or GIMP. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Hi, Olga! Here is a special switch View->Lock Guides, which locks guides so they are not movable anymore. I guess it works the same way both, in PS and Gimp. Isn't it?
Created attachment 129071 [details] Guides in Gimp and Krita differences
No, it's wrong. Tge existing guide most not interact with other tools than move tool, and intersection of guides must to be mover too, when selected with move tool (both intersected guides are moving).
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
My vision of this problem, and several methods of solving for the best user experience, locking guides or switching to gimp/photoshops method are not correct by the Krita main ideology and design. The issue appears when you working with all tools without left mouse button (stylus pressure or a finger touch event) pressed. In this case guide selects immediately and prevents to drawing at this place, even snap to this guide. The most awful UX example is drawing with Polyline, Polygon, or Bezier Curve tool. There are three possible solutions to workaround this issue: The first - we are may limit tools, that can select the guides for the moving purposes, for example Select shapes, Edit Shapes, Move and Zoom tools (such as Inkscape does). The second - will be adding a small delay (for example 300ms) after activating guide in case of mouse hover event, but this solution are not perfect at all, and dissolves other user experience. The third possible solution - to disable selecting guides when tool are in active state (in the process of drawing, or selecting next point) without left button pressed. This solution was solved issue, but not in the cases when you must start drawing with snapping to the guide. This method can be combined with the second solution for the best effort. I may try to implement any of above solutions and contribute this patch to the upstream, if it will be needed by the developer community. Best regards, Ivan Batalin.
Hi, Ivan! I had a talk with Olga in VK and she said that "Lock Guides" option solves her problem. Is your comment still valid? Concerning your proposals, I think it might be useful to limit guides modifications to the Shape Move tool only. Though this solution is rather disputable and we would have to ask painters if they want such behavior. Technically, the relevant parts of the code are in: 1) KoRuler::mousePressEvent() 2) class KisGuidesManager 3) class DefaultTool Here is the most up-to-date guide for building Krita on Windows: https://invent.kde.org/snippets/877
Hi, Dmitry! Yes this problem a take in place. Thank you for hinting to code snippets for the review. As at last 15yeas I was using Linux at home and work, I'll try to build Krita in chroot sandbox by the official documentation: https://docs.krita.org/en/untranslatable_pages/building_krita.html
Hi, Ivan! On Linux, if you have not-very-modern Intel GPU or NVidia GPU you can use the docker for building, it will save you a lot of time: https://invent.kde.org/dkazakov/krita-docker-env I will downgrade this bug to a wish: WISHGROUP: Small Usability Fixes
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!