maliit / keyboard Goto Github PK

The japanese layout lacks a spacebar, as a result both cursor mode and selection mode are unavailable

I understand that keyboard control should be completely intuitive, but it would speed up the discovery of functions for newcomers.🤔 (And it helped to distinguish what is an bug and what is a feature 😇)

When a new punctuation symbol is inserted, a space should be added.

When you touch a predicted word to have it inserted, a space should be added after it automatically. And, after this additional space is added, if you insert a punctuation symbol, this space should be removed automatically.

cmake -C /var/tmp/portage_zram/portage/kde-misc/maliit-keyboard-2.1.0/work/keyboard-2.1.0_build/gentoo_common_config.cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/usr -DKDE_INSTALL_USE_QT_SYS_PATHS=ON -DKDE_INSTALL_DOCBUNDLEDIR=/usr/share/help -Denable-tests=OFF -Denable-presage=OFF -Denable-hunspell=no -DCMAKE_DISABLE_FIND_PACKAGE_Qt5Feedback=ON -DCMAKE_DISABLE_FIND_PACKAGE_Anthy=ON -DCMAKE_DISABLE_FIND_PACKAGE_Pinyin=ON -DCMAKE_DISABLE_FIND_PACKAGE_Chewing=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage_zram/portage/kde-misc/maliit-keyboard-2.1.0/work/keyboard-2.1.0_build/gentoo_toolchain.cmake /var/tmp/portage_zram/portage/kde-misc/maliit-keyboard-2.1.0/work/keyboard-2.1.0

/var/tmp/portage_zram/portage/kde-misc/maliit-keyboard-2.1.0/work/keyboard-2.1.0/plugins/westernsupport/spellchecker.cpp: In member function ‘void SpellCheckerPrivate::addUserDictionary(const QString&)’:
/var/tmp/portage_zram/portage/kde-misc/maliit-keyboard-2.1.0/work/keyboard-2.1.0/plugins/westernsupport/spellchecker.cpp:111:80: error: cannot convert ‘std::string’ {aka ‘std::__cxx11::basic_string<char>’} to ‘const char*’
  111 |                 hunspell->add(codec->fromUnicode(stream.readLine()).toStdString());
      |                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
      |                                                                                |
      |                                                                                std::string {aka std::__cxx11::basic_string<char>}
/var/tmp/portage_zram/portage/kde-misc/maliit-keyboard-2.1.0/work/keyboard-2.1.0/plugins/westernsupport/spellchecker.cpp:47:13: note:   initializing argument 1 of ‘int Hunspell::add(const char*)’
   47 |     int add(const char *) { return 0; }

I'm running void Linux with KDE.

I first installed the packages pkg-config wayland-protocols wayland-devel qt5-wayland-devel libxbkcommon-devel doxygen qt5-declarative-devel glib-devel to be able to compile and install the maliit-framework.

After that, I searched the void package manager for presage but I didn't find it, so I resorted to what I guess to be the official presage webpage and presage SourceForge release. I installed the packages autoconf automake libtool and sqlite-devel. I ran ./configure and then make -j8 all which failed with the following error:

In file included from contextTracker.h:41,
                 from contextTracker.cpp:25:
../charsets.h:174:10: error: narrowing conversion of '192' from 'int' to 'char' [-Wnarrowing]
  174 |     '\0' };
      |          ^
../charsets.h:174:10: error: narrowing conversion of '193' from 'int' to 'char' [-Wnarrowing]
../charsets.h:174:10: error: narrowing conversion of '194' from 'int' to 'char' [-Wnarrowing]
../charsets.h:174:10: error: narrowing conversion of '195' from 'int' to 'char' [-Wnarrowing]
../charsets.h:174:10: error: narrowing conversion of '196' from 'int' to 'char' [-Wnarrowing]

../charsets.h:174:10: error: narrowing conversion of '252' from 'int' to 'char' [-Wnarrowing]
../charsets.h:174:10: error: narrowing conversion of '253' from 'int' to 'char' [-Wnarrowing]
../charsets.h:174:10: error: narrowing conversion of '254' from 'int' to 'char' [-Wnarrowing]
../charsets.h:174:10: error: narrowing conversion of '255' from 'int' to 'char' [-Wnarrowing]

To solve it I edited charset.h by subtracting 256 to all the const int variables in DEFAULT_WORD_CHARS (such as Agrave) in order to make them between -128 and 127 (c++11 char is signed but from a bits point of view there should be no difference).

Finally, after successfully compiling and installing presage, I installed the hunspell-devel, libpinyin-devel, anthy-devel and libchewing-devel to compile maliit but make fails with

/usr/include/qt5/QtCore/qobject.h:253:9: error: static assertion failed: The slot requires more arguments than the signal provides.
  253 |         Q_STATIC_ASSERT_X(int(SignalType::ArgumentCount) >= int(SlotType::ArgumentCount),
      |         ^~~~~~~~~~~~~~~~~
/usr/include/qt5/QtCore/qobject.h:255:9: error: static assertion failed: Signal and slot arguments are not compatible.
  255 |         Q_STATIC_ASSERT_X((QtPrivate::CheckCompatibleArguments<typename SignalType::Arguments, typename SlotType::Arguments>::value),
      |         ^~~~~~~~~~~~~~~~~
In file included from /usr/include/qt5/QtCore/qobjectdefs.h:50,
                 from /usr/include/qt5/QtCore/qobject.h:46,
                 from /usr/include/qt5/QtCore/QObject:1,
                 from /home/kruayd/Builds/keyboard/plugins/westernsupport/westernlanguagesplugin.h:4,
                 from /home/kruayd/Builds/keyboard/plugins/westernsupport/westernlanguagesplugin.cpp:1:
/usr/include/qt5/QtCore/qobjectdefs_impl.h: In instantiation of 'struct QtPrivate::List_Left<QtPrivate::List<>, 1>':
/usr/include/qt5/QtCore/qobjectdefs_impl.h:72:118:   recursively required from 'struct QtPrivate::List_Left<QtPrivate::List<QStringList>, 2>'
/usr/include/qt5/QtCore/qobjectdefs_impl.h:72:118:   required from 'struct QtPrivate::List_Left<QtPrivate::List<QString, QStringList>, 3>'
/usr/include/qt5/QtCore/qobject.h:266:28:   required from 'static QMetaObject::Connection QObject::connect(const typename QtPrivate::FunctionPointer<Func>::Object*, Func1, const typename QtPrivate::FunctionPointer<Func2>::Object*, Func2, Qt::ConnectionType) [with Func1 = void (SpellPredictWorker::*)(QString, QStringList); Func2 = void (AbstractLanguagePlugin::*)(QString, QStringList, int); typename QtPrivate::FunctionPointer<Func>::Object = SpellPredictWorker; typename QtPrivate::FunctionPointer<Func2>::Object = AbstractLanguagePlugin]'
/home/kruayd/Builds/keyboard/plugins/westernsupport/westernlanguagesplugin.cpp:24:137:   required from here
/usr/include/qt5/QtCore/qobjectdefs_impl.h:72:118: error: no type named 'Car' in 'struct QtPrivate::List<>'
   72 |         typedef typename List_Append<List<typename L::Car>,typename List_Left<typename L::Cdr, N - 1>::Value>::Value Value;
      |                                                                                                                      ^~~~~
make[2]: *** [CMakeFiles/westernsupport.dir/build.make:118: CMakeFiles/westernsupport.dir/plugins/westernsupport/westernlanguagesplugin.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:477: CMakeFiles/westernsupport.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

This project ships maliit-keyboard in /usr/bin, but does not come with a man page.

W: maliit-keyboard: no-manual-page usr/bin/maliit-keyboard
N: 
N:   Each binary in /usr/bin, /usr/sbin, /bin, /sbin or
N:   /usr/games should have a manual page
N:   
N:   Note that though the man program has the capability to
N:   check for several program names in the NAMES section,
N:   each of these programs should have its own manual page (a
N:   symbolic link to the appropriate manual page is
N:   sufficient) because other manual page viewers such as
N:   xman or tkman don't support this.
N:   
N:   If the name of the manual page differs from the binary by
N:   case, man may be able to find it anyway; however, it is
N:   still best practice to match the exact capitalization of
N:   the executable in the manual page.
N:   
N:   If the manual pages are provided by another package on
N:   which this package depends, Lintian may not be able to
N:   determine that manual pages are available. In this case,
N:   after confirming that all binaries do have manual pages
N:   after this package and its dependencies are installed,
N:   please add a Lintian override.
N: 
N:   Please refer to Debian Policy Manual section 12.1 for
N:   details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: documentation/manual
N:   Renamed from: binary-without-manpage

I'm reproduceably seeing this crash in KDE Neon. This keeps the keyboard from ever showing.

#0  QList<QtWaylandClient::QWaylandDisplay::RegistryGlobal>::const_iterator::operator* (this=<synthetic pointer>) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:313

warning: Source file is more recent than executable.
313             inline const T &operator*() const { return i->t(); }
[Current thread is 1 (Thread 0x7f46e84f3940 (LWP 2065))]
(gdb) where
#0  QList<QtWaylandClient::QWaylandDisplay::RegistryGlobal>::const_iterator::operator*() const (this=<synthetic pointer>) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:313
#1  QtWaylandClient::QWaylandInputPanelShellIntegration::initialize(QtWaylandClient::QWaylandDisplay*) (this=0x55a64678a460, display=0x55a64628f900) at ./src/qt/plugins/shellintegration/qwaylandinputpanelshellintegration.cpp:35
#2  0x00007f46e7e9f8a8 in QtWaylandClient::QWaylandShellIntegrationFactory::create(QString const&, QtWaylandClient::QWaylandDisplay*, QStringList const&, QString const&) () at /lib/x86_64-linux-gnu/libQt5WaylandClient.so.5
#3  0x00007f46e7e6d981 in QtWaylandClient::QWaylandIntegration::createShellIntegration(QString const&) () at /lib/x86_64-linux-gnu/libQt5WaylandClient.so.5
#4  0x00007f46e7e6dc9b in QtWaylandClient::QWaylandIntegration::initializeShellIntegration() () at /lib/x86_64-linux-gnu/libQt5WaylandClient.so.5
#5  0x00007f46e7e6e6ad in QtWaylandClient::QWaylandIntegration::shellIntegration() const () at /lib/x86_64-linux-gnu/libQt5WaylandClient.so.5
#6  0x00007f46e7e80f81 in QtWaylandClient::QWaylandWindow::shouldCreateShellSurface() const () at /lib/x86_64-linux-gnu/libQt5WaylandClient.so.5
#7  0x00007f46e7e8aeca in QtWaylandClient::QWaylandWindow::initWindow() () at /lib/x86_64-linux-gnu/libQt5WaylandClient.so.5
#8  0x00007f46e7e8b68e in QtWaylandClient::QWaylandWindow::setVisible(bool) () at /lib/x86_64-linux-gnu/libQt5WaylandClient.so.5
#9  0x00007f46ec4ef9eb in QWindowPrivate::setVisible(bool) () at /lib/x86_64-linux-gnu/libQt5Gui.so.5
#10 0x00007f46ec1291be in  () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007f46ed9c2500 in Maliit::Wayland::InputMethodContext::InputMethodContext(MInputContextConnection*, zwp_input_method_context_v1*) () at /lib/x86_64-linux-gnu/libmaliit-plugins.so.2
#12 0x00007f46ed9c2807 in Maliit::Wayland::InputMethod::zwp_input_method_v1_activate(zwp_input_method_context_v1*) () at /lib/x86_64-linux-gnu/libmaliit-plugins.so.2
#13 0x00007f46eb4e5ff5 in  () at /lib/x86_64-linux-gnu/libffi.so.7
#14 0x00007f46eb4e540a in  () at /lib/x86_64-linux-gnu/libffi.so.7
#15 0x00007f46eb81e3a8 in  () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#16 0x00007f46eb81ac48 in  () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#17 0x00007f46eb81c21c in wl_display_dispatch_queue_pending () at /lib/x86_64-linux-gnu/libwayland-client.so.0
#18 0x00007f46e7e7a12a in QtWaylandClient::QWaylandDisplay::flushRequests() () at /lib/x86_64-linux-gnu/libQt5WaylandClient.so.5
#19 0x00007f46ec1291f0 in  () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x00007f46ec14ca2c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x00007f46ec0f0c9b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#22 0x00007f46ec0f8e44 in QCoreApplication::exec() () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x000055a644fe404c in main(int, char**) (argc=<optimized out>, argv=0x7ffcba4eb378) at ./src/keyboard/keyboard.cpp:40
(gdb) frame 1
#1  QtWaylandClient::QWaylandInputPanelShellIntegration::initialize (this=0x55a64678a460, display=0x55a64628f900) at ./src/qt/plugins/shellintegration/qwaylandinputpanelshellintegration.cpp:35
35      ./src/qt/plugins/shellintegration/qwaylandinputpanelshellintegration.cpp: No such file or directory.
(gdb) p display
$1 = (QtWaylandClient::QWaylandDisplay *) 0x55a64628f900
(gdb) p globals
$2 = {<QListSpecialMethods<QtWaylandClient::QWaylandDisplay::RegistryGlobal>> = {<No data fields>}, {p = {static shared_null = {ref = {atomic = {_q_value = {<std::__atomic_base<int>> = {static _S_alignment = 4, 
                _M_i = -1}, <No data fields>}}}, alloc = 0, begin = 0, end = 0, array = {0x0}}, d = 0x55a64630b4f0}, d = 0x55a64630b4f0}}
(gdb) p globals.count()
Cannot evaluate function -- may be inlined

Enable multiple key layouts and hold down the language switch key - a checkbox will appear instead of a radio button.

Linux plasma-mobile 5.12.9-1-MANJARO-ARM #1 SMP Thu Jun 3 10:11:08 UTC 2021 aarch64 GNU/Linux
maliit-keyboard 2.0.0-2

So we have Plasma QQC2 theme which (unfortunately ab)uses the context properties, one such property registered is, units, https://api.kde.org/frameworks/plasma-framework/html/classUnits.html

Now, maliit itself also registers the context property called units, which have totally different API/ABI then one in the theme.

I am not saying that what Plasma theme is doing is "correct" but we are currently in situation where solving this in plasma-framework would essentially means the breaking API/ABI compat. I am not sure what could be correct solution though..

Currently what we plan to do is write a wrapper for maliit-keyboard which sets QT_QUICK_CONTROLS_STYLE=Default environment variable which makes it "work". But this does not seem like a solution

Any thoughts on how to solve this issue?

PS: context properties are going away in Qt 6 as far as I understand anyway...

So, maliit-keyboard provides the gsettings interface for setting enabled languages:

https://github.com/maliit/keyboard/blob/master/data/schemas/org.maliit.keyboard.maliit.gschema.xml#L14

That is fine, but I wonder how can I figure out available language from app? i.e what are valid values for the enabled-language settings?

Background: I want to write a settings module for configuring maliit in Plasma Mobile.

I'm thinking of being able to use Maliit for Plasma Bigscreen. Currently they use Qt5VirtualKeyboard as that allows navigating the keyboard using key navigation. They require to be able to accept input from remote (TV) controls which often only have arrow keys available, and they emulate the arrow keys from a keyboard.

I’d like to add the Bépo (Dvorak-like for French) keyboard layout to this project. Looking quickly at the source code, it seems there is one keyboard layout per language/locale.

The maliit keyboard in Plasma Mobile provides some control keys in the upper row. Is it possible to get the PgUp / PgDn keys to work?

Or is there any one click workaround?

The Squeekyboard in Phosh has now a nice feature to access them (PgUp, PgDn, Home, End), just by clicking the Shift key. I found that solution very handy.

Is there any way to open the keyboard manually? It does not open when I highlight text inputs in some applications, and i can't find any way to open it manually.

I installed maliit-framework-2.0.0-4.fc34 and maliit-keyboard-2.0.0-2.fc34 in fedora34,But it can not be used normally。
when i run maliit-server,print this information in the terminal
WARNING: PulseAudioService: pa_context_connect() failed
WARNING: PulseAudioService: pa_context_connect() failed
WARNING: file:///usr/lib64/maliit/keyboard2/qml/Keyboard.qml:257:9: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/ActionKey.qml:59:9: QML Image: Error decoding: file:///usr/share/maliit/keyboard2/images/keyboard-caps-disabled.svg: Unsupported image format
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }
WARNING: file:///usr/lib64/maliit/keyboard2/qml/keys/CharKey.qml:338:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo() { ... }

Hi,
after installing maliit-keyboard (and maliit-framework) on debian (compile went without any errors) the keyboard refuses to show up.
Fiddling with the virtual keyboard KDE settings didn't change anything.
I attached the console log when I run maliit-keyboard
Any help would be greatly appreciated!

maliit-keyboard.log

So after canonical dropped the phone project we both forked the ubuntu keyboard, on our side we have made some major improvements with lots of new features, also some of new languages added. See https://github.com/ubports/keyboard-component

Example of some of the things that got added to the ubports fork is a swipe up to get a "control panel"

But the problem is we are now both in a state where we are unable to merge as both forks have made changes in different directions (example is the move to qqc2). To slowly solve this i'll start sending pr to the things that does not touch the qml parts, as these will be easier to handle. But the question remain, how can we best solve the UI part as that will be the most challenging part?

I also want to bring up the point of maybe making the keyboard component more pluggable so forexample the likes of ubports and kde can made there own UI tweaks to the qml part without needing to fork the whole keyboard to do so. As for qqc2 that is fine for ubports to move to, but its missing some features that is required for a more fluid UI.

I've installed maliit a couple of months ago on my Lenovo miix-720 2 in 1 pc running archlinux and KDE with plasma.
It used to work correctly, but now it does not pop up any more.
It is in the tray, and when I tap on it a popup is showed which says that the keyboard is activated, but then it never appears.
Could you help me debugging why it doesn't work anymore, please?

It's not in this source tree, it's not in that of frameworks, it's not in plugins, and it's in none of the -dev packages I have so far tried on Kubuntu Impish Indri.

Do you guys perhaps have any build instructions? Because none exist in this repository either.

I'm looking for a keyboard to be used in an embedded device and would like to try Maliit 2. However I'm having trouble compiling the project.

CMake Error at CMakeLists.txt:29 (find_package):
  By not providing "FindMaliitPlugins.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "MaliitPlugins", but CMake did not find one.

  Could not find a package configuration file provided by "MaliitPlugins"
  (requested version 0.99.1) with any of the following names:

    MaliitPluginsConfig.cmake
    maliitplugins-config.cmake

  Add the installation prefix of "MaliitPlugins" to CMAKE_PREFIX_PATH or set
  "MaliitPlugins_DIR" to a directory containing one of the above files.  If
  "MaliitPlugins" provides a separate development package or SDK, be sure it
  has been installed.

And the "maliit/plugins" project's About states:

Contains the reference input method plugins, such as the Maliit Keyboard.

Is it necessary to include Maliit keyboard to build a Maliit keyboard? Interestingly, if I try to build the plugins project itself it fails with exactly the same error message, like if it was trying to include itself.

Would it be possible to create a step-by-step guide how to build the keyboard on desktop Linux just to try it out?
The way the keyboard is split into several projects some of which seem to be abandoned is pretty confusing tbh, especially since the available documentation mentions old Qt4 and a non-existent wiki.

Tablet-Desktop/X11.

For example, the extended area of - has a short dash, a long dash and a dot symbol. The dot is extremely narrow, and only when the cursor is within the width of that symbol can one input that character. It makes it hard to select that one with fingers. I think we should have some way to resolve this (making each symbol slot the same with with one another, etc.). I am aware that this bug does not happen on PinePhone, where each symbol slot takes the same width, no matter what character it is.

Video:
https://tusooa.xyz/_matrix/media/r0/download/tusooa.xyz/CnXBEHowyeHseUkpiVEJrHBV

It's very common to mix words from the two main languages you master in a single conversation. Prediction hardly based on the chosen language is very anti-intuitive.

make[2]：Presage_TEXT2NGRAM-NOTFOUND：命令未找到
make[2]: *** [CMakeFiles/koplugin.dir/build.make:63：database_ko.db] 错误 127
make[1]: *** [CMakeFiles/Makefile2:179：CMakeFiles/koplugin.dir/all] 错误 2
make: *** [Makefile:130：all] 错误

The title bar represents my initial shock, certainty I was doing something wrong, then dumbfounded state when I realized: nope.

I understand that this keyboard was made for mobile device support, but Plasma's developers seem to have gotten confused…OSK has a dual purpose. Accessibility and mobile.

Please help me understand how we went from this practical application:

To this shockingly incomplete keyboard, (which by the way, amusingly abuses the Tagalog language, there is nothing “maliit” (small) about this thing, much better translation would be “pinakamalaki” (too big), maybe “malaki” (big) if we're trying to be neutral).

I want to help, but first I have to understand how we actually got to a place where Kwin+Wayland works so well yet disabled people either have to pound sand or use a keyboard that looks ridiculous on a desktop. Was a single physically disabled person asked before this was decided to be good enough for us?

Kvkbd, which I've helped maintain for years, is unfortunately broken ATM because it is quite hard to upgrade to Wayland (though I'm trying to upgrade it and have gotten quite far)

Thanks :)

qt5-qtfeedback is deprecated. It is optional now, but would be good to have a new supported way for haptic heedback.

I am confused what kind of licensing each file has because there are 3 different licenses. In commit 6430c82 the debian directory was deleted and along with it the copyright file which listed all the licenses for each component. I don't know if deleting the copyright file was intentional but now it's unclear what kind of licensing model this project has.

When looking at the repository it's not completely clear how to compile the keyboard and what dependencies are needed (for example, the usual cmake steps don't work)
The documentation should not assume users are familiar with what is maliit framework is and how does it work

When a punctuation symbol is inserted, keyboard should automatically insert a space and change capitalization mode on.

Hey guys,

Just wondering if swipe support is planned. I use swipe on the google keyboard on android and find it much faster than having to press each key.
Is there planned support for this feature at all?

Currently clicking the Settings button in the language menu opens the settings:///system/language URI (https://github.com/maliit/keyboard/blob/master/qml/keys/LanguageMenu.qml#L48)

It would be good to have a way to configure an arbitrary command to be run instead, e.g. on Plasma we'd like to run something like kcmshell5 kcm_maliit.

System:

• MS Surface Pro 2
  • Intel Core i5-4200U
  • Memory 4GB
  • Storage 128 GB
• OS:
  • Base system of Pop!_os 21.04
  • Hijacked with Bedrock Linux
  • Running Alpine Linux modified to PostmarketOS
  • DE: Plasma Mobile
  • Kernel: 5.11.0-7620-generic (from Pop!_os)

Issue:

Maliit does not always show up which has been a previously reported issue. I therefore plug in a USB keyboard, and Plasma deactivates Maliit, unplugging the keyboard causes Plasma to deactivate Maliit. Sometimes hot-plugging the keyboard will crash Plasma, and sometimes Maliit will not show up, at all. This could be a Plasma issue, but it is directly tied to the virtual keyboard.

I'm trying to compile this for Alpine Linux/postmarketOS, but am having some issues.

I have maliit-framework installed including the -dev package for it which contains the header files, cmake files and pkconfig files. However, while compiling maliit-keyboard it complains that it can't find maliit/plugins/abstractinputmethodhost.h.

/home/bart/Documents/Git/alpine/aports/testing/maliit-keyboard/src/keyboard-99cd3f439b9504881027ce1b95f8eaa89881e027/tests/unittests/common/inputmethodhostprobe.h:35:10: fatal error: maliit/plugins/abstractinputmethodhost.h: No such file or directory
   35 | #include <maliit/plugins/abstractinputmethodhost.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

Seems CMake did find the package so I'm not sure why this is happening, /usr/include/maliit-2/maliit/plugins/abstractinputmethodhost.h is available.

(The title is an actionable task, my personal issue is: maliit process runs, but no virtual keyboard is shown and I don't know what I'm doing!)

Hi,

I'm packaging maliit keyboard for NixOS, and am hitting an issue where I don't know how to test whether maliit works or not. I'm assuming it might not and there are packaging issues from the distro still.

Under X11, an awesome session without an actual desktop environment.

Running maliit-keyboard produces logging output, which ends with:

wordengine.cpp plugin "/nix/store/hxi7val5227lyyvigi0qw2i5dhcd70s6-maliit-keyboard-2.0.0/lib/maliit/keyboard2/languages/en/libenplugin.so" loaded
inputmethod_p.h registerActiveLanguage(): activeLanguage is: "en"
in inputMethod.cpp setActiveLanguage() activeLanguage is: "en"
inputMethod::reset()
in clear preedit.. clearing word engine
[...]
[... repeated similar warnings: ...]
file:///nix/store/hxi7val5227lyyvigi0qw2i5dhcd70s6-maliit-keyboard-2.0.0/lib/maliit/keyboard2/qml/[...]: QML Connections: Implicitly defined onFoo pr
operties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
[...]
keyboard is reporting <x y w h>: < 0 -8 0 8 > to the app manager.
keyboard is reporting <x y w h>: < 0 1432 0 8 > to the app manager.
keyboard is reporting <x y w h>: < 0 870 0 570 > to the app manager.
keyboard is reporting <x y w h>: < 0 309 0 1131 > to the app manager.
keyboard is reporting <x y w h>: < 0 871 0 569 > to the app manager.
keyboard is reporting <x y w h>: < 0 871 2560 569 > to the app manager.

I don't believe the program is frozen in a bad way. I think it's waiting for whatever it would be waiting, as running under a wayland plasma mobile session its output is similar, but it seems to be notified when trying to get it shown by touching input fields (when no keyboard is connected on a tablet).

I say it seems to be notified since it reports those:

Apr 03 22:25:30 nixos ..maliit-keyboa[1424]: in clear preedit.. clearing word engine
Apr 03 22:25:30 nixos ..maliit-keyboa[1424]: maliit.connection.wayland: virtual void Maliit::Wayland::InputMethodContext::zwp_input_method_context_v1_commit_state(uint32_t)
Apr 03 22:25:30 nixos ..maliit-keyboa[1424]: maliit.connection.wayland: virtual void Maliit::Wayland::InputMethodContext::zwp_input_method_context_v1_commit_state(uint32_t)
Apr 03 22:25:30 nixos ..maliit-keyboa[1424]: maliit.connection.wayland: virtual void Maliit::Wayland::InputMethodContext::zwp_input_method_context_v1_surrounding_text(const QString&, uint32_t, uint32_t)
Apr 03 22:25:30 nixos ..maliit-keyboa[1424]: maliit.connection.wayland: virtual void Maliit::Wayland::InputMethodContext::zwp_input_method_context_v1_commit_state(uint32_t)
Apr 03 22:25:30 nixos ..maliit-keyboa[1424]: keyboard is reporting <x y w h>: < 0 592 0 8 > to the app manager.
Apr 03 22:25:30 nixos ..maliit-keyboa[1424]: keyboard is reporting <x y w h>: < 0 358 0 242 > to the app manager.

Questions

These should help figuring out whether I'm trying things that shouldn't work at all:

• Is maliit-keyboard expected to be able to work with X11
• Does running the maliit-keyboard binary on a computer with a keyboard attached, and no toolkit involvement expected to show up in any form?
• Assuming maliit-keyboard is running in an environment it should with in (plasma-mobile), is it possible to force maliit-keyboard to show even if a keyboard is attached? (e.g. in a QEMU vm.)

Additionally, what is the development workflow like for a developer that wants to test changes on maliit-keyboard on their computer? (That workflow might help someone who's packaging too.)

Thanks!

I think the About section of this Github repo is a bit uninspired and sells community contributions short.
My suggestion:
"Maliit Keyboard, a free software virtual keyboard for Linux"

I wonder if it is possible to add a terminal layout with additional buttons like Ctrl/Alt/Esc etc?

In Plasma Mobile, there is no option to select any Indian language for the Virtual Keyboard. It would be very useful to have Indian languages in maliit-keyboard to interact with people in local language.

Also a guide to add a language layout and to build the application is greatly appreciated.

On master

1. Switch layout to zh-hans
2. Type something
3. Press Backspace
4. Press Enter

Observed:
on 3: Suggestion words disappeared.
on 4: Primary suggestion for what is typed in 2 is inputted.

Expected:
on 3: Suggestion words should be shown.
on 4: Primary suggestion for what is typed in 2, minus the last one character, should be inputted.

Video:
https://tusooa.xyz/_matrix/media/r0/download/tusooa.xyz/OIxkmLSjmlgxpMydWKpjRsdU

Depends on: maliit/framework#34

Try to enable e.g. Czech, English and Emoji. Then activate Emoji in the virtual keyboard.
Use (tap) the button/key to select the language - the language does not switch, the icons are displayed. (Hold works properly 👍)
I think emoji should be controlled separately.🤔

Linux plasma-mobile 5.12.9-1-MANJARO-ARM #1 SMP Thu Jun 3 10:11:08 UTC 2021 aarch64 GNU/Linux
maliit-keyboard 2.0.0-2

KDE Plasma Mobile uses this keyboard but many Linux distributions don't like to ship random Git snapshots.
Considering how long this code has been in use already under various stewards, I think even releasing a "Maliit Keyboard 2.0" (as opposed to Mayliit Keyboard 2, beta 1) doesn't seem that outlandish to me.

My personal preference for a release cycle down the line would be to align it with Plasma releases because the majority of commits come from KDE developers like @bhush9 already, so maybe he could be given the permissions to press the Make Release button if @jpetersen is occupied with other stuff?

Gentoo GNU/Linux, X11, compiled from source at branch master.
maliit-keyboard @ 1a8af6d
maliit-framework @ a478e92

The gsettings does not have any option to set font.

] gsettings list-recursively  org.maliit.keyboard.maliit
org.maliit.keyboard.maliit spell-checking true
org.maliit.keyboard.maliit spell-checking-languages @as []
org.maliit.keyboard.maliit auto-capitalization true
org.maliit.keyboard.maliit double-space-full-stop true
org.maliit.keyboard.maliit theme 'Ambiance'
org.maliit.keyboard.maliit previous-language 'emoji'
org.maliit.keyboard.maliit stay-hidden false
org.maliit.keyboard.maliit key-press-feedback-sound '/usr/share/maliit/keyboard2/styles/ubuntu/sounds/key_tick2_quiet.wav'
org.maliit.keyboard.maliit key-press-haptic-feedback true
org.maliit.keyboard.maliit predictive-text true
org.maliit.keyboard.maliit enabled-languages ['en', 'emoji', 'zh-hans']
org.maliit.keyboard.maliit disable-height false
org.maliit.keyboard.maliit auto-completion true
org.maliit.keyboard.maliit opacity 1.0
org.maliit.keyboard.maliit key-press-feedback false
org.maliit.keyboard.maliit active-language 'zh-hans'
org.maliit.keyboard.maliit plugin-paths ['/custom/share/maliit/plugins/org/maliit/lib/']
org.maliit.keyboard.maliit device 'default'

Screenshot:

So I had been debugging issue with kwin where if applications have text fields with specific content_purpose/hint (digits, passwords, no autocorrect, sensitive data) etc.

And as far as I can tell it seems to be sending correct values from kwin side at least, but still maliit never switches to e.g numerical keyboard where only digits are allowed.

I wanted to see if weston shows same behavior but I can't get that to work somehow, do you have instructions on what compositor you use for testing?

Please see attached build log:
maliit.log

Windows 10 Mobile had a joystick in the virtual keyboard for cursor navigation... Is that something that could be added to maliit?

On master

1. Switch language to zh-hans
2. Type miaowu
3. Press on any single character
4. Press Backspace

Observed:
in 3: the single character is inputted.
in 4: the character is removed.

Expected (ideal):
in 3: selected character kept in a buffer, displayed on the left. Suggestion list should be for the remaining input. For the example video, the buffer should be 喵wu, and suggestions be those for wu.
in 4: return to the state just after 2. i.e. the Backspace serves roughly the same as an undo.

Video:
https://tusooa.xyz/_matrix/media/r0/download/tusooa.xyz/wPSiRWcURuzdzGkqFFLTrtHb

Steps to reproduce:

1. Have 2 layouts 'English' and 'emoji'
2. Switch the active layout to English
3. Go to the keyboard settings and remove the 'English' layout
4. Add a new layout (Ex: Romanian)
5. Open the virtual keyboard. The current layout is still 'English' even if this was removed (and on the list of available layouts is not even mentioned). This behavior is persistent (even for reboots) until you change the keyboard layout.

I'm using the Maliit Keyboard (2.x) with KDE Neon in a Plasma desktop Wayland session. The keyboard works great with desktop elements, but doesn't work with any major web browser (Firefox, Chrome, Opera, etc). Is there a way to make these browsers recognize the keyboard in Wayland?

I noticed the plugins directory contains some free books to extract language characteristics (n-grams) that I guess are used for the autocomplete feature.

In the case of Spanish, I saw that the book "Don Quijote de la Mancha" is used as sample text. This is good because the book is long and it has a large vocabulary, but it has the problem that it was written in 1605-1615, so it uses quite a lot of old Spanish vocabulary and expressions that are not used at all these days and it doesn't include new words and expressions that appeared since then.

So I think it would be good to find a substitute text.

Apart from it being free for (re)distribution. Are there any special features that the text should have?

Currently themes are looked only at /usr/share/maliit/keyboard2/themes/. It would be better to let it look at $XDG_DATA_DIRS (/usr/local/share and /usr/share) and $XDG_DATA_HOME (~/.local/share/) so that custom themes could be installed there.

It would enhance writing speed on tablets as it enables writing just with thumbs but it also does the same for the landscape mode on phones.