Make the Makefile.am targets for generating the Visual Studio projects re-generate the
project files and the header listings whenever the Makefile.am's that include
build/Makefile.msvcproj changes, so that whenever a source/header is added, they will
be reflected in the projects and in the property sheets that are used to copy the
headers.
Also ensure that these are applied to the vs11, vs12 and vs14 projects when this
happens, as they are copied and processed from the Visual Studio 2010 projects.
This allows the use of a "text-direction" hint set to one of "none", "rtl",
or "ltr" to enforce the text direction of a "horizontal-buttons"
display-hint.
This is useful when a menu has buttons that map to physical space in the
UI and therefore must match the application widgetry.
https://bugzilla.gnome.org/show_bug.cgi?id=772775
gtk_widget_destroy() removes widgets from their container. However
_internal_ widgets must be unref'ed using gtk_widget_unparent() instead.
This is symmetric with the fact that these widgets were ref'ed by direct
call to gtk_widget_set_parent(). It's also the method that was used in
gtk_headerbar_destroy().
https://bugzilla.gnome.org/show_bug.cgi?id=772859
> Due to Gtk+ keeping a reference to the window internally,
> gtk_window_new() does not return a reference to the caller.
> To delete a GtkWindow, call gtk_widget_destroy().
Caller(s) aren't expecting a need to delete help_overlay themselves
once they've installed it. (E.g. see gtk_application_window_added()).
I didn't notice any direct precedents, but there's a parallel in the
current implementation of gtk_container_destroy() which uses
gtk_widget_destroy() on any added widget.
This avoids leaking 100s of kB per window, when I tested nautilus.
https://bugzilla.gnome.org/show_bug.cgi?id=772859
ClutterEmbed on Wayland uses a subsurface and relocates it on configure
events, but when placed within a scrolled window, no configure event is
emitted and the ClutterEmbed subsurface remains static.
Emit a configure event for native windows in GdkWindow's internal
move_native_children() so that custom widgets relying on configure
events such as ClutterEmbed can relocate their stuff.
Similarly, when switching to/from normal/maximized/fullscreen states
which change the shadows' size and possibly shows/hides a header bar,
we need to emit a configure event even if the abs_x/abs_y haven't
changed to make sure the subsurface is size appropriately.
https://bugzilla.gnome.org/show_bug.cgi?id=771320https://bugzilla.gnome.org/show_bug.cgi?id=767713
These functions don't work well on backends without global
coordinates (such as Wayland or Mir), and the gtk_menu_popup_at_
variants are better alternatives.
https://bugzilla.gnome.org/show_bug.cgi?id=772552
to hilight drop target there is a wildcard selector which turns
the border and shadow to green, this clearly shouldn't happen when
the whole window is a drop target.
...by putting it in a stack. The busy_spinner and eject_button are
mutually exclusive, but only the latter was coded to ensure that its
visibility did not cause the rest of the row to reflow. By putting both
widgets in a stack and setting child_visible on that, the row allocates
enough space to show one - or none - at once, avoiding any misalignment.
https://bugzilla.gnome.org/show_bug.cgi?id=772345https://bugzilla.gnome.org/show_bug.cgi?id=772348
Calling eglGetDisplay forces libEGL to guess what kind of pointer you
passed it. Different EGL libraries will do different things here, and in
particular glvnd will do something different than Mesa. Since we do have
an API that allows us to explicitly type the display, use it.
The explicit call to eglGetProcAddress is working around a bug in
libepoxy 1.3, which does not understand the EGL concept of client
extensions. Since it does not, the normal epoxy resolver for
eglGetPlatformDisplayEXT would not find any provider for that entry
point, and crash when you attempted to call it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772415
EGLDisplays are already opaque pointers, and eglGetDisplay returns an
EGLDisplay not a pointer to one.
Signed-off-by: Adam Jackson <ajax@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772415
We currently beep when a character is appended at the end in
overwrite mode. That is obviously not right. Patch based on
a patch by Ian MacDonald.
https://bugzilla.gnome.org/show_bug.cgi?id=772389
13 bytes in 1 blocks are definitely lost in loss record 766 of 16,875
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0xA9D0247: vasprintf (in /usr/lib64/libc-2.24.so)
by 0xA2453FC: g_vasprintf (gprintf.c:316)
by 0xA2152F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0xA21539C: g_strdup_printf (gstrfuncs.c:540)
by 0x678F25C: gdk_rgba_to_string (gdkrgba.c:360)
by 0x5FAE00D: rgba_to_string_noalpha (gtkicontheme.c:4322)
by 0x5FAE6F2: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4492)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
14 bytes in 1 blocks are definitely lost in loss record 801 of 16,875
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0xA9D0247: vasprintf (in /usr/lib64/libc-2.24.so)
by 0xA2453FC: g_vasprintf (gprintf.c:316)
by 0xA2152F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0xA21539C: g_strdup_printf (gstrfuncs.c:540)
by 0x678F25C: gdk_rgba_to_string (gdkrgba.c:360)
by 0x5FAE00D: rgba_to_string_noalpha (gtkicontheme.c:4322)
by 0x5FAE68E: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4482)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
15 bytes in 1 blocks are definitely lost in loss record 838 of 16,875
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0xA9D0247: vasprintf (in /usr/lib64/libc-2.24.so)
by 0xA2453FC: g_vasprintf (gprintf.c:316)
by 0xA2152F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0xA21539C: g_strdup_printf (gstrfuncs.c:540)
by 0x678F25C: gdk_rgba_to_string (gdkrgba.c:360)
by 0x5FAE00D: rgba_to_string_noalpha (gtkicontheme.c:4322)
by 0x5FAE6C3: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4487)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
16,384 bytes in 1 blocks are definitely lost in loss record 16,847 of 16,875
at 0x4C2DADE: malloc (vg_replace_malloc.c:298)
by 0x4C2FC91: realloc (vg_replace_malloc.c:785)
by 0xA1F89FA: g_realloc (gmem.c:159)
by 0xA1BAD2E: g_array_maybe_expand (garray.c:779)
by 0xA1BA566: g_array_set_size (garray.c:555)
by 0xA1BBCB8: g_byte_array_set_size (garray.c:1752)
by 0x8D1CC48: g_file_load_contents (gfile.c:6766)
by 0x5FAE767: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4501)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
https://bugzilla.gnome.org/show_bug.cgi?id=772215
The relative-to widget may be reparented itself into/out of a
scrollable. In this cases make the hierachy-changed handler to
unset the parent scrollable when unparented, and look up again
the parent scrollable after it's reparented.
https://bugzilla.gnome.org/show_bug.cgi?id=771812
gtk_popover_set_scrollable_full() takes care of the signal connected
on the scrollable itself, in addition to the adjustment signals the
popover listens to.
gtk_popover_update_scrollable() looks up the current relative-to
widget hierarchy and updates the current scrollable.
The places where the scrollable is being maintained have been updated
to use these functions.
https://bugzilla.gnome.org/show_bug.cgi?id=771812
Opaque region, margin and input region were only being synced when a cairo
paint happened. That caused GL paints to sometimes end up with bad state.
Move calls to sync state to gdk_window_impl_wayland_end_paint.
https://bugzilla.gnome.org/show_bug.cgi?id=771553
Setting the shadow width earlier as done with commit 4cb1b96 to address
bug 771561 proved to cause unexpected side effects on size_allocate
signal propagation.
As the window is sized correctly earlier, the size_allocate signal is
not emitted again in gtk_widget_size_allocate_with_baseline() which
prevents clutter-gtk from relocating its child widget correctly.
To avoid this issue, revert commit 4cb1b96 but make sure the values
passed as min and max size is never negative in Wayland as this is a
protocol error.
With this, the min/max size will be wrong for a short amount of time,
during the state transition, until the shadow width is updated from
gdk_window_set_shadow_width().
This approach is much safer and less intrusive than changing the
size_allocate logic in gtk.
This reverts commit 4cb1b9645e.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=771915
