summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* gdkwindow: Don't clear to the background automaticallywip/paint-stack-cleanupJasper St. Pierre2014-06-213-13/+26
| | | | | | | | | | Introduce a new API, gdk_window_paint_background, which paints the background, which we call inside GtkWidget as part of expose event handling. This allows users that were using gdk_cairo_create without a gdk_window_begin_paint_region to start using it now, as they did not want the clear-to-background behavior.
* gdkwindow: Use bitfields for packing storageJasper St. Pierre2014-06-211-2/+2
| | | | Gotta save those 4 bytes.
* gdkwindow: Only skip alpha blending if we cleared to the backgroundJasper St. Pierre2014-06-212-2/+9
| | | | | | | Currently, this always happens, but some consumers of begin_paint_region want to be able to start a paint that doesn't end up clearing to the background pattern. We'll expose a new API for this and remove the automatic clear from begin_paint_region.
* gdkwindow: Correct a signatureJasper St. Pierre2014-06-211-2/+1
| | | | | | We removed the parameter from callers and from the implementation, but not from the signature up top. I didn't notice because the branch I was working on removed the signature entirely.
* gdkwindow: Remove an extra region copyJasper St. Pierre2014-06-211-10/+3
| | | | | | This code is only called with the current paint region as its argument. Instead of having to copy it and do a no-op intersect against itself, just use the current paint directly.
* gdkwindow: Clean up codeJasper St. Pierre2014-06-211-2/+7
| | | | Introduce a temporary to make the code a bit more clear under these cases.
* gdkwindow: Clean up formattingJasper St. Pierre2014-06-211-9/+10
| | | | Tabs to spaces, add some whitespace.
* gdkwindow: Add some extra documentation to gdk_cairo_createJasper St. Pierre2014-06-211-0/+5
| | | | | Mention the need to wrap the function inside gdk_window_begin_paint_region and gdk_window_end_paint.
* widgetpath: Deprecate regionsBenjamin Otte2014-06-216-6/+31
| | | | This is a foolowup to d80bf0790d0903ba2825f306b6f7435529f922e2
* gtkwidget: Add a warning about set_double_bufferedJasper St. Pierre2014-06-211-0/+2
| | | | As requested on the mailing list.
* testwindows: Remove another reference to set_double_bufferedJasper St. Pierre2014-06-211-1/+0
|
* gtktrayicon-x11: Stop using set_double_bufferedJasper St. Pierre2014-06-211-26/+0
| | | | | | There's nothing better we can do for this case, now that we always redirect drawing to a temporary pixmap. Maybe since this is already X11-specific code, we should just do everything with Xlib directly.
* Adwaita: Fix highlight on check buttonsMatthias Clasen2014-06-203-0/+8
| | | | | The .button style class does not apply to check and radio buttons, and .check only applies to menuitems.
* gdkwindow: Squash a leak in the subsurface caseJasper St. Pierre2014-06-201-7/+10
| | | | | | | | cairo_surface_create_for_rectangle takes a ref on the parent surface, so we need to drop ours. Rename get_window_surface to ref_window_surface to make the code more clear and to stop this error from happening again.
* gdkwindow: Don't create a subsurface if we don't need toJasper St. Pierre2014-06-201-5/+12
| | | | | In the case we have a native window, we don't need to crop it to a non-native subrectangle, as abs_x / abs_y / width / height are all 0.
* gdkwindow: Remove the ability to call begin_paint_region more than onceJasper St. Pierre2014-06-204-166/+68
| | | | | | | | | | | | | | | Previously, each begin_paint_region added to a stack of current paints, and when end_paint was called, the paint was popped off of the stack and the surface was composited into the parent paint surface. However, the code was broken in the case of a backend like Wayland which didn't keep track of nested calls and simply wiped and returned the native impl backing surface every time. Since this feature is flat out unused by GTK+ and we don't want to really support tricksy things like these for other clients, just remove the feature. If somebody does call begin_paint_region more than once, warn and return without doing anything.
* gdkwindow: Remove the internal cairo_surface used for out-of-band paintingJasper St. Pierre2014-06-209-202/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Traditionally, the way painting was done in GTK+ was with the "expose-event" handler, where you'd use GDK methods to do drawing on your surface. In GTK+ 2.24, we added cairo support with gdk_cairo_create, so you could paint your graphics with cairo. Since then, we've added client-side windows, double buffering, the paint clock, and various other enhancements, and the modern way to do drawing is to connect to the "draw" signal on GtkWidget, which hands you a cairo_t. To do double-buffering, the cairo_t we hand you is actually on a secret surface, not the actual backing store of the window, and when the draw handler completes we blit it into the main backing store atomically. The code to do this is with the APIs gdk_window_begin_paint_region, which creates the temporary surface, and gdk_window_end_paint which blits it back into the backing store. GTK+'s implementation of the "draw" signal uses these APIs. We've always sort-of supported people calling gdk_cairo_create "outside" of a begin_paint / end_paint like old times, but then you're not getting the benefit of double-buffering, and it's harder for GDK to optimize. Additionally, newer backends like Mir and Wayland can't actually support this model, since they're based on double-buffering and swapping buffers at various points in time. If we hand you a random cairo_t, we have no idea when is a good time to swap. Remove support for this. This is technically a GDK API break: a warning is added in cases where gdk_cairo_create is called outside of a paint cycle, and the returned surface is a dummy that won't ever be composited back onto the main surface. Testing with complex applications like Ardour didn't produce any warnings.
* gtkwidget: Widgets are now always double-bufferedJasper St. Pierre2014-06-203-58/+18
| | | | | | | gtk_widget_set_double_buffered is now deprecated, and we don't support non-double-buffered widgets. This means that under normal circumstances, paints are never outside of a begin_paint / end_paint sequence, which natively-double-buffered backends like Wayland can't possibly support.
* gdkwindow: Deprecate gdk_window_flushJasper St. Pierre2014-06-203-21/+4
| | | | The function does nothing.
* GtkIconTheme: Drop an unused functionMatthias Clasen2014-06-201-9/+0
|
* GtkIconTheme: Small cleanupMatthias Clasen2014-06-201-16/+6
| | | | Make the default symbolic colors a little more readable in the code.
* GtkIconTheme: Trivial cleanupMatthias Clasen2014-06-201-30/+29
| | | | | Drop the _-prefix from a static function. We've agreed to no stop using those prefixes.
* Avoid a compiler warningMatthias Clasen2014-06-201-2/+0
| | | | The name_offset variable is indeed unused.
* Big spinnerMatthias Clasen2014-06-201-0/+11
|
* GtkIconTheme: Don't create empty IconThemeDir structsMatthias Clasen2014-06-201-39/+44
| | | | | Starting gtk3-demo currently creates ~1200 of these, most of them for nonexisting directories. Lets try to avoid that.
* GtkIconCache: Add api to find if directories are emptyMatthias Clasen2014-06-202-0/+44
| | | | | This will help in not creating structs for tons of empty directories.
* GtkStatusbar: Add some space between the frame and the labelMatthias Clasen2014-06-201-0/+1
| | | | Looks better this way.
* Adwaita: check/radio selector simplificationLapo Calamandrei2014-06-203-98/+50
|
* widget factory: Use a property action for the toolbar toggleMatthias Clasen2014-06-201-16/+4
| | | | This is slightly more elegant than doing it manually.
* widget factory: Add a statusbarMatthias Clasen2014-06-202-0/+23
| | | | | A widget that is not represented in the widget factory is likely to not get proper attention from theme authors.
* docs: Drop image references for stock itemsMatthias Clasen2014-06-202-346/+92
| | | | | | Most of those images are no longer in our tree, so just say which ones have icons and rtl variants, instead of showing it.
* wayland: Prevent stale paints and weird artifacts when using WestonJasper St. Pierre2014-06-203-1/+25
| | | | | | | | | | | | | | | | Weston releases buffers almost immediately after they're done, which means that GTK+ doesn't use a temporary surface and instead paints directly onto the SHM backing store that Weston will use. Normally, after painting to the temporary surface, GTK+ *replaces* the existing backing surface with CAIRO_OPERATOR_SOURCE. However, if we immediately paint to the backing surface, it might have junk from the last paint in it. So clear out the backing surface whenever somebody calls begin_paint_region(). Maybe we should just always use the temporary surface like the X11 codepath, since that prevents us from having to do weird things like this, but oh well.
* GtkIconTheme: Keep gtk_icon_theme_add_resource_path private for nowMatthias Clasen2014-06-201-4/+0
| | | | | We need to discuss some details of the semantics before we can make this public.
* Revert "Document gtk_icon_theme_add_resource_path"Matthias Clasen2014-06-202-17/+0
| | | | This reverts commit 988b6b483dc9c21d050161d26652bb1006b9c686.
* Revert "Deprecate gtk_icon_theme_add_builtin_icon"Matthias Clasen2014-06-202-7/+2
| | | | This reverts commit 923eeda2d3cae13d02b0a9d2e5774b12eed999e0.
* Deprecate gtk_icon_theme_add_builtin_iconMatthias Clasen2014-06-202-2/+7
|
* Document gtk_icon_theme_add_resource_pathMatthias Clasen2014-06-202-0/+17
|
* Adapt the icontheme testsMatthias Clasen2014-06-201-4/+5
| | | | | With the new way of dealing with the legacy stock icons, the builtin test needed some small updates.
* GtkIconTheme: Include legacy stock icons from resourcesMatthias Clasen2014-06-201-0/+26
| | | | | | Add /org/gtk/libgtk/icons as a resource path, and ensure that we always parse an index.theme file for hicolor which makes the builtin icons available as part of the hicolor theme.
* GtkIconTheme: Allow loading icons from resourcesMatthias Clasen2014-06-202-17/+112
| | | | | | We add a new API, gtk_icon_theme_add_resource_path, which can be used to add resource path as a base location for icon theme content, similar to gtk_icon_theme_append_search_path.
* GtkIconTheme: Drop the all_icons hash tableMatthias Clasen2014-06-201-17/+2
| | | | It is not used anywhere anymore.
* GtkIconTheme: Stop using the all_icons hash tableMatthias Clasen2014-06-201-3/+32
| | | | | | This hash table was used in gtk_icon_theme_has_icon; we can implement that function just as well without it and save some memory.
* icontheme: Add some more testsMatthias Clasen2014-06-201-0/+38
| | | | | This test checks that gtk_icon_theme_list_icons and gtk_icon_theme_has_icon work as expected.
* Formatting fixesMatthias Clasen2014-06-201-851/+831
|
* GtkIconTheme: Drop the code for parsing .icon filesMatthias Clasen2014-06-201-307/+9
| | | | Modern icon themes don't ship .icon files anyway.
* GtkIconTheme: Deprecate functionality related to .icon filesMatthias Clasen2014-06-202-4/+12
| | | | This functionality is not used at all in modern icon themes.
* Drop the builtin icon cacheMatthias Clasen2014-06-2085-17365/+6
| | | | | We don't need it anymore, now that the non-standard stock icons are using resources.
* Add non-standard stock icons as resourcesMatthias Clasen2014-06-2042-0/+6
| | | | | This will allow us to remove the builtin icon cache in the future while keeping the deprecated stock icons working.
* Drop all standard icons from the builtin iconthemeMatthias Clasen2014-06-20346-55348/+4
| | | | | | We're going to require a complete icon theme, and we have a test that checks for all the icons we use, so there is no need to include all these fallback icons.
* stylecontext: Deprecate regionsBenjamin Otte2014-06-196-7/+31
| | | | | | | | | | | Regions are done in a very non-css way. They don't fit the DOM in that they don't integrate into the CSS tree and they have very weird matching behavior in selectors. So I'm deprecating them now. GtkNotebook and GtkTreeview will continue to use them and as long as they do, we can't remove the code for it. But once those are ported it might be safe to remove the code as it will clean up lots of places in the code by quite a bit.