Please, there has to be some way to set the Qtvk size without resorting to qml.
-
Re: how to change the size of virtual keyboard?
That's definitely the qt vk. I've been fighting with a similar problem, but on a legacy application that uses qml in widgets on .ui files.
As long as I leave the qtvk with its default settings, it's fine. The problem is that it fills half the screen. The UX team says this is unacceptable.
Setting the vk size with qml is trivial, but once I do this, the vk is clipped by any widget that contains qml. In other words, if I have a screen filled with 4 equal-sized widgets, the qtvk will clip to whichever widget has focus, which of course loses at least 75% of the keys.
I've tried setting the vk size with a custom style, but there doesn't really seem to be an easy way of accomplishing this. One way or another, the vk width always ends up filling the screen width, even if I make the vk height much smaller.
I can kinda-sorta fake a smaller keyboard with a style if I set the style background transparent, add an opaque rectangle inside that, and then shrink the key sizes until they all fit inside that rectangle. But this doesn't work for internationalization, because I need the Simplified Chinese version of the keyboard, which means I need the selection list. Selection list width is pegged to the real keyboard width (full screen width), so I'm stuck with an ugly rectangle that sticks out of my faux shrunken keyboard on both sides.
Seriously, folks, please help. There has to be a simple way of sizing this keyboard, which is invaluable for i18n purposes.
-
I'm disappointed that no one ever answers these questions. This was part of a work assignment, and I'd really be up the creek if I hadn't gotten a bit lucky to find things on my own.
First, let's talk about the obvious answer for changing the Qt virtual keyboard size: qml. Which assumes you have this option.
InputPanel { id: inputPanel anchors.left: parent.left anchors.right: parent.right anchors.leftMargin: 250 anchors.rightMargin: 250 y: Qt.inputMethod.visible ? parent.height - inputPanel.height : parent.height; }
You can put this block in your ApplicationWindow qml or whatever you have available. Just remember to include "import QtQuick.VirtualKeyboard 2.7" or whatever version of the vk you're using. And keep this InputPanel in the top level of your display items; you don't want it stuck inside any of your controls or any subdivision of the qml.
Which leads to the problem I was having with my company's legacy application, which is a .ui form tiled with serveral widgets that display qml. Normally the Qt virtual keyboard acts as a nearly independent window, displaying over your application, which is necessary behavior. However, when I was trying to control its size with the qml block above, the vk wasn't showing up at all when an edit control would receive focus in one of our widgets.
When I set the y in this InputPanel block to a function and logged the various properties when that y was hit, it seemed like the vk had lost its window independence. It was only seeing the immediate widget size, which was fairly small. I wasn't seeing the vk appear because the margins were setting its width to less than 0. Of course, when I tried setting its width, x, and y to absolute numbers, the widget with the focus clipped the vk. Any attempt to control the vk's size in qml resulted in it losing window independence and becoming part of the qml that received focus.
I tried various things to get around this, including an invisible qml-displaying widget that received only the InputPanel block as source. In all cases, the act of referencing InputPanel (or Keyboard, one of its constituents) in qml was enough to make the Qt vk lose its window independence. That's not a problem if your app is full-screen anyway, but that's not always the way my company did it in their .ui files.
My best guess about the cause is that InputPanel starts with the top-level window as its parent, but any mention of InputPanel in qml wipes out this property and it resets to the default local parent. I see something similar happen if I include the InputPanel block without properties, which wipes out all of its dimensions and coordinates, leaving a mess at the top left corner of the screen. Is there a way to set InputPanel's parent to the top-level window in qml? Maybe, but I haven't found a way that works yet. Setting InputPanels flags or modality just end up crashing things.
My current solution is to violate one of Qt's rules and set the vk's width property from C++:
static void handleVisibleChanged(){ if (!QGuiApplication::inputMethod()->isVisible()) return; const int desiredWidth = 1000; for(QWindow * w: QGuiApplication::allWindows()){ if(std::strcmp(w->metaObject()->className(), "QtVirtualKeyboard::InputView") == 0){ QQuickItem* rootObject = ((QQuickView*)w)->rootObject(); if(rootObject) rootObject->setProperty("width",QVariant::fromValue(desiredWidth)); return; } } }
Then put this in a convenient ctor or some other piece of code that will be run early on:
QObject::connect(QGuiApplication::inputMethod(), &QInputMethod::visibleChanged, &handleVisibleChanged);
When your vk pops up, the function iterates through all available windows until it finds the vk's InputView, then pulls out its rootObject and changes the width there. (Changing width at the QQuickView level will only clip the keyboard, rather than causing it to scale to a different size. It's okay to change the x,y coordiantes of the keyboard at this level, though.)
They really don't want you doing things this way, but in this case, I don't feel too bad about just changing width. Everything visible has width. And if Qt decides to change the name of the virtual keyboard windows, that's going to show up in the documentation.
Of course, if they just happened to have a convenient way to change the vk size without assuming that everyone will always use qml exclusively these days, that would've made all of this nonsense unnecessary. Maybe they have something like that, who knows?
Nobody bothered to answer.
-
Hi and welcome to devnet,
Thanks for the detailed analysis and solution even if not ideal.
I suggest that you check the bug report system to see if there's something related. If not you should open an issue there.
As for people not answering, this is a voluntary driven forum. Usually if there's no answer to a question it's mainly because nobody hit the same problem as you or you are using a module that is less used.