| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Gotta save those 4 bytes.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Introduce a temporary to make the code a bit more clear under these cases.
|
|
|
|
| |
Tabs to spaces, add some whitespace.
|
|
|
|
|
| |
Mention the need to wrap the function inside
gdk_window_begin_paint_region and gdk_window_end_paint.
|
|
|
|
| |
This is a foolowup to d80bf0790d0903ba2825f306b6f7435529f922e2
|
|
|
|
| |
As requested on the mailing list.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
The .button style class does not apply to check and radio
buttons, and .check only applies to menuitems.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
The function does nothing.
|
| |
|
|
|
|
| |
Make the default symbolic colors a little more readable in the code.
|
|
|
|
|
| |
Drop the _-prefix from a static function.
We've agreed to no stop using those prefixes.
|
|
|
|
| |
The name_offset variable is indeed unused.
|
| |
|
|
|
|
|
| |
Starting gtk3-demo currently creates ~1200 of these, most
of them for nonexisting directories. Lets try to avoid that.
|
|
|
|
|
| |
This will help in not creating structs for tons of empty
directories.
|
|
|
|
| |
Looks better this way.
|
| |
|
|
|
|
| |
This is slightly more elegant than doing it manually.
|
|
|
|
|
| |
A widget that is not represented in the widget factory is likely
to not get proper attention from theme authors.
|
|
|
|
|
|
| |
Most of those images are no longer in our tree, so just
say which ones have icons and rtl variants, instead of
showing it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
We need to discuss some details of the semantics before
we can make this public.
|
|
|
|
| |
This reverts commit 988b6b483dc9c21d050161d26652bb1006b9c686.
|
|
|
|
| |
This reverts commit 923eeda2d3cae13d02b0a9d2e5774b12eed999e0.
|
| |
|
| |
|
|
|
|
|
| |
With the new way of dealing with the legacy stock icons,
the builtin test needed some small updates.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
It is not used anywhere anymore.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This test checks that gtk_icon_theme_list_icons and
gtk_icon_theme_has_icon work as expected.
|
| |
|
|
|
|
| |
Modern icon themes don't ship .icon files anyway.
|
|
|
|
| |
This functionality is not used at all in modern icon themes.
|
|
|
|
|
| |
We don't need it anymore, now that the non-standard stock icons
are using resources.
|
|
|
|
|
| |
This will allow us to remove the builtin icon cache in the future
while keeping the deprecated stock icons working.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|