Feature Request: Add Key Border Color and Width Options

[Mokhyy]

Feature Request

I would like to request two customization options for key borders:

Proposed Features:

1. Key Border Color - Add a color picker option in the Colors section to customize the border color of keys
2. Key Border Width - Add a slider/option in Preferences to adjust the thickness of key borders

Benefits:

• Better visual customization for users
• Improved key visibility and differentiation
• More personalization options for the keyboard appearance

[LeanBitLab]

even though its optional i feel too much ui customisation make the keyboard bloated and less serious (something like that :) )

[Mokhyy]

To be honest, I still have a long list of features I’d love to see added to the keyboard! 😁😁😁

You’re right that adding more customization options might lead to some code bloat. However, in the long run, it actually forces you to write cleaner code and improve the overall architecture. 😁

I suggest gradually migrating away from legacy Java patterns. We could model the keyboard’s features and parameters using Data Classes, Sealed Classes, and Enum Classes. This approach would make the codebase much cleaner and make it significantly easier to add new features in the future.

Also, if possible, it would be great to isolate Android-specific code and APIs into a separate module. Then, you could connect them to the core keyboard logic through an abstraction layer.

Honestly, this keyboard is becoming so powerful that with just a few more additions, I don’t think there will be a better keyboard available on Android.

It would also be amazing if you eventually ported this keyboard to Linux. Of course, not all at once, but by gradually reducing Android dependencies within the code. For example, replacing Android-specific libraries with standard Kotlin Multiplatform libraries would allow for cross-platform usage."

[LeanBitLab]

It would also be amazing if you eventually ported this keyboard to Linux. Of course, not all at once, but by gradually reducing Android dependencies within the code. For example, replacing Android-specific libraries with standard Kotlin Multiplatform libraries would allow for cross-platform usage."

damn 😅, seems you have an deep long complicated plan .Expected project timeline: 7 to 42 years 😄.

[AZADAYAZ]

42 years later, our grandchildren will be very happy about this. 😁

[Mokhyy]

damn 😅, seems you have an deep long complicated plan .Expected project timeline: 7 to 42 years 😄.

😅😂😂😂

Yeah, it might get a bit long, but if it actually works, it would completely change the overall OS experience.
Since Linux allows for even more customization than Android, we could customize different parts of the keyboard and even connect it to other libraries and apps, exchanging data via APIs. This would take the keyboard to a whole new level.
For instance, instead of embedding Llama.cpp directly into the keyboard to run the AI model, we could connect the keyboard to a standalone AI model runner and exchange data between the model, the keyboard, and the text field through API.

To port it, a few things need to be done:
First, Android dependencies in the core code should be minimized or removed entirely.
Second, an abstraction layer should be written for components like the IME and Android APIs, so the keyboard can perform its functions through these abstractions.

Another thing is to use Dependency Injection (DI), specifically a library like Koin, to make it easy to connect different components and inject dependencies created in a centralized module.

Also, we should use data classes. This means we should define all root-level parameters of the keyboard—and anything involved in its construction—as base data classes, and then build composite features using these primitive properties.

I know that with the complex legacy code left from OpenBoard, porting it to Linux or even adding new features is incredibly difficult. However, if you refactor the architecture, adding features becomes much easier.

In my opinion, even if you don't port it fully to Linux, at least try to clean up the code so that we can at least use this keyboard's architecture as a blueprint/pattern for building keyboards on Linux.

It would also be amazing if you eventually ported this keyboard to Linux. Of course, not all at once, but by gradually reducing Android dependencies within the code. For example, replacing Android-specific libraries with standard Kotlin Multiplatform libraries would allow for cross-platform usage."

---

What do you think about starting a general discussion thread to continue the Linux port discussion there? I can also post anything I come across that might be useful for porting the keyboard to Linux. What do you think, dev?”

---

Sorry for the late reply. I’m in the middle of exams right now, so I can’t check my messages very often.

[LeanBitLab]

damn 😅, seems you have an deep long complicated plan .Expected project timeline: 7 to 42 years 😄.

😅😂😂😂

Yeah, it might get a bit long, but if it actually works, it would completely change the overall OS experience. Since Linux allows for even more customization than Android, we could customize different parts of the keyboard and even connect it to other libraries and apps, exchanging data via APIs. This would take the keyboard to a whole new level. For instance, instead of embedding Llama.cpp directly into the keyboard to run the AI model, we could connect the keyboard to a standalone AI model runner and exchange data between the model, the keyboard, and the text field through API.

To port it, a few things need to be done: First, Android dependencies in the core code should be minimized or removed entirely. Second, an abstraction layer should be written for components like the IME and Android APIs, so the keyboard can perform its functions through these abstractions.

Another thing is to use Dependency Injection (DI), specifically a library like Koin, to make it easy to connect different components and inject dependencies created in a centralized module.

Also, we should use data classes. This means we should define all root-level parameters of the keyboard—and anything involved in its construction—as base data classes, and then build composite features using these primitive properties.

I know that with the complex legacy code left from OpenBoard, porting it to Linux or even adding new features is incredibly difficult. However, if you refactor the architecture, adding features becomes much easier.

In my opinion, even if you don't port it fully to Linux, at least try to clean up the code so that we can at least use this keyboard's architecture as a blueprint/pattern for building keyboards on Linux.

It would also be amazing if you eventually ported this keyboard to Linux. Of course, not all at once, but by gradually reducing Android dependencies within the code. For example, replacing Android-specific libraries with standard Kotlin Multiplatform libraries would allow for cross-platform usage."

What do you think about starting a general discussion thread to continue the Linux port discussion there? I can also post anything I come across that might be useful for porting the keyboard to Linux. What do you think, dev?”

Sorry for the late reply. I’m in the middle of exams right now, so I can’t check my messages very often.

i am definitely interested in linux apps, since it being years linux being my daily driver,

for the keyboard how do you intended to use it on the linux , a virtual keyboard? or you mean on the ubuntu touch os or sailfish os? , as for other desktop distros i dont think it need an virtual keyoard, unless you are using it on phone/tab, for an desktop os its better to have an utility tool for writing like the proofreading and writing stuffs

i think for the use case of the linux its lot easier to create an new app rather than porting, else it just adds up work while might not be suitable for the linux and buggy, the best option would be create an keyboard from scratch while cherry picking suitable features from lentype implemented in its own way