Since demos.h is now generated according to the platform for which GTK+ is
built, don't distribute it. Generate a Windows-specific demos.h.win32 and
distribute that instead, in which the Visual Studio build files will copy
it to demos.h, so that the build will proceed normally.
https://bugzilla.gnome.org/show_bug.cgi?id=749622
To generate the icon cache files.
We want to avoid a dependency loop if possible; additionally, on some
Debian-based systems gtk-update-icon-cache maps to the GTK2 version of
the utility and the GTK3 version is renamed to
gtk-update-icon-cache-3.0.
To avoid a build dependency on GTK2, use the binary that we just built
in-tree.
https://bugzilla.gnome.org/show_bug.cgi?id=749593
The other Radio* widgets have this convenience method that removes the
memory management of the opaque GSList used to handle the group from the
API usable from language bindings (especially the ones not based on
introspection).
This commit adds gtk_radio_menu_item_join_group().
https://bugzilla.gnome.org/show_bug.cgi?id=671362
When removing all rows, trying to add rows would not work
and throw criticals. This is fallout from a recent change
to insert rows at the right position. Fix this by handling
the 'empty model' case separately.
https://bugzilla.gnome.org/show_bug.cgi?id=743157
Adding rows to the bottom of the list is confusing as you cannot see
them if the window is small so it is not apparent that anything has
happened. Fix this by adding the new row immediately below the current
row and set the cursor on the new row so it is ready to be edited.
https://bugzilla.gnome.org/show_bug.cgi?id=721939
We really want margins around the scrollable content, not around
the viewport. Make it so by using textview-specific properties.
This is unfortunately a little complicated for top/bottom.
"Hey I know, let's do an easter egg!"
"What kind of easter egg?"
"We can nest lots of textviews!"
"Sounds cool!"
...
"But how does one see a textview inside a textview?"
"What do you mean?"
"Well, it just looks like black text on a white background."
"You mean it's the same as if we just duplicated the text?"
"Yeah!"
"Hrm, maybe we can put a frame around it."
"Sounds good. I'll stuff the textviews in a GtkFrame."
"What? Why? Let's use a GtkEventBox and override its background"
"Why is that a good idea when we have GtkFrame?"
"Because I said so!"
"Okay."
Overriding the background color for a color swatch is wrong. The color
is not the background, it's the foreground, so it should be painted in
a draw signal handler.
GtkSidebar behaves internally much like GtkStackSwitcher, providing a vertical
sidebar like widget. It is virtually identical in appearance to the widget
currently used in GNOME Tweak Tool.
This widget is connected to a GtkStack, and builds its own contents as a
GtkListBox subclass, using the "title" child property to provide a consistent
navigatable widget.
Being a subclass of GtkListBox it benefits immediately from strong keyboard
navigation, and minimal changes are required for theming.
https://bugzilla.gnome.org/show_bug.cgi?id=735293
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Loading a builder file with a window leaves a ghost behind, since
windows need to be explicitly destroyed. Avoid that by using
gtk_builder_add_objects_from_resource.
... for displaying resources. Instead use the proven and way more
reliable method of trial and error.
It's less code and more portable for a start.
But most of all it displays PNM files as text if you fail to compile
the gdk-pixbuf loader for it.
As a noinst_PROGRAMS, the libtool generated for cross-compiling will be
used, which will mess up the linking. Create a all-local target instead.
Also ensure that building uses always a native version of the tool by
specifying a GTK_UPDATE_ICON_CACHE automake variable.
Finally "config.h" has been created to work for the target platform and
causes problem when cross-compiling. So we temporarily generate a basic
config.h which contains only the strict minimum.
Otherwise, we get every icon twice. To switch between symbolic
and non-symbolic icons, this css fragment comes in handy:
* { -gtk-icon-style: symbolic; }
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
The propagation phase property/methods in GtkEventController are gone,
This is now set directly on the GtkWidget add/remove controller API,
which has been made private.
The only public bit now are the new functions gtk_gesture_attach() and
gtk_gesture_detach() that will use the private API underneath.
All callers have been updated.
The incremental loading was broken by GtkIconHelper - queuing a
redraw is no longer sufficient to cause GtkImage to redraw with
the new pixbuf contents.
Pointed out by Jasper St. Pierre.
The keynav dialog is transient to the example window; since the
example window is now modal, we need to make the keynav dialog
modal as well, so it can receive input.
Problem pointed out by Jasper St. Pierre.
This property is TRUE by default, when a popover is modal, it
will automatically set a GTK+ grab on the popover, and grab
the keyboard focus into the popover.
The GtkBuilder window containing the complex popover UI was left
dangling, and with a dangling pointer to its former child, causing
crashes on gtk_grab_notify() after the popover was destroyed.
Two changes that sneaked in during the GtkApplication port
made it so that the window would not let you shrink it again
after you've made it larger. This also yielded very surprising
results when unmaximizing the window: it would come back to
have a minimum width slightly larger than the screen, making
maximization fail from then on.
This demo condenses the essentials of advanced management of
input events. Depending on the information available in input events,
this demo will try to represent as much information as possible for
those.
https://bugzilla.gnome.org/show_bug.cgi?id=719987
* gtk/gtkwidget.c: drag-leave signal: Document that it is called before
drag-drop.
drag-data-received signal: Document that it is up to the application
to know why the data was requested (e.g. drag motion or drop).
* demos/gtk-demo/toolpalette.c: interactive_canvas_drag_drop():
Do not transform the drop_item created in the drag-motion handler.
Instead caused drag-data-received to be called, remembering why,
and create a new item there.
interactive_canvas_drag_leave(): Remove the idle-handler hack,
now that we do not need to keep the drag-motion drop_item alive until
the drop.
I noticed that this patch was sitting in bug #605611 from 2009
though it had been approved. I do not remember much about why I
created it.
We rename the gtk_widget_class_bind_template_child{_internal}
macros by appending a _private to their name. Otherwise, it
would be too magic to pass the 'public' names as arguments,
but affect a member of the Private struct. At the same time,
Add two new macros with the old names,
gtk_widget_class_bind_template_child{_internal} that operate
on members of the instance struct.
The macros and functions are inconsistently named, and are not tied to
the "template" concept - to the point that it seems plausible to use
them without setting the template.
The new naming scheme is as follows:
gtk_widget_class_bind_template_child_full
gtk_widget_class_bind_template_callback_full
With the convenience macros:
gtk_widget_class_bind_template_child
gtk_widget_class_bind_template_child_internal
gtk_widget_class_bind_template_callback
https://bugzilla.gnome.org/show_bug.cgi?id=700898https://bugzilla.gnome.org/show_bug.cgi?id=700896
Using an offset from the struct means you can have children in
both the public and private (via G_PRIVATE_OFFSET) parts of the
instance. It also matches the new private macros nicer.
https://bugzilla.gnome.org/show_bug.cgi?id=702563
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Emit the "changed" signal after 150 msecs, so that searching
through big lists, or doing online searches feels more responsive.
This is something already done in various applications to make
search-as-you type more responsive (gnome-shell, gnome-documents,
gnome-control-center, etc.). The 150 msecs is the value currently
used by gnome-shell, so keep it (invisibly) consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=700229
In commit 4e41577b, we are using g_content_type_is_a() to determine how
to display the demo resources in the right pane of the gtk3-demo program.
Use g_content_type_get_mime_type(), so that we can obtain the mime
type of the demo resources on all platforms, as g_content_type_guess()
returns a platform-specific string, as
https://developer.gnome.org/gio/2.35/gio-GContentType.html states.
As .ui files and .css files are normally registered with a different mime
type string on Windows, check for those strings as well.
This will ensure the demo resources can be properly displayed on Windows
as well.
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
This way, people know what stuff we are loading.
And instead of listing all the files in the top (and forgetting things),
we just take them from the resources list.
