I was messing around on a drawing app that I have earlier today, and thought to myself, "I bet I could make my own view for simplistic drawing in Pythonista using the ui module." Okay, maybe not that precise, but I was sure I could make something that would make it easy for anyone making their own apps that require drawing capabilities.
After hours of nonstop work, I have got the first edition of the product ready to go.
The reason this took hours was because I needed to go through and learn how to do all of the stuff with ui.Path and all of that individually, right on the spot during its development. If I already knew how everything else worked already, it probably wouldn't have taken as long.
@AtomBombed , thanks for sharing. Not sure if you have an Apple Pencil or not. I did the below with the Apple Pencil. It's a little jerky, gets a little better if I avoid my palm touching the screen when writing. Anyway,must wanted to give you some feedback
@Phuket2 no, I do not have an Apple Pencil sadly. Nor do I have an iPad Pro. But the reason it gets jerky is because the way it operates is by taking each stroke, and adding it to an image, and saves it. Then the next stroke comes along and overlays the old image to create a new one. It's a laggy process which I'm going to eventually patch later on.
I made a little UI application that takes advantage of this cool new drawing view. It currently only works successfully for iPad 4 as far as I know. There are some problems with the cross-device mathematics that resize everything to fit the user's screen, no matter the device. But obviously it doesn't quite work yet.
You can go check it out here.
You might want to take a look at the Sketch.py in the Examples/USer Interface folder in the Pythonista app. you should create the image on touch_ended, rather than touch_moved. touch_moved can be called at least 20-30 times per second, while touch_ended is probably called once every few seconds (when the user lifts his finger)
@AtomBombed
This is awesome. Thanks!
@AtomBombed Have you looked into doing this with a ui.Path? That could be cool, and also much more performant because it's native code (a thin wrapper around UIBezierPath)
It is done with ui.Path. Unless you're getting at something else... @Webmaster4o
New version of my drawing app (which uses Paper to draw with) is out for iPad. It should work for iPhone as well, but it's optimized for iPad. It's programmed to resize to fit any screen size, but some may not work as well as others due to smaller devices only being able to have drawings that are as big as their screen. This is a problem that I'm working to fix soon.
The biggest change is the fact that changing colors from the toolbar no longer gives you a boring dialogs.list_dialog. It's now a horizontally-scrolling color palette which shows previews of the color itself.
You can check it out here.
@AtomBombed But you said it renders an Image for every stroke. Why not use the draw method to stroke the path?
similar to the sketch.py example, drawing ui.Paths get bogged down if they are hundreds or thousands of points long. or, if you are drawing many paths. creating an image on touch_ended is an efficient approach (But not touch_moved... that's crazy). Another approach might be to have two layers, one which draws the current path, but then touch_ended moves the current path to a separate view, which is only redrawn on touch_ended.
@JonB yeah I'm working on various improvements.
@JonB That would make erasing hugely impractical if @AtomBombed decided to do it later.
@AtomBombed I'd suggest using that math you'll never need to use to approximate Bézier Curves from what the user draws, and chaining those together. You could also look to simplify long, straight line sections to a single line. This may not be easily possible, though, UIBezierPaths are quite rigid.
@Webmaster4o I am not following you... once it is an image, you could erase in PIL, or by drawing the background color over top.
It comes down to whether you are trying to simulate a "paint" program, (thnk photoshop "paintbrush tool") or a vector program, like illustrator (or photoshop path tool). if the goal is to have a vector program, you don't "draw" them, you would add control points. If the goal is a paint tool, you might want to store the last few operation to facilitate undo, but at some point you end up with pixels on the screen, not paths with 1000s of points.