@cvp It's not always though. I posted a counterexample.
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.
Latest posts made by bensaccount
-
RE: Reference for numeric values of ObjC enums?
-
Reference for numeric values of ObjC enums?
The UIKit docs list all of the enums for things like DatePicker style, but not their numeric values. Since we don't have those enums available to us (as far as I can tell), is there any way to look up their values?
They don't seem to line up the way you'd expect- for example, for DatePicker style, the docs list:
UIDatePickerStyleAutomatic A style indicating that the system picks the concrete style based on the current platform and date picker mode. UIDatePickerStyleCompact A style indicating that the date picker displays as a label that when tapped displays a calendar-style editor. UIDatePickerStyleInline A style indicating that the date pickers displays as an inline, editable field. UIDatePickerStyleWheels A style indicating that the date picker displays as a wheel picker.
But when using
setPreferredDatePickerStyle_()
, 1 corresponds to Wheel, 2 corresponds to Compact, and 3 corresponds to Inline.--
Some notes on the DatePicker styles (date only):
- Inline does work (and shows the calendar inline), but you can only set it from the main thread, otherwise you get an ObjC exception. It's much taller than the wheel, approximately 320x310.
- Compact is approximately 80x35 (but its width shrinks with shorter date strings). If you shrink it in the .pyui editor, the date won't be visible there, but it will still work when you run your app.
(also, thanks to cvp for the code to set the style!)
-
RE: Shortcut to run a script located in Working Copy's dir?
@cvp Thanks, looks like we had the same idea. I had just removed the close button, but I have to admit that hiding the title bar is tempting to reclaim some vertical space.
-
RE: Shortcut to run a script located in Working Copy's dir?
Hm, if I add a
will_close
method to my root View, it never gets called, I guess that's only called when you use.close()
.The UIKit docs show a
viewWillDisappear
method for NavigationView, which does show up in__dir()__
for its objc object. Is there any way to set that via Python?My temporary workaround is
hide_close_button=True
, so the app can only shutdown properly. But there's still the problem I mentioned earlier of AppSingleLaunch not working due to the NavigationView not getting cleaned up after closing. (edit: Though it's not a problem if the script always closes down properly) -
RE: Shortcut to run a script located in Working Copy's dir?
I'm running into two problems with @TPO's AppSingleLaunch:
- I'm using a NavigationView as my top-level view, which doesn't have a will_close function. It's immutable, so it won't let me monkey patch one in either. Is there another way to detect when the script is exiting?
- I don't think the forced garbage collection is working. If I close the Python script and re-open it (which doesn't delete the lock file due to issue #1), the id it stores- the NavigationView's id- still exists. Even if I wait a while, gc.collect() won't collect it.
-
RE: Shortcut to run a script located in Working Copy's dir?
@cvp That's handy. So a separate launcher script file isn't needed.
It can still launch multiple times though. I think I'll have to add TPO's util to my app to prevent that.
-
RE: Shortcut to run a script located in Working Copy's dir?
@cvp Thanks, having a launcher script in Pythonista's Documents dir fixes the issue! I think starting another interpreter may be unnecessary though, since I do want the script to run inside Pythonista, and using the same version of Python.
Here's what I ended up using for my launcher script:
dir = '/private/var/mobile/Containers/Shared/AppGroup/......' filename = 'app.py' import sys import os sys.path.append(dir) os.chdir(dir) with open(filename) as f: exec(f.read())
This seems to work fine. And of course this could be altered to take arguments for directory and filename.
I've run into a couple issues with Shortcuts now:
- If I use the Pythonista Run Script shortcut, I have to stop the shortcut manually afterwards, even if Pythonista is closed. Adding "Stop this shortcut" doesn't make a difference. It's not a huge deal, but it may be confusing for the client.
- Pythonista will happily run the script multiple times. Is there any way to tell Pythonista not to do this, or do I need to implement something manually, like a lock file? (Or is there a more reliable way to check if a script is running?)
edit: Ah, I've found TPO's AppSingleLaunch util. Looks like it handles the issues with lock files sticking around when the app doesn't shut down properly, so I may try that.
-
Shortcut to run a script located in Working Copy's dir?
This seems like it should be a simple thing, but after searching through these forums, Googling, and asking ChatGPT, I still came up short.
I'm using Pythonista to run code that's managed by Working Copy, so it's under that app's directory. I'm trying to create a shortcut on the home screen to directly run a script in that directory.
It seems like there's a couple options here- a
pythonista3://
URL opened in Safari with?action=run
, or running Pythonista directly using the Shortcuts app.I've found I can get the full directory path with
os.path.realpath(__file__)
, but everything I try just results in Pythonista opening with no scripts open (if I use the URL), or with the last used script open (if I use the Run Script shortcut). It doesn't try to run anything. When I tried it a couple weeks ago, it would give me error messages about the script not being found, but now I'm not even getting those.ChatGPT suggested using the Wrench in Pythonista, but it gives me the error message "Script Required: You need to open a Python script in order to generate URLs." A script is already open in the editor, so I'm guessing this only works if the script is located in Pythonista's directory.
-
Super minor editor bug (in both 3.3 and 3.4)
[Sorry if there's a minor bug thread somewhere- I didn't see one. I would have put this in the 3.4 thread, but it's not specific to 3.4]
Using (or abusing, as some may argue) triple quotes as an f-string messes up the formatting in the editor. It treats the closing quotes like they're starting quotes.
f""" multi line string """ (code here will look like a comment now)
Not a bit deal, but Python allows this for strings in general, not just for comments.
Just checked this on an old iPad with 3.3 still installed- same behavior there.
-
RE: alert() prompt not visible
@cvp That works, thanks!
Is there any downside to just sticking that decorator on every UI callback that might lead to an alert or a database query? Seems like it would only be a problem if the function blocks the main (non-UI) thread, but that's no worse than blocking the main UI thread.