Martin Koller posted on Tue, 22 May 2018 14:43:09 +0200 as excerpted:
> I want my application to show the Qt virtual keyboard when it's running
> on a touchscreen.
> To avoid that the virtual keyboard covers the input field, I'd like to
> move the whole application window upwards so that the input field is
> always visible above the VKB, and move the window back downwards when
> the keyboard hides.
>
> However kwin seems to restrict the y-coordinate to only positive values.
> Using xfwm4 this is possible (except when the window is fullscreen or
> maximized).
>
> How can this be solved (best in a way which works regardless of the
> window manager) ?
IIRC, I've not used a virtual keyboard since playing with them a bit way
back in my MS era, which ended in 2001, so I've no specific experience of
that utility, but three possible suggestions (following on from each
other) altho you may have tried them:
1) Is it possible using kwin rules to (if only temporarily, I'm skipping
a description of how to get to the window rules config here as I assume
you know or can find it easily enough, ask if you need more detail) set
it where you want? Presumably this wouldn't work permanently as working
with the app permanently partially offscreen would be at minimum
inconvenent, but demonstrating that you could do it at least temporarily
would help for the next step.
* Note that your mention of only being able to get positive Y values so
far suggests that you might need to set/force more than the position. In
particular, "ignore requested geometry" may need to be forced on, and
possibly "obey geometry restrictions" forced off.
I have quite a number of window rules setup, and I know some window
positioning rules simply didn't work (even with force) until I set these
additional rule-points to avoid the app overruling kwin's otherwise too
gentle prodding.
2) I'd also try the wmctrl utility. It does similar things to kwin
window rules, but is command-line based and thus scriptable, making it
possible to dynamically invoke the script (perhaps making it a position
toggle, partial offscreen vs. full onscreen) with for instance a hotkey
when necessary.
* You can use the match rules you setup above to help you devise the
match rule(s) for wmctrl.
* I regularly use this technique (along with a static kwin rule setup to
overrule the window insistence points as above if necessary, while doing
the dynamic positioning with wmctrl in a script) to accomplish "dynamic"
positioning that I can't do with a kwin window rule because it's not
dynamic.
3) You said "my application", implying you're writing it and that once
you get it worked out with the above tools how to behave as you wish
using these external tools, you can code up the same behavior builtin to
the application itself.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
