Some changes to make creating an editing text objects easier to use. It is a bit hard to explain these changes, so I made a video explaining what I changed.
Details
Details
Diff Detail
Diff Detail
- Repository
- R37 Krita
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Comment Actions
Hi, @scottpetrovic!
I do really love the idea of your patch. The UIX looks very natural and convenient. Though there are a few bugs that should be fixed before merging that into master:
- [disputable] When creating a text shape with the text tool, the text editing dialog has two buttons: OK and Cancel. I would expect that pressing "Cancel" button would cancel creation of the shape. But in the current version of the patch it doesn't.
- [major] When dragging the shape on the canvas the new button interferes into the process. If you start the drag by clicking of the "T" button, the drag starts, but when you release the mouse button, the text editing dialog will fire up. That looks naughty :)
- [major] When running on non-hidpi display the button overlaps the test handles when zoomed out. It looks like you use wrong coordinate system for painting the icon. Please use KisHandlePainterHelper and its internal coordinate systems for painting it. Don't try to paint it manually :)
- [blocker] Auto-updates and a really nice feature, but it needs special handling, otherwise we UI may freeze easily. Just try to create an image 8000x8000 and add a full-canvas text. UI will become unusable. Two things are needed to overcome that:
- Auto-update signal should be connected via KisSignalCompressor (or KisSignalCompressorWithParam) and the updates should be limited to something like "once in 300ms"
- GUI should not wait for the canvas to update. Right now it looks like there is some image->barrierLock() somewhere...
Comment Actions
@dkazakov I updated all the points except the one that is disputable. I also don't see any type of image barrier locking dealing with that code, so I didn't do anything regarding that. Maybe I am not looking in the right location.
I think the disputable point is ok for now. I think people will need to play around with this new UX pattern a bit more before we can make further UX changes. People seemed to like how it worked in my video so I think it is good for a first pass.
Let me know if you see anything else.
Comment Actions
Hi, @scottpetrovic!
I have tested your branch. There are still a few issues :(
- The button offset problem is fixed, but there is some issue with rendering of the border of the button:
It looks like it still renders with some scale (though it shouldn't) and the border gets truncated dues to nearest neighbor filtering.
- Editing text on big images still blocks the GUI, so it becomes almost unusable. I can have a look at the code and check why it happens, please ping me on IRC
Comment Actions
I think the live text editing needs a bit more thinking and work, so I am completely removing that code from this patch.
This patch now just includes that text UX changes for entering and exiting text edit mode with the "T" GUI button on vector text objects.
Comment Actions
I just pushed it out to master. If there are issues with it, it is all in one patch -- so it would be easy to revert.
I think Dmitry has to approve it before i can mark this patch as "shipped" and closed since he is a reviewer.