| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| | |
This is undefined and crashes on macOS.
|
|\ \
| |/
|/| |
|
| | |
|
| |
| |
| |
| | |
This should have been done as part of cf1bc66.
|
|/ |
|
|
|
|
|
|
| |
There were not many uses of this left after the move to std::exception
and the move to the core library. Let's get rid of the last stragglers
and reduce the risk of name collisions.
|
|
|
|
|
| |
OS abstractions are generic enough that we can merge these with the new
core library.
|
|
|
|
|
| |
OS abstractions are generic enough that we can merge these with the new
core library.
|
|
|
|
|
| |
These are general plumbing, so they fit in nicely with the new core
library.
|
|
|
|
|
| |
It's just string helper functions here, so let's get rid of the
catch-all name for this module.
|
|
|
|
|
|
|
|
| |
They weren't that well used, and were mostly just confusing special
functions anyway.
Allows us to move away from generic and ambigious headers such as
"util".
|
| |
|
|
|
|
|
|
| |
These functions assumes there is a specific ordering between the given
moments. Make sure we don't return something completely crazy if this
ordering isn't true.
|
|
|
|
| |
Let's clear things up by categorizing our utility functions.
|
|
|
|
|
|
|
| |
Make it clearer what is protocol handling and what is just general
plumbing.
This is one step of several.
|
|
|
|
|
|
|
| |
Make it clearer what is protocol handling and what is just general
plumbing.
This is one step of several.
|
|
|
|
|
|
|
| |
Make it clearer what is protocol handling and what is just general
plumbing.
This is one step of several.
|
|
|
|
|
|
|
| |
Make it clearer what is protocol handling and what is just general
plumbing.
This is one step of several.
|
|
|
|
|
|
|
| |
Make it clearer what is protocol handling and what is just general
plumbing.
This is one step of several.
|
|
|
|
|
|
|
| |
Make it clearer what is protocol handling and what is just general
plumbing.
This is one step of several.
|
|
|
|
|
| |
We normally avoid specifying a class' own namespace prefix in order to
keep the code more compact. Region was the sole exception.
|
|
|
|
|
|
|
|
| |
Try to keep the code more compact for the simple things where the type
should be obvious from the context. Helps us avoid line wrapping.
Also remove explicit conversions to Region where the compiler is able to
figure it out by itself, again to reduce line length.
|
|
|
|
|
| |
This is a network function, so it makes more sense in the network
library.
|
|
|
|
|
| |
Make compile times faster by reducing the number of headers included in
other headers.
|
|
|
|
| |
This inline class just makes this header overly complex.
|
|\ |
|
| |
| |
| |
| |
| |
| | |
We've made the client more aggressive in resizing sessions, so this can
quickly produce a lot of log output. Reduce the log level to debug until
we can keep the stats for the entire session lifetime.
|
| |
| |
| |
| |
| |
| |
| | |
These are not needed since the cleanup in 6ea58ba.
At the same time, move the error logging for a failed SetDesktopSize to
the base CConnection class as it is a generic thing.
|
| | |
|
|/
|
|
| |
Broken in e97e225.
|
|
|
|
|
| |
Bad logic introduced in 28e35d0. Fortunately, nothing currently uses
this method.
|
|\ \ \
| | | |
| | | |
| | | | |
https://github.com/CendioOssman/tigervnc
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is a lot more readable than "0"/"1", which can easily be confused
with integer parameters.
Note that this breaks some backwards compatibility. Older clients will
not be able to parse configuration files generated by newer clients, as
they had a bug where they could only understand "0" and "1".
|
| | | |
| | | |
| | | |
| | | | |
Makes it much easier to find all the different options.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Now that we are based on a normal std::list, we can use normal iterators
to go through the parameters.
|
| | | |
| | | |
| | | |
| | | | |
Avoid rolling our own linked list when we have the standard library.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We don't consistently use these, so they are just confusing.
Instead, we rely on the linker to not include unnecessary objects, and
hence irrelevant configuration objects.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This allows smooth upgrades for users if the defaults change in the
future.
|
| | | |
| | | |
| | | |
| | | | |
This should have been cleaned up in adaedc9.
|
| |_|/
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is not providing protection for all of the logging, so it gives a
false sense of security. We're also not making use of this as we have
barely any threading.
The exception is the WinVNC code, which is very thread heavy. But it is
unmaintained and will not be a blocker for this.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is not providing adequate protectection in more complex cases, and
we're not making use of threads in a way that should require this.
The exception is the WinVNC code, which is very thread heavy. But it is
unmaintained and will not be a blocker for this.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Decoders are run in threads, and not everything in the logging system is
thread safe.
Normally decoders consider errors to be fatal and throw an exception.
But the H.264 decoder wants to be able to tolerate misbehaving H.264
encoders.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Reset individual contexts the same way we reset all contexts, i.e. by
deleting and recreating them. Avoids surprises by having a consistent
method.
|
| | |
| | |
| | |
| | |
| | | |
A false return value from these methods result in an exception anyway,
so let's keep things simple and throw the exception right away.
|
| | |
| | |
| | |
| | | |
It uses the size_t type, which might not otherwise be defined.
|
| |/
|/|
| |
| |
| | |
The decodered is already flagged as strictly ordered, which means it
will only be used from a single thread at a time.
|
| |
| |
| |
| |
| | |
This was a weird hack just to support the method that split arguments.
We don't need this know as we expect callers to do any string handling.
|
| |
| |
| |
| |
| | |
These two values were overlooked in the look-ahead list and hence did
not work reliably.
|