Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not recognise modifier keys #17

Open
fromheten opened this issue May 15, 2015 · 6 comments
Open

Does not recognise modifier keys #17

fromheten opened this issue May 15, 2015 · 6 comments
Assignees

Comments

@fromheten
Copy link

The functions get-key and get-key-blocking are giving you all keys pressed. But they don't seem to recognise the Control, Alt & super (and on Mac Command) keys.

For instance, get-key returns 'å' when I hit Alt-a on my mac keyboard. Ctrl and any character just returns the character. It would be nice to let the program get {:mod :ctrl :key "a"} or something like that.

@fromheten fromheten changed the title Does not recognise modifier keys nor Does not recognise modifier keys May 15, 2015
@heyestom
Copy link

+1 This would be very useful.
There is #18 which provides behaviour similar to what is being asked for. :)

osfameron added a commit to osfameron/pterodactyl that referenced this issue Jan 1, 2017
Note that clojure-lanterna doesn't check for modifier keys.
There's an issue and PR at

  MultiMUD/clojure-lanterna#17
  MultiMUD/clojure-lanterna#18

in the meantime, can either resort to Java interop for just
those sections, or (as clojure-lanterna library is looking
fairly unmaintained) fork it, or simply use interop?
@MultiMUD
Copy link
Owner

MultiMUD commented Feb 7, 2017

v0.10.0 will include this:

(require '[lanterna.terminal :as t] 
               '[lanterna.api :as api])
(let [term (-> (t/get-terminal :swing) api/start) 
        stroke (api/get-stroke term)] 
  (api/stop term) 
  stroke)
;; hitting alt-a (on BSD) => {:key \a, :ctrl false, :alt true, :shift false}

@MultiMUD MultiMUD self-assigned this Feb 7, 2017
@fromheten
Copy link
Author

@MultiMUD Will the get-key function then sometimes return a string and sometimes a map?

If you want to keep backwards compatibility (always a good idea, and a proud tradition in Clojure-land), a simple way could be to just add functions get-key-with-modifier & get-key-with-modifier-blocking which always return a map like {:key \a, :ctrl false, :alt true, :shift false}.

Please keep my suggestion in mind, and thanks for the nice library!

@MultiMUD
Copy link
Owner

MultiMUD commented Feb 14, 2017

@fromheten backwards compatibility was a requirement when handing over the repository & project from @sjl. To achieve this, there will be a split in API between 0.9.7 (current and last release by @sjl) and 0.10.0: The terminal and screen API will remain unchanged, maybe even a bit extended, with the mindset that this is the "low level", stable API. On top of this there will be a (protocol driven) generic API for all things drawing in lanterna3, terminals, screens and textgraphics. This allows experimentation for a more clojurey API on a higher layer, while current code will remain to function as expected with an updated clojure-lanterna. The only thing that changes from the low-level API is the return value (for any side-effecting fn this will return the context object (the first argument to the functions, a terminal or screen) as to permit (->) chaining of the fns. Check out the lanterna3 branch for a mid-development state snapshot.

So to directly answer your question: get-key returns a keycode constant now, and it will continue doing so. To get the map version, use get-stroke (a new fn) from either the low-level, or the API namespace.

@fromheten
Copy link
Author

@MultiMUD all right, if I understand you correctly it will be backwards compatible. Cheers

@MultiMUD
Copy link
Owner

Indeed. I'd consider it a bug if it isn't (save for the one-offs that make programming and design so beautiful :) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants