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
-
-
@omz Improvement suggestion -> iPad UI editor persistent controls panel state across sub views /maybe files
What I mean by the above is that currently the view detail panel to the right of the UI layout area currently does not persist across sub views. For example, If I expand the "Auto-resizing / Flex" panel on one sub view and then switch to another one, it's collapsed again. It's also collapsed again if I switch back to the sub view for which I expanded it. I think it would be useful to have all collapsed/expanded panel states persevere across subviews, and possibly even across pyui files...
Another thing -> in the current 3 beta, the new floating traceback view seems to only sometimes want to list the trace backs... Pythonista 2 seems to have the full traceback for the same scripts. Also, when the correct trace backs are listed, there's no way to jump to the appropriate file on iPad Pro....while the floating view of that file is nice, it would be great if there was also a way to jump to the actual file in full screen editing mode.
-
+1 for a debugger.post_mortem(), and also moving along stack should open the appropriate file ( or long tap to open, etc)
-
Please fix string.maketrans() method. It not working at all. Thanks.
-
@craftmojo See my response in your other thread, this is not a bug in Pythonista.
-
Thanks for fast responses. Now, it worked :)
-
suggestion: adjustable line height for fonts (especially useful for those on smaller devices). Sometimes text size alone isn't enough to optimize for the screen size.
-
@omz one more suggestion regarding line numbers on different device sizes. What if you had line numbers be an optional toggle on all devices, with sane defaults in place. In fact, I'd love to be able to turn it off temporarily on an iPad Pro. And besides that way maybe you'd be recycling code anyways?
-
Yes, it would be nice if all device specific ( as opposed to crrent size specific) settings were togglable, to facilitate cross-app development.
-
In the ui designer, ability to change the font name of the ui.Table object rows.
Also, would be great if for the CUSTOM ATTRIBUTES panel, if this could be done in a pop up window (ui.View) and better still if that view subclassed the editor so that you had a full editor in the ui.View. Not a ui.TextField which is pretty clunky to type into compared to the editor. Not critical, but I think would be a big enhancement -
@omz Suggestion: simple built in sqlite3 viewer. When you go to a SQLite 3 db file in the Pythonista file browser, it would be great if instead of just showing a large icon and open in, it showed the contents. Would be useful as a quick reference while developing...remove friction for just quickly checking a result.
-
@Tizzy , I am doing some things in sqlite3 at the moment. Not trying to be smart, but seems like a unreasonable request. A SQLite browser is a full app. I use SQLed App to open the Sqlite3 databases. It shows up in the share sheet , when you click the "open in..." button from the file browser page. Maybe I misunderstood your request. I am at the moment trying to make some generic classes to give info of the database as well as the data for a given table. But will be nothing like an app intended for this purpose. Anyway, maybe you had something else in mind. Would like to hear about it as I am still trying to work out what to display. Which tables, Pragms, record counts etc... A lot of info
-
@Tizzy , hmmm funny, I just shafted myself. Was not connected to my comment, I was just doing this anyway. Both @JonB and @ccc have warned me in the past about using del in classes 😱 I was calling my SQLite wrapper that contains a del in a ui.tableView. Got the below 😂
I always have to learn the hard way.🤐
Just seemed relevant somehow. And it just happened. Sorry I digress. -
CREATE TABLE IF NOT EXISTS Junk
That command is 100% guaranteed to be a no-op in my Pythonista.
:P
-
@dgelessus 😱😱😱
Now it's not easy for me. I can get it to work by using the @on_main_thread decorator with my custom class.
I sort of know why, but not really. So I think I can solve the problem but without understanding exactly why it's solved. I have to live and learn 😱😱😱 -
@cook
Yes, I know it can be done with the objc_utils, and that's what I'll be using. It just seems like the sort of thing that would be useful in a standard library, and as the speech library already sets up all the listeners etc to queue up multiple lines, it feels slightly like reinventing the wheel to write my own library. -
@omz feature suggestion - text resizing in the documentation viewer - especially useful in conjunction with the newish console/docs sidebar-pinning.
Bonus points: keyboard commands to resize (command +, command - ???)
-
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, -