summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* theme: use invisible borders only with compositing managerwip/invisible-bordersAlberts Muktupāvels2015-01-202-5/+20
| | | | If compositing manager is not available set invisible borders to 0.
* compositor: fix border_sizeAlberts Muktupāvels2015-01-201-0/+52
|
* frame: make frame window transparentAlberts Muktupāvels2015-01-201-6/+20
|
* frames: apply shapes in different wayAlberts Muktupāvels2015-01-203-4/+77
|
* frames: add dest_kind to apply_cairo_region_to_windowAlberts Muktupāvels2015-01-201-3/+4
|
* frames: Fall back to title bar if nothing else matchedJasper St. Pierre2015-01-191-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
* Disable top resizing for attached modal dialogs, for real this timeJasper St. Pierre2015-01-191-4/+6
| | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=657795 With this fix applied: https://git.gnome.org/browse/mutter/commit/?id=00e49b330c413dae96ba16b3ce2a1a6962b0f0df
* Disable top resizing for attached modal dialogsJasper St. Pierre2015-01-191-1/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=656619
* theme-viewer: Fix invisible bordersJasper St. Pierre2015-01-192-10/+10
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=662895
* window: Correct coordinates for the configure eventJasper St. Pierre2015-01-191-4/+8
| | | | We should still correct the coordinates for withdrawn windows.
* frame: Make sure to offset by invisible borders when unmanaging windowsJasper St. Pierre2015-01-191-2/+5
| | | | | | | | When we reparent a window to the root when we're exiting, we need to offset the position by the invisible borders, otherwise windows will creep up and to the left. https://bugzilla.gnome.org/show_bug.cgi?id=660848
* window: Fix _NET_FRAME_EXTENTS to work properlyJasper St. Pierre2015-01-191-4/+7
| | | | | | | | _NET_FRAME_EXTENTS should contain the difference between where a window asked to be placed, and where it is. Ideally, this should be the same as the visible extents. https://bugzilla.gnome.org/show_bug.cgi?id=659848
* theme: don't add invisible borders for windows that can't be resizedAlberts Muktupāvels2015-01-191-12/+15
| | | | | | | | | | 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
* window: Fix window placement to exclude invisible bordersJasper St. Pierre2015-01-191-4/+4
| | | | | | | | A window can specify geometry that it is placed at. We need to exclude invisible borders when calculating where to place the window, otherwise the window will have a strange offset. https://bugzilla.gnome.org/show_bug.cgi?id=659848
* theme: Don't add any bottom border to shaded windowsFlorian Müllner2015-01-191-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
* theme: Attached modal dialogs should have no top invisible borderJasper St. Pierre2015-01-192-0/+10
| | | | | | | | | | If we do this, then there will be invisible borders around the top of attached modal dialogs, which is unnecessary -- they can't be resized from the top border and just interfere with the parent dialog. This requires changing a bit of API to help identify the type of dialog. https://bugzilla.gnome.org/show_bug.cgi?id=657795
* frames: Fix the visible region when we have a rounded bottom-right cornerJasper St. Pierre2015-01-191-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=657661
* Account for invisible borders when constraining modal dialogsJasper St. Pierre2015-01-191-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=656619
* compositor: fix shadow size and placementAlberts Muktupāvels2015-01-191-4/+7
|
* MetaWindow: Repurpose get_outer_rect and add get_input_rectAlberts Muktupāvels2015-01-192-1/+41
| | | | | | | | get_outer_rect now returns the visible region, and a new get_input_rect method returns the boundaries of the full frame, including the possible invisible regions. When undecorated, both do the samething. https://bugzilla.gnome.org/show_bug.cgi?id=644930
* MetaWindow: Compensate for invisible border changesJasper St. Pierre2015-01-191-20/+20
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=644930
* ui: Replace inline borders in MetaFrameGeometry with MetaFrameBorderJasper St. Pierre2015-01-193-141/+160
| | | | | | | | ... and start compensating for invisible borders in all of the math. https://bugzilla.gnome.org/show_bug.cgi?id=644930 NOTE: Updated for metacity...
* MetaFrameBorders: add invisible bordersAlberts Muktupāvels2015-01-193-4/+19
| | | | | | | | 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
* doc: add info for 3.5 and 3.6 theme format versionsAlberts Muktupāvels2015-01-191-0/+12
|
* theme: add invisible_border to metacity themeAlberts Muktupāvels2015-01-193-1/+11
| | | | | This adds 'invisible_border' to metacity theme. This invisible border will be used for resize cursor area.
* ui: always set the frame background to NoneGiovanni Campagna2015-01-195-152/+12
| | | | | | | | | | | | This way the xserver never paints the frame background, even if the client window is destroyed. This allows us to have clean destroy window animation. There is no problem with interactive resizing because applications are using the XSync protocol, so we're not painting unless the client has redrawn. https://bugzilla.gnome.org/show_bug.cgi?id=734054
* theme: Rename button_rect() to get_button_rect()Florian Müllner2015-01-191-5/+5
| | | | | | | | | Basically it's odd to have "button_rect" be a function with all the foo_rect GdkRectangles around - renaming to get_button_rect() will free the name for the generically named "rect" once buttons are the only movable pieces in the frame. https://bugzilla.gnome.org/show_bug.cgi?id=741917
* Fix handling of dynamic updates to colors/font/etc.Owen W. Taylor2015-01-192-23/+22
| | | | | | | | | | | | | | | | | | Since the introduction of frame sync in GTK+, updates to titlebar font and colors haven't been working because GTK+ counts on the frame clock to do style updates, and the frame clock doesn't run for an unmapped GdkWindow. (It's possible that GtkStyleContext changes subsequent to the introduction of the frame clock were also needed to fully break things.) We actually need to map the MetaFrames GdkWindow and let the compositor code send out the frame sync messages in order to pick up style changes. Hopefully no bad side effects will occur from this - we make the window override-redirect, 1x1, and outside the bounds of the screen. https://bugzilla.gnome.org/show_bug.cgi?id=725751
* constraints: fix mem leak in meta_window_constrain()Pavel Vasin2015-01-191-3/+10
| | | | | | | MetaFrameBorders leaked when orig_borders != NULL and window->fullscreen == TRUE https://bugzilla.gnome.org/show_bug.cgi?id=679153
* MetaFrames: factor out MetaUIFrame accessors for borders, corner radiusesSimon McVittie2015-01-191-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>
* frame: Add "get_corner_radiuses" chainJasper St. Pierre2015-01-196-0/+81
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=628195
* frames: Fix astonishing accidental pointer trickeryJasper St. Pierre2015-01-191-1/+1
| | | | | | | | | | | | | | | Whenever we added a frame to the GHashTable, we added the frame itself as the value, and a pointer to its storage of the frame window XID, as the key. When we iterated over the hash table, we actually looked up the MetaUIFrame in the key, which might seem extraordinarily wrong, but eagle-eyed viewers might notice that the XID is the first field in MetaUIFrame, so the key and value are actually the same pointer. Changing the layout of MetaUIFrame at all causes this to go haywire, so let's not do this and simply put the MetaUIFrame in the value, as expected.
* frame: destroy window->frame_bounds when destroying the frameRui Matos2015-01-191-0/+5
| | | | | | | Since window->frame_bounds is used as a cache we need to invalidate it when destroying the frame. https://bugzilla.gnome.org/show_bug.cgi?id=660773
* Only shadow ARGB windows with a frame outside the frameOwen W. Taylor2015-01-199-79/+210
| | | | | | | | | | | | | | | | | 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...
* Fix XShapeJasper St. Pierre2015-01-191-1/+1
| | | | | | | | 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
* Convert frame region handling to cairo regionsOwen W. Taylor2015-01-191-46/+79
| | | | | | | | | It's useful to get frame shapes and manipulate them within Mutter, for example so that the compositor can use them to clip drawing. For this, we'll need the regions as cairo regions not X regions, so convert frame shaping code to work in terms of cairo_region_t. https://bugzilla.gnome.org/show_bug.cgi?id=635268
* compositor: don't draw shadow under windowsAlberts Muktupāvels2015-01-193-20/+80
|
* autogen: remove deprecated variablesAlberts Muktupāvels2015-01-191-2/+2
|
* Revert "use force_save_user_rect=TRUE for maximized windows too"Alberts Muktupāvels2015-01-191-0/+2
| | | | This reverts commit fbfcbc5e35e35063c8ff71b399a0bf72a31852e7.
* constraints: initialize window->user_rect in initial placementAlberts Muktupāvels2015-01-191-0/+4
|
* all-keybindings.h: move switch-applications to correct placeAlberts Muktupāvels2015-01-071-6/+4
| | | | | | | Bindings should be added in correct order and should match MetaKeyBindingAction enums order in prefs.h. Otherwise meta_prefs_get_keybinding_action function will return incorrect action.
* keybindings: add keycode_to_stringAlberts Muktupāvels2015-01-071-25/+22
|
* keybindings: add keycode_to_keysymAlberts Muktupāvels2015-01-071-2/+16
|
* remove application-based preferenceAlberts Muktupāvels2015-01-073-41/+2
| | | | | It's hardcoded to false. Based on mutter commit: https://git.gnome.org/browse/mutter/commit/src/?id=1c569c2d0e651215d2a468fd80a449588a4743ca
* theme: Add the .background style class back to framesJasper St. Pierre2015-01-071-0/+1
| | | | | | | | | GtkWindow added the BACKGROUND style class to all windows, which the CSS file selects on to set a background color for all windows. Without this, the background color becomes undefined, and thus window frames look like they have "glitchy" graphics. https://bugzilla.gnome.org/show_bug.cgi?id=690317
* theme-viewer: use the same GtkStyleContext as mutter usually rendersJasper St. Pierre2015-01-076-44/+82
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=690317
* theme: Make meta_frame_draw_theme take a GtkStyleContext instead of a widgetJasper St. Pierre2015-01-075-64/+29
| | | | | | | | 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
* remove common.cAlberts Muktupāvels2015-01-073-39/+0
|
* build everything as libraryAlberts Muktupāvels2015-01-071-28/+17
|
* Allow raise_on_click to be set independent of focus_modeJasper St. Pierre2015-01-072-6/+2
| | | | Based on a patch by Thomas Jaeger <ThJaeger@gmail.com>
View Lorry Controller Status