back in the days one of the big things was Swype keyboard for Nokia N9. As I see the company was acquired and later development was abandoned.
There are other alternatives out there - e.g. OKBoard by Eric Berenguier - but it has limited language, OS version and device support (and had to be uninstalled before each upgrade of the OS if I recall right).
@Jolla what do you think about closing this age old gap? The new phone is a great success (financially, too), and this is the most missing feature of the N9 for me (and most probably for quite some)…
1 Like
I don’t know what is needed for this, but there is a FOSS android keyboard that is working on this and collecting movement data. Heliboard, maybe something there that will make this easier?
to clarify for others, like aegg says, they are working on it. heliboard does not currently support opensource glide-typing. it currently uses closed source swypelibs. https://github.com/HeliBorg/HeliBoard/issues/2226
i think okboard is fully opensource, and it can be tweaked to build on XA2/etc. language support is limited, but the community is already the source of multilingual support for SailfishOS. dunno what the future will be like, but we will definitely need this
2 Likes
I do not know wheter there is some patent related issue here with (ex)Swype but would be good to have e.g. OKboard factory integrated. If a few euros to be paid for license, let it be so…
I mentioned it in a community meeting in the past, but I will say it here as well.
We definitely need a new keyboard for j2.
We need proper theming options (some people like me find it hard to use without borders), suggestions, auto correction, more languages (WITH autocorrect and suggestions) and more modern keyboard options.
The way we interact with our phones these days is either by tapping or swiping, and texting (even before calling someone) is the most common thing.
It makes sense to me to double down on a great keyboard experience that doesn’t lack anything and swipe is definitely a very common typing method for 15 years now.
6 Likes
I don’t think this is the case. At least I don’t recall ever uninstalling it before an update
1 Like
Agreed. I mistype far less on any Android keyboard, on any device.
I know the Xperia’s are narrow, but my main comparison device’s screen is just 2mm wider. And I had the same problem on my XA2 Ultra which is the biggest of the supported devices.
The basic layout is the same so there must be something else going on here. My guess is that Android has tweaked and developed touch input and interpretation of edge cases.
PS: somebody claimed that changing the font to something slightly more bold helps. I am now enduring an otherwise unsuitable system font to test this.
3 Likes
per Leo AI…
Yes, Android has significantly tweaked its touch input handling and edge case interpretation, particularly with the release of Android 15 (API 35). The most notable change is the enforcement of edge-to-edge rendering by default, which fundamentally alters how the system interprets touches near screen boundaries, gestures, and display cutouts (notches)
Here are the key developments:
Mandatory Edge-to-Edge Rendering: Starting with Android 15, apps targeting SDK 35 are forced to draw content behind the status and navigation bars. This means the system must now accurately distinguish between touches intended for the app’s UI and those intended for system gestures (like swiping up for home or back)
Enhanced Gesture Navigation Handling: To prevent accidental triggers, Android 15 introduced refined logic for mandatory system gesture insets. The system now provides more precise data on which areas are reserved for system gestures, allowing apps to explicitly opt-out of back-swipe gestures in specific regions (e.g., custom navigation drawers) while ensuring home/quick-switch gestures remain uninterrupted
Improved WindowInsets API: The framework updated how apps receive and handle WindowInsets. Developers can now more accurately query for system bars, display cutouts, and ime (keyboard) insets, ensuring that touch targets near the screen edges are not obscured or misinterpreted
- This is critical for handling “edge cases” like content overlapping with a punch-hole camera or the bottom gesture pill
Touch Target Optimization: While not a single “feature,” the shift to edge-to-edge has pushed developers to implement better touch target sizing and padding logic (using APIs like ViewCompat.setOnApplyWindowInsetsListener) to ensure buttons near the edges remain tappable and don’t conflict with system navigation areas
These changes aim to provide a more immersive, consistent experience across devices but require developers to actively manage how their apps respond to touches at the screen’s periphery to avoid “zombie touches” (where a tap is registered by the system instead of the app) or UI overlap