I'm glad to see native keyboard feature in Frodo currently, it comes from #1194, but the Keyboard in python interface still wasn't benefit from the feature.
This little commit, just enable use native keyboard feature in python interface if possible.
since the python addon is running in standalone thread other than the main xbmc thread, there is a little adjust need to be set to let the ios keyboard works, which include:
Thanks for the patch. Please split the commit up into a single change per commit (i.e. "changed: CApplicationMessenger::SendGUIMessage to handle case where winid == 0", "add autopool if none available" etc.)
git reset HEAD~1, git add -p
well, splited, and I also have another non-finished commit I'm working on it for use ios native UITextField control to input, which can input any language chars supported by ios native input method, and support clipboard copy and paste, also will include tap non-input region to cancel feature just like the generic keyboard does.
Nice work - does it still work with the common keyboard dialog on non ios?
Beside that i'm really looking forward to your change by using the UITextField on ios - i was not able to figure it out and the current approach just looks a bit ugly on ios :D
Thx for working on that front :)
the original great work is from #1194, the ios native keyboard will be used for most cases on ios, except for the python addons. on other platforms it still showing the original generic keyboard.
Ahh right - i heard of the guy who did this :D - just wanted to make sure that its still working outside of ios with your patches ;)
it's still working on non-ios, certainly, ios keyboard only used on ios, else generic keyboard window instance is used.
this can be checked in KeyboardFactory::ShowAndGetInput method, where is the only place IOSKeyboard instance is created.
Since this is part of #2105 i have tested this with the youtube addon and it works like a charm (native keyboard is used in addon settings there). Nice :)
This has to go in before #2105
@jmarshallnz are you ok with that?
Overall it looks fine once the inline comments are taken care of.
Does the factory not support autoclose?
factory not support autoclose, yet.
@ulion could you rebase and adapt to master please? Factory has the autoclose added now ;) - thx for your patience.
Change GUIWindowManager.SendMessage(msg, winid) to handle window id 0…
which sent by CApplicationMessenger::SendGUIMessage by if no window id specified.
Add autopool for IOSKeyboard main function, in case it is called
from somewhere no pool was set.
In callback method of ShowAndGetInput, send messages in safe way, may…
…be it is called
from non xbmc main thread.
only change get text when confirmed like generic keyboard did.
rebased, and last 3 commits were changed from the first request.
nice cleanup - i'm fine with it
so far so good, but I found we have to handle the Cancel() from the timer thread at any time, which makes it not so easy to write strong code. I will handle the Cancel() in more thread-safe way, if I can figure it out.
finally, I got the Cancel() call thread-safe.
Python interface now use native keyboard from keyboard factory.
handle IOSKeyboard::Cancel() in more thread-safe way.
looks good - but why that bool pointer - instead just call a function setcanceled in the keyboardview which sets a normal bool member
when Cancel() get called, we really don't known whether keyboardView pointer is valid and where the keyboard thread is running to, there could be some race-conditions. so finally I let the Cancel() just set a flag, and let the keyboard thread do the check cancel flag work.
share one common cancel flag make the Cancel() code really simple, and the whole keyboard thread and logic also simple to understand. if we got two cancel flag, it will be more hard to understand how can it safely works.
@jmarshallnz since i don't see your inline comments - can you confirm that those are fixed? If so i'm fine enough with it to pull the trigger...