• JonB

    I did a somewhat convincing search bar in my objc_browser.py in objc_hacks repo.

    using:

    • a container view (gray bg color), 320x420
      ** subview: textfield, frame=(20,4,280,32) to center it up in the larger frame, corner radius 16, border color 0,0,0, bg color slightly off white, and placeholder='\U0001F50E Search'
      with a delegate that looked like:
        def textfield_did_change(self,textfield):
            self.filter=textfield.text.lower()
            self.filtereditems=[x for x in self.items if self.filter in x.lower()]
            self.tv.reload()
    

    Well, probably best just to go look at the code...

    I have in my half finished projects a wrapper that implements a UISearchController in objc_util, but this isnt quite finished(it displays, but is not functional).

    you might also look at the blackmamba code -- i feel like this is something @zrzka may have done already.

    posted in Pythonista read more
  • JonB

    Scrollviews are just container views that contain subviews.
    You use add_subview to add stuff to a scroll view (usually will be a single view that is larger than the scrollview.
    You then use content_size to set the scrollable region -- usually would be the size of your subview. When content_size is larger than the scrollview frame, it will allow scrolling.

    Note that both TableView and TextView are actually subclasses of ScrollView, so if you are just doing tabular or textual work, you don't need scrollview per se, but can still implement some of the delegate methods.

    posted in Pythonista read more
  • JonB

    I never realized you could use unicode in python variable names... makes sense, but didnt realize that was true.

    Since unicode has combining diacritics, you could actually make a floating math keyboard that insers the special characters -- so you could add dots, arrows, subscripts, etc:

    Ḃᵧ=1

    posted in Pythonista read more
  • JonB

    sounds like you are using ssh?
    how did you create and link the keys?

    posted in Pythonista read more
  • JonB

    I would suggest that the accessory/select actions be @ui.in_backgrounded, so that control returns to the main thread and those functions exit.
    list_dialog might then need to be on_main_thread'd, not sure -- or maybe if you need the result, you would call another function...
    i.e

    def another_function():
       result=list_dialog('test-3',items=['test3'])
       do_something(result)
    
    @ui.in_background
    def accessory_action(sender)
       another_function()
    
    @on_main_thread
    def list_dialog(...
    

    You could consider refactoring so that a callback function is called, rather than using wait_modal.
    A third option, is to use navigatinviews, and push a new dialog into the nav view.

    I suspect there are problems when you have multiple nested wait_modals.

    posted in Pythonista read more
  • JonB

    if you search the forums for dropbox api v2, or anything dropbox related in the last 6 months or so,myou should find several options that replace the depreciated dropbox module.

    posted in Pythonista read more
  • JonB

    Basically, there are two threads

    1. The main thread, or ui thread
    2. The interpreter thread
      plus 3) Any threads you create with threading

    Any ui callbacks, like layout, update, button actions, delegate methods, etc, are called on the main/ui thread. Nothing interrupts the ui/main loop, so any long calculations will make the app unresponsive. The main thread has a queue of operations it is executing -- touch events add callbacks to this queue. So does on_main_thread.

    The interpreter thread is basically a background thread. ui.in_background lets you run long calcs that would have been in th ui thread in the background thread instead. It too only runs one thing at a time, but can be interrupted by the main thread whenever events happen. The interpeter thread also has a queue of operations -- it starts with the current script being "played". ui.in_background is the way to append things to this background queue -- the name can be a bit misleading, since it is the background to the ui thread, but would be done after anything already in the interpreter queue.

    Any other threads you create share time with the interpreter thread.

    A way to think about this all is to imagine a hard loop.
    First, sequentially run operations in the main queue, which are put there either by the OS ir by calling on_main_thread
    Then, give a little time to each background thread. Operations are queued up into the first background thread by either pressing play, typing commands in the console, or by ui.in_background, while other background threads just run to completion.

    while True:
        for operation in main_queue:
            operation.run()
        for t in local_threads:
            t.run_for_5_msec()
    

    posted in Pythonista read more

Internal error.

Oops! Looks like something went wrong!