summaryrefslogtreecommitdiff
path: root/src/ui
Commit message (Collapse)AuthorAgeFilesLines
* cleanup: Don't use g_memmove()Florian Müllner2019-07-181-2/+2
| | | | | | | | | Glib stopped providing any fallback implementations on systems without memmove() all the way back in 2013. Since then, the symbol is a simple macro around memmove(); use that function directly now that glib added a deprecation warning. https://gitlab.gnome.org/GNOME/mutter/merge_requests/689
* theme: Remove DEBUG_FILL_STRUCTMarco Trevisan (Treviño)2019-05-271-4/+0
| | | | | | | | This debug statement is actually applied all the times, while it could be useful for crashes analysis, these days the same can be done using `MALLOC_CHECK_` and `MALLOC_PERTURB_` env variables. https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
* frame: Remove flashing supportwip/fmuellner/flash-flashFlorian Müllner2019-03-121-2/+0
| | | | | | It's now unused. https://gitlab.gnome.org/GNOME/mutter/issues/491
* Use a consistent style for enum bracesNiels De Graef2019-02-281-1/+2
| | | | https://gitlab.gnome.org/GNOME/mutter/merge_requests/361
* ui: Remove fallback app menuFlorian Müllner2019-01-304-42/+3
| | | | | | | | | | | | The app menu is in the process of being retired[0], and the shell stopped displaying it while applications are in the process of dropping it. It therefore doesn't make sense to always show a fallback menu in server-side decorations, applications that still set the menu can rely on GTK+'s own fallback instead. [0] https://gitlab.gnome.org/GNOME/Initiatives/wikis/App-Menu-Retirement https://gitlab.gnome.org/GNOME/gnome-shell/issues/624
* Fix builds with G_DISABLE_ASSERTFlorian Müllner2019-01-251-0/+3
| | | | | | | | | Commit 25f416c13db added additional compilation warnings, including -Werror=return-type. There are several places where this results in build failures if `g_assert_not_reached()` is disabled at compile time and the compiler misses a return value. https://gitlab.gnome.org/GNOME/mutter/issues/447
* meta: Hide libmutter symbols by default and selectively export themMarco Trevisan (Treviño)2019-01-231-1/+3
| | | | | | | | | | | | | Make meson link libmutter using -fvisibility=hidden, and introduce META_EXPORT and META_EXPORT_TEST defines to mark a symbols as visible. The TEST version is meant to be used to flag symbols that are only used internally by mutter tests, but that should not be considered public API. This allows us to be more precise in selecting what is exported and what is not, without the need of a version-script file that would be more complicated to maintain. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
* theme: Drop gtk_css_provider_get_default()Georges Basile Stavracas Neto2018-11-081-4/+18
| | | | | | | Instead of using gtk_css_provider_get_default(), add a static GtkCssProvider and fetch it instead. Creating GtkCssProviders consume a bit more memory, so keeping a single one alive is slightly more memory saving.
* Clean up include macros messJonas Ådahl2018-11-066-41/+47
| | | | | | The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
* Split GDK initialization from MetaUIArmin Krezović2018-07-062-51/+12
| | | | | | Get rid of the deprecated gdk_display_get_default_screen () https://bugzilla.gnome.org/show_bug.cgi?id=759538
* frames: Allow for unknown mouse buttonsOlivier Fourdan2018-05-251-4/+11
| | | | | | | | | | Commit 47131b1d ("frames: Handle touch events") introduced an assert to make sure that all mouse button actions are handled in mutter. However, mice can have a more than 5 buttons, so simply ignore the "other" actions instead of aborting. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/160
* frames: Handle touch eventswip/carlosg/touch-on-framesCarlos Garnacho2018-05-142-29/+137
| | | | | | | | | | | | This is just done on wayland as it'll break horribly on X11, we let this happen through pointer emulated events in XISelectEvents evmask instead. Some things had to be made slightly more generic to accomodate touch events. The MetaFrames shall lock onto a single touch at a time, we don't allow crazy stuff like multi-window drag nor multi-edge resizes. https://bugzilla.gnome.org/show_bug.cgi?id=770185
* frames: Make 1st button/motion handlers take generic eventsCarlos Garnacho2018-05-141-51/+77
| | | | | | This will ease handling of touch events through these same handlers. https://bugzilla.gnome.org/show_bug.cgi?id=770185
* theme, frames: Use surface device scale instead of cairo_scaleMarco Trevisan (Treviño)2018-04-202-4/+22
| | | | | | | | | | | Gtk now is caching the themed cairo surfaces, then as per commit gtk@e36b629c the surface device scale is used to figure out the current paint scaling. Without this when using background-image's for window buttons the -gtk-scaled icons isn't properly resized. Fixes #99
* theme: Scale titlebar spacing when computing xMarco Trevisan (Treviño)2018-04-031-1/+1
| | | | | | | The value is not scaled by default so it needs to be adjusted depending on the window scaling, as it's done in other places. Fixes: #87
* theme: add ".appmenu" class to the appmenu buttonMarco Trevisan (Treviño)2018-04-031-0/+2
| | | | So it does gtk headerbar, so mutter should do.
* theme: Fix icon scalingEgmont Koblinger2018-03-031-4/+4
| | | | | | | | | | | | | When painting the titlebar, button icons that aren't available in the desired size need to be scaled. However the current code inverses the scale factor, with the result that the adjusted icons are much worse than the original icons, whoops. This went unnoticed for a long time given that most icons are availa- ble in the desired 16x16 size, and the most likely exceptions - window icons - are not shown by default. https://gitlab.gnome.org/GNOME/mutter/issues/23
* window: Allow resizing of tiled windowsFlorian Müllner2017-10-031-2/+5
| | | | | | | | | | | | Currently tiled windows are not resizable and their size is fixed to half the screen width. Adjust the code to work with fractions other than half, and allow users to adjust the split by dragging the window edge that is not constrained by a monitor edge. Follow-up patches will improve on that by resizing neighboring tiled windows by a shared edge, and making the functionality available to client-side decorated windows implementing the new edge constraints protocol.
* frames: use correct variable in for loop assignmentShantanu Goel2017-04-041-1/+1
| | | | | | | | | | | | | | | | | | | update_context_styles is using the wrong variable when advancing to the next key in the hash table which can cause an infinite loop if # of variants is ever greater than 1. This problem was originally reported here: https://github.com/linuxmint/Cinnamon/issues/5254 The following patch was commited in Mint: https://github.com/linuxmint/muffin/commit/6120bdde This patch is just a shorter version of the Mint patch and they deserve all the credit for the idea. https://bugzilla.gnome.org/show_bug.cgi?id=780254
* ui/frames: Simplify client area control computationRui Matos2017-03-021-16/+3
| | | | | | | | | | | | | | | | | | | | | | | | Ungrabbed pointer motion events over a client window area don't even reach mutter in X compositor mode, but as a wayland compositor we process those events which ends up in a call stack like: - meta_window_handle_ungrabbed_event - meta_ui_frame_handle_event - handle_motion_notify_event - get_control - meta_ui_frame_calc_geometry Computing frame geometry is a relatively CPU expensive operation and doing it on every motion event over a client window is pointless work since we aren't going to change the cursor or prelight any frame widget. This commit special cases the determination of META_FRAME_CONTROL_CLIENT_AREA using a much faster method. When continuously moving the pointer over an X (client) window, it results in a ~40% decrease in mutter cpu usage. https://bugzilla.gnome.org/show_bug.cgi?id=779436
* Always use the default screenJonas Ådahl2016-07-234-19/+12
| | | | | | | | | GDK doesn't support multiple screens, so effectively we don't either. Lets stop pretending we do. This fixes a few -Wdeprecated warnings. https://bugzilla.gnome.org/show_bug.cgi?id=769070
* ui/frames: Drop the current grab info on button releaseRui Matos2016-06-231-0/+1
| | | | | | | | This was added in commit d05b750b8dec3825d286e3ae30c41b41bd6aed98 and later removed inadvertently in commit d561b3b18f73a66bcd7947dce7ab1aab9e09965a . https://bugzilla.gnome.org/show_bug.cgi?id=767969
* frames: "Initialize" frame backgroundFlorian Müllner2016-06-231-0/+7
| | | | | | | | | | | | | | | Frames are painted on the frame window according to the GTK+ theme. Depending on the target's visual, this means either drawing over a black destination or a fully transparent one. So in cases where the theme doesn't paint decorations with full opacity, decorations for windows with an rgba visual look different from those with a non-rgba visual. Using an rgba visual for all frames independent from the client's visual can potentially break clients, so our only option for a consistent appearance is to explicitly initialize the frame background to black before painting the theme's decoration on top. https://bugzilla.gnome.org/show_bug.cgi?id=745060
* frames: Don't clip out "invisible" parts of framesFlorian Müllner2016-06-231-10/+10
| | | | | | | | | | | | | | | | | The GTK+ theme may draw parts of the decorations outside the actual frame. Since commit f9db65f47f we make sure that the frame is big enough to account for any overdrawing, however as we still clip the cairo context to the actual frame before drawing the decorations, those parts aren't actually painted. This issue is not very obvious for most frames, as they use a non-rgba visual where the unpainted parts appear black, which gives the expected result with many themes once the shape mask is applied (as the mask does include any overdrawn parts). For frames using an rgba visual however, unpainted parts are transparent, so any overdrawn decorations are clearly missing. Fix this by only clipping out the client area when drawing decorations. https://bugzilla.gnome.org/show_bug.cgi?id=745060
* theme: set RTL/LTR flags on the style contextCosimo Cecchi2016-04-091-0/+14
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=764807
* theme: Take invisible borders required by the theme into accountFlorian Müllner2016-02-042-4/+18
| | | | | | | | | | | GTK+ paints some elements like box shadows (which Adwaita likes to (ab)use for borders) outside the rectangle passed to gtk_render_*. This is not an issue if our own invisible frame border is big enough, but in case of non-resizable windows we end up clipping away part of the decoration. Use the newly added gtk_render_background_get_clip() to make sure we always use a mask that is large enough to contain all decorations. https://bugzilla.gnome.org/show_bug.cgi?id=752794
* theme: Update style context hierarchy (again)Florian Müllner2016-02-043-3/+13
| | | | | GtkWindow actually uses two CSS nodes, 'window' and 'decoration'. Simulate that by using two separate style contexts for the frame.
* frames: don't force dark theme to all windowsAlberts Muktupāvels2016-02-041-8/+4
| | | | | | | | Use global theme variant only if window does not have _GTK_THEME_VARIANT property. This allows applications to request default theme variant when global dark theme is enabled. https://bugzilla.gnome.org/show_bug.cgi?id=761543
* frames: default theme variant now is set as empty stringAlberts Muktupāvels2016-02-041-1/+1
| | | | | | | Related change in GTK+: https://git.gnome.org/browse/gtk+/commit/?id=8eb261988869608604c78ed90de5579beb4ef2b0 https://bugzilla.gnome.org/show_bug.cgi?id=761543
* theme: Support margins on titlebar title/buttonsFlorian Müllner2016-01-212-3/+34
| | | | | | GTK+ improved its CSS support, and the default theme started to make use of it, so we must update our theming code accordingly. Add support for margins where they make sense.
* theme: Consider minimum sizesFlorian Müllner2016-01-212-4/+29
| | | | | | GTK+ improved its CSS support, and the default theme started to make use of it, so we must update our theming code accordingly. Start by supporting min-width/min-height where it makes sense.
* Revert "frame: Don't allow resizing of edges that are constrained"Florian Müllner2016-01-101-8/+5
| | | | This reverts commit 8a481b3e1039f58067293132777c80c061a63b72.
* frame: Don't allow resizing of edges that are constrainedJasper St. Pierre2016-01-091-5/+8
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=751857
* ui/frames: Don't focus if the button press is on the client areaRui Matos2016-01-051-5/+4
| | | | | | | | | | | This is a really old behavior introduced in commit 585e3625266dd0fadcdb033739760db423d31714 which is inconsistent since it only applies to SSD windows. If we really want this, we should focus the window elsewhere so that it applies consistently to all windows. https://bugzilla.gnome.org/show_bug.cgi?id=756789
* theme: Shut up some GTK+ warningsFlorian Müllner2015-11-241-2/+3
| | | | | | GTK+ started to complain when the state parameter passed to any gtk_style_context_get*() method mismatches the context's current state a while ago.
* theme: Update style hierarchy (again)Florian Müllner2015-11-121-6/+4
| | | | | GTK+ has updated some more widgets to use element names, so do some catching up again ...
* theme: Set object-name on style contextsFlorian Müllner2015-10-271-0/+9
| | | | | | | | The default theme started to use them in GTK+ commit 371f50, so we need to update the style contexts to keep matching the style of client-side decorations. https://bugzilla.gnome.org/show_bug.cgi?id=757101
* theme: Complete removal of "fringe" titlebar button supportFlorian Müllner2015-10-164-176/+3
| | | | | | We have been ignoring those buttons since 3.16 after they had been broken in the default theme for a couple of versions. As nobody appears to miss them, it's time to remove them for good.
* theme: Reset button style state when done drawingFlorian Müllner2015-10-161-0/+1
| | | | | | | | We use a single style context to draw titlebar buttons, updating its state according to each button's prelight state as necessary. This assumes that the original state is neither ACTIVE nor PRELIGHT, which means we need to reset the state after drawing to avoid propagating the state of the last-drawn button.
* theme: Stop hiding titlebar buttons in dialogsFlorian Müllner2015-10-071-2/+0
| | | | | | | As design patterns have evolved, dialogs that use CSD do use titlebar buttons, so it's time to re-enable them for SSD as well. https://bugzilla.gnome.org/show_bug.cgi?id=641630
* frames: handle META_FRAME_CONTROL_NONE on left clickMarek Chalupa2015-07-151-0/+5
| | | | | | | | | | We can get this operation in some cases, for example when we're trying to resize window that cannot be resized. This can occur with maximized windows that have a border (without border we couldn't resize them by mouse in maximized state). In this case we reached abort() beacuse we did not handle this op. https://bugzilla.gnome.org/show_bug.cgi?id=751884
* theme: Fix C++-ismJasper St. Pierre2015-07-011-1/+1
|
* prevent duplicate declaration of MetaUIFrameJasper Lievisse Adriaanse2015-06-261-2/+1
| | | | fixes bug 747326
* theme: Make sure to clear the entirety of buttons properlyJasper St. Pierre2015-06-231-1/+1
| | | | | | | | | | | | In commit cc5def1, buttons were changed from GdkRectangles to MetaButtonSpace units, but the corresponding memset hack was not. This means that the clickable portion of the unshade rectangle was always set to uninitalized memory. The effects of this were random, but in cases where the moon is aligned just right, the rectangle would graze over the borders, and so it would take priority over other borders and show a pointer cursor instead of a resize cursor.
* theme: Scale window decorations on HiDPI displaysFlorian Müllner2015-03-173-30/+84
| | | | | | | | As we opt out of GTK+/Clutter's HiDPI handling, we need to apply the window scaling factor manually to decorations, both the geometry and when drawing. https://bugzilla.gnome.org/show_bug.cgi?id=744354
* ui: Remove device events from X11 maskJasper St. Pierre2015-03-131-7/+1
| | | | These interfere with our touch handling.
* ui: Fix undefined variable warningJasper St. Pierre2015-03-131-0/+1
| | | | gcc is super smart and notices that we don't have a default case here.
* theme: Stop clipping titlebar buttonsFlorian Müllner2015-03-111-3/+1
| | | | | | There is no good reason to do so, besides a nice way to check whether a particular button is enabled. However there are legitimate reasons for overdrawing like box-shadows or outlines, so remove the clip.
* frames: Refactor out another inner switchJasper St. Pierre2015-03-081-40/+30
|
* frames: Refactor control handling with a switch statementJasper St. Pierre2015-03-081-71/+75
|
View Lorry Controller Status