summaryrefslogtreecommitdiff
path: root/src/ui
AgeCommit message (Collapse)AuthorFilesLines
2021-03-06i18n: Use glib's gettext support macrosrbuj7-5/+15
2020-09-05Do not call cairo paint on generate_pixmaps.rcaridade1451-2/+0
Based on Metacity commit https://gitlab.gnome.org/GNOME/metacity/-/commit/0b2f5ad0a2f30726ac0dc59aa59f7f513e91c832 Fixes transparent windows.
2020-09-01theme: macro "ALPHA_TO_UCHAR" is not usedrbuj1-2/+0
2020-08-04Remove multiple empty linesrbuj16-39/+0
find . \( -name '*.h' -o -name '*.c' \) -exec sed -i 'N;/^\n$/D;P;D;' {} \;
2020-08-04Remove trailing spaces/tabsrbuj2-5/+5
find . \( -name '*.h' -o -name '*.c' \) -exec sed -i 's/[[:space:]]*$//' {} \; find . \( -name '*.h' -o -name '*.c' \) -exec sed -i 's/\t*$//' {} \;
2020-06-16Remove enum conversion warningsrbuj3-5/+5
2020-05-27In the pop-up workspace switcher, show the selected workspace withWilliam Bader1-1/+10
a dark color when compositing is disabled. Updates #566 which changed the selected workspace to a light color on a light background.
2020-02-21theme: avoid deprecated g_memmovercaridade1451-3/+3
https://gitlab.gnome.org/GNOME/glib/commit/6554c91b https://gitlab.gnome.org/GNOME/glib/commit/6e4a7fca based on https://gitlab.gnome.org/GNOME/metacity/commit/359f60a6
2020-02-21frames: don't bother painting the backgroundrcaridade1451-23/+0
GDK (and also GTK+!) do this for us already. based on https://gitlab.gnome.org/GNOME/metacity/commit/1dcde194
2019-12-05theme.c: Fix window control hidpi rendering for all themes.Michael Webster1-3/+15
By scaling the pixbuf when loading, existing assets can be used.
2019-10-27tabpopup: Fix deprecation warningsVictor Kareh1-26/+38
2019-10-27tabpopup: Make workspaces compatible with OSD popupVictor Kareh2-25/+23
When drawing the workspace switcher OSD, we want it to be slightly transparent to match the OSD style. Also changed how the popup size is calculated and changed window icons to cairo surfaces.
2019-10-27tabpopup: Render window thumbnail as cairo surfaceVictor Kareh1-10/+20
Instead of converting from surface to a GdkPixbuf and then back to a surface, we keep it as a surface for the entire manipulation flow. This improves rendering speed a bit and sets the ground for a higher resolution thumbnail in the future.
2019-10-27tabpopup: Draw transparent OSD-style popupsVictor Kareh1-56/+89
2019-10-07theme: Render window control buttons and icons as surfacesVictor Kareh2-24/+291
When loading window control buttons and icon as pixbufs, we just set them as the source for the cairo context used to paint them. Instead, we now convert them to cairo surfaces and scale them to the correct display density before painting them. This allows us to load higher resolution assets (i.e. at twice the size) and by explicitly setting the intended size in the theme draw_ops, we can then scale them down to fit lower resolution displays, or render them at full density for HiDPI displays.
2019-09-19Remove warning: format not a string literal, argument types not checkedrbuj1-7/+1
ui/tabpopup.c:176:7: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] 176 | tmp = g_markup_printf_escaped (formatter, str); | ^~~
2019-08-10frames: bump priority of style providersmonsta1-1/+1
finally, apps that prefer dark theme variant (gtk-application-prefer-dark-theme in GtkSettings) should also have dark window decorations taken from: https://github.com/GNOME/metacity/commit/6b0d325442b995a78b8783384f7ec370db1369a4
2019-08-10frames: apply modified hack from Mutter/Metacitymonsta3-27/+25
- this will be needed for proper window decoration color updates on theme change when theme variants fixes are applied - realize/unrealize functions are dropped instead of map/unmap ones, because we didn't change these during GTK+3 porting - MetaFrames now has GtkWindow as parent instead of GtkInvisible, otherwise the hack doesn't work (revert part of 96c7256d638b8c76c8abf786ba307e82a595dd67) adapted from: https://github.com/GNOME/metacity/commit/ba8500663457ad9f18ebfdf405162c2cb5caf88f
2019-08-10frames: avoid infinite loop on the variants GListmonsta1-4/+4
and make variable names less similar taken from: https://github.com/linuxmint/muffin/commit/6120bddefd709d3f1
2019-08-10frames: use style_updated instead of style_setmonsta1-6/+4
guess it was overlooked when porting to GTK+3
2019-06-07Make alt+tab max columns configurable and consider window label widthosch1-13/+43
2019-06-05theme: Fix window state when tiling from maximizedVictor Kareh1-0/+2
2019-06-05frames: include invisible area in cacheVictor Kareh1-11/+11
GTK+ theme might use this area to paint box-shadow. Also use CAIRO_CONTENT_COLOR_ALPHA for cairo surfaces. upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/13137b1d
2019-06-05frames: Rename layout to text_layoutVictor Kareh2-25/+19
... to differentiate PangoLayout from MetaFrameLayout. https://bugzilla.gnome.org/show_bug.cgi?id=741917 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/8e5781bc
2019-06-05theme: fix warningVictor Kareh1-0/+1
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/3a3c47e3
2019-06-05frames: again change meta_frames_applet_shapesVictor Kareh2-64/+29
With compositing manager: 1. Apply only client shape. Without compositing manager: 1. Apply client shape. 2. Apply shape around visible frame. upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/3913dcf1
2019-06-05Fix scaling overcorrection when caching frame bordersVictor Kareh1-18/+16
2019-06-05frames: apply shapes in different wayVictor Kareh2-4/+53
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/cd383e72
2019-06-05frames: add dest_kind to apply_cairo_region_to_windowVictor Kareh1-3/+4
upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/94c8d620
2019-06-05frames: Fall back to title bar if nothing else matchedVictor Kareh1-1/+4
The condition got removed in eeb2efe01001fef7655b2ba95ca1456f7fe9214b but that had a side effect of adding a couple of rows of dead pixels so add it back. https://bugzilla.gnome.org/show_bug.cgi?id=658069 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/37e1fa8c
2019-06-05theme-viewer: Fix invisible bordersVictor Kareh2-10/+11
https://bugzilla.gnome.org/show_bug.cgi?id=662895 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/6836a621
2019-06-05theme: don't add invisible borders for windows that can't be resizedVictor Kareh1-7/+14
Invisible borders are all about resizing -- in the case that a window cannot be resized, it makes no sense to add them. https://bugzilla.gnome.org/show_bug.cgi?id=659854 Based on mutter commit: https://git.gnome.org/browse/mutter/commit/?id=be9f7d77292c1dfd868640fe95f7223fbbfd4273 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/64615667
2019-06-05theme: Don't add any bottom border to shaded windowsVictor Kareh1-4/+4
Shaded windows are assumed to be reduced to the titlebar: the current code enforces a visible bottom border of 0 and only takes the size of the title bar (+ invisible top border) into account when resizing the frame. However, we still add an invisible border at the bottom, which is than subtracted from the title bar, resulting in shaded windows being cut off. Fix by forcing both visible and invisible bottom borders to 0. https://bugzilla.gnome.org/show_bug.cgi?id=659266 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/7a80fcfd
2019-06-05ui: Replace inline borders in MetaFrameGeometry with MetaFrameBorderVictor Kareh3-172/+198
... and start compensating for invisible borders in all of the math. https://bugzilla.gnome.org/show_bug.cgi?id=644930 NOTE: Updated for marco... upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/daf6bc08
2019-06-05MetaFrameBorders: add invisible bordersVictor Kareh2-0/+20
This just adds the invisible border field and populates it with data but doesn't use it in any way. Based on mutter commit: https://git.gnome.org/browse/mutter/commit/?id=a1a2527c75ab0c135f89396ea036336fb67ac538 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/bf02c7c3
2019-06-05theme: add invisible_border to metacity themeVictor Kareh1-0/+5
This adds 'invisible_border' to be used for resize cursor area.
2019-06-05MetaFrames: factor out MetaUIFrame accessors for borders, corner radiusesVictor Kareh1-15/+38
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 <[email protected]> Signed-off-by: Simon McVittie <[email protected]> upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/79384de0
2019-06-05frame: Add "get_corner_radiuses" chainVictor Kareh3-0/+55
https://bugzilla.gnome.org/show_bug.cgi?id=628195 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/3994d7a0
2019-06-05Only shadow ARGB windows with a frame outside the frameVictor Kareh3-68/+135
An ARGB window with a frame is likely something like a transparent terminal. It looks awful (and breaks transparency) to draw a big opaque black shadow under the window, so clip out the region under the terminal from the shadow we draw. Add meta_window_get_frame_bounds() to get a cairo region for the outer bounds of the frame of a window, and modify the frame handling code to notice changes to the frame shape and discard a cached region. meta_frames_apply_shapes() is refactored so we can extract meta_frames_get_frame_bounds() from it. https://bugzilla.gnome.org/show_bug.cgi?id=635268 NOTE: Applied only partially, compositor part is still missing... upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/0f2e32d1
2019-06-05Fix XShapeVictor Kareh1-1/+1
Commit https://gitlab.gnome.org/GNOME/metacity/commit/c3a04bf unintentionally broke XShape handling. By studying the code extremely carefully, I found this inconsistency with the code that was there before. https://bugzilla.gnome.org/show_bug.cgi?id=635268 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/2b1c6443
2019-06-05theme: Make meta_frame_draw_theme take a GtkStyleContext instead of a widgetVictor Kareh5-56/+21
The style context of the widget is rarely what we want. We won't fix this to be a MetaFrames style context yet; this just changes the internal API. https://bugzilla.gnome.org/show_bug.cgi?id=690317 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/76aa0704
2019-06-05frames: Explicitly initialize style contextsVictor Kareh1-0/+1
We were relying on GTK+ emitting GtkWidget::style-updated during widget initialization to create the GtkStyleContexts used for window decorations. A recent GTK+ update broke this assumption, so do the necessary initialization ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=671796 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/e4fde7b0
2019-06-05fix a crash-on-exitVictor Kareh1-0/+9
meta_frames_destroy() was not safe to be called multiple times, which was causing a crash on exit due to something else changing somewhere that makes it get called multiple times. https://bugzilla.gnome.org/show_bug.cgi?id=654489 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/e35be641
2019-06-05ui-frame: Add support for style variantsVictor Kareh2-4/+93
Rather than sharing a single style context between all frames, use a default style and one style per encountered variant. The value of the _GTK_THEME_VARIANT property should determine which style is attached to a particular frame, though for the time being the default style is used for every frame, as the window property cannot be accessed at the time the style is attached. This will be fixed in a later commit. https://bugzilla.gnome.org/show_bug.cgi?id=645355 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/04d8135f
2019-06-05ui-frames: Delay attaching the style to new framesVictor Kareh1-1/+0
Like the setting of new frames' background is delayed until the frame is associated with its window, delay attaching the initial style, so that the correct style variant is picked. https://bugzilla.gnome.org/show_bug.cgi?id=645355 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/ee056853
2019-06-05ui: Add meta_ui_update_frame_style()Victor Kareh3-0/+23
This method allows forcing a style update of a particular frame from the core, so that it can pick up style variants. https://bugzilla.gnome.org/show_bug.cgi?id=645355 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/97554dc4
2019-06-05MetaFrameBorders: Add meta_frame_borders_clearVictor Kareh4-34/+10
Just a quick little commit to help clean things up for when we add invisible borders. Additionally, do a little housekeeping in preview-widget as well. https://bugzilla.gnome.org/show_bug.cgi?id=644930 NOTE: Patch copied from metacity and adapted for marco. upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/7d519b3f
2019-06-05Replace public MetaFrameGeometry with MetaFrameBordersVictor Kareh8-133/+96
There were actually *two* MetaFrameGeometry structs: one in theme-private.h, one in frame.h. The latter public struct was populated by a mix of (void*) casting and int pointers, usually pulling directly from the data in the private struct. Remove the public struct, replace it with MetaFrameBorders and scrap all the pointer hacks to populate it, instead relying on both structs being used in common code. This commit should be relatively straightforward, and it should not do any tricky logic at all, just a sophisticated find and replace. https://bugzilla.gnome.org/show_bug.cgi?id=644930 upstream commit: https://gitlab.gnome.org/GNOME/metacity/commit/72224a165 NOTE: Patch copied from metacity and adapted for marco.
2019-06-03alt+tab popup: bugfix mouse click handling for scale factor > 1osch1-5/+5
2019-06-03Handle mouse clicks in Alt+Tab Popuposch1-0/+40
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-04 02:07:50 +0000