Check out the cmd module. It makes it very easy to write interactive command-line programs.

Excellent, that seems to have me up and running again. Thanks.

Must be fallout from Python 3 having better support for Unicode and other character encodings.

Just bought and installed Pythonista 3, and the first thing I'm trying to do is move over the usual Dropbox sync script. I ran both dropboxlogin.py and dropboxsync.py through the 2to3 converter (which mostly just cleaned up print statements), and now I get this error from dropboxlogin.py:

[401] 'Request token not found.'

This is from line 34, request_token = get_request_token(). Did something in the Dropbox API change in P3, and does dropboxlogin.py need to be updated accordingly? Peeking at the locals in the exception window shows that "request_token" on the DropboxSession object is "None".

Do you mean take a .pyui file and "decompile" it into a .py module that produces the same effect? (Like the .designer.cs files that you get with .NET WinForms.)

I was playing around with that idea a bit, but didn't get too far with it, as it seems a lot of the object property names on the UI classes differ from what's serialized into the JSON .pyui files. Feel free to play around with this and improve on it, though.

https://gist.github.com/dave-britten/5b2d1c66f5fc042a6b2c

Check out the cmd module. It makes it very easy to write interactive command-line programs.

@JonB said:

also, keep in mind that the screen size is orientation dependant.

you can also use convert_rect to convert betwen screen coords and the scrollview frame. That way, you shouldnt need to worry about screen size or orientation at all.
when you present as a panel, or some other types, the top of your view is not the top of the screen.
convert_point or convert_rect take care of that for you -- although in 1.5 it was broken for full_screen. Use None for the from view.

Seems to be working more or less as intended on my iPad, but I'm getting pretty weird numbers (mostly for the y coordinate) out of my iPhone where it runs in full screen. Is there a way to check at run-time how a view is presented (sheet vs. full-screen) so I can either pass the view or None as appropriate when calling convert_rect?

This seems kind of on the right track, but I'm obviously doing some things wrong with the sizing. Functionally, it's behaving more or less how I want, but the scroll distances aren't being calculated properly.

import ui

#Get current screen size, taking orientation into account.
def screen_size():
	size = ui.get_screen_size()
	if int(ui.WebView().eval_js('window.orientation')) % 180 != 0:
		return (size[1], size[0])
	return size

class DynamicScrollViewTest (ui.View):
	def __init__(self):
		self.frame = (0, 0, 320, 504)
		sv = self.scroll_view = ui.ScrollView()
		self.add_subview(sv)
		sv.frame = self.bounds
		print "self.frame: " + str(self.frame)
		print "scroll_view.frame: " + str(sv.frame)
		sv.content_size = (320, 504)
		sv.flex = "wh"
		sv.background_color = "silver"
		self.fields = []
		for i in range(13):
			field = ui.TextField(frame=(6, 10 + 42 * i, 308, 32))
			field.placeholder = "Field " + str(i + 1)
			field.flex = "w"
			sv.add_subview(field)
			self.fields.append(field)
		
	def keyboard_frame_will_change(self, frame):
		print("Keyboard frame: " + str(frame))
		print("Window frame: " + str(main_form.frame))
		screen = screen_size()
		print("Screen size: {} x {}".format(screen[0], screen[1]))
		y_overlap = max([main_form.frame[1] + main_form.frame[3] + frame[1] - screen[1], 0])
		print("Y Overlap: " + str(y_overlap))
		self.scroll_view.content_inset = (0, 0, y_overlap, 0)

main_form = DynamicScrollViewTest()
main_form.present("sheet")

Awesome, thanks for the samples. That should give me a push in the right direction. I'll do some more experimenting and see where I can go from there. I'm presenting the form as "sheet" so it shows up as a nice popup window on the iPad, so I'm guessing I can just change the window dimensions on the fly and let the scroll view deal with its larger content area.

@ccc said:

Can you use these techniques to achieve what you want or do you really need editable text fields underneath where the onscreen keyboard will pop up? If your editable fields could be above the keyboard and uneditable results could be underneath the keyboard then when it is time to show the results, you could use the techniques above to hide the keyboard.

Might be possible in this particular case, but I can see a need for having more fields in the future if I think of other things I want it to do, and having nice, tall text areas is a plus when mucking with multi-line regexes. If I shrink the main input textarea, I could probably keep the other inputs above the keyboard. Of course, keyboard size isn't always the same, depending on what keyboard you're using, whether prediction is on, etc. I'll probably do that for now as a stop-gap, but having the form scrollable would be the ideal solution.

Here's a couple screenshots of what happens when you try to enter text in the replacement field (the one with '28' in it).

I've been dabbling with Pythonista on my iPad, and I put together a little regex testing tool (much like the .NET one I made for my Windows dev machine) using the ui module. It's just a single form with some fields on it. The obvious problem is that the touch keyboard pops up and obscures the bottom half of the form. Works fine when I'm running with my bluetooth keyboard on my iPad, not so much on my iPhone.

I'm pretty sure I need to use a scroll view and dynamically resize either the scroll view or the window itself, but I'm not quite sure how to put all the pieces together for that. I figure I need to subclass View so I can handle keyboard_frame_did_change.

Anybody have any good sample code for a form that's got a handful of fields on it, and which shrinks/allows scrolling when the keyboard gets in the way?

Related question: In the UI designer, is it possible to move existing controls into/out of the subview of a scroll view? I don't see any obvious cut/paste operation.