Hi @Lacajenne
Is it one of the new iPads Pros with bigger screens ? When I remember correctly the current version on the app store is not so compatible with the new screen sizes from the new iPads. A new beta version is already available since late december which fixes this. You could download it, just watch out for the thread about the new Pythonista 3.3 BETA or you have to wait and have a bit patience it should be out sometime soon.

I am just again overwhelmed by this new clean beautiful piece of API creation from @mikael ! Thank you so much for this...

I tested the new BETA build 330012

it still crashes when I use the in 330007 new introduced key_command feature

Pythonista.app completely exists when pressing the 'a' key on the external BT keyboard

# coding: utf-8
import ui
import console

class UIView (ui.View):
    def get_key_commands(self):
        print('get_key_commands')
        return [{'input': 'a'}]
        #return [{'input': 'a', 'modifiers':'cmd'}]
        
    def key_command(self,sender):
        print('key_command='+str(sender))

def main():
    main_view = UIView(frame=(0, 0, 400, 400))
    main_view.name = 'Key Commands Demo'
    
    main_view.present('sheet')
    
if __name__ == '__main__':
    main()

@omz Do you still have some working example code of the new keycommand API ?

EDIT: OMZ wrote me. Although title is optional as written in the documentation, it must be set in the BETA otherwise it crashes.

so the statement

 return [{'input': 'a', 'title': 'a'}]

repairs keycommands for the BETA. It will be fixed in the coming builds...

@mikael I like that .... ;-)

You have to open and select the workingcopy folder in pythonista. It is definitely possible.

Hi @omz ,
if I move the main_view creation into the global scope (i.e. out of the main function) it also crashes.

There is another issue with the newest BETA: When you create a custom view (extending ui.View) and add with the help of objc_util a native KeyCommandsView as a subview into that custom view. With the newest BETA that does not work anymore. Whereas it worked with the Beta before and with the current production version. I guess that you also added a KeyCommandsView into the ui.View and it consumes all key events, so the self-done-native way is not working anymore when using a custom view. When not extending the ui.View (e.g. using a pure ui.View) and adding the KeyCommandsView to it, the self-done-native way still works.

Could you also do something for this second issue ?

test case example of the second issue:

# coding: utf-8
from objc_util import *
import ui
import console
UIKeyCommand = ObjCClass('UIKeyCommand')

modifiers = {(1<<17): 'Shift', (1<<18): 'Ctrl', (1<<19): 'Alt', (1<<20): 'Cmd', (1<<21): 'NumPad'}

def keyCommands(_self, _cmd):
    keys =['A']
    cmd_key_flag = 0
    key_commands = []
    for k in keys:
        key_commands.append(UIKeyCommand.keyCommandWithInput_modifierFlags_action_(k, cmd_key_flag, 'keyCommandAction:'))
    commands = ns(key_commands)
    return commands.ptr
    
def canBecomeFirstResponder(_self, _cmd):
    return True
    
def keyCommandAction_(_self, _cmd, _sender):
    self = ObjCInstance(_self)
    key_cmd = ObjCInstance(_sender)
    flags = key_cmd.modifierFlags()
    modifier_str = ' + '.join(modifiers[m] for m in list(modifiers.keys()) if (m & flags))
    key_input = key_cmd.input()
    console.hud_alert(str(key_input))
        
    
KeyCommandsView = create_objc_class('KeyCommandsView', UIView, [keyCommands, canBecomeFirstResponder, keyCommandAction_])


class CustomUIView (ui.View):
    def will_close(self):
        pass
        
@on_main_thread
def main():
    #this does not work anymore in latest Beta. E.g console.hud_alert('A') is not called anymore
    main_view = CustomUIView(frame=(0, 0, 400, 400))
    
    #this still works. console.hud_alert('A') is called 
    #main_view = ui.View(frame=(0, 0, 400, 400))
        
    v = KeyCommandsView.alloc().init()
    v.becomeFirstResponder()
    ObjCInstance(main_view).addSubview_(v)

    main_view.present('sheet')
    
if __name__ == '__main__':
    main()

New BETA crashes when I use the new introduced key_command feature

Pythonista completely exists when pressing the a key on the external BT keyboard

# coding: utf-8
import ui
import console

class UIView (ui.View):
    def get_key_commands(self):
        print('get_key_commands')
        return [{'input': 'a'}]
        #return [{'input': 'a', 'modifiers':'cmd'}]
        
    def key_command(self,sender):
        print('key_command='+str(sender))

def main():
    main_view = UIView(frame=(0, 0, 400, 400))
    main_view.name = 'Key Commands Demo'
    
    main_view.present('sheet')
    
if __name__ == '__main__':
    main()

you could setup a custom view and overwrite the will_close method, maybe you also like to know when the view is fully loaded...

I have copied the appropiate code from the docs http://omz-software.com/pythonista/docs/ios/ui.html for you

import ui

class MyView (ui.View):
    def did_load(self):
        # This will be called when a view has been fully loaded from a UI file.
        pass

    def will_close(self):
        # This will be called when a presented view is about to be dismissed.
        # You might want to save data here.
        pass

Hi,
I tested the new Beta on my current projects. It run most of the time fine. I had some methods where I had to additionally annotate with @on_main_thread to make it run, which I must not in pythonista 3.2 . But I think this is more correct and I guess v3.2 was just a bit more forgiving in that regard and v3.3. a bit more strict which is fine.

I had an issue though with pythonista-gestures from @mikael :
it gives an key error upon accessing a dictionary each time you trigger a gesture

I opened an issue for this at https://github.com/mikaelho/pythonista-gestures

Due to some restructuring in the new pythonista v3.3, in the end I think it has to be repaired in Gestures.

EDIT: it has been repaired. ;-)

I hope @mikael has also access to the beta :-)

How many seats are there free ?

Now I will have a look at the funny keyboard thing ... ;-)

Hi @robnee
huh, nobody answers to you. Ok I will try. From what I have seen, only breakpoints of the script on which you started the debug-session will fire. That means if you debug a.py only those breakpoints will fire.

But what seems to work is some sort of multi-module or multiple script debugging. That means if you have your break in a.py then the debugger will perfectly step into b.py when you single step forward and the code leads into a method located in b.py