tested on 2012-03-27-15-24-basyskom-plasma-active-testing-meego-usb-live.iso - in some workflows the keyboard is covering important buttons or stays longer than needed on the screen - could the keyboard vanish automatically in specificic cases? like currently it dissappears in the browser after hitting enter for entering an url -> this is already great, because hitting enter normally means, the user finished his input and needs the screen space for the content - same situation would be in the add-activity dialog after choosing a wallpaper, I guess. the normal flow would be "insert a name", "Choose a wallpaper", "make it private (in case)", hit "create" - So already in step2 while choosing a wallpaper, the keyboard is not necessary any more, but covers important buttons... For me this is an open discussion, if there are more cases in PA where a certain logic of the appearing and disappearing of the virtual keyboard could support the flow of the user
For me this is quite simple: It only makes sense to show the keyboard as long as its input is being used, i.e. - in our case - as long as a widget that takes keyboard input has focus. When I select a wallpaper, the activity name input field loses focus. Any keyboard input I make afterwards goes straight into space. So the virtual keyboard lost its purpose and should disappear. Just hiding the keyboard when no input widget has focus should solve many of the cases where the keyboard covers important elements without having any use. So is there any reason for not implementing this behavior?
Git commit 426633fcf8551c7ca288b13eb42e71e6ba92c605 by Marco Martin. Committed on 28/03/2012 at 10:56. Pushed by mart into branch 'master'. explicitly close the keyboard in some cases M +3 -0 shell/activityconfiguration/package/contents/ui/WallpaperDelegate.qml M +2 -0 shell/activityconfiguration/package/contents/ui/view.qml M +2 -0 shell/widgetsexplorer/package/contents/ui/ResourceBrowser.qml M +3 -0 shell/widgetsexplorer/package/contents/ui/WidgetExplorer.qml M +3 -0 shell/widgetsexplorer/package/contents/ui/view.qml http://commits.kde.org/plasma-mobile/426633fcf8551c7ca288b13eb42e71e6ba92c605
unfortunately is a thing that has to be done explicitly in the code case by case, so i made not the keyboard close when an icon on the settings or add resource pages is tapped. this is hardly automatic tough, so needs intervention case by case :/
Oh, this is really unfortunate :( I think for the future we need some way to be technically able to make this a general rule, or else it will have to be implemented manually again and again and again...
tested on 2012-04-04-11-10-basyskom-plasma-active-testing-meego-usb-live.iso - now the keyboard vanishes in the add-activity dialog, which is good resulting new bug: if I open the add-resource dialog and select in the app section an app, the keyboard pops up for one second and vanishes again. it seems like the keyboard is triggered by selecting an app icon. thats a new bug - maybe related?
Git commit b0573e2ad724d101e07a8923af412edccad96ed5 by Marco Martin. Committed on 04/04/2012 at 15:34. Pushed by mart into branch 'master'. don't open the keyboard before closing M +0 -1 shell/widgetsexplorer/package/contents/ui/ResourceBrowser.qml M +0 -1 shell/widgetsexplorer/package/contents/ui/WidgetExplorer.qml http://commits.kde.org/plasma-mobile/b0573e2ad724d101e07a8923af412edccad96ed5
Git commit f1ee21730d50af8782883517b681f723282a5a94 by Marco Martin. Committed on 04/04/2012 at 15:34. Pushed by mart into branch 'Active/2.1'. don't open the keyboard before closing M +0 -1 shell/widgetsexplorer/package/contents/ui/ResourceBrowser.qml M +0 -1 shell/widgetsexplorer/package/contents/ui/WidgetExplorer.qml http://commits.kde.org/plasma-mobile/f1ee21730d50af8782883517b681f723282a5a94
I can confirm that the specific problem mentioned was fixed (or rather successfully worked around)