a) because getdomainname() is not POSIX compliant
b) because it invokes NIS and not DNS, thus the desired check can fail.
See discussion on https://bugs.kde.org/show_bug.cgi?id=256258 and patch provided there.
Created attachment 74545 [details]
Fix hostname display in titlebar with certain programs
Patch adapted to current GIT HEAD
I tried to do a review-request, but I do not know whether it is correctly:
(In reply to comment #2)
> I tried to do a review-request, but I do not know whether it is correctly:
Mostly, I filled out the missing fields and clicked publish. The Ship-It is actually meant to be used by the reviewers :-)
*** Bug 256258 has been marked as a duplicate of this bug. ***
Git commit cbb7f5750fe2a3b4916a00a648efe71f51af3b77 by Martin Gräßlin.
Committed on 07/01/2013 at 08:07.
Pushed by graesslin into branch 'master'.
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.
M +1 -0 kwin/CMakeLists.txt
M +10 -8 kwin/client.cpp
M +1 -1 kwin/client.h
A +237 -0 kwin/client_machine.cpp [License: GPL (v2)]
A +117 -0 kwin/client_machine.h [License: GPL (v2)]
M +1 -1 kwin/kcmkwin/kwinrules/CMakeLists.txt
M +1 -0 kwin/kcmkwin/kwinrules/kwinsrc.cpp
M +5 -2 kwin/kcmkwin/kwinrules/main.cpp
M +5 -4 kwin/rules.cpp
M +1 -1 kwin/rules.h
M +17 -0 kwin/tests/CMakeLists.txt
A +197 -0 kwin/tests/test_client_machine.cpp [License: GPL (v2)]
M +12 -11 kwin/toplevel.cpp
M +8 -1 kwin/toplevel.h
M +5 -30 kwin/utils.cpp
M +0 -2 kwin/utils.h