- 12 Sep, 2020 1 commit
-
-
Alberts Muktupāvels authored
#13
-
- 05 Sep, 2020 2 commits
-
-
Alberts Muktupāvels authored
And deprecate old compositing-manager setting.
-
Alberts Muktupāvels authored
-
- 29 Apr, 2020 2 commits
-
-
Alberts Muktupāvels authored
1) These buttons are broken with default GTK theme. As nobody has reported bug I assume these buttons are unused. GTK is default theme type since 3.2.0. 2) These buttons are not supported by client side decorated windows. 3) Few Metacity themes I checked had no icons for these buttons. They had empty draw_ops... 4) These buttons has been removed also from Mutter. Functionality itself is not removed! Still available using window menu and/or keybindings.
-
Alberts Muktupāvels authored
This button has never been used by Metacity nor by Compiz. Remove everyting related to this button.
-
- 27 Mar, 2020 1 commit
-
-
Alberts Muktupāvels authored
Reduced resources setting was used to disable minimize effect and to show wireframe when moving or resizing windows. Minimize effect still can be disabled by using enable-animations setting from org.gnome.desktop.interface schema. And if you are really trying to reduce resource usage you probably already have animations disabled. Wireframe mode has not been updated/fixed to work with CSD windows and/or to exclude shadow/resize area from SSD windows. Also quickly testing with and without compositor wireframe sometimes leaves parts of frame on screen. Considering that there has not been any bug report about broken wireframe mode I think it is time to remove it instead of wasting time trying to fix something that nobody is using.
-
- 28 Feb, 2020 2 commits
-
-
Alberts Muktupāvels authored
-
Alberts Muktupāvels authored
-
- 29 Nov, 2019 1 commit
-
-
Alberts Muktupāvels authored
When window that is direct child of root window and have input focus with revert_to set to RevertToParent closes focus will revert to root window. This used to be problem when metacity did not manage override redirect windows. Now fix in commit 714fb3d5 is obsolete as metacity these days have MetaWindow also for override redirect windows, meaning that focus will be moved to another window when any focused window will close. Also debug message is misleading, it has nothing to do with gnome-session. For example closing any client side decorated GTK window will log this debug message and may move focus to wrong window as we no longer have not_this_one window. Original bug: https://bugzilla.gnome.org/show_bug.cgi?id=153220
-
- 13 Sep, 2019 3 commits
-
-
Alberts Muktupāvels authored
Changes in window decoration result in the window being reparented in and out its frame. This in turn causes unmap/map events, and FocusOut if the window happened to be focused. In order to preserve the focused window across the decoration change, add a flag so that the focus may be restored on MapNotify. Based on mutter commit: mutter@8dcac664
-
Alberts Muktupāvels authored
-
Alberts Muktupāvels authored
A base type shouldn't know about subtypes. Move needed functionality to MetaDisplay.
-
- 22 Aug, 2019 1 commit
-
-
Alberts Muktupāvels authored
-
- 18 Aug, 2019 1 commit
-
-
Alberts Muktupāvels authored
The default configuration of libinput-gestures utility invokes wmctrl to switch between desktops. It uses wmctrl because this works on both Xorg and Wayland (via XWayland). Unfortunately, this generates the following warning message every time, in both Xorg and Wayland desktops: "Received a NET_CURRENT_DESKTOP message from a broken (outdated) client who sent a 0 timestamp" The desktop switch still works fine. The tiny code change here removes this specific warning because, as the prefacing code comment originally said and still says, older clients can validly pass a 0 time value so why complain about that? I also refactored the "if (workspace)" code slightly to avoid the double test of the workspace value. Based on mutter commit: mutter@e9cc220c
-
- 14 Aug, 2019 1 commit
-
-
Alberts Muktupāvels authored
Commit 37fa0d19 replaced gtk_menu_popup with gtk_menu_popup_at_rect to avoid deprecated warning making it more complicated then needed. gtk_menu_popup_at_rect requires two parameters that are not always available. For example we don't have GdkWindow for CSD windows. And next commit will popup menu in response of ClientMessage event where we don't have any info about key and/or button press events. Simplify code by creating fake event in menu.c with minimal data needed for gtk_menu_popup_at_rect. GdkEvent is used to get GdkDevice, button and time. For GdkWindow we can use root window.
-
- 13 Aug, 2019 1 commit
-
-
Alberts Muktupāvels authored
glib@626b6f5e Replace g_get_current_time with g_get_real_time that has been documented to be functionally equivalent.
-
- 29 Nov, 2018 1 commit
-
-
Alberts Muktupāvels authored
According to ICCCM client is allowed to go from Withdrawn to Iconic state. Also there are x11 apps that has -iconic command line option that was broken. Revert 6875256e commit to restore previous behaviour. #4
-
- 09 Sep, 2018 1 commit
-
-
Alberts Muktupāvels authored
-
- 08 Sep, 2018 2 commits
-
-
Owen W. Taylor authored
When a client spontaneously focuses their window, perhaps in response to WM_TAKE_FOCUS we'll get a FocusOut/FocusIn pair with same serial. Updating display->focus_serial in response to FocusOut then was causing us to ignore FocusIn and think that the focus was not on any window. We need to distinguish this spontaneous case from the case where we set the focus ourselves - when we set the focus ourselves, we're careful to combine the SetFocus with a property change so that we know definitively what focus events we have already accounted for. https://bugzilla.gnome.org/show_bug.cgi?id=720558
-
Alberts Muktupāvels authored
When we set the input focus, we first set the predicted window, and then try to process focus events. But as FocusOut on the existing window comes before 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 metacity think the prediction failed. 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 metacity doens't make any requests after the focus request, this could be racy, as another client could steal the focus, but metacity would ignore it as the serial was the same. Bump the serial by making a dummy ChangeProperty request to a metactiy-controlled window in this case. Based on mutter commit: mutter@7fdfbad6
-
- 02 Sep, 2018 1 commit
-
-
Alberts Muktupāvels authored
-
- 16 Jun, 2018 2 commits
-
-
Alberts Muktupāvels authored
Follow mutter and rename xineramas to monitors.
-
Alberts Muktupāvels authored
Solaris should work with Xfree Xinerama according to these bugs: - https://bugzilla.gnome.org/show_bug.cgi?id=674727 - https://bugzilla.gnome.org/show_bug.cgi?id=580079
-
- 11 Mar, 2018 1 commit
-
-
Alberts Muktupāvels authored
-
- 21 Jul, 2017 1 commit
-
-
Owen W. Taylor authored
Since meta_workspace_invalidate_work_area() frees the edges workspace->screen_edges and workspace->monitor_edges, we must clean up our cached edge resistance data when the invalidate_work_area() is called on the active workspace, or when the workspace changes. Make the computation of the edge resistance data lazy so that it will be recomputed the next time we try to access it. meta_display_compute_resistance_and_snapping_edges() is made private to edge-resistance.c Invaliding the data when active workspace changes also will improve correctness for edge resistance when the current workspace changes during a grab operation. (Even with this fix we still don't try to handle window positions changing during a grab operation; that can't cause a crash since, unlike screen and monitor edges, the window edges are freshly allocated, it will just cause slight oddness in that corner case.) Root cause tracked down due to much effort by Jon Nettleton. https://bugzilla.gnome.org/show_bug.cgi?id=608800 (Mutter) https://bugzilla.gnome.org/show_bug.cgi?id=603632 (Metacity)
-
- 04 Jul, 2017 1 commit
-
-
Alberts Muktupāvels authored
-
- 19 Jun, 2017 2 commits
-
-
Alberts Muktupāvels authored
-
Alberts Muktupāvels authored
-
- 25 Apr, 2017 1 commit
-
-
Alberts Muktupāvels authored
Commit 23fcfbf1 was supposed to use alarm_window not display->grab_window... https://git.gnome.org/browse/mutter/commit/?id=7743c70d4753e1bd299f59e3f252257464031ff2
-
- 20 Apr, 2017 2 commits
-
-
Alberts Muktupāvels authored
-
Alberts Muktupāvels authored
-
- 01 Apr, 2017 1 commit
-
-
Jasper St. Pierre authored
-
- 18 Mar, 2017 2 commits
-
-
Jasper St. Pierre authored
It was never turned on for all the years it's been there.
-
Daniel Drake authored
Remove some obvious server grabs from the window creation codepath, also ones that are taken at startup. During startup, there is no need to grab: we install the event handlers before querying for the already-existing windows, so there is no danger that we will 'lose' some window. We might try to create a window twice (if it comes back in the original query and then we get an event for it) but the code is already protected against such conditions. When windows are created later, we also do not need grabs, we just need appropriate error checking as the window may be destroyed at any time (or it may have already been destroyed). The stack tracker is unaffected here - as it listens to CreateNotify and DestroyNotify events and responds directly, the internal stack representation will always be consistent even if the window goes away while we are processing MapRequest or similar. https://bugzilla.gnome.org/show_bug.cgi?id=721345
-
- 16 Mar, 2017 1 commit
-
-
Jasper St. Pierre authored
-
- 12 Mar, 2017 5 commits
-
-
Alberts Muktupāvels authored
-
Alberts Muktupāvels authored
-
Alberts Muktupāvels authored
-
Alberts Muktupāvels authored
-
Alberts Muktupāvels authored
-