summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* screen: Allow reusing the current position when quering the monitorAdel Gadllah2013-06-233-22/+66
| | | | | | Add new api (meta_screen_get_current_monitor_for_pos and meta_screen_get_current_monitor_info_for_pos) that allow querying the monitor without a roundtrip by reusing the passed in cursor position.
* compositor: Add an API to query if the stage is focusedJasper St. Pierre2013-06-204-5/+34
| | | | | | | | | | gnome-shell needs to know whether the stage window is focused so it can synchronize between stage window focus and Clutter key actor focus. Track all X windows, even those without MetaWindows, when tracking the focus window, and add a compositor-level API to determine when the stage is focused. https://bugzilla.gnome.org/show_bug.cgi?id=700735
* display: Ensure that we ignore our own focus events for focus predictionsJasper St. Pierre2013-06-202-15/+45
| | | | | | | | | | | | | | | | | | | | | | | 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
* compositor: Prevent an error in application code from keeping unredirect on ↵Adel Gadllah2013-06-181-2/+4
| | | | | | | | | | | | | permanently We substract one from the unredirect counter when enable_unredirect_for_screen gets called. It is an unsigned integer so substracting one from zero (which means enable) would overflow and thus keep it peramently enabled. This should never happen because it means there is an unmatched enable / disable pair somewhere. So in addition to fixing it add a warning when this case gets triggered. https://bugzilla.gnome.org/show_bug.cgi?id=701224
* make the window shadows lighterAllan Day2013-06-181-6/+6
| | | | | | Subtler shadows look more refined. https://bugzilla.gnome.org/show_bug.cgi?id=702141
* Bump version to 3.9.33.9.3Florian Müllner2013-06-182-1/+10
| | | | Update NEWS.
* Use new clutter_stage_set_paint_callback() function for after-paint notificationOwen W. Taylor2013-06-032-9/+10
| | | | | | | | | | | | | | | | | Commit 4f2bb583bf8c changed things so that the compositor used clutter_threads_add_repaint_func_full (CLUTTER_REPAINT_FLAGS_POST_PAINT to get after-paint notification and send _NET_WM_FRAME_DRAWN, but this doesn't actually work, since Clutter will already have blocked for VBlank before calling post-paint functions. The result is that frame synced toolkits like GTK 3.8 will normally only be able to draw every other frame. Since ::paint doesn't work either, a new function clutter_stage_set_paint_callback() has been added to Clutter (and will be included in the 1.14 branch) https://bugzilla.gnome.org/show_bug.cgi?id=698794
* keybindings: Make sure events are always reported to the grab windowRui Matos2013-05-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | We have no need for normally reported events during grabs. In fact, it might be harmful. A plugin might grab the keyboard through meta_begin_modal_for_plugin() and then expect events to be reported to the grab window they provide. If meanwhile this XIGrabDevice is issued, events might start being reported normally to one other of our windows breaking the plugin event processing. In particular, on an empty workspace, we set input focus to our no_focus_window. Then, if gnome-shell calls meta_begin_modal_for_plugin() and meta_display_freeze_keyboard(), in that order, input events will start being reported to no_focus_window. There are two issues with this. One is that no_focus_window isn't selecting for XI input events and thus the server discards them completely. But even if that is fixed, events being reported to any window other than the one gnome-shell expects - the clutter stage window - means that events will stop reaching it. https://bugzilla.gnome.org/show_bug.cgi?id=701219
* Bump version to 3.9.23.9.2Florian Müllner2013-05-282-1/+20
| | | | Update NEWS.
* Updated Norwegian bokmål translationKjartan Maraas2013-05-281-15/+15
|
* keybindings: Grab and emit a signal when XK_ISO_Next_Group is pressedRui Matos2013-05-273-0/+262
| | | | | | | | This will make it possible to implement input source switching in gnome-shell using the popular modifiers-only keybinding that's implemented on the X server through an XKB option. https://bugzilla.gnome.org/show_bug.cgi?id=697002
* prefs: Track the XKB 'grp:' option in gsettings as a keybinding prefRui Matos2013-05-272-0/+58
| | | | | | | We'll use the value of this option to establish a passive grab on the keycode/modifier combos generating XK_ISO_Next_Group. https://bugzilla.gnome.org/show_bug.cgi?id=697002
* keybindings: Add API to freeze/unfreeze the keyboardRui Matos2013-05-272-4/+47
| | | | | | | | We'll use this in gnome-shell to freeze the keyboard right before switching input source and unfreeze it after that's finished so that we don't lose any key events to the wrong input source. https://bugzilla.gnome.org/show_bug.cgi?id=697001
* prefs: Fix binding remaining grabbed after clearing all strokesRui Matos2013-05-271-9/+32
| | | | | | | | | | | If a binding is updated with a clear set of strokes (effectively disabling it) we aren't signaling that the binding changed and thus the previous strokes will continue to be grabbed. This fixes that and tries to do a better effort at checking if the binding changed or not. https://bugzilla.gnome.org/show_bug.cgi?id=697000
* Updated slovak translationJán Kyselica2013-05-251-213/+267
|
* compositor: Add an API to focus the stage X windowJasper St. Pierre2013-05-244-0/+41
| | | | | | | | | | gnome-shell has traditionally just called XSetInputFocus when wanting to set the input focus to the stage window, but this might cause strange, hard-to-reproduce bugs because of an interference with mutter's focus prediction. Add API to allow gnome-shell to focus the stage window that also updates mutter's internal focus prediction state. https://bugzilla.gnome.org/show_bug.cgi?id=700735
* display: Consolidate code calling XSetInputFocus into a new functionJasper St. Pierre2013-05-241-97/+78
| | | | | | | At the same time, rename set_focus_window and add a comment so we're not confused about which function does what. https://bugzilla.gnome.org/show_bug.cgi?id=700735
* window: Properly handle focusing override redirect windowsJasper St. Pierre2013-05-222-6/+7
| | | | | | | | | | | | If an app pops up an OR window and sets input focus to it, like Steam does, we'll think the focus window is null, causing us to think the app is not focused. OR windows should not be special if they get input focus, where the input focus would be set to NULL. Instead, the window should be marked as focused. https://bugzilla.gnome.org/show_bug.cgi?id=647706
* display: Use XI2 constants for mode/detail focus event valuesJasper St. Pierre2013-05-221-4/+4
| | | | | | This makes no functional difference, except conceptual clarity. https://bugzilla.gnome.org/show_bug.cgi?id=647706
* display: clean up focus_window vs expected_focus_windowDan Winship2013-05-227-223/+261
| | | | | | | | | | | | | | Mutter previously defined display->focus_window as the window that the server says is focused, but kept display->expected_focus_window to indicate the window that we have requested to be focused. But it turns out that "expected_focus_window" was almost always what we wanted. Make MetaDisplay do a better job of tracking focus-related requests and events, and change display->focus_window to be our best guess of the "currently" focused window (ie, the window that will be focused at the time when the server processes the next request we send it). https://bugzilla.gnome.org/show_bug.cgi?id=647706
* test-focus: test program for focus window managementDan Winship2013-05-223-1/+368
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=647706
* compositor: remove the overlay_group conceptGiovanni Campagna2013-05-222-26/+2
| | | | | | | | The hierarchy handling is handled in the shell by adding stuff directly to the uiGroup, and we have a dedicated actor for the overview there, so we don't need this anymore. https://bugzilla.gnome.org/show_bug.cgi?id=700735
* window: Clean up the set_focused_internal functionJasper St. Pierre2013-05-221-88/+80
| | | | | | | Move things out of an indentation layer, and reshuffle things around. https://bugzilla.gnome.org/show_bug.cgi?id=647706
* window: Merge got_focus/lost_focus to a new functionJasper St. Pierre2013-05-221-91/+101
| | | | | | | | | Make it a static function for now, but this will be a private function soon, replacing meta_window_lost_focus. This should contain no functional changes, only cosmetic indentation changes, so best viewed with ignorews=1 or -w or -b, you know the drill. https://bugzilla.gnome.org/show_bug.cgi?id=647706
* window: Refactor "got focus" codeJasper St. Pierre2013-05-221-70/+76
| | | | | | Just move this out to a separate function. https://bugzilla.gnome.org/show_bug.cgi?id=647706
* Updated Norwegian bokmål translationKjartan Maraas2013-05-201-12/+14
|
* compositor: Fix regression of shaded windowsStef Walter2013-05-151-2/+5
| | | | | | Fix issues drawing shaded window shadows. https://bugzilla.gnome.org/show_bug.cgi?id=693714
* window: Eliminate a potential race condition with _NET_WM_MOVERESIZEJasper St. Pierre2013-05-141-41/+78
| | | | | | | | | | | | | | | | | | | Clients using _NET_WM_MOVERESIZE to start a drag operation may encounter a race condition if the user presses and releases a mouse button very fast, getting "stuck" in a grab state. While this is easily fixed with the user pressing the button or hitting Escape as the EWMH spec suggests, its's still a bit of annoyance for users. After starting a grab operation, check that the button is actually pressed by the client, and if not, cancel the grab operation. This prevents the stuck grab in a race-free way, although it requires an extra round-trip to the server. With client-side decorations becoming more popular, the use of _NET_WM_MOVERESIZE is on the rise, thus this bug is seen more frequently than before. https://bugzilla.gnome.org/show_bug.cgi?id=699777
* prefs: Add support for string-array preferencesFlorian Müllner2013-05-131-52/+109
| | | | | | | | | | As we only had one string-array preference so far, we didn't bother with adding a generic way to handle string-array preferences, and just handled the preference in question explicitly. However we are going to parse another string-array setting, so generalize the existing code to make it reusable for that case. https://bugzilla.gnome.org/show_bug.cgi?id=700223
* window: Add an accessor for whether the window can closeJasper St. Pierre2013-05-092-0/+8
| | | | | | | The shell will use this to determine whether to show a close button in the overview. https://bugzilla.gnome.org/show_bug.cgi?id=699269
* ui: add missing delimiter in GTK-Doc comment blockDieter Verfaillie2013-05-041-1/+1
| | | | | | | | | | | | | | | | | | | | | g-ir-scanner will emit more warnings regarding broken GTK-Doc syntax in the near future, which due to --warn-error being used would break the build: ''' ui/theme.c:1883: Warning: Meta: missing ":" at column 20: * @tokens_p: (out) The resulting tokens ^ g-ir-scanner: compile: gcc -Wall -Wno-deprecated-declarations ... g-ir-scanner: link: /bin/sh ../libtool --mode=link --tag=CC gcc ... libtool: link: gcc -o /home/dieterv/gnome.org/checkout/mutter/... <unknown>:: Fatal: Meta: warnings configured as fatal <unknown>:: Fatal: Meta: warnings configured as fatal make[4]: *** [Meta-3.0.gir] Error 1 ''' https://bugzilla.gnome.org/show_bug.cgi?id=699636
* Bump version to 3.9.13.9.1Florian Müllner2013-04-302-1/+9
| | | | Update NEWS.
* window: Add missing chain-up for finalize()Pavel Vasin2013-04-291-0/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=698710
* background: Fix memory leakPavel Vasin2013-04-291-0/+12
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=698710
* barrier: Fix memory leakPavel Vasin2013-04-291-0/+4
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=698710
* Let the UI layer (via the core) construct the frame maskSimon McVittie2013-04-177-131/+131
| | | | | | | | | | | | | | | | | | | | | This essentially just moves install_corners() from the compositor, through the core, into the UI layer where it arguably should have been anyway, leaving behind stub functions which call through the various layers. This removes the compositor's special knowledge of how rounded corners work, replacing it with "ask the UI for an alpha mask". The computation of border widths and heights changes a bit, because the width and height used in install_corners() are the meta_window_get_outer_rect() (which includes the visible borders but not the invisible ones), whereas the more readily-available rectangle is the MetaFrame.rect (which includes both). Computing the same width and height as meta_window_get_outer_rect() involves compensating for the invisible borders, but the UI layer is the authority on those anyway, so it seems clearer to have it do the calculations from scratch. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=697758 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
* Fix use of uninitialized variablesStef Walter2013-04-171-9/+12
| | | | | | | If mutter is going to -Werror by default, then it can play footloose and fancy free with this sorta stuff. https://bugzilla.gnome.org/show_bug.cgi?id=698179
* Bump version to 3.8.13.8.1Florian Müllner2013-04-162-1/+15
| | | | Update NEWS.
* MetaFrames: factor out MetaUIFrame accessors for borders, corner radiusesSimon McVittie2013-04-121-17/+39
| | | | | | | | | This makes it a bit simpler for other functions on a MetaUIFrame to get this information. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=697758 Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net> Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
* keybindings: Fix ungrabbing of keysRui Matos2013-04-101-73/+89
| | | | | | | | | XUngrabKey() doesn't work for XI2 grabs and XI2 doesn't provide API with similar functionality. As such, we have to refactor the code a bit to be able to call XIUngrabKeycode() for each key binding, then reload keybindings and finally grab the new ones. https://bugzilla.gnome.org/show_bug.cgi?id=697003
* Updated Uyghur translationGheyret Kenji2013-04-061-90/+96
| | | | Signed-off-by: Gheyret Kenji <gheyret@gmail.com>
* Updated Norwegian bokmål translationKjartan Maraas2013-04-031-86/+86
|
* Updated Hebrew translation.Yaron Shahrabani2013-04-031-98/+103
|
* Updated Indonesian translationAndika Triwidada2013-03-301-326/+309
|
* Updated British English translationBruce Cowan2013-03-291-339/+325
|
* Don't redefine MetaBackgroundPrivate, fixing a build issue:Jasper Lievisse Adriaanse2013-03-291-1/+0
| | | | | compositor/meta-background.c:64: error: redefinition of typedef 'MetaBackgroundPrivate' ./meta/meta-background.h:51: error: previous declaration of 'MetaBackgroundPrivate' was here
* ui: Fix crash getting default fontBastien Nocera2013-03-291-0/+10
| | | | | | | | A correctly constructed GtkStyleContext must have its screen and widget paths set. Getting the frame font caused crashes on some systems because those were not correctly initialised. https://bugzilla.gnome.org/show_bug.cgi?id=696814
* Updated kn translationsShankar Prasad2013-03-281-205/+329
|
* l10n: fix parser error message translationGuillaume Desmottes2013-03-271-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=696690
* Bump version to 3.8.03.8.0Florian Müllner2013-03-262-2/+16
| | | | Update NEWS.
View Lorry Controller Status