Welcome!
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.
Wish list for next release
-
I know that it already asked tens of times, and @omz noticed, and know. But I also want to add that I'm interested in
scipy scikit-learn pandas
modules.And thank you for your great work.
-
Currently, the rootview controller has three gestures, but no gesture delegate implementing
gestureRecognizer:shouldBeRequiredToFailByGestureRecognizer:
When presenting in a
panel
, this sometimes means gestures are stolen from the view being presented.This can partly be prevented by implementing one's own delegate for panel views that prevents simultaneous recognization from the rootview recognizers, however sometimes the system sends the gestures first to the rootview. An example is when implementing a pinch/pannable view, that makes use of transforms, and also has the ability to do single finger panning (drawing).
All works fine, until the view is zoomed such that it is larger than the rootview... then suddenly the rootview gets first crack at the gestures, and greedily accepts them to pan back to the editor.
The ideal situation: the root view controller should implement
gestureRecognizer:shouldBeRequiredToFailByGestureRecognizer:
, and check if the other gesture recognizer is from a view inside a tab (if so, fail the rootview's gestures). Well, any approach that allows ui.View's presented in panels to get first crack at touch events (the abive approach is what I plan to swizzle into place, but it just seems very wrong)This makes it impossible to design reliable ui's intended to live in a panel. the user can always swipe from the title bar...
-
Hi there,
I share my point of view here, in my specific context : Dummy in Python starting with Pythonista.
During the last weeks, I started a little game project to get more familiar with Python, and here are the most wanted features I have :-
Communication between dev. target machine (iPhone, iPad, ...) and a desktop machine (Mac). This will extend drastically the quality of development environment, especially for long script, but also will help to integrate your own graphics, music, in an easy way. This can be :
- Direct link using a specific app on desk machine to communicate with Pythonista app on target machine.
- Pythonista "emulator" on desktop machine / specific setup to be able to write and run scriptes directly on the desktop machine and simulating the target one
- Integration of the DropBox Sync script in the native tools given with Pythonista + an "how to" in documentation.
- Active version of the DropBox guy, with no run to do to synch (speed up dev process)
-
More and more code samples in the reference documentation. Even if the documentation is really well done, dummies need help and as much examples as possible.
-
iAd module easy to use in Pythonista (apple advertising in apps or equivalent). This will help a lot developers to make money with their Pythonista projects, and then probably bring a lot more projects under this platform.
I admit that's a Christmas list :)
Thanks, -
-
@BillBaroude , this is not an answer directly. Not sure you have seen this repository or not. Has a lot of great Pythonista tools etc...
http://pythonista-tools.github.io/Pythonista-Tools/index.html@omz, maybe a good idea to expand the sticky post here to say something like Pythonista resources and include the Pythonista Tools Repo as a link also?
-
Bill, you will find a number of dropbox sync tools if you search the forums or Pythonista-Tools. Other working solutions right now are stash, which includes a workng git client, as well as scp, ftp, as well as a new command in the dev branch (i forget the name) which lets you "mount" things like dropbox repos. Ole cannot include a full sync capability due to app store rules regarding executable code, so homegrown tools are the best solution.
-
ui.Path.rounded_rect , I am having difficulty to make a recipe that can deal with the 3 built in shapes (rect/oval/rounded_rect) generically. I mean without a test.
I assume there is a "Python way to do this. But I can't figure it out.
I posted here because, it still seems like there must be a better way to natively handle these Params. Eg, rect and oval get a corner_radius param that basically is a no op. As I said before, I don't look at objc stuff yet. But as I start to put it together in my head, I start to understand that most if not all these API calls are mimicking the objective c calls. Anyway, it would be nice if it could be rationalized some how.
My small example is below. Is only a test case. Maybe I would like to pass the base class instead of a index.class MyShape(object): shapes = [ui.Path.rect, ui.Path.oval, ui.Path.rounded_rect] def __init__(self, r = ui.Rect(0, 0, 100, 100), shape_index = 0, *args, **kwargs): self.r = r self.radius = 6 shape = self.shapes[shape_index] if shape_index == 2: # rounded rect self.shape = shape(*r, self.radius) else: self.shape = shape(*r) def draw_me(self): with ui.GState(): ui.set_color('yellow') self.shape.fill()
-
This may sound a little stupid. But I would love to see a run button incorporated into the Pythonista part of the keyboard. On a iPad Pro, the run button is quite far away. Also with my bad eyesight I often end up hitting a editor tab or its close button quite often. Not sure you need to have bad eyesight for this to happen.
On the iPad Air 2, this wasn't an issue -
Wasn't sure if this Thread was dead or not. But will write here anyway.
@omz, what would be really really and more really cool would to be able to use the drawing functions such as ui.Path etc to draw into Custom Views inside a pyui file. The code/commands could possibly live In dict style construct inside the custom attributes, whist still being able to the custom attribute fields for custom attributes. So the idea is that drawing Cmds would be both executed in the designer as well as runtime.
This would be great for making user controls, like a radio button for example. Of course the custom attributes a huge benefit, already having a built in mechanism to handle state etc.I am sure a more grandiose implementation could be done. But this in its self would be great.
I know, we can implement all this now all except the rendering inside the Designer. For me, I think this type of extensibility is huge.
My fingers are crossed 😇😇 -
I agree it would be nice to show what a custom view looks like in the ui editor, but I don't see how that could work unless the custom view was instantiated as a live object. Most useful
draw
methods, I think, depend in some way on the instance properties. How would the UI editor know which class to instantiate? (custom view class names are not in scope until runtime).I guess what you are suggesting is the ability to set some preview draw code or image. For instance maybe you'd copy your draw code, replacing any self.property's with hard coded values, so the preview would show a sort of generic instance, like the way tableview is shown
You would need to add that custom code at the top level pyui, not your custom view....
Perhaps if there was a "CustomView Library", sort of a snippet manager for the UI editor, where you could define commonly used custom views (size, colors, preview, CustomView, custom dict, etc)
-
@JonB , I am sort of guessing now. I am not 100% sure. But let's say you could put code somewhere, like the Custom Attributes. Some code that looks like a dict or whatever. As an example I put in the pic below.
So let's say the rule is for user drawn controls, locals are not allowed. The code/function defined has no parent. It's just a function. This is where it gets fuzzy for me. I am not sure how you add that text function. Possibly just a exec. Maybe some of the libs like functools. Not sure. But of course the approach needs to be generic so that the ui.View knows how to call it, if it's present. I am sure it can be done. Well pretty sure.
This would be a big break through.
-
If you are thinking that this code would be used when actually presenting, I think the utility will end up being very limited. Most cases for a custom class I can think of need to use instance properties to decide what to draw.
Keep in mind, the ui editor does not load pyui's. It lets you type a name of a class which might not currently exist until runtime.
-
[Edit] This was implemented in version 2.1 and on Pythonista 3. Thanks omz team :)
In the Console window, when I copy a long line from the history, and type something at the start of the line, the part I am typing now is hidden in the left part of the input field. Could you update the app so that the place where I am typing (in other words, around the place of the cursor) is always displayed? Thanks.
-
@omz, I realize this will be not high on the todo list. But would be nice if you extended themes to dialogs.
Eg...def show_about_dialog(): dialogs.list_dialog(items = ['one', 'two'], theme_name = 'Cool Glow')
-
This post is deleted! -
would love to see editor code folding
screen realestate on an idevice is precious
folding would help maximize this -
same code folding, along with vertex shaders in scene and opencv