The system steals keyboard events for certain system keyboard shortcuts,
e.g. Cmd+Tab. Unfortunately this isn't considered a focus loss, so we
don't realise we've lost a few keyboard events and can end up in a
confused state.
Fortunately it is possible to detect when this happens and reset the
keyboard state, just like we do when focus is lost.
FLTK's fullscreen_x() function will always put the window on a high
level (NSStatusWindowLevel = 25), even if the window doesn't have focus.
This causes the OptionsDialog to end up behind the DesktopWindow when
the fullscreen function is called. Until we can rest assured that most
people building TigerVNC will use a fixed version of FLTK, we will need
this workaround.
cocoa_capture_displays it captures all displays enclosed by the
window_rect. If a set of displays were captured, but the configuration of
what monitors to use changed, a second call would only add to the set
of captured displays. Therefore, if the user enabled
FullScreenAllMonitors (all displays captured) and then disabled it (only
one display captured) they would get into a state were monitors not used
for the VNC session still were captured (which on macOS for example,
results in displays being unusable for other things).
This has now been fixed, resulting in monitors outside the window_rect
not being unnecessarily captured.
It was only possible to capture either the current, or all displays
previously. This could become an issue if you want to show a vnc session
over only a selected set of displays, because then we only want to
capture those displays.
The solution in the commit was chosen because it handles all cases - by
looking at what monitors are enclosed by the viewport the implementation
is independent on any configuration, but instead captures the monitors
actually being used.
It's a better match for what the key symbolises, even though it is not
as common on Unix systems. But we want to avoid getting in to tailoring
things for any one specific input method implementation.
Added OS X JIS Keyboard keys (kVK_JIS_Eisu, kvK_JIS_Kana). The Kana and Eisu keys are used to alter IME behavior, but currently the Kana key produces an unwanted space character and the Eisu key does not work.
Some input sources are still using input methods even though they
claim to be "ASCII" input. This causes our input handling to fail
since we need to query the layout to handle dead keys.
Fortunately there is another API to get the raw, underlying input
source that the input method uses. So let's use that and be sure
that we're always getting something we can use.
We won't always be on the primary monitor, so check which color space
we're actually using right now. For offscreen stuff we assume a standard
sRGB color space.
Pierre Ossman
Samuel Mannehed
Hugo Lundin
gsittyz