• Thanks a lot @dgelessus ! One cannot ask for a better answer!

  • I reported that for Pythonista 2 and it was fixed for the Pythonista 2 beta.

    But this time it is for Pythonista 3's python 2 interpreter. Sorry if this caused any confusion.

  • @ywangd, no problems I understand. The main reason to bring it up is mainly a support issue. I have used the autocorrect buttons a few times. And something fails, like selfupdate. But it didn't really fail, just got some strange input. Easy to jump to the conclusion that stash is not working.

    Edit-Great to see @omz gave a way forward

  • @ywangd yes in regards to the dependencies. in the previous version it wouldn't even prompt you it just started downloading. This one it asks first. Good call.

  • Thanks @omz The pattern seems reasonable to follow.

  • @JonB, not exactly what we were talking about, but same idea would apply.
    JPeg lockdown: Restriction options sought by committee
    http://www.bbc.co.uk/news/technology-34538705
    With a well thought out universal file header, all sorts of benefits could be gained and implemented reasonably easily. But now a the JPEG committee will spend a lot of time trying to solve a problem for only one file format. I think the issue they are trying to take here and other issues should be addressed across the whole spectrum of files.
    I know is an old discussion we had, but seen this article today and instantly reminded me of our discussion here

  • Thanks @omz The workaround works.

  • Yeah, I think the console could use more features of the full editor. For example, auto bracketing, where [ becomes [], and auto-indent for the next line after a colon.

  • Also on current beta, no label will appear in a full_screen view.

    import ui label = ui.Label() label.text = 'Hello World!' label.present() # works with 'sheet', 'popover', 'panel', but not with 'full_screen'

    I can add label.text_color = 'blue' to get the text to appear in full screen mode but that trick does not work if I create a ui.DatePicker instead of a ui.Label.

  • @omz
    I wonder whether this could be a **permission ** issue which prevents the library file being loaded by PyDLL?

    In 1.5, we can access the Pythonista.app folder alongside with the Documents folder. But it is no longer there in 1.6. Presumably this folder is where the library file (e.g. libpython.dylib) resides. Is this something worth to look at? Again I am no expert and could be very wrong. Please bear with me.

    My intention is to use this API for better thread management in StaSh so that a worker thread can be interupted/stopped by user from the UI thread.

  • Has anyone tried personal hotspot tethering with Bluetooth? That’s the way I used to do it until my data plan changed and I didn’t have the ability to host a hotspot.

  • @omz: Thanks. If I am reading this right, I need to go back and decorate some gesture-adding functions.

  • Thanks everyone.

    @omz Yes the ui.measure_string is bugged in 1.5. Luckily I do have the beta.

  • @FarmerPaco StaSh v0.7.0 made some change to the selfupdate mechanism. To update from v.0.6.19 to v0.7.0, please use selfupdate -f to skip the version check.

  • You might try requesting access
    https://docs.google.com/forms/d/1ikwuxcIEj7LrOaZHaENJ0eHmhS5p7H8Fmyl_70p_Yo0/viewform

    The current beta version expires in 25 days (I just noticed 160016 was posted) -- I think he likes to send out invites in batches corresponding with new versions, assuming there is room left.

  • To download a single file, use wget. Use the -o option to specify the destination file name, otherwise it will download to the clipboard:

    wget http://www.example.com/path/to/file -o file.py
  • I have a few wacky ideas on this.

    TextView inside of a scrollview.

    textview_did_change_selection or textview_should_change would use ui.measure_string (which has to be inside a drawing context as i recall) to figure out the width of text before the cursor, and then would adjust the scrollview's content_offset to keep the cursor on screen.

    My initial thought was to compute this on the fly, which might be insanely slow, since you'd be calling measure_string each and every keystroke, but I've been surprised at the speed of the built in drawing functions. Also, since you're using a monospace font, just compute the character width once during startup (maybe compute the average character width for a string containing all of the alpha numeric, uppercase, punctuation that are typical, so that even proportional fonts would be approximately correct).
    Then, your textview_should_change simply grabs selected_range[1], multiplies by the character width, and then adjusts the offset to leave a certain amount of gap.

    You could instead use an HTML input field controlled with javascript inside a WebView. This has the advantage of being very customizable, but the disadvantage of being javascript, and debugging javascript within pythonista is akin to trying to program using only a typewriter.

    I've been long considering trying to create a fully custom ui.View that acts similar to a textfield. touch_began would focus a hidden textview, to accept keystrokes and in particular backspaces. This would require implementing customized timers to implement gestures for the ui events (long tap to bring up a copy/paste dialog, double tap to select words, dragging selection boundaries, etc). The deal breaker would probably be that as soon as you touch anywhere, the keyboard might try to disappear, thinking input has ended.

  • Thanks!
    Just realised it is in fact documented ...

Internal error.

Oops! Looks like something went wrong!