[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:
Since it is the only match for "keyboard" in that directory?


I'm still looking forward to having this sort of features in KDE.
It is said there:
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 
> <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: