wilderjds/kwin - kwin - gitea-jacopods

10671 Commits

36 Branches

0 Tags

96 MiB

Tag: Branch: Tree: f70208c7c4

Commit Graph

Author	SHA1	Message	Date
Martin Gräßlin	330d40f425	Fix no cast to/from ASCII intrduced issues * "" needs to be wrapped in QStringLiteral * QString::fromUtf8 needed for const char* and QByteArray * QByteArray::constData() needed to get to the const char*	13 years ago
Raphael Kubo da Costa	d703adbdc1	Add a few more headers required by getaddrinfo(3). Follow-up to cbb7f57; the code built on Linux despite the lack of required includes most likely because netdb.h ends up indirectly including sys/types.h and sys/socket.h.	13 years ago
Martin Gräßlin	5cd223f051	Improved resolving whether a window is on local machine Most windows use the hostname in WM_CLIENT_MACHINE, but there are windows using the FQDN (for example libreoffice). So instead of "foo" it is "foo.local.net" or similar. The logic so far has been unable to properly determine whether windows with FQDN are on the local system. In order to solve this problem the handling is split out into an own class which stores the information of hostname and whether it is a local machine. This is to not query multiple times. To determine whether the Client is on the local system getaddrinfo is used for the own hostname and the FQDN provided in WM_CLIENT_MACHINE. If one of the queried names matches, we know that it is on the local machine. The old logic to compare the hostname is still used and getaddrinfo is only a fallback in case hostname does not match. The problem with getaddrinfo is, that it accesses the network and by that could block. To circumvent this problem the calls are moved into threads by using QtConcurrent::run. Obviously this brings disadvantages. When trying to resolve whether a Client is on the local machine and a FQDN is used, the information is initially wrong. The new ClientMachine class emits a signal when the information that the system is local becomes available, but for some things this is just too late: * window rules are already gathered * Session Management has already taken place In both cases this is an acceptable loss. For window rules it just needs a proper matching of the machine in case of localhost (remote hosts are not affected). And the case of session management is very academic as it is unlikely that a restoring session contains remote windows. BUG: 308391 FIXED-IN: 4.11 REVIEW: 108235	13 years ago

Author

SHA1

Message

Date

Martin Gräßlin

330d40f425

Fix no cast to/from ASCII intrduced issues

* "" needs to be wrapped in QStringLiteral
* QString::fromUtf8 needed for const char* and QByteArray
* QByteArray::constData() needed to get to the const char*

13 years ago

Raphael Kubo da Costa

d703adbdc1

Add a few more headers required by getaddrinfo(3).

Follow-up to cbb7f57; the code built on Linux despite the lack of required
includes most likely because netdb.h ends up indirectly including
sys/types.h and sys/socket.h.

13 years ago

Martin Gräßlin

5cd223f051

Improved resolving whether a window is on local machine

Most windows use the hostname in WM_CLIENT_MACHINE, but there are windows
using the FQDN (for example libreoffice). So instead of "foo" it is
"foo.local.net" or similar. The logic so far has been unable to properly
determine whether windows with FQDN are on the local system.

In order to solve this problem the handling is split out into an own
class which stores the information of hostname and whether it is a local
machine. This is to not query multiple times. To determine whether the
Client is on the local system getaddrinfo is used for the own hostname
and the FQDN provided in WM_CLIENT_MACHINE. If one of the queried
names matches, we know that it is on the local machine. The old logic to
compare the hostname is still used and getaddrinfo is only a fallback in
case hostname does not match.

The problem with getaddrinfo is, that it accesses the network and by that
could block. To circumvent this problem the calls are moved into threads
by using QtConcurrent::run.

Obviously this brings disadvantages. When trying to resolve whether a
Client is on the local machine and a FQDN is used, the information is
initially wrong. The new ClientMachine class emits a signal when the
information that the system is local becomes available, but for some
things this is just too late:
* window rules are already gathered
* Session Management has already taken place

In both cases this is an acceptable loss. For window rules it just needs
a proper matching of the machine in case of localhost (remote hosts are
not affected). And the case of session management is very academic as it
is unlikely that a restoring session contains remote windows.

BUG: 308391
FIXED-IN: 4.11
REVIEW: 108235

13 years ago

3 Commits (f70208c7c49d4f826118ab463e15b0692eb90f49)