Re: Qt 5.7 submodules that didn't make it to Stretch but will be in testing
Sorry to to-up on this old post.
I just came across "Problems while searching for a new upstream version"
in <https://tracker.debian.org/pkg/qtvirtualkeyboard-opensource-src>.
Could that be that the name changed to:
<http://download.qt.io/official_releases/qt/5.10/5.10.0/submodules/
qtvirtualkeyboard-everywhere-src-5.10.0.tar.xz>
Since it is the only match for "keyboard" in that directory?
Best,
Chris
PS:
I'm still looking forward to having this sort of features in KDE.
It is said there:
<https://blog.martin-graesslin.com/blog/2017/03/virtual-keyboard-on-lock-screen/>
that it is working out of the box with Plasma 5.10.
I'm not sure we are yet (fully) in Plasma 5.10
But last time I installed qtvirtualkeyboard packages, it wasn't working out of
the box to me. It looked more like a piece of software for developers than
like a keyboard for end-users. But maybe I missed something; or maybe it is
because we were not yet in plasma 5.10, or ... Anyway I'm confident it will be
working at some point. And that it is a necessary technology.
On Sunday, June 25, 2017 12:43:51 AM CET Lisandro Damián Nicanor Pérez Meyer
wrote:
> <http://perezmeyer.blogspot.com.ar/2017/06/qt-57-submodules-that-didnt-make-> it-to.html>
>
> There are two Qt 5.7 submodules that we could not package in time for Strech
> but are/will be available in their 5.7 versions in testing. This are
> qtdeclarative-render2d-plugin and qtvirtualkeyboard.
>
> declarative-render2d-plugin makes use of the Raster paint engine instead of
> OpenGL to render the contents of a scene graph, thus making it useful when
> Qt Quick2 applications are run in a system without OpenGL 2 enabled
> hardware. Using it might require tweaking Debian's
> /etc/X11/Xsession.d/90qt5-opengl. On Qt 5.9 and newer this plugin is merged
> in Qt GUI so there should be no need to perform any action on the user's
> behalf.
>
> Debian's VirtualKeyboard currently has a gotcha: we are not building it with
> the embedded code it ships. Upstream ships 3rd party code but lacks a way
> to detect and use the system versions of them. See QTBUG-59594, patches are
> welcomed. Please note that we prefer patches sent directly upstream to the
> current dev revision, we will be happy to backport patches if necessary.
> Yes, this means no hunspell, openwnn, pinyin, tcime nor
> lipi-toolkit/t9write support.
Reply to: