Summary:
This wasn't used on startup (ksmserver calls KProcess)
Nor for the rules dialog (kwin invokes it with QProcess)
We may as well simplify the code and drop the dependency
See also T12140
Test Plan:
Restarted
Opened the rules dialog
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26835
We have lots of inconsistency at the moment in CMakeLists.txt files. Most
of it is due to kwin being a very old project. This change hopefully fixes
all of it.
Summary:
The dialog invoked through user actions menu takes the internal uuid as
command line argument which allows to query the required information
from KWin instead of using X11.
This allows to enable the system for Wayland windows.
In order to replace the usage of ClientMachine in the rules dialog the
dbus interface is extended by a value whether the window is on the
localhost. This is exposed through a virtual method on toplevel which is
overridden in ShellClient and there always returning true.
Test Plan: Run a nested Wayland and opened the dialog on a wayland window
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17750
Summary:
This call is added for the window rules kcm which has a detect
functionality. As that detect functionality cannot query any Wayland
windows we need to have some functionality in KWin core. Furthermore
this allows to simplify the code in the kcm as all the custom X11
interaction can be removed. KWin internally has the functionality to
find a window at a given position.
From a security perspective adding this dbus method is fine as the user
stays in control of the functionality. It requires active click to
select a window.
The new dbus call is already used in the rules kcm replacing the
X11 based detect functionality. That a detect is now able to get
information for both X11 and Wayland windows. So far only X11 windows
on X11 were supported. So this fills an important gap in the Wayland
offerings. It should now be possible to create rules for Wayland
windows (though may not be fully functional).
Test Plan: Run the kwin_rules_dialog and it detected the window correctly
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10490
At the same time the xinput2 integration is split out of X11Cursor
and made a standalone part of the platform plugin. XInput integration
is nowadays not only used by the cursor position polling, but also
for modifier only shortcuts.
By splitting it out the modifier shortcuts start to work also when
one doesn't have anything requesting a mouse position polling.
This also simplifies the conditional builds: xinput integration is
only included if we have support for it at compile time without having
to have many ifdefs in the cursor implementation. For the inclusion of
cursor in the kcmkwin this also removes all the ifdefs.
The key events are only requested if we have xinput 2.1. Otherwise we
would not get all raw events if the input device gets grabbed.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2473
Straight forward port from XLib based XCursor library to the
xcb variant which is considerably new. The xcb variant only allows
to create xcb_cursor_t for the default theme and size. Which suits
the needs in Cursor quite well, but means it's not a replacement for
the usage in zoom effect.
REVIEW: 122290
* Ported last qt4_wrap thingy to qt5_wrap thingy
* Include KF5Init (needed for kdeinit_executable
* Optionally include KF5DocTools and bind the docs subdirectory to it
* Include GenerateExportHeaders
It's basically a run of the port-cmake.sh script in here, mostly the changes
are the following:
- Using KF5::* targets
- Using the proper macros, following recent developments in frameworks
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
- adds the kcm rule option to set the activity - one or all option like
for virtual desktops
- makes the windows obey the rule
- makes the rule enforced even when the user tries to change the
window's activity via the alt+f3 menu
REVIEW:104972
(He didn't have time to make it yesterday and will able to commit it next thursday)
This patch clean up some :
target_link_libraries(kfoo kdeinit_kfoo) which is already done in kde4_add_kdeinit_executable()
macro and use "INSTALL_TARGETS_DEFAULT_ARGS" in other place.
I tested all compile file, all works fine but if there is a pb send me a mail.
CCMAIL: neundorf@kde.org
svn path=/trunk/KDE/kdebase/workspace/; revision=795711
by not loading the support libraries and the complete kdelibs stack it depends
on. Gdb taking 0.5M and lousy handling of near-OOM in Linux kernel
can be a pretty bad combination :(.
svn path=/trunk/KDE/kdebase/workspace/; revision=741856
r619161 | mlaurent | 2007-01-02 22:48:19 +0100 (Tue, 02 Jan 2007) | 2 lines
Use signal to refresh config into all kwin instance
svn path=/trunk/KDE/kdebase/workspace/; revision=659520
r602118 | neundorf | 2006-11-05 13:24:44 +0100 (Sun, 05 Nov 2006) | 5 lines
-remove kde4_install_libtool_file(), not necessary anymore since we switched away from libltdl
Alex
svn path=/trunk/KDE/kdebase/workspace/; revision=659301
r598290 | mlaurent | 2006-10-23 08:53:27 +0200 (Mon, 23 Oct 2006) | 5 lines
Apply Alex patch (now we can use enable-final argument
some module compiles with enable-final now)
As discussed with Alex it's not necessary to have program name
into automoc macro
svn path=/trunk/KDE/kdebase/workspace/; revision=659295
Henri Chain