keymanapp / keyman Goto Github PK
View Code? Open in Web Editor NEWKeyman cross platform input methods system running on Android, iOS, Linux, macOS, Windows and mobile and desktop web
Home Page: https://keyman.com/
License: Other
Keyman cross platform input methods system running on Android, iOS, Linux, macOS, Windows and mobile and desktop web
Home Page: https://keyman.com/
License: Other
OSK keys on iPhones truncate key text in landscape mode - CSS needs adjusting
https://bugs.chromium.org/p/chromium/issues/detail?id=676808 describes why and optional workaround
In prep for open-sourcing our KMEA/KMEI code and relocating it to this repo, it's noteworthy that we could use some cleanup and refactoring of the embedded-related code paths existing in KMW.
A few note-worthy points:
keymanweb.fullInitialization
is basically just an inverted keymanweb.embedded
flag, but isn't nearly as explicit.util.wait
function is only ever declared for 'native' mode and basically serves as an embedded marker; the code has a lot of if(typeof(util.wait) == 'function')
tests that equate to if(!keymanweb.embedded)
.util.wait
and util.alert
in kmwembedded.js that does nothing.KeymanWeb does not always set input element directionality correctly when changing input from LTR to RTL language. If an element is empty, it should always change element directionality when the input language directionality changes. (If the element already contains text, the text content will have mixed directionality when new text is added, so changing element directionality automatically is not appropriate.)
In most cases, directionality will be applied correctly by going back to an LTR language then re-selecting the wanted RTL language.
No matter the actual language or keyboard installed on a system, Keyman labels the default keyboard "English." Shouldn't we perform an actual check somewhere to detect the language and run with that? What if someone wishes to use an alternate name for it?
If you create a touch layout with e.g. 5 rows on base layer but only 4 rows on subsequent layers, you'll get an error in adjustHeights function which does its calculations based on the first layer and then applies them to all layers identically.
Some OSK functions can be called early while resources are still loading, if the user interacts with the page, and this can cause an error.
When using the KeymanWeb ToggleUI, removing a keyboard with a call to KeymanWeb.removeKeyboards() while exactly 2 keyboards are loaded causes the ToggleUI to break. From what I've looked at when doKeyboardUnregistered is called the event handler for ToggleUI doesn't remove the removed keyboard from its internal keyboard array. This then leads to all kinds of issues when it attempts to switch the button back into single course mode.
The Khmer keyboard here at least gives the following error when you click the bookmarklet:
KeymanWeb: Invalid call to r.keymanweb.com - page missing
The current keyboard loading and registration process has some inefficiencies that need to be resolved.
If a keyboard has already been loaded by KeymanWeb, adding a new stub that uses a loaded keyboard will attempt to reload the keyboard by making cloud requests and injecting script tags before realizing, at the last moment, that it's already loaded the thing.
Stub processing is deferred until initialization can fully proceed and is directly linked to how the initial active keyboard is set. That needs to be decoupled.
In cases where KeymanWeb attempts to display two or more messages through util.alert
or util.wait
, the later message will simply overwrite the former, erasing all evidence of the original message.
removeKeyboards should return true if keyboard(s) were successfully removed, and false otherwise. It shouldn't throw an error.
See http://www.tavultesoft.com/forums/topic.php?ForumTopicID=367&ForumPostID=1242 for back story.
If you include <script src='keymanweb.js'></script>
more than once, KeymanWeb should be smart enough to not instantiate multiple times...
Currently, any device with a touch screen is treated like a mobile device and has its inputs covered with the blocker elements to absorb touch handlers. This causes problems for users of touch screen laptops because the blocker element does not respond to being clicked on, preventing users from selecting the input underneath. In addition to this, using the blocking element via the touch screen does not allow the user to type with their keyboard.
While these issues mostly effect users on touchscreen laptops, the typing problems could also extend to users of tablets with keyboard attachments.
To work around this problem on my employer's website I've had to modify the util code relating to device identification. I changed it so that if the device is touchable but also has a form factor of desktop, the touchable field is set to false. I considered running the desktop initialization separately instead, but I noticed a lot of functions that run differently on touchable devices and decided not to.
Another thing worth noting is that passing the blocking element to KeymanWeb.attachToControl() allows to it work with keyboard input, but it does allow the user to move the caret with arrow keys (moving me away from using that).
During debugging and testing for issue #29, I found that the on-screen keyboard code constantly re-assigns text to the OSK spacebar, triggering a DOM mutation with every keystroke and another 40 or so upon toggling the OSK itself.
Using Keymanweb 2.0 build 396.
Can dynamically add a keyboard from a html select list on a form, but cannot display the keyboard to the form. The user must manually mouse click on the keyboard from the keyboard menu to display the keyboard.
Here is the code:
(function(kmw) {
kmw.init();
if ($("#id_language_code").val() == 'ar' ) {
kmw.addKeyboards('arabic_101'); // this will add the keyboard.
kmw.setActiveKeyboard('Keyboard_arabic_101','arb'); // this should display the vkb .
} else if ($("#id_language_code").val() == 'ru' ) {
kmw.addKeyboards('russian'); // this will add the keyboard
kmw.setActiveKeyboard('Keyboard_russian','rus'); // this should display the vkb
}
}...
The code appears to be correct, but the API does not work as documented.
If you define a nextlayer property for a given key, this overrides the output rule defined for the key, so it becomes a plain modifier key. This is probably not a good situation -- ideally, the nextlayer control should allow output, then swap layers.
A workaround is to use the layer(<name>)
statement in the keyboard source for the associated rule instead.
The moveToNext function in keymanweb.js never actually checks if the target it wants to focus on exists or not, causing errors when it doesn't. I've seen this come up in my implementation for my employer where moveToNext is called and no other inputs exist on the page.
Whenever KeymanWeb is initialized and it seeks out controls as targets for KeymanWeb, it also sets these controls with the formatting necessary to properly display text from the new keyboard. This is fine.
What is not fine is when read-only input elements or kmw-disabled elements are automatically reformatted as well; KeymanWeb shouldn't be affecting these controls if it's not handling their input.
The source is in keymanweb.js
's function keymanweb.setupDesktopElement
.
Pull request #30 has a fix for INPUT and TEXTAREA elements on mozilla (standards-based) browsers. Need to verify the same fix for older IE and contentEditable code paths as well.
After the MutationObserver PR sequence ( #71, #77, #80 ), attachToControl no longer fully covers all use cases... and in fact, never quite did everything necessary for desktop control setup as it was. Additionally, our online documentation makes mention of a detachFromControl
method to be implemented soon.
As the MutationObserver code actually provides tons of infrastructure toward both these objectives, the code's ready for refactoring to establish detachFromControl
as an actual API function while doing rewriting attachToControl
to make a version handling all cases while renaming the old version if it cannot otherwise easily be refactored.
We need to review this on each modern browser and if it works reliably, we can upgrade KMW keyboards to support both.
https://msdn.microsoft.com/en-us/library/ie/ff974894(v=vs.85).aspx
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.location
Currently, minified KeymanWeb includes a __BUILD__=xxx;
line which ends up assigning that value to window.__BUILD__
. Similarly, dfltLayout
is also global.
When using KeymanWeb on a touchscreen device, the keyboard will not work with inputs added to the page after KeymanWeb has initialized. Specifically, new inputs do not get the blocking element added to them that captures the touch event to open the keyboard.
My limited knowledge of web development tells me that automatically setting up the touch stuff on new inputs would not really be a feasible addition, but it would be useful to at least move the touch input initialization into functions that developers can call to add inputs on their own.
At my company I've had to work around this issue by adding the kmwInput property to my new inputs and rerunning the setupTouchDevice function.
Putting the existing touch input setup code blocks into functions doesn't seem too difficult and I may try to fix it myself if I find the time.
There should be no mouse events in the touch interfaces because this causes duplicate events.
In the numeric/symbol layer, the long press doesn't produce an output. In the default layer, however, it works just fine.
Ctrl+Alt key sequences not displaying in onscreen keyboard although we can successfully input characters.
keyboard layout: el_togo
repo: https://bitbucket.org/enablinglanguages/globalbility_project/src/35654d99094891366f20c8bb9c32caf30a1e3cdf/el_togo/?at=master
See https://github.com/tavultesoft/keymanweb/pull/18/files source/keymanweb.js:3510
We need to review this on each modern browser and if it works reliably, we can upgrade KMW keyboards to support both.
https://msdn.microsoft.com/en-us/library/ie/ff974894(v=vs.85).aspx
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.location
The nextlayer
property for keys in a touch layout determines the next layer to be selected after the key is pressed and its output generated. However, currently the nextlayer
property overrides output so no output is generated. Furthermore, if the keyboard code sets the next layer via the layer()
statement, this will be overridden by the touch layout key's nextlayer
property (which it shouldn't be).
So there are two separate issues to resolve:
nextlayer
when the key is being processed in osk.clickKey
: // Process modifier key action
// TODO: Fixup the duplication of nextlayer processing here and below.
// This breaks the `nextlayer` property on keys with output
// even though it does the right thing for modifier keys.
if(osk.selectLayer(keyName,nextLayer)) return true;
osk.clickKey
: // Test if this key has a non-default next layer
if(typeof e.key != 'undefined' && e.key['nextlayer'] !== null) osk.nextLayer=e.key['nextlayer'];
When this is resolved, we need to ensure that existing keyboards do not regress in their modifier key functionality. The behaviour needs to be identical on native and embedded versions (pay particular attention to the longpress keys).
This issue was identified during work arising from #115.
https://developers.google.com/web/fundamentals/getting-started/primers/promises
We want (and have) a non-blocking init, but there are certain API calls or page code setups that rely upon init()
having been called and fail if we don't wait until initialization has already occurred. Promises provide a way to have Javascript reliably execute a block of explicitly post-initialization code and could be used to handle these cases.
http://caniuse.com/#feat=mutationobserver
http://leaverou.github.io/stretchy shows one way to do it.
KeymanWeb in kmwcallback.js:795 tests for the device.browser in a specific set but fails to remember that 'web' is a grouping of all the web browsers and should only exclude 'native'.
The bookmarklet typically loads KeymanWeb after page initialization is complete. This means that kmwinit.js
calls keymanweb.init(null);
without giving the bookmarklet a chance to set different initialisation arguments.
An appropriate fix would be to postpone initialization to happen async by wrapping the init()
call in kmwinit.js
with setTimeout()
. This would mean that the bookmarklet could inject its own call to init()
which would then take precedence over the call in kmwinit.js
, but we wouldn't lose the initialization for other pages.
Regardless of attachType
value, the current initialization code runs setupDesktopPage/setupTouchDevice and adds all controls to the internal input list (keymanweb.inputList
) that do not explicitly disable KeymanWeb detachment, even when it is set to manual
.
This is likely to cause errors, at minimum, on touch devices when the TAB key is pressed to swap inputs.
Android 4.3 and older versions should prioritise SVG because this renders correctly on the built-in browser used for the on screen keyboard in Keyman Pro, and also improves usability in apps.
SVG is not great because it doesn't do complex script but for the OSK it is sufficient.
When registering a keyboard in KMW, the developer must include a 'language' member in the object with an array of language objects. However, the name of this member in the cloud API is 'languages'.
See http://help.keyman.com/developer/engine/web/2.0/webapi.php vs http://help.keyman.com/developer/engine/web/2.0/reference_kmw20_core_addKeyboards.php (recently updated to match implementation)
Keyman for Android does not support SPACEBAR and ENTER on external keyboards. The issue lies in KeymanWeb code.
Issue moved from private as the fix is applied to KeymanWeb.
It would be great if you could add support for these flags in KeymanWeb on those browsers that support l/r ctrl/alt.
I get the error: Extended shift flags LALT, RALT, LCTRL, RCTRL are not supported in KeymanWeb.
Thanks and regards,
John
Hi,
Thanks for the great library!
We're using Version 1.0 and are considering moving to version 2.0 (which I'm currently testing), however we're facing an issue with using the keyboard in an application that relies on onChange events firing (for example - in a 3rd party library like this https://github.com/gcanti/tcomb-form).
As you probably know, onChange events only fire when an input is manipulated via a user action, however we need these to fire when someone clicks one of the keys in the virtual keyboard.
While I can track typed-values using code like this:
{code}
myInput.addEventListener(
'keyup',
function() { console.log('test') },
false);
{code}
I can't seem to figure out how to listen to the event that corresponds to someone clicking a key via the moust (or for the matter, can't find a way to manually trigger an onChange event via KeyManWeb). Tried adding event listeners via kmw.addEventListener and kmw.osk.addEventListener, and had a through read of the documentation.
Any help would be appreciated.
A separate, embedded font specified for the OSK is not being applied.
The only thing it presently does is talk about its failure to register. The console provides no useful information - not even if it's a simple id mismatch with the keyboard to be loaded. We should fix that and provide a little error report.
Original issue: https://github.com/sillsdev/keyman-archive-android/issues/7
Then opened as https://github.com/sillsdev/keyman/issues/10 (refer for more screenshots)
Issue by MakaraSok
Thursday May 11, 2017 at 02:52 GMT
Originally opened as https://github.com/sillsdev/keyman-android/issues/7
The Khmer characters on each key are too big and they can't been seen. This is with the Khmer NiDA keyboard from the Keyman keyboard repository.
Please see the screenshot here:
The current code produces lots of warnings when compiled with the latest version of Google Closure.
In particular, it doesn't properly shift the bit-array parameter, causing an array-out-of-bounds error that prevents many symbols from working on touch-optimized keyboards and that locks KMEA into desktop mode since the error is presently uncaught when text is entered through an external keyboard.
See keymanweb.executeHardwareKeystrokeInternal
, line 513. To prevent overall breakage, either lines 500-517 should be wrapped in a try-catch or line 465 of executeHardwareKeystroke
should.
There appears to be some inconsistencies in how the OSK is constructed with respect to the emulator in Chrome. This should be reviewed.
Review use of .kmw-portrait/.kmw-landscape classes
Scaling for keyboard per devices in the test window (this code may need cleanup yet):
tavultesoft.keymanweb.getOskHeight = function() {
if(tavultesoft.keymanweb.util.device.formFactor == 'phone') {
if(tavultesoft.keymanweb.util.portraitView()) {
var height = 428;
} else {
var height = 220;
}
height=height/2; //tavultesoft.keymanweb.util.getViewportScale();
} else {
if(tavultesoft.keymanweb.util.portraitView()) {
var height = 264;
} else {
var height = 350;
}
height=height/tavultesoft.keymanweb.util.getViewportScale();
}
return height;
};
Review the key sizes, etc, against all common keyboards before we go live with this.
Arising from the Keyman Developer demo during Bootcamp
Attached keyboard demonstrates the issue. Q key is 'phone' or 'tablet'. Easiest to run this in Keyman Developer web debugger.
When using a device with a touch screen, the blocking elements added by KeymanWeb are created at the same size as their base input. To deal with the issue of inputs that change size, those inputs get a "resize" event added to them that then calls resizeInput on the blocker element on top of them.
The problem is that resize events seem to only be supported by the window , meaning they cannot be fired (even manually) in the input element.
I tried to get around this by calling the resizeInput function on the blocking element, but that didn't work as anticipated. While the blocking element expanded to fully cover the expanded size of the input, the fake input inside of it did not. It instead remained the same size and moved position to the top left corner of the input.
I've attached three screenshots showing the problem. The first shows the input being covered as expected, the second what happens when the input is made larger (which was also programmed to fire the resize event), and the third what happens after calling the resizeInput function on the blocking element (specifically the one with the "keymanweb-input" class).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.