works perfect for my issue! Thanks, @FernetMenta

jenkins build this please

@Memphiz iOS fails in IOSKeyboardView. Could you have a look please. Why does it not use a BusyDialog?

Will something break from this? I'm assuming there was a reason for adding fcc1090

Possible but hard to tell. This change was done 4 years ago. If anybody notices an issues, please let me know. We'll find a better solution.

lets ping @jimfcarroll then

may have time tomorrow to look at it - gui keyboard ios needs to call renderloop because its like a modal dialog and if you for example enter something in a live filter you want kodi to react on it while keyboard is still open...

there are also some comments in the code there https://github.com/xbmc/xbmc/blob/master/xbmc/platform/darwin/ios/IOSKeyboardView.mm#L252

@Memphiz is this required to run on the main/render thread?

can confirm that this fixes the visual glitches related to plugins. Will keep this in my branch and see if I notice any regressions.
Thx!

@FernetMenta well its by design i think - see

https://github.com/xbmc/xbmc/blob/master/xbmc/guilib/GUIKeyboardFactory.cpp#L114

our generic keyboard dialog is a modal dialog in our gui thread aswell - that GetInput method is meant to be blocking...

@Memphiz then I think we should create something like CGUIDialogKeyboardIOS instead of emulating a dialog outside guilib. This dialog could embed OSKeyboard. As far as I can tell this should be doable. What do you think?

@FernetMenta wouldn't this mean we need to add a skin xml file for this "fake" window? Not sure if this is what we want really? Not even sure if what i would need to skin in that xml - actually we don't want to see any window from the guilib with this do we? (maybe a 1x1 pixel window which is covered by the native keyboard then - not sure).

@Memphiz it should be a modal dialog because this is the behaviour we want. The skin file does not need to have any controls, means that we don't show anything but the IOS keyboard.
I think the current implementation of the ios keyboard has flaws because it isn't a modal dialog. That means other windows can be opened behind the keyboard triggered by API calls from outside.

@FernetMenta am i right that you would call this approach here abusive?

Memphiz@f71043f

@Memphiz those changes are in the context of splitting the render thread from the main thread. The outside world should not block or drive the render loop.

args time is over already ... please simply comment out the call to processrenderloop in case you need to go forward quick here. Keyboard should still work like before. Only the live filtering will not work anymore. (but it will update after keyboard is closed)

Line168, ProcessRenderLoop, leads to glitches commented in various posts.
I don't think simply enabling this line again is the solution here.

Enabling this line again will lead to development needs in GUI (opening VideoNav for example), Removing this line will lead to development in keyboard things. If I understand right the ProcessRenderLoop call at this place is really part of a concept, its more a workaround, right?

Isn't there a solution for the ios keyboard wich follows the concept @FernetMenta described?

Edit: Sorry, this line 168 is NOT the line wich leads to glitches. It was the part of jimfcarrol wich seems not to be point of discussion here.

as for the "native keyboard overlay" used by iOS atm, if this is moved to some GUI component, I think it would be nice to implement it (or at least name it) in some generic way so that other OSes (like Android) could also make use of it. Just an idea.

Well it already was designed in a generic way. Thats why we have the CGUIKeyboard class (which needs to be derived and implemented for each natvie keyboard platform). Moving the ios native keyboard over to a GUIDialog won't change things that much - you still need to implement the CGUIKeyboard interface for android ...

@Memphiz I embedded the iOS keyboard into a dialog.
jenkins build this please

jenkins build this please

That looks pretty clean - thx!

jenkins build this please

jenkins build this please

Would this change be responsible for deadlocking the Kodi GUI when clicking on "Search..." > "Search YouTube" from Estuary Home screen?

http://forum.kodi.tv/showthread.php?tid=269815&pid=2328176#pid2328176

This is a "crashlog" obtained by executing kill -SIGSEGV $(pidof kodi.bin) on the deadlocked process: http://sprunge.us/dgJW

And a debug-enabled "crashlog" (produced the same way as above): http://sprunge.us/NRCN