Commit Graph

23 Commits

Author SHA1 Message Date
Jasper St. Pierre
0a20f7458c window: Remove support for _NET_WM_ICON_NAME
We don't seem to use it anywhere.
2014-03-18 22:04:36 -04:00
Andika Triwidada
9b21346427 Changed obsolete FSF postal address into generic URL.
Fix https://bugzilla.gnome.org/show_bug.cgi?id=721517 #2
2014-01-13 11:35:47 -05:00
Jasper St. Pierre
8131f34eb6 Move _NET_WM_WINDOW_OPACITY handling to the standard window-props interface 2013-12-09 15:53:23 -05:00
Marc-André Lureau
957513242c xrandr: use "hotplug_mode_update" property
Use the "hotplug_mode_update" connector property indicating that the
screen settings should be updated: get a new preferred mode on hotplug
events to handle dynamic guest resizing (where you resize the host
window and the guest resizes with it).

https://bugzilla.gnome.org/show_bug.cgi?id=711216
2013-11-19 13:50:15 -05:00
Giovanni Campagna
93ae868987 wayland: sync the keymap from X to wayland
When X clients change the keyboard map, the also update a property
on the root window. We can notice that and rebuild our data structures
with the new values, as well as inform the wayland clients.

This is a terrible hack, and it's not how we want to implement things
in 3.12, but it's enough to have the same keyboard layout in the
shell, in X clients and in wayland clients in 3.10, until we decide
on the fate of the keyboard g-s-d plugin.

https://bugzilla.gnome.org/show_bug.cgi?id=707446
2013-11-12 16:53:13 -05:00
Giovanni Campagna
8b52782ed4 MonitorManager: add support for backlight
GnomeRR needs that too.
The backlight is exported as a normalized 0-100 value, or -1 if not
supported. Clamping to HW limits is handled by the backend.
Changing backlight uses a different method call, to avoid recomputing
the full display configuration every time the user presses the
backlight keys.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-18 00:47:53 +02:00
Giovanni Campagna
5c27a91684 MonitorManager: store the presentation mode bit in XRandR
Use a private output property to store if the output is in
presentation mode or not, so that this information is not lost
after the configuration read back from the server.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-18 00:34:16 +02:00
Jasper St. Pierre
12d2e1f600 Support _GTK_FRAME_EXTENTS
https://bugzilla.gnome.org/show_bug.cgi?id=705766
2013-08-13 10:40:15 -04:00
Jasper St. Pierre
8c1c77482d Remove old, deprecated utilities that nobody has used in a million years
https://bugzilla.gnome.org/show_bug.cgi?id=704437
2013-08-13 09:39:02 -04:00
Jasper St. Pierre
7fdfbad6d4 display: Ensure that we ignore our own focus events for focus predictions
When we set the input focus, we first set the predicted window,
and then try to process focus events. But as XI_FocusOut on the
existing window comes before XI_FocusIn on the new window, we'll
see the focus out on the old window and think the focus is going
to nothing, which makes mutter think the prediction failed.

This didn't really matter as nothing paid attention to the focus
window changing, but with gnome-shell's focus rework, we'll try
and drop keyboard focus in events like these.

Fix this by making sure that we ignore focus window changes of our
own cause when updating the focus window field, by ignoring all
focus events that have a serial the same as the focus request or
lower. Note that if mutter doens't make any requests after the
focus request, this could be racy, as another client could steal
the focus, but mutter would ignore it as the serial was the same.
Bump the serial by making a dummy ChangeProperty request to a
mutter-controlled window in this case.

https://bugzilla.gnome.org/show_bug.cgi?id=701017
2013-06-20 17:21:54 -04:00
Tomeu Vizoso
e0b698d365 Fix gobs of gtk-doc warnings
https://bugzilla.gnome.org/show_bug.cgi?id=676856
2013-03-14 18:02:43 -04:00
Owen W. Taylor
2d9b8bb2d0 Send _NET_WM_FRAME_TIMINGS messages
We previously had timestamp information stubbed out in
_NET_WM_FRAME_DRAWN. Instead of this, add a high-resolution timestamp
in _NET_WM_FRAME_DRAWN then send a _NET_WM_FRAME_TIMINGS message
after when we have complete frame timing information, representing
the "presentation time" of the frame as an offset from the timestamp
in _NET_WM_FRAME_DRAWN.

To provide maximum space in the messages,_NET_WM_FRAME_DRAWN and
_NET_WM_FRAME_TIMINGS are not done as WM_PROTOCOLS messages but
have their own message types.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:27 -05:00
Owen W. Taylor
fbfab93c63 Send _NET_WM_FRAME_DRAWN messages
When the application provides the extended second counter for
_NET_WM_SYNC_REQUEST, send a client message with completion
information after the next redraw after each counter update
by the application.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Jasper St. Pierre
a613a55658 Support _NET_WM_OPAQUE_REGION
This new hint allows compositors to know what portions of a window
will be obscured, as a region above them is opaque. For an RGB window,
possible to glean this information from the bounding shape region of
a client window, but not for an ARGB32 window. This new hint allows
clients that use ARGB32 windows to say which part of the window is
opaque, allowing this sort of optimization.

https://bugzilla.gnome.org/show_bug.cgi?id=679901
2013-02-06 00:08:04 -05:00
Adel Gadllah
9a57626556 meta-window-actor: Change unredirection hints to match spec changes
Change the bypass / dont_bypass compositor code to match the latest
spec.

https://bugzilla.gnome.org/show_bug.cgi?id=693064
2013-02-03 14:29:45 +01:00
Adel Gadllah
3876a1a192 Support bypass compositor hints
Add support for _NET_WM_BYPASS_COMPOSITOR and _NET_WM_DONT_BYPASS_COMPOSITOR
as proposed here: https://mail.gnome.org/archives/wm-spec-list/2012-February/msg00010.html

https://bugzilla.gnome.org/show_bug.cgi?id=683020
2012-12-18 19:02:34 +01:00
Ryan Lortie
1772a2a59c adjust to new Gtk properties for app menu
https://bugzilla.gnome.org/show_bug.cgi?id=668118
2012-01-18 17:26:12 -05:00
Florian Müllner
9729a99ec5 window: Support GTK+'s hide-titlebar-when-maximized hint
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
To account for this use case, a setting for requesting that windows'
titlebars should be hidden during maximization has been added to
GTK+, add support for this in the window manager.

https://bugzilla.gnome.org/show_bug.cgi?id=665617
2011-12-15 16:37:20 +01:00
Ryan Lortie
e4ed433e18 Add _DBUS_UNIQUE_NAME and _OBJECT_PATH properties
https://bugzilla.gnome.org/show_bug.cgi?id=664851
2011-12-15 10:21:22 -05:00
Colin Walters
8ab5cc8f19 Load _DBUS_APPLICATION_ID property, expose it via API
This is used to associate GtkApplication -> X window, and will
be consumed by gnome-shell.

https://bugzilla.gnome.org/show_bug.cgi?id=664851
2011-12-15 10:12:31 -05:00
Rui Matos
6e47f0e846 window: add _NET_WM_STATE_FOCUSED hint to _NET_WM_STATE
This hint reflects whether a window appears focused.

https://bugzilla.gnome.org/show_bug.cgi?id=661427
2011-11-08 19:19:32 +00:00
Florian Müllner
4f3b03e13b window: Parse _GTK_THEME_VARIANT property
Since version 3.0, GTK+ has support for style variants. At the moment,
themes may provide a dark variant, which can be requested by
applications via GtkSettings. The requested variant is exported to
X11 via the _GTK_THEME_VARIANT property - support this property, in
order to pick up the correct style variant in the future.

https://bugzilla.gnome.org/show_bug.cgi?id=645355
2011-05-18 23:07:23 +02:00
Dan Winship
c84da3ce1b Move the installed includes to a subdir
If mutter is going to be a "real" library, then it should install its
includes so that users can do

    #include <meta/display.h>

rather than

    #include <display.h>

So rename the includedir accordingly, move src/include to src/meta,
and fix up all internal references.

There were a handful of header files in src/include that were not
installed; this appears to have been part of a plan to keep core/,
ui/, and compositor/ from looking at each others' private includes,
but that wasn't really working anyway. So move all non-installed
headers back into core/ or ui/.

https://bugzilla.gnome.org/show_bug.cgi?id=643959
2011-03-07 18:19:53 -05:00