| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
The window also needs to be aware of the focus changes (to manage
keyboard grab), not just the viewport widget.
|
|\ |
|
| |
| |
| |
| |
| |
| | |
For some reason the macOS authentication dialog is shown behind our
windows, which makes it very easy to miss. Try to manually find it and
switch to it.
|
| |
| |
| |
| |
| |
| | |
The user needs to authorize vncviewer in order to get the access needed
to grab the keyboard. Show this dialog at suitable times to make sure
there are no surprises why the keyboard grab isn't working.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This allows us to fully be free from level fiddling now that we've
switched the keyboard grab to use event taps.
This will require users to build the macOS version of TigerVNC with a
reasonably okay version of FLTK (1.3.9 or newer).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These are the slightly more proper way to grab the keyboard and macOS
and is what similar applications do. It avoids a lot of issues we have,
e.g., problems with multiple monitors.
Unfortunately we need to have the user explicitly approve this (which
really is a good thing, security wise), and Apple have chosen to mark
this feature as only for accessibility.
|
| |
| |
| |
| | |
The compiler will flag this as a likely mistake otherwise.
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Most users will not care that there is also server components in our
project, so the "viewer" or "client" qualifier is just unnecessary
noise.
As an added bonus, it reduces the number of places that need to be
translated.
|
| | |
|
| |
| |
| |
| |
| | |
Other applications don't include the version number in the application
name, so it's just confusing that we do.
|
| |
| |
| |
| |
| | |
The user never sees this, so let's keep the original filename for
consistency.
|
| |
| |
| |
| |
| |
| | |
We generate files in these targets, so let's use the proper CMake
constructs for it. If nothing else, it let's CMake properly track when
they need to be rebuilt or not.
|
| |
| |
| |
| | |
Make it more robust by having it work anywhere.
|
| |
| |
| |
| |
| | |
It didn't really work anyway as it made a bunch of assumptions on how
you had built Xvnc and mesa.
|
| |
| |
| |
| |
| | |
It is a requirement from hogweed, and we've apparently been lucky up
until now that the ordering was correct.
|
| |
| |
| |
| |
| |
| |
| | |
If we'll be running in inetd mode, then stdout and stderr will be a
client socket and not an appropriate place for logging.
Mimic what Xorg does instead.
|
| |
| |
| |
| |
| |
| | |
There already exists variables for having different compile flags
depending on the build type. Let's use them instead of doing conditional
checks.
|
| |
| |
| |
| |
| |
| | |
Primarily because _FORTIFY_SOURCE throws warnings without any
optimizations enabled. But this should also make the development
experience a bit nicer.
|
| |
| |
| |
| |
| |
| | |
The compiler sometimes fails to see the symmetry between the case
statement and if statement and complains about "delta" being used
uninitialized.
|
| |
| |
| |
| |
| |
| | |
The compiler keeps getting confused by our manual code to avoid
overflowing the buffer and throwing false warnings. Side step the issue
by using std::string instead.
|
| |
| |
| |
| | |
We haven't used that information in a decade.
|
| |
| |
| |
| | |
Avoid passing arguments around more than we actually need.
|
| |
| |
| |
| |
| | |
This is a generic thing, not specific to the FLTK viewer. It belongs in
the core code.
|
| |
| |
| |
| |
| | |
You need to activate the feature by setting supportsCursorPosition, so
there is no point in forcing everyone to implement the handler.
|
| |
| |
| |
| |
| |
| | |
We already had a field in the ServerParams structure, but we never
actually stored anything in it. Let's fix that so the cursor behaves
like other state we get from the server.
|
| | |
|
| |
| |
| |
| | |
Keep the compiler happy and get rid of noise.
|
| |
| |
| |
| |
| | |
These things have been removed or moved to common code in Xorg 21.1, so
let's avoid it in our code to get rid of warnings.
|
| |
| |
| |
| | |
These have never been used for anything and just clutter up the API.
|
| |
| |
| |
| |
| | |
These are not per-client settings, so let's move the enforcement to the
common server object as much as possible.
|
| |
| |
| |
| |
| |
| | |
Access bits are part of SConnection, so let it handle all the basic
checks as well. This allows us to reduce the complexity of
VNCSConnectionST a bit.
|
| |
| |
| |
| |
| |
| | |
It's a bit confusing that some handling is done in
CMsgHandler/SMsgHandler, and some handling is done in
CConnection/SConnection.
|
| |
| |
| |
| |
| |
| | |
These are just for interactions internally within the connection objects
and their sub classes. Mark them as protected to make the API more
clear, and to avoid accidental use.
|
| |
| |
| |
| |
| | |
Only override the actively used values, not the user values that are
stored and displayed in the options dialog.
|
| |
| |
| |
| | |
Let's coordinate the logic in a single place for clarity.
|
| |
| |
| |
| | |
That is just useless noise and churn.
|
| |
| |
| |
| |
| | |
The fake ones have a special mode, so we can simply filter them before
they are passed on as FLTK events.
|
| |
| |
| |
| |
| |
| |
| | |
To be able to debug exactly what is wrong with the layout. Unfortunately
we don't know what log level is used for actual "invalid layout"
message, or if it is even logged as all, since that happens elsewhere.
So let's be cautious and use a debug log level here.
|
| | |
|
| |
| |
| |
| |
| | |
This is already enabled in Ubuntu and RPM builds, so we might as well
enable it everywhere so all developers and users see the same behaviour.
|
|\ \ |
|
| | | |
|
|/ /
| |
| |
| | |
Make sure we get the details in the logs, if we need to debug things.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Make sure everything on screen has a consistent look when the client
switches between different pixel formats.
Use the lossless refresh mechanism to make sure this doesn't interfere
with more important updates.
Based on a suggestion by Piotr Henryk Dabrowski.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is a revert of 0ce9fef. The object slicing is causing issues, e.g.
when we get a completely expected end_of_stream exception.
It's unclear what exceptions we needed this wrapping for. We'll just
have to remove it and see what problems we encounter.
|
| |
| |
| |
| | |
This is much more robust and flexible than what we came up with.
|
| |
| |
| |
| |
| |
| | |
It's rare, but there are some things that can go wrong in the
constructor for a new client object. Make sure we handle these and
properly close the socket, rather than leave it dangling.
|
| |
| |
| |
| | |
Broken in 4ff02ae.
|