-
Notifications
You must be signed in to change notification settings - Fork 118
clx: input: english layout #35
Comments
This bug has assigned 100$ bounty: https://www.bountysource.com/teams/mcclim/bounties |
Is this include the basic text-field and text-editor panels? After switch to a layout such as pl, characters with right alt doesn't work. I also tried es, in es layout, Spanish symbols typed out directly and symbols with shift can work, such as !"·$%&/()= (these are shift+1 2 ... 0), but symbols with right alt ones don't work. May be a awkward solution is to add right alt+character commands in Libraries/Drei/basic-commands.lisp, as input to any text field/editor in the end call com-self-insert in line 514, basic-commands.lisp to insert the character. |
it generally affects everything what takes keyboard input in McCLIM. You can render any character, but you can't type them. I suspect it's a trouble in |
|
Oh, an you have to hotpatch XLIB::DISPLAY-KEYBOARD-MAPPING, else new keyboard layouts won't be picked up, in any language.
|
@gabriel-laddel It works, excellent work! |
@ailisp Anything else in McCLIM you'd like to see fixed/improved? |
@gabriel-laddel Maybe we will find a way to send a pull issue to clx and automatically add mapping from character representing keywords to unicode characters, then all keyboard layout input may be perfect. a longer term objective is, in fact i'm from China, i would like to add an input method for Chinese, Korean and Japanese. Input method is to show a panel to construct a block word from typing something into a panel. As when use English or Russian, there is no need to use input method so you may not heard of, but if someone want to type hello in Chinese (你好), he must first type "nihao" into the panel and then select correct one from candidate words which have same pronunciation from the panel. So that is much more work than keyboard layout only. I first wonder why, for example, a textbox in GTK+ is able to enable both different kbd layout and input methods. For kbd layout, it directly wrap from x. For input method, it implement a IMEContext mixin based on xim (the official x input method extension) for all text input widgets. So next step I want to add input method feature for McCLIM. |
Thanks! I can confirm, that this work for changing keyboard layout (but not keyboard mapping, It's a very good starting point. I'll consult this change with CLX developers after the weekend and hopefully merge this change there. (NB, as found previously by @gabriel-laddel) |
Created a few issues on CLX: |
The change in this commit seems to allow mcclim to detect and handle keymap changes appropriately: |
From IRC:
|
Also, I've noticed that different gadgets handle input differently. In this example, typing dead keys (e.g. the circumflex accent in the french layout) into the text-editor signals a condition while the interactor handles such characters properly. (defpackage :fwoar.clim-test-app
(:use :clim :clim-lisp))
(in-package :fwoar.clim-test-app)
(define-application-frame test-app ()
()
(:menu-bar (("Quit" :command com-quit)))
(:panes
(text :text-editor :height 200 :value "Some text")
(int :interactor :height 400 :width 600))
(:layouts
(default (labelling (:label "foo")
(vertically ()
text
int)))))
(define-test-app-command (com-quit :name t) ()
(frame-exit *application-frame*))
(defun main ()
(bt:make-thread
(lambda ()
(run-frame-top-level (make-instance 'test-app))))) |
Using @gabriel-laddel's keysym definitions and the code in my pr, I can type cyrillic characters |
Ok, using the code in this gist, I've managed to get characters from several different non-us locales to work correctly. This depends on the latest commit in my fork, which needs to be cleaned up a bit before it's ready. https://gist.github.com/fiddlerwoaroof/5b62a4be6b115c08665d1d5989d3b4e7 |
@dkochmanski What exactly do you need to consider this issue resolved and reward me the $150? |
Cleaned up and merged pull request which make McCLIM input obey keyboard layout set with |
The difficult part is that the pull request has to coordinate with CLX because most of the changes necessary involve filling out CLX's keysyms. |
We are in luck here, because I'm also CLX contributor and have PR accept permission there too |
There are a few misunderstandings in the thread above, and this should help to put everyone on the same page. If #P"/usr/share/X11/xkb/rules/xorg.xml" does not exist on your machine, you will need to locate it (try "locate xorg.xml") & substitue into the above code snippet. |
Hi, I would like to ask about the progress on the bug? I would like to fix it myself if no one else has already tried to do it; otherwise I'll spend my time on other bug. It also looks like @fiddlerwoaroof has an almost working solution, so I don't want to "steal" the bounty from him. Are you still working on the issue? What about you, @gabriel-laddel ? |
So what is the acceptance criterium for this to be solved? Any set of languages or characters? |
Hey. The acceptance criterium is: Technical perspective:
Expected behavior:
Solution should support keysyms supported by xlib/xcb (if there is no licensing issue with that such mappings could be generated by hand from xml). First tests will include Note that many pieces of this puzzle were tackled by various people, so it will be best to communicate with them. I'm little concerned that this solution has many creators so there may be some dissatisfaction with regard to whom we should give bounty. IMHO @dbjergaard solution is the most complete approach (and his analysis of the situation is a very valuable resource). Quote from the PR 100 in CLX:
Given above and to avoid misunderstandings: @dbjergaard are you willing to coordinate the effort to implement this solution? If so, then I would shed judgement to whom the bounty goes when this issue is solved and integrated to CLX/McCLIM. If you do it yourself that's fine, and if you are OK someone else do it when possible please say so. It is possible to split a bounty (we will claim it, re-add to McCLIM pool and create N separate issues with bounty parts to be claimed by different people). But this split must be among contributors to the final solution (not to prior incomplete attempts) and it must be consensual. Previous approaches (most notably by @fiddlerwoaroof and @gabriel-laddel) were fine proof of concept solutions but they are seemingly not pursued twoards a clean pull request nor are as complete and beneficial to the community as XKB implementation for CLX. CC: @fiddlerwoaroof @gabriel-laddel @quasus Some related work and pointers:
|
Yeah, I ran out of free time (got a job) but I agree that XKB support is the right way to go. |
Sounds interesting, thanks for elaborating. I'll let you know once I decide to tackle it. |
I will help coordinate the solution. We need people contributing however they can since this is such a large issue. This is where the bounty complicates things because a complete solution already has at least three or four authors I can think of. My development time lately hasn't been dedicated to the xkb extension, but I'm happy to help coordinate efforts and point people to tasks of varying difficulty in getting things going. |
Fine with me, how do we proceed? My point is that clx-xkeyboard almost does the trick but for the lack of events. The fairly simple code I add to McCLIM already fulfills the requirements to support any keyboard layout and to track changes to the keyboard state. (Basically, in some places I replace pre-XKB functions by their XKB counterparts and also cache the keyboard state invalidating the cache on XkbMapNotify events in order to stay up-to-date.) However, I don’t insist on merging it, because the hack I use to track the XkbMapNotify events is not neat and doesn’t deserve to be a part of McCLIM or clx-xkeyboard. What we need is a serious implementation of XKB events. This is beyond McCLIM and belongs to the realm of CLX. The stumbling block is that the |
It might be worthwhile to write a code generator that transforms the XCB xml files into common lisp code. |
This would make it a lot easier to keep CLX up to date with various X extensions. |
The best way forward is to port the partial solution from @fiddlerwoaroof to the clx-xkeyboard extension that I’ve started. It may be that once the extension is in clx McCLIM will get international input for free. |
As far as I can tell, @fiddlerwoaroof's idea is to use xkb:mapping-notify whenever a MappingNotify event is detected. Of course, it is a sound idea. The conceptual drawback of the implementation is that it doesn’t use XKB and so it is in principle limited. For instance, it has been noted that Polish 3rd-level characters are not working―and this is not surprising, as the concept of the level only exists in XKB. Also I think it doesn’t work with the third and fourth layouts (groups) e. g. if one sets them with
Thus, a fundamental solution requires XKB.
I have addressed these issues by 1) fixing some places in McCLIM to use XKB translations; 2) implementing XKB keyboard mapping cache for a class of CLIM ports; 3) providing a temporary solution concerning events both on the McCLIM and clx-xkeyboard side. Practically all the McCLIM code with comments is in this file. |
It seems to me that you have two separate problems and perhaps the bounty should be split.
In regards to 2, I don't know how mcclim works(if you depend on the window manager), but in my system the input manager keeps per input per window mappings(been more focused on xinput), so you can do things like have your laptop keyboard enter english in one window, french in an other, while having your plugged in keyboard type russian in the first window and greek in the second. Sure that's a bit a of a contrived example for keyboards but I'm more concerned with graphics applications and per widget input customizations. If mcclim itself is stateless you might want to pass the buck on to programmers, where it's usually tossed. About 1. Besides xinput this is the most complex extension to x to implement. I think it deserves all the bounty. Now if you follow me to my van in the alley, I'd like to show you an xkb extension I'm selling. ;) Which brings me to the most important question, to me, of how you guys think things should be reported by xkb, I'm leaning towards outputing structures of type list so that destructuring can be used on nested structures as well as struct accessors. Or does this even matter to you guys? Do you guys need to revisit your implementation of keyboard events, and input in general, that seems to have been based off the original protocol? Xinput is coming soon*, so it might be something you guys need to think about. *by soon, i mean after xkb because I want your moolah. |
McCLIM input (interactor, listener) are set to the english layout (even if other layout is set on the X window system), so the user can't insert characters like "łęść". If truetype is loaded these characters are rendered without a problem, just can't insert them.
Up-to-date summary is present on the Bounties wiki page.
The text was updated successfully, but these errors were encountered: