The last change fixed the windowed widget case but broke
opacity group handling for windowed child widgets. This fixes
up the code by making sure we norender_children in when there
is an opacity group.
This also cleans up the comments about how this works to something
that is hopefully more understandable.
We always need to render the background, as the window
background is not always set (i.e. during gtk_widget_draw()) or
when its partially visible.
https://bugzilla.gnome.org/show_bug.cgi?id=694925
Mutter magically ignores override-redirect windows with geometry
-100-100+1+1, and this breaks the frame synchronization between
gtk+ and mutter. For now, we avoid the issue by simply giving
the window a different geometry.
https://bugzilla.gnome.org/show_bug.cgi?id=694217
When the range of the GtkRange is zero (i.e. the upper and lower bounds
of the adjustment have the same value), don't use an origin to draw the
trough, as the slider will also be hidden, and the juncture between the
two sections of the trough will be visible.
Since we are linking in the resource items by the source, we need to
disable WholeProgramOptimization so that the resource stuff does get linked
into the demo binaries, so that they can be loaded properly.
Also make sure that gtk3-demo-application is also built with the multibyte
character set, like the rest.
This should fix bug 694342, at least for Visual Studio builds.
If no updates, redraws, or repaints have been scheduled for this frame,
we will skip immediately to RESUME_EVENTS, and no GdkFrameTimings will
be created.
https://bugzilla.gnome.org/show_bug.cgi?id=694732
This is so we can prepare these buffers without them being set on the
widgets yet and only gtk_text_view_set_buffer() them afterwards. And
this in turn gets rid of all the a11y events we were needlessly
emitting.
https://bugzilla.gnome.org/show_bug.cgi?id=694406
-Use ApiVersion instead of GtkApiVersion for consistency's sake across
the board
-Add placeholder directives in the property sheets for building
introspection files using .bat files directly from the Visual Studio IDE.
This is used by the "Application Class" demo... so this should be built
as well especially as we are getting gspawn-win{32|64}-helper.exe fixed
on Visual Studio 2005 (and later) builds.
