summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* prefs: force theme reloadwip/gtk-themeAlberts Muktupāvels2015-02-191-1/+1
|
* theme: don't load metacity theme when using GTK+ themeAlberts Muktupāvels2015-02-191-3/+91
| | | | | | | | | | | | | | All geometry/drawing information is now picked up from the GTK+ theme, so replace the remaining bits (hide_buttons + title_scale) with hardcoded values from the default Adwaita theme. If there is a need to theme those constants again in the future, we should make them available from GTK+ where they are available for client-side decorations as well. They certainly don't justify maintaining support for a complex theme format. Based on mutter commit: https://git.gnome.org/browse/mutter/commit/?id=d5e6177900f5cdf90bb3ba86603d6b6ff0a919f7
* Properly update on GTK+ theme changesFlorian Müllner2015-02-193-4/+9
| | | | | | | | | With geometry information picked up from GTK+, we need to queue a resize on GTK+ theme changes to correctly update to the new geometry. https://bugzilla.gnome.org/show_bug.cgi?id=741917 NOTE: Updated for metacity.
* theme: allow NULL as theme nameAlberts Muktupāvels2015-02-192-5/+6
| | | | Theme name == NULL - use current GTK+ theme.
* frames: Rename layout to text_layoutFlorian Müllner2015-02-192-24/+18
| | | | | | ... to differentiate PangoLayout from MetaFrameLayout. https://bugzilla.gnome.org/show_bug.cgi?id=741917
* theme: Scale whitespace from theme with title_scale factorFlorian Müllner2015-02-191-0/+14
| | | | | | | | | | | | | | | GTK+ doesn't deal with different frame types for its client-side decorations - it just treats dialogs the same as normal windows and ignores the odder frame types like UTILITY and MENU. That's fine as those have largely gone out of fashion anyway, but it's a different case for the WM - we still have to support them somehow. For now, just apply the existing title_scale factor to the geometry information picked up from the theme in addition to the title font. If it turns out that there's demand for something more sophisticated, we can still consider adding wm-only style information to the GTK+ theme. https://bugzilla.gnome.org/show_bug.cgi?id=741917
* theme: Use style information from GTK+Florian Müllner2015-02-196-22/+218
| | | | | | | | | | | We now have everything in place to pick up geometry and drawing information from GTK+ rather than the metacity theme, so do just that; the metacity theme is now only used for some constants (title_scale, hide_buttons, ...), which we will replace soon. https://bugzilla.gnome.org/show_bug.cgi?id=741917 NOTE: Updated for metacity.
* theme: Add function to fill geometry information from GTK+ themeFlorian Müllner2015-02-192-0/+90
| | | | | | | | | | We want to eventually pick up all theme information from GTK+ instead of our own theme format; to prepare for this, add another helper method to fill in geometry information from the GTK+ theme. https://bugzilla.gnome.org/show_bug.cgi?id=741917 NOTE: Updated for metacity.
* theme: Add method to adjust styles for frame stateFlorian Müllner2015-02-192-0/+75
| | | | | | | | GTK+ expresses the window state as style classes and widget state for client-side decorations. Add a helper method to translate our own frame state to the corresponding changes to the style context hierarchy. https://bugzilla.gnome.org/show_bug.cgi?id=741917
* frames: Use title style to set up title layoutFlorian Müllner2015-02-194-20/+77
| | | | | | | | | | | | Sounds obvious, doesn't it? After this change when titlebar-uses-system-font is set, the "system font" used will not be a generic one, but match what GTK+ uses in client-side decorations. https://bugzilla.gnome.org/show_bug.cgi?id=741917 NOTE: Updated for metacity.
* theme: fix warningAlberts Muktupāvels2015-02-191-0/+1
|
* theme: Build a StyleContext hierarchy that matches GTK+'s CSDFlorian Müllner2015-02-192-23/+83
| | | | | | | | In order to pick up all theme information from GTK+, a single style context is not enough; a style hierarchy that closely matches the widget hierarchy by GTK+'s client-side decorations will allow this soon. https://bugzilla.gnome.org/show_bug.cgi?id=741917
* theme: Add MetaStyleInfo for wrapping frame style contextFlorian Müllner2015-02-197-55/+113
| | | | | | | | | | | | | | Our current use of style contexts is fairly limited - we don't use them for much more than picking up some color information. We will soon start to make more elaborate use of GTK style information, but a single context will no longer be enough to draw a frame then. To prepare for this, add a simple ref-counted type to wrap style information. https://bugzilla.gnome.org/show_bug.cgi?id=741917 NOTE: Updated for metacity.
* theme: Add titlebar_spacingFlorian Müllner2015-02-192-9/+52
| | | | | | | | | | | | | Rather than defining the space to the left and right of buttons, add a simple spacing property that defines the space between buttons, which is what GTK+ does for client-side decorations (e.g. GtkButtons in a GtkBox). Unfortunately the value is hardcoded in GTK+; if it is exposed in the theme in the future, we should pick it up from there, but for now we just use the same value as GTK+. https://bugzilla.gnome.org/show_bug.cgi?id=741917 NOTE: Updated for metacity.
* prefs: add theme preferenceAlberts Muktupāvels2015-02-192-1/+9
|
* themes: add Adwaita and HightContrast themesAlberts Muktupāvels2015-02-193-0/+3648
| | | | | These themes are copied from gnome-themes-standard before they were removed.
* Improve translatable strings in gschema filePiotr Drąg2015-02-191-5/+5
| | | | Just some minor nitpicks.
* ui: use rgba visual in meta_ui_get_pixbuf_from_pixmapAlberts Muktupāvels2015-02-191-4/+5
|
* screen: use old icon size with alt-tab thumbnailAlberts Muktupāvels2015-02-191-3/+12
|
* prefs: add alt-tab-thumbnails preferenceAlberts Muktupāvels2015-02-194-2/+34
|
* gschema: fix indentationAlberts Muktupāvels2015-02-191-1/+1
|
* Revert "screen: Remove alt-tab thumbnails"Alberts Muktupāvels2015-02-191-13/+74
| | | | This reverts commit 04ad17378e0f366dd503cf0881e3a3f9ae603699.
* ui: update meta_ui_get_pixbuf_from_pixmapAlberts Muktupāvels2015-02-191-18/+16
|
* Revert "ui.[c/h]: remove unused function"Alberts Muktupāvels2015-02-192-0/+30
| | | | This reverts commit 54244b4b60016612270de42c00836ec5f90f262b.
* frames: fix typoAlberts Muktupāvels2015-02-191-1/+1
|
* frames: remove unused defineAlberts Muktupāvels2015-02-191-5/+0
|
* frames: again change meta_frames_applet_shapesAlberts Muktupāvels2015-02-192-59/+24
| | | | | | | | | With compositing manager: 1. Apply only client shape. Without compositing manager: 1. Apply client shape. 2. Apply shape around visible frame.
* Revert "theme: use invisible borders only with compositing manager"Alberts Muktupāvels2015-02-192-20/+5
| | | | This reverts commit 43250740ab2a56991744a1525bad2930d7541595.
* require xsync and xshape at build timeAlberts Muktupāvels2015-02-1912-244/+13
|
* window: load NET_WM_USER_TIME from the right windowAlberts Muktupāvels2015-02-181-1/+9
| | | | | | | | | | | | | | | On subsequent changes, if there is a NET_WM_USER_TIME_WINDOW, then read the property from that rather than from the main window. (Fix an accidental regression: the right Window was being computed but no longer passed in.) Original patch author - Owen Taylor: https://bugzilla.gnome.org/show_bug.cgi?id=585979 This patch also reverts some code removal from this metacity commit: be478298219d2207c8e7a5ba79f20485afe24b70 https://bugzilla.gnome.org/show_bug.cgi?id=587425
* compositor: don't use invalid back_pixmapAlberts Muktupāvels2015-02-181-1/+6
| | | | | | XCompositeNameWindowPixmap can generate BadMatch error. If this error is generated then returned pixmap is not valid. Just set back_pixmap to None in case of error.
* Updated Turkish translationMuhammet Kara2015-02-171-234/+211
|
* preview-widget: use correct name for missing iconAlberts Muktupāvels2015-01-261-2/+2
|
* frame: remove uneeded includeAlberts Muktupāvels2015-01-221-4/+0
|
* bump xcomposite required version to 0.3 and simplify codeAlberts Muktupāvels2015-01-225-175/+59
| | | | Version 0.3 is available more then 8 years.
* theme: use invisible borders only with compositing managerAlberts 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/+23
|
* 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-201-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-201-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-201-1/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=656619
* theme-viewer: Fix invisible bordersJasper St. Pierre2015-01-202-10/+10
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=662895
* window: Correct coordinates for the configure eventJasper St. Pierre2015-01-201-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-201-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-201-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-201-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-201-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-201-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
View Lorry Controller Status