This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
Paper for UIs
@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)
chriswilson last edited by
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
It is done with
ui.Path. Unless you're getting at something else... @Webmaster4o
AtomBombed last edited by AtomBombed
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
drawmethod 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.