I'm using tmux window manager with OS X's terminal. I'd like to be able to use the key bindings to switch between tmux panes or split them instead of having to type out 'tmux select-pane' or 'tmux split-window' every single time. However, pressing CTRL and b together, which according to the man page is the default key binding, has no effect.
For example, the man page says I should be able to type CTRL and b (or, as it puts it, C-b) along with " to split the window. Pressing these keys together does nothing. None of the key bindings produce any effect in tmux.
I tried googling the issue and got back lots of results telling me to edit my ~/.tmux.conf file, but I don't have this file at all. It doesn't exist and was not created when I installed tmux using MacPorts, thus I cannot edit it to change the key bindings.
I can't find anyone who has had a similar problem, that of the key bindings not producing any effect at all. What am I doing wrong? Does the Macbook Pro keyboard simply not support key bindings? I'd appreciate it if someone could shed light on what my problem is.
Do simple commands work? Like C-b , to rename the window? If not maybe try using iTerm2?
Related
Is there a way to check for dead keys in the current layout? I am currently capturing the users input for a project I am doing. I created a map of all keys on the keyboard, but there seems to be no flag or whatsoever defining a key as dead or not. I use libxkb in my current code.
The layout is retrieved using
KeySym * keysyms = XGetKeyboardMapping(display_, keycode_low, keycode_high - keycode_low + 1, &num_keysym);
I understand you need to know which key will not directly produce a character, maybe because you are writing a game and do not want to have it use keys as input that would require another key to be pressed to produce some output (if so, please mention in the question)
Not through standard Xlib calls, to my knowledge, and definitely not without actually pressing the respective key. Composing is entirely done within Xlib, and transparent to the front end. (For its original purpose, it should be as transparent as possible to work properly, after all)
You could, however, do the same thing that Xlib does and parse through the various Compose configuration files starting with $HOME/.Xcompose. But that could be a tedious process.
On second thought, I am definitely not proposing the following:
You could, for each key you are looking for information, create a synthetic keypress event and feed it into XLookupString. Hand in an emptied XComposeStatus structure as well. If the structure returns modified, this could be a strong hint you have found a compose key. But it could also mean the server modifies it without any need..... If I were very desparate, I'd probably try.
I am using CEF3 and want to hardcode and disable the address bar of the browser. I am not finding the right place in the code base to do the same. Any pointers would be of great help.
Either through the C++ or Javascript methods would help.
Thanks,
Ashwin
Are you using cefclient? I don't think there's a clean way to turn it off in the standard version of cefclient.
However, in the brackets-shell fork of cefclient there's a #define you can use to toggle it on/off cleanly. Just search for references to SHOW_TOOLBAR_UI (it's only used in four files). I'm guessing it wouldn't be too hard to manually apply those diffs back onto a clean copy of cefclient (you probably don't want to take the brackets-shell fork as-is – it's not very generic).
You can build a CEF application using the binary, just like the WIKI does. Please see the github project for a reference https://github.com/acristoffers/CEF3SimpleSample
I realize this question is old but I had the same question and found the solution.
In the cefclient example, the address bar is drawn within the RootWindowGtk::CreateRootWindow function.
Delete the gtk_container_add function call that adds the GtkToolItem* corresponding to the address bar and the address bar will be gone.
I'm trying to get a .net 2 Windows.Forms application running on the Mac using Mono. The application has key combination short cuts for all functions, which have pre-defined defaults and can be reconfigured by the user. The Form KeyDown event handler looks up the action to be performed.
My problem is relating the Modifiers and KeyCode to the actual keys pressed. I don't mind if some mapping needs to be added for the Mac, but I need at least 3 modifier keys. However of the 4 modifiers on the Mac, few seem to produce obvious results. I get:
Shift - works as expected
Ctrl - reports a different KeyCode, but with correct modifier (eg Ctrl+N has Modifiers = Control and KeyCode 14 = "RButton, Clear").
Alt - reports some other key, unmodified (eg Alt+R gives KeyCode = 168 = "BrowserRefresh")
Cmd - reports as Alt with expected KeyCode (eg Cmd+N appears as Alt-N)
I presume that the Cmd key would normally be used where Ctrl is used on Windows. Can anyone advise which of the three Mac keys I should be trying to use? And most importantly how to parse the KeyEventArgs to consistently report a base key plus three optional modifiers?
Mono is the latest version (as of a week or two ago), and it's a MacBook Air, OS X 10.8.1 if that makes any difference.
I get the same issues. Try using IRC and asking at irc.gnome.org on rooms Mono and MonoMac. Very helpful folks.
Apparently with MonoMac, which lets you build a native UI in Interface Builder and helps stub out your backend C# code to talk to it (that is, MonoMac is Mono talking to native Mac, not Mono running on a Mac; the second is just plain Mono), Windows.Forms support has dropped to the wayside -- I was told that Windows.Forms is essentially "dead" on the Mac, and the quiet bugzilla page seems to support that. It really is quite buggy. I ran into SelectionBackColor not working in RichTextBox right off the bat, then menu accelerators not working reliably. Windows.Forms on Mac is alpha to beta quality, I think.
That said, for what's essentially a labor of love, a surprising amount of Windows.Forms works well, but I wouldn't use it for a polished app. Good luck.
EDIT: I realize the OP wasn't specifically talking about menuitems, but here's a bug report about accelerators and menu items not working so well, just to speak to related bugginess.
[Mono-bugs] [Bug 75996][Maj] New - menuitem event not triggered by Shortcut
Windows.Forms on Mono is so close to working, it's tempting to think it's going to support what you need to get done, but, imo, to consider it solid enough for use beyond making quick utilities would be a mistake.
In case it's useful to anyone, this is where I ended up:
I eventually managed to hack my way around this particular 'feature' by creating a new KeyData value to replace the one provided by the event (this code running only if it's a Mac).
I swapped round some of the modifiers to make it more consistent with windows (ie if Cmd was pressed, and reported as Alt by Mono I changed that to Ctrl). I also filtered out ctrl+A to ctrl+Z which return KeyCodes 0 to 25 (not 65 to 90) and replaced these with their normal values.
Fortunately my code only wanted the KeyData. It wouldn't be possible to create a new KeyEventArgs using the updated data, since Mono checks the current keyboard state and sets modifier flags for any pressed modifier keys, in addition to any modifiers passed to the KeyEventArgs constructor.
BUT - as ruffin commented Mono on the Mac is very flaky. We've parked this work for the moment as it's taking quite a bit of time to work around all the problems. So far we've managed to find a solution for each item we've looked at, and may well come back to this - but at best it will be a nasty hack to get this S/W running on the Mac.
I'm trying to make a small game using (free)GLUT. I know that it's old and there are better alternatives, but currently I prefer to stick with it and use it as much as possible. I program with C.
I'm currently trying to make GLUT detect properly all the keys I press.
I use glutKeyboardFunc, glutKeyboardUpFunc, glutSpecialFunc and glutSpecialUpFunc to detect pressed keys and I store their state in a short array I created (I currently have only 5 usable keys, so I just created a specific array for them).
However, while everything works fine for 2 keys or less, the game doesn't detect properly 3 keys or more. While for some keys it detect the combination properly (that actually happens for only 1 specific combination), for others the functions simply don't detect the third key that I press.
I checked my code a few times, and there is nothing special about the combination that does work.
I also made glutKeyboardFunc and glutSpecialFunc directly print every key-press that they receive, and it seems they simply stop working after I press more then 2 keys.
Is it a known issue with GLUT or something? I googled a lot and didn't find anyone with a similar issue.
I am not very into GLUT but as I know, but you should make sure, that your keyboard supports more than 2 input keys at once. This feature is called n-key rollover. This page says, that 2-key rollover may be a common value for some keyboards, but you dont need to trust this source.
I'll clarify a point: The glutKeyBoardFunc is a callback i.e., it is invoked for every key pressed and re-executed over and over again and all the if-else (or switch-case) statements for various key combinations are executed. What it means is this - if you were to press 'A', '->' (right arrow) and 'D' all at once, depending on which key-press event was received first the callback will be executed accordingly. Sometimes with a delay and sometimes the on screen animation may stop momentarily.
GLUT is purely for educational/learning purposes but not good for full blown applications since that's not what it was designed for. You land up using OS specific libs or other languages (e.g., Qt) to embed OpenGL "window" within them and execute the keyboard events etc., The event handling in those (and/or OS specific frameworks) is radically different (and better) than GLUT.
You may want to keep your simultaneous key presses to a minimum. You may augment it with the mouse to get rid of the jerky response/processing...
I'm using Xlib for a project, and I'm trying to get the KeySym relative to a pressed key.
I've got the KeyCode relative to the pressed key, keyboard modifiers and keyboard indicators. I'm referring to this page to understand how to retrieve the correct key, but it must be out of date or something, because my X doesn't behave like that page says.
I've got some questions:
What is MODE SWITCH? How can I see what key is my MODE SWITCH and how can I set it? (via Xlib functions or via a command, it's the same).
That page says that the first 4 KeySyms associated to a KeyCode (found with XGetKeyboardMapping, or shown by xmodmap -pk command) are divided into two groups. MODE SWITCH switches between groups, and within a group the first or the second KeySym is chosen according to modifiers (ie, shift key) or indicators (ie, caps lock). But on my X I can see that if shift is pressed, I switch to the third KeySym, not the second one.
On many european layouts AltGr key is bound to KeySym XS_ISO_Level3_Shift, which doesn't belong to any keyboard modifier (ie, shift, lock, control, mod1, mod2, mod3, mod4 and mod5). When such XS_ISO_Level3_Shift is pressed, the fifth KeySym associated to the KeyCode is chosen. Why? Where can I found some info about this XS_ISO_Level3_Shift and about other keysyms that are actually used, but not documented on Xlib manuals?
It looks like the page you're reading predates Xkb - I'd guess that content is 10-15 years old at least.
See: http://www.xfree86.org/current/XKBproto.pdf
"xmodmap -pm" will show you the modifier keys such as mode switch.
With Xkb, the behavior of basically everything is configurable, I believe. Start looking at /usr/share/X11/xkb/ for example. I don't know a lot about it but hopefully looking at Xkb instead of old docs will get you pointed in the right direction.
Tronche's manual is incomplete. I found more info about keyboard functions in:
1. xlib.pdf
2. xlib html manual at static.cray-cyber.org. This doc is hidden and a bit broken. Links are typed in lowercase, but the actual documents are in uppercase. After correcting the urls in browser it's readable.
PDF is complete I guess. I don't know if [2] is complete too, but for example the chapter 16.2 (sorry, I can't give a link cause my link limit is exceeded) is far longer than in Tronche's doc.
I'm a beginner in understanding xlib, that's what I managed to google out today.