Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Solved: No on-screen keyboard on the 7-inch local display?
#11
It's not necessarily the number of lines of code. My quick read of the sample files showed loops that add the OSK event handers to all the input fields in the DOM. This bumps the runtime footprint.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#12
(09-14-2022, 10:27 PM)Tim Curtis Wrote: It's not necessarily the number of lines of code. My quick read of the sample files showed loops that add the OSK event handers to all the input fields in the DOM. This bumps the runtime footprint.

It does, on the first load, of course, there's no other easy way, as far as I know. I just wished you to try it to check how heavy it resulted (although I believe it's far lighter than a library parsing...)

As I said I'll try it on my PI4, but I've done this runtime-binding many times, and it indeed does not take up any time. And it is far less resource consuming than a JQuery module, that adds a lot more complexity for such a trivial task (the main reason I ended up developing mine few years ago on the first place...). It has some cosmetics that may eventually need to be tweaked, in order to make the keyboard in-style with the bright/dark themes and the accent-color, but that's not trivial.

I took into consideration just the extended-search page, in which all the inputs have the class I use for the elements-collection; there may be others in the setup (but we can skip them, as for the setup we can connect with a PC...), but those really needed on a "daily" basis are the search-related.
Reply
#13
If it could be made to only load when chromium-browser is detected (which indicates locally attached display) then much better.

There is a code block early in scripts-panels.js that does chromium detection.

Code:
       // CoverView auto-display
       var userAgent = navigator.userAgent;
       if (userAgent.indexOf('X11; CrOS armv') != -1 || userAgent.indexOf('X11; CrOS aarch64') != -1) {
           GLOBAL.chromium = true;
       } else {
           GLOBAL.chromium = false;
       }
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#14
(09-15-2022, 12:15 AM)Tim Curtis Wrote: If it could be made to only load when chromium-browser is detected (which indicates locally attached display) then much better.

There is a code block early in scripts-panels.js that does chromium detection.

Code:
       // CoverView auto-display
       var userAgent = navigator.userAgent;
       if (userAgent.indexOf('X11; CrOS armv') != -1 || userAgent.indexOf('X11; CrOS aarch64') != -1) {
           GLOBAL.chromium = true;
       } else {
           GLOBAL.chromium = false;
       }

That's the idea, of course.

Even better, I wanted to change the index.php accordingly... but nevertheless, even if we do retrieve both js and css files, they're not heavy at all; then we initialize the whole thing only if we detect chromium.

Sounds weird, though... on a Linux machine, such as my laptop, how will it behave...? I think it'll detect chromium too.

I'll try it first, then will decide.

Cheers, Al.
Reply
#15
Hello all,

I finally got the OSK installed on my moOde 8.0.2, popping-up upon selecting _any_ text-input. It also takes care of resizing the relevant containers, in order to have all the inputs visible (and restores them upon exiting). I've tested it on almost every page, and seems to be working fine.

I still need to try running it only if Chromium for arm is detected locally, which I'll do later tonight, or tomorrow.

If there's anybody interested in giving it a shot, just write here, and I'll setup a link with the two files and a brief set of instructions for its installation.

P.S.
at this very moment I come to realize that one important character is missing from it... the "=" (usefulk for some configuration parameters, AFAICR)
I'll add it somewhere.


Cheers, Al.
Reply
#16
@Nutul

I have an RPi3B+ with "official" 7-in LCD touchscreen I can try it on. Always willing to be a crash-test dummy Tongue

Regards,
Kent
Reply
#17
(09-23-2022, 08:13 PM)TheOldPresbyope Wrote: @Nutul

I have an RPi3B+ with "official" 7-in LCD touchscreen I can try it on. Always willing to be a crash-test dummy Tongue

Regards,
Kent

Hi Kent,

Here's the link:
https://drive.google.com/file/d/1WDWKcoc...sp=sharing

Stll does not load _ONLY_ if Chromium is running; so it could be annoying on any other device, but since it is smaller than half the screen, either orientation, it should remain hidden under the phone/tablet automatic OS keyboard.


Looking forward to hear from you.

Cheers, Al.
Reply
#18
@Nutul

Finally got time to build your OSK on moOde 8.2.0.

Seems to work as advertised on my local touchscreen. It does obscure the bottom portion of the screen but have been able to scroll the moOde page(s) behind it so I could see the box I'm trying to fill. Don't know (yet) if there's any moOde-input box so low on a page that I can't see what I"m typing.

First time I tried it on my Pixel 3A phone, your OSK keyboard was stuck above the Android virtual keyboard but I think that's because I hadn't refreshed the browser since this hasn't recurred. FYI, if I rotate the phone to landscape mode while the OSK is up, I get a horribly elongated keyboard. Not so if I open it in landscape mode. (Just an observation, not a big issue IMHO.)

Seems well-behaved on my 9.7-in iPad 2017.

ETA - The above not withstanding, I hope you can figure out how to avoid it appearing on a remote device.

Candidly, I use the local touchscreen just for display and drive the player variously from phone, tablet, or laptop so the OSK is not an essential feature for me. Having said that, I think you've got a good thing going here.

Regards,
Kent
Reply
#19
(09-25-2022, 06:15 PM)TheOldPresbyope Wrote: @Nutul

Finally got time to build your OSK on moOde 8.2.0.

Seems to work as advertised on my local touchscreen. It does obscure the bottom portion of the screen but have been able to scroll the moOde page(s) behind it so I could see the box I'm trying to fill. Don't know (yet) if there's any moOde-input box so low on a page that I can't see what I"m typing.

First time I tried it on my Pixel 3A phone, your OSK keyboard was stuck above the Android virtual keyboard but I think that's because I hadn't refreshed the browser since this hasn't recurred. FYI, if I rotate the phone to landscape mode while the OSK is up, I get a horribly elongated keyboard. Not so if I open it in landscape mode. (Just an observation, not a big issue IMHO.)

Seems well-behaved on my 9.7-in iPad 2017.

ETA - The above not withstanding, I hope you can figure out how to avoid it appearing on a remote device.

Candidly, I use the local touchscreen just for display and drive the player variously from phone, tablet, or laptop so the OSK is not an essential feature for me. Having said that, I think you've got a good thing going here.

Regards,
Kent

Hi Kent,

first of all, thank you for your time.

Then:

1. I am now able to run the OSK _ONLY_ on the local UI (unless you have an ARM based portable phone/tablet which can report the same navigator.userAgent string...), so no more weird overlapping/stretched keyboards.

2. maybe I have done some improvements since I uploaded the code for you to test:
2.1. not the OSK attaches to _ANY_ input with type="text"/"number"/"password"
2.2. while active, it extends the height of the container of the input fields by an amount equal to the OSK height, in order to be able to see even the bottom-most input. It restores the original container height on exit.

I am now dealing with the type="number" inputs, in order to be able to provide "bigger" and "easier" to access +/- buttons (they are so small, even on my laptop... imagine on the 7" screen)

TTYTT, I wasn't expecting it to appear everywhere... then I realized that the header.php is part of each and every UI context, hence automagically the keyboard was available on every configuration page.

I am happy enough that I was able to restrict it to the locally running Chromium, so that the graphic behavior won't affect any user controlling moOde by their phone/tablet/PC/laptop.

Hopefully I had every possible western character covered (at least all those needed for son titles AND/OR configuration strings).
Since I do have some Bulgarian/Russian artists in my library, rather than experimenting with transliteration/phonetization (which I have done in the past, and it's far from being easy), I believe I'll add just another keyboard layout to cover the cyrillic alphabet.

Maybe later tonight I'll be able to give you a release-candidate to check out... Then you'll adorably talk to @Tim Curtis, explaining him that the OSK is working wonderfully, it's not a resource/CPU hungry thing, and can be integrated, possibly, in the upcoming 8.2.1 release... :-D

Thanks again for your time.

Cheers, Al.
Reply
#20
Hi all,

here's a link to an improved version of the OSK:

- installs itself only on the Raspberry local UI, hence doesn't show up on your mobile phone/tablet etc.
- includes a cyrillic layout
- adds a numeric-only layout for "number" inputs, which includes both increase and decrease value keys (this layout is not directly accessible, it is automatically shown only for such inputs)

https://drive.google.com/file/d/1_zVTBrU...sp=sharing

Thanks in advance to who wants to try it and comment.

Cheers, Al.
Reply


Forum Jump: