Summary: | Please provide an updated version of Maliit that is usable | ||
---|---|---|---|
Product: | [KDE Neon] neon | Reporter: | Nathan <2gd4who> |
Component: | Packages User Edition | Assignee: | Neon Bugs <neon-bugs> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | bhush94, bugs.kde.org, carlosd.kde, jr, kelnio, nate, neon-bugs, nicolas.fella, sergio.callegari, sgmoore, sitter, s_chriscollins, twohlfarth |
Priority: | NOR | Keywords: | usability |
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Nathan
2021-03-06 01:48:49 UTC
It's packaged for Neon unstable, but apparently not for stable We don't typically package stuff that isn't KDE since we're a KDE package. But this is an infrastructure package and we can't easily point to snaps/flatpaks/appimages that might replace it and we already package it for unstable so maybe we should. What think you Harald? We kinda need it for plasma mobile anyway, which I guess is why we have it unstable? May as well put it into release. I temporarily switched to the unstable repo and manged to install maliit-keyboard with its dependancies without any issues. I could not get it to work but it has installed. We kinda need it for the desktop also. There has been no working virtual keyboard for the desktop Wayland session since the release of 5.20 (https://bugs.kde.org/show_bug.cgi?id=427972). Maliit was recommended as a replacement, but there are no installable Maliit packages for KDE Neon (user edition) and Ubuntu 20.04. Attempts to build maliit packages on KDE Neon from source fail with the following configuration errors: git clone https://github.com/maliit/framework.git && cd framework && mkdir build && cd build && cmake .. && make -j8 && sudo make install && cd ../.. && git clone https://github.com/maliit/keyboard.git && cd keyboard && mkdir build && cmake .. && make -j8 && sudo make install Cloning into 'framework'... remote: Enumerating objects: 75, done. remote: Counting objects: 100% (75/75), done. remote: Compressing objects: 100% (55/55), done. remote: Total 15347 (delta 29), reused 38 (delta 18), pack-reused 15272 Receiving objects: 100% (15347/15347), 3.21 MiB | 4.83 MiB/s, done. Resolving deltas: 100% (11672/11672), done. -- The C compiler identification is GNU 9.3.0 -- The CXX compiler identification is GNU 9.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") -- Found WaylandProtocols: //usr/share/wayland-protocols CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message): Could NOT find QtWaylandScanner (missing: QtWaylandScanner_EXECUTABLE) Call Stack (most recent call first): /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE) cmake/FindQtWaylandScanner.cmake:75 (find_package_handle_standard_args) CMakeLists.txt:53 (find_package) -- Configuring incomplete, errors occurred! The qtwaylandscanner executable exists on the system, so I don't understand why the error appears. This has been frustrating and, frankly, a hot mess since QT5 virtual keyboard support was removed from the desktop. X86 tablet users like myself have been stuck without a virtual keyboard for Plasma Wayland since this decision was made. Any help with packages or dependencies for KDE Neon User Edition would be greatly appreciated. I was (FINALLY!!!, after 6 months!!) able to install Maliit under KDE Neon user edition by following this post on Reddit: https://www.reddit.com/r/kde/comments/lx0zpe/virtual_keyboard_on_wayland_not_showing_up/gsw9jdn?utm_source=share&utm_medium=web2x&context=3 Of course now it doesn't work with GTK apps, like Firefox and every other browser. Ugh! I see many (open) issues about Maliit, but I cannot understand if Maliit is the single on screen keyboard that works on plasma or if there are other ones to test... To better frame my question: The development of Malitt seems to be halted 2 years ago (at least referring to github and the "framework" component. A tiny bunch of more recent commits exists for the "keyboard" component). The recent commits seems to be related mostly to the removal of older features. The status of the documentation pages is at best mixed (roadmap page is 404, older roadmap still indicates Qt5 as a work in progress and catch up of Qt4), developers page declares itself outdated and most entries that should be links are not. Main issue is that there is no indication at whether and how the OSK can be extended with special keys that are indispensable for using many applications (CTRL, ESC, ALT). Without such extendibility, using the kosole, but also other less text oriented applications is impossible. Specifically, it is unclear if there should be a "terminal" layout with these keys or if the OSK is meant to remain purely alphabetic with an overlay bar with the extra chars appearing only when needed. To the best of my understanding the situation on gnome with the OSK is much better, but it is unclear to me if there is a freedesktop standard making the gnome keyboard usable on KDE or not. There should also be a Qt native OSK, but again it is unclear to me if this has been integrated in some way in a framework making it usable at the DE level. This affects Kubuntu ( *Ubuntu) as well. The maliit in archive will completely crash plasma. Leaving an unusable system. I had to remove it from seed and thus we have no working on screen keyboard. Can we please depend on something that works, I am open to suggestions. i've added git master versions to all editions. there is a little bit of activity upstream so lets if that helps a bit. i'll test over the next days. Let's see if this helps testing and as a consequence the consolidation of the development of Maliit. Currently there are many issues, that I would like to summarize as follows: 1. Maliit looks like a keyboard for a mobile phone or tablet. It has alphanumeric characters, and it lets you write texts, with localization. As is it appears in no way ready for "convergent" devices, such as powerful tablets or dual in ones laptops where you may or may not be using a detachable keyboard. On these devices the expectation is that in lack of a physical keyboard you should be able to carry out most activities (though with limited ergonomics) on the virtual one. Unfortunately, with Maliit you cannot use accelerators, terminals, nor most KDE applications that depend on keys such as CTRL, ALT, ESC, TAB, etc. I personally have a dual in one laptop, and it is totally useless in KDE without its physical keyboard attached. It is not even possible to deliver a presentation from a projector attached tablet, since you do not have ESC to exit full screen. Other DEs have OSKs that seem to be in better shape for these tasks. 2. Maliit does not make clear its goals: does it want to remain a phone-like keyboard or does it want to support terminal layouts? This is fundamental to know, because if Maliit is unwilling to support "terminal" layouts, then either: (i) another solution is needed; or (ii) each individual application will need to provide its own keyboard overlay with the keys it needs. This is what applications designed for mobile phones regularly do. For instance Termux adds a bar over the Android alphanumeric keyboard and emacs is going to do the same. I do not think that this approach is the best one for devices where you could have a proper "terminal" OSK, since it leads to a wild inconsistency among the different applications, but it would still be better than nothing. 3. Maliit documentation is missing or very much out of date. If you go to https://maliit.github.io/documentation/ most links are missing or point to information that is explicitly declared as old. So even if the Maliit framework could enable developing a terminal layout, the *how* is going to remain totally unknown to most. Point 3 is probably where NEON could help most, by packaging the pieces of documentation that are available and still relevant. In perspective, KDE should probably have its own, internally developed OSK, being this a key functionality of the desktop with today's emergence of many dual mode devices sitting midway between tablets and laptops. On some systems, maalit-keyboard prevents Plasma X11 session from logging in (Wayland is unaffected). SDDM just freezes after entering the password. I have experienced this on two systems running KDE neon User Edition, but am unable to replicate in VirtualBox. Related bug report: https://bugs.launchpad.net/ubuntu/+source/maliit-keyboard/+bug/2039721 Remove the package im-config, then X11 ist starting, also with maliit-keyboard installed. |