vitalif
/
kwin
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
kwin/atoms.h

99 lines
2.3 KiB
C
Raw Normal View History

Prettify license headers
2020-08-03 01:22:19 +03:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 21:35:43 +04:00
Prettify license headers
2020-08-03 01:22:19 +03:00
SPDX-FileCopyrightText: 1999, 2000 Matthias Ettrich <ettrich@kde.org>
SPDX-FileCopyrightText: 2003 Lubos Lunak <l.lunak@kde.org>
SPDX-FileCopyrightText: 2013 Martin Gräßlin <mgraesslin@kde.org>
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 21:35:43 +04:00
Prettify license headers
2020-08-03 01:22:19 +03:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 21:35:43 +04:00
#ifndef KWIN_ATOMS_H
#define KWIN_ATOMS_H
some krazy fixes svn path=/trunk/KDE/kdebase/workspace/; revision=664331
2007-05-13 21:47:20 +04:00
Use Xcb::Atom in KWin::Atoms to resolve all atoms During startup we only create the request, the reply will be fetched once the atom is needed. To make proper use of this async behavior the creation of Atoms is moved directly to the claim of the manager selection, so they can be fetched while we wait for the previous manager selection to give up on it.
2013-09-10 15:18:55 +04:00
#include "xcbutils.h"
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 21:35:43 +04:00
namespace KWin
{
Create screen edge through the Platform Removes a diversion between X11 and Wayland. The base class Platform creates an instance of class Edge with plugin implementations being able to create a different type. The X11StandalonePlugin does that and creates a WindowBasedEdge. For this the implementation of WindowBasedEdge is moved from screenedges into the plugin. Unfortunately an ifdef is needed to make the screenedge test still work as expected. This should be improved in future, e.g. have a good way to load the platform plugin from the tests. Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1419
2016-04-15 14:47:56 +03:00
class KWIN_EXPORT Atoms
KWin uses kdelibs coding style.
2011-01-30 17:34:42 +03:00
{
public:
Atoms();
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 21:35:43 +04:00
Use Xcb::Atom in KWin::Atoms to resolve all atoms During startup we only create the request, the reply will be fetched once the atom is needed. To make proper use of this async behavior the creation of Atoms is moved directly to the claim of the manager selection, so they can be fetched while we wait for the previous manager selection to give up on it.
2013-09-10 15:18:55 +04:00
Xcb::Atom kwin_running;
Xcb::Atom activities;
Xcb::Atom wm_protocols;
Xcb::Atom wm_delete_window;
Xcb::Atom wm_take_focus;
Xcb::Atom wm_change_state;
Xcb::Atom wm_client_leader;
Xcb::Atom wm_window_role;
Xcb::Atom wm_state;
Xcb::Atom sm_client_id;
Xcb::Atom motif_wm_hints;
Xcb::Atom net_wm_context_help;
Xcb::Atom net_wm_ping;
Xcb::Atom net_wm_user_time;
Xcb::Atom kde_net_wm_user_creation_time;
Xcb::Atom net_wm_take_activity;
Xcb::Atom net_wm_window_opacity;
[xwl] Drag and drop between Xwayland and Wayland native clients Summary: Building upon the generic X Selection support this patch establishes another selection class representing the XDND selection and provides interfaces to communicate drags originating from Xwayland windows to the Wayland server KWin and drags originating from Wayland native drags to Xwayland. For Wayland native drags KWin will claim the XDND selection as owner and will simply translate all relevant events to the XDND protocol and receive alike messages by X clients. When an X client claims the XDND selection KWin is notified via the X protocol and it decides if it allows the X drag to transcend into the Wayland protocol. If this is the case the mouse position is tracked and on entering a Wayland native window a proxy X Window is mapped to the top of the window stack. This proxy window acts as a drag destination for the drag origin window and again X messages will be translated into respective Wayland protocol calls. If the cursor leaves the Wayland window geometry before a drop is registered, the proxy window is unmapped, what triggers a subsequent drag leave event. In both directions the necessary core integration is minimal. There is a single call to be done in the drag and drop event filter through the Xwayland interface class. From my tests this patch facilitates drags between any Qt/KDE apps. What needs extra care are the browsers, which use target formats, that are not directly compatible with the Wayland protocol's MIME representation. For Chromium an additional integration step must be done in order to provide it with a net window stack containing the proxy window. Test Plan: Manually. Auto tests planned. Reviewers: #kwin Subscribers: zzag, kwin, alexde Tags: #kwin Maniphest Tasks: T4611 Differential Revision: https://phabricator.kde.org/D15627
2018-08-22 15:56:48 +03:00
Xcb::Atom xdnd_selection;
Use Xcb::Atom in KWin::Atoms to resolve all atoms During startup we only create the request, the reply will be fetched once the atom is needed. To make proper use of this async behavior the creation of Atoms is moved directly to the claim of the manager selection, so they can be fetched while we wait for the previous manager selection to give up on it.
2013-09-10 15:18:55 +04:00
Xcb::Atom xdnd_aware;
[xwl] Drag and drop between Xwayland and Wayland native clients Summary: Building upon the generic X Selection support this patch establishes another selection class representing the XDND selection and provides interfaces to communicate drags originating from Xwayland windows to the Wayland server KWin and drags originating from Wayland native drags to Xwayland. For Wayland native drags KWin will claim the XDND selection as owner and will simply translate all relevant events to the XDND protocol and receive alike messages by X clients. When an X client claims the XDND selection KWin is notified via the X protocol and it decides if it allows the X drag to transcend into the Wayland protocol. If this is the case the mouse position is tracked and on entering a Wayland native window a proxy X Window is mapped to the top of the window stack. This proxy window acts as a drag destination for the drag origin window and again X messages will be translated into respective Wayland protocol calls. If the cursor leaves the Wayland window geometry before a drop is registered, the proxy window is unmapped, what triggers a subsequent drag leave event. In both directions the necessary core integration is minimal. There is a single call to be done in the drag and drop event filter through the Xwayland interface class. From my tests this patch facilitates drags between any Qt/KDE apps. What needs extra care are the browsers, which use target formats, that are not directly compatible with the Wayland protocol's MIME representation. For Chromium an additional integration step must be done in order to provide it with a net window stack containing the proxy window. Test Plan: Manually. Auto tests planned. Reviewers: #kwin Subscribers: zzag, kwin, alexde Tags: #kwin Maniphest Tasks: T4611 Differential Revision: https://phabricator.kde.org/D15627
2018-08-22 15:56:48 +03:00
Xcb::Atom xdnd_enter;
Xcb::Atom xdnd_type_list;
Use Xcb::Atom in KWin::Atoms to resolve all atoms During startup we only create the request, the reply will be fetched once the atom is needed. To make proper use of this async behavior the creation of Atoms is moved directly to the claim of the manager selection, so they can be fetched while we wait for the previous manager selection to give up on it.
2013-09-10 15:18:55 +04:00
Xcb::Atom xdnd_position;
[xwl] Drag and drop between Xwayland and Wayland native clients Summary: Building upon the generic X Selection support this patch establishes another selection class representing the XDND selection and provides interfaces to communicate drags originating from Xwayland windows to the Wayland server KWin and drags originating from Wayland native drags to Xwayland. For Wayland native drags KWin will claim the XDND selection as owner and will simply translate all relevant events to the XDND protocol and receive alike messages by X clients. When an X client claims the XDND selection KWin is notified via the X protocol and it decides if it allows the X drag to transcend into the Wayland protocol. If this is the case the mouse position is tracked and on entering a Wayland native window a proxy X Window is mapped to the top of the window stack. This proxy window acts as a drag destination for the drag origin window and again X messages will be translated into respective Wayland protocol calls. If the cursor leaves the Wayland window geometry before a drop is registered, the proxy window is unmapped, what triggers a subsequent drag leave event. In both directions the necessary core integration is minimal. There is a single call to be done in the drag and drop event filter through the Xwayland interface class. From my tests this patch facilitates drags between any Qt/KDE apps. What needs extra care are the browsers, which use target formats, that are not directly compatible with the Wayland protocol's MIME representation. For Chromium an additional integration step must be done in order to provide it with a net window stack containing the proxy window. Test Plan: Manually. Auto tests planned. Reviewers: #kwin Subscribers: zzag, kwin, alexde Tags: #kwin Maniphest Tasks: T4611 Differential Revision: https://phabricator.kde.org/D15627
2018-08-22 15:56:48 +03:00
Xcb::Atom xdnd_status;
Xcb::Atom xdnd_action_copy;
Xcb::Atom xdnd_action_move;
Xcb::Atom xdnd_action_ask;
Xcb::Atom xdnd_drop;
Xcb::Atom xdnd_leave;
Xcb::Atom xdnd_finished;
Use Xcb::Atom in KWin::Atoms to resolve all atoms During startup we only create the request, the reply will be fetched once the atom is needed. To make proper use of this async behavior the creation of Atoms is moved directly to the claim of the manager selection, so they can be fetched while we wait for the previous manager selection to give up on it.
2013-09-10 15:18:55 +04:00
Xcb::Atom net_frame_extents;
Xcb::Atom kde_net_wm_frame_strut;
Xcb::Atom net_wm_sync_request_counter;
Xcb::Atom net_wm_sync_request;
Xcb::Atom kde_net_wm_shadow;
Xcb::Atom kde_first_in_window_list;
[kwin] Client supports an X property for color scheme The X property _KDE_NET_WM_COLOR_SCHEME can be set on a window and specifies the absolute path to a .color file describing the color scheme of the managed client. The Client reads this property and creates a QPalette from it. If the property is not set or the value is incorrect, the Client uses KWin's default palette. The idea behind this property is to allow an application with a custom color scheme to tell KWin which color scheme the window decoration should use. So that the window looks as a solid pattern again.
2013-10-14 09:17:07 +04:00
Xcb::Atom kde_color_sheme;
Allow windows to specify that they should not get animated on window close By setting the X property _KDE_NET_WM_SKIP_CLOSE_ANIMATION to 1 a window can request to be excluded from any close animation. This property is read in Toplevel, so that it is available to both Client and Unmanaged. If the window has this property set the Scene suppresses the paintWindow loop of the Deleted. Thus no effect needs to be adjusted. But an effect using drawWindow directly would still be able to render the Deleted as there is no suppression. Furthermore the property is passed to the EffectWindow so that an Effect can make use of this functionality and not start the animation in the first place. REVIEW: 115288
2014-01-24 15:34:16 +04:00
Xcb::Atom kde_skip_close_animation;
Screenedge show support for Clients This provides a new protocol intended to be used by auto-hiding panels to make use of the centralized screen edges. To use it a Client can set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin. As value it takes: * 0: top edge * 1: right edge * 2: bottom edge * 3: left edge KWin will hide the Client (hide because unmap or minimize would break it) and create an Edge. If that Edge gets triggered the Client is shown again and the property gets deleted. If the Client doesn't border the specified screen edge the Client gets shown immediately so that we never end in a situation that we cannot unhide the auto-hidden panel again. The exact process is described in the documentation of ScreenEdges. The Client can request to be shown again by deleting the property. If KWin gets restarted the state is read from the property and it is tried to create the edge as described. As this is a KWin specific extension we need to discuss what it means for Clients using this feature with other WMs: it does nothing. As the Client gets hidden by KWin and not by the Client, it just doesn't get hidden if the WM doesn't provide the feature. In case of an auto-hiding panel this seems like a good solution given that we don't want to hide it if we cannot unhide it. Of course there's the option for the Client to provide that feature itself and if that's wanted we would need to announce the feature in the _NET_SUPPORTED atom. At the moment that doesn't sound like being needed as Plasma doesn't want to provide an own implementation. The implementation comes with a small test application showing how the feature is intended to be used. REVIEW: 115910
2014-02-20 15:39:23 +04:00
Xcb::Atom kde_screen_edge_show;
Announce KWin's dbus service name on a root window property KWin sets a _ORG_KDE_KWIN_DBUS_SERVICE property on the root window with the name of the DBus service it registered. The type of the property is UTF8_STRING. REVIEW: 122215
2015-01-23 11:06:05 +03:00
Xcb::Atom kwin_dbus_service;
Xcb::Atom utf8_string;
[xwl] Generic X selections translation mechanism with Clipboard support Summary: In this patch an infrastructure is created to represent generic X selections in a Wayland session and use them for data transfers between Xwayland windows and Wayland native clients. The central manager is the DataBridge class, in which Selection objects can be created. This is hard-coded and such a Selection object persists until the end of the session, so no arbitrary selections can be created on the fly. For now the X Clipboard selection is supported, whose corresponding mechanism in the Wayland protocol is just called Selection. A Selection object listens for selection owner changes on the X side and for similar events into the Wayland server interfaces. If a data provider is available a selection source object is created by the Selection object. In case data is requested on the other side, a data transfer is initialized by creating a Transfer object. A Selection keeps track of all transfers and makes sure that they are destroyed when they are finished or in case they idle because of misbehaving clients. The Clipboard class translates the X Clipboard via a proxy window. Selection changes on the Wayland side are listened to through a new signal on the active KWayland seat interface. The previously used X clipboard syncer helper is disabled. The clipboard sync autotest is changed to the new mechanism. BUG: 394765 BUG: 395313 Test Plan: Manually and clipboard sync autotest. Reviewers: #kwin Subscribers: zzag, graesslin, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D15061
2018-08-21 23:06:42 +03:00
Xcb::Atom text;
Xcb::Atom uri_list;
[xwl] text/x-uri converter for selected X url list format targets Summary: On X several target atoms are established to provide data similar to the text/uri-list target format (the respective MIME on Wayland is called text/x-uri). Firefox can send link data in the NETSCAPE_URL format ones. Chromium on the other side sends link data in the text/x-moz-url format, which transports UTF-16 text. For both these peculiarities this patch provides converter functions, that translate these formats into the Wayland native text/x-uri format. In the other direction no translation is necessary. Both browsers supports the text/uri-list format when receiving link lists. Test Plan: Manually with Firefox and Chromium. Reviewers: #kwin Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D15629
2018-08-25 00:05:35 +03:00
Xcb::Atom netscape_url;
Xcb::Atom moz_url;
[xwayland] Add support for WL_SURFACE_ID When XWayland associates a Wayland surface with an X window it sends a WL_SURFACE_ID client message to the window manager. KWin listens for this client message in Toplevel and provides it as a member in Toplevel. This requires KWin to actually start a Wayland server (and XWayland) to make proper use of the information.
2015-01-09 13:16:57 +03:00
Xcb::Atom wl_surface_id;
Restore global menu support This brings back global menu support in KWin. The DBusMenu infrastructure is different that we just read the DBus service name and menu object path from the windows rather than passing around window IDs on DBus which won't work on Wayland. Differential Revision: https://phabricator.kde.org/D3089
2017-01-11 12:21:03 +03:00
Xcb::Atom kde_net_wm_appmenu_service_name;
Xcb::Atom kde_net_wm_appmenu_object_path;
[xwl] Generic X selections translation mechanism with Clipboard support Summary: In this patch an infrastructure is created to represent generic X selections in a Wayland session and use them for data transfers between Xwayland windows and Wayland native clients. The central manager is the DataBridge class, in which Selection objects can be created. This is hard-coded and such a Selection object persists until the end of the session, so no arbitrary selections can be created on the fly. For now the X Clipboard selection is supported, whose corresponding mechanism in the Wayland protocol is just called Selection. A Selection object listens for selection owner changes on the X side and for similar events into the Wayland server interfaces. If a data provider is available a selection source object is created by the Selection object. In case data is requested on the other side, a data transfer is initialized by creating a Transfer object. A Selection keeps track of all transfers and makes sure that they are destroyed when they are finished or in case they idle because of misbehaving clients. The Clipboard class translates the X Clipboard via a proxy window. Selection changes on the Wayland side are listened to through a new signal on the active KWayland seat interface. The previously used X clipboard syncer helper is disabled. The clipboard sync autotest is changed to the new mechanism. BUG: 394765 BUG: 395313 Test Plan: Manually and clipboard sync autotest. Reviewers: #kwin Subscribers: zzag, graesslin, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D15061
2018-08-21 23:06:42 +03:00
Xcb::Atom clipboard;
Xcb::Atom timestamp;
Xcb::Atom targets;
Xcb::Atom delete_atom;
Xcb::Atom incr;
Xcb::Atom wl_selection;
Use Xcb::Atom in KWin::Atoms to resolve all atoms During startup we only create the request, the reply will be fetched once the atom is needed. To make proper use of this async behavior the creation of Atoms is moved directly to the claim of the manager selection, so they can be fetched while we wait for the previous manager selection to give up on it.
2013-09-10 15:18:55 +04:00
/**
* @internal
Use more traditional doxygen style Summary: So far we were following a bit unique and rare doxygen comment style: /** * Contents of the comment. **/ Doxygen comments with this style look balanced and neat, but many people that contribute to KWin don't follow this style. Instead, they prefer more traditional doxygen comment style, i.e. /** * Contents of the comment. */ Reviewing such changes has been a bit frustrating for me (so selfish!) and for other contributors. This change switches doxygen comment style in KWin to a more traditional style. The main reason for doing this is to make code review process easier for new contributors as well us. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22812
2019-07-29 21:58:33 +03:00
*/
Use Xcb::Atom in KWin::Atoms to resolve all atoms During startup we only create the request, the reply will be fetched once the atom is needed. To make proper use of this async behavior the creation of Atoms is moved directly to the claim of the manager selection, so they can be fetched while we wait for the previous manager selection to give up on it.
2013-09-10 15:18:55 +04:00
void retrieveHelpers();
private:
// helper atoms we need to resolve to "announce" support (see #172028)
Xcb::Atom m_dtSmWindowInfo;
Xcb::Atom m_motifSupport;
bool m_helpersRetrieved;
KWin uses kdelibs coding style.
2011-01-30 17:34:42 +03:00
};
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 21:35:43 +04:00
Create screen edge through the Platform Removes a diversion between X11 and Wayland. The base class Platform creates an instance of class Edge with plugin implementations being able to create a different type. The X11StandalonePlugin does that and creates a WindowBasedEdge. For this the implementation of WindowBasedEdge is moved from screenedges into the plugin. Unfortunately an ifdef is needed to make the screenedge test still work as expected. This should be improved in future, e.g. have a good way to load the platform plugin from the tests. Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1419
2016-04-15 14:47:56 +03:00
extern KWIN_EXPORT Atoms* atoms;
branches/work/kwin_composite becomes new trunk kwin. svn path=/trunk/KDE/kdebase/workspace/; revision=659202
2007-04-29 21:35:43 +04:00
} // namespace
#endif