The center widget in GtkBox was only introduced to use it in
GtkActionBar. However, the implementation there is much more complex
than it needs to be, so move the center widget into GtkActionBar instead
and later remove it from GtkBox.
This replaces all internal gadgets with widgets.
Remaining problem: "block" nodes have a min-width of 32px in Adwaita,
but when allocated in continuous mode, the levelbar doesn't care and
underallocates them.
GtkGizmo is the easiest possible widget to implement. It does nothing
except give its creator a way to control measure/size-allocate/snapshot,
so it can be used in a variety of use cases.
Insert the css node before setting a parent widget on the column button,
so the gtk_widget_set_parent won't attempt to add the css node as child
of the parent widget css node.
Translating it seems pointless if we can use a non-translatable example
such as gnome.org instead of foo.example.com.
This will help to make changes in here without breaking string freeze.
https://bugzilla.gnome.org/show_bug.cgi?id=781622
We were send the "open-location" signal without mounting first the
location if necessary, making the open in tab/window context menu not
work for those.
This patch makes sure we mount the location before emitting the signal.
https://bugzilla.gnome.org/show_bug.cgi?id=771269
Because the network monitor can perfectly be NULL,
the tests were failing on that for GtkPlacesView
always tries to disconnect this handler.
Fix that by only disconnecting the handler when
the network monitor exists.
https://bugzilla.gnome.org/show_bug.cgi?id=781195
GtkPlacesView exposes local access points and network
shares transparently by using the 'network:///' URI,
which is handled by GIO.
Currently, however, it doesn't monitor the network
for new available points, such as computers that just
join the network. It may happen too that the backend
won't find all the networks before the network enumeration
finishes.
Fix that by keeping a file monitor inspecting the network
uri, and update the places list when that happens.
https://bugzilla.gnome.org/show_bug.cgi?id=781162
Instead of the deprecated g_object_newv().
This requires some internal surgery to create our own vector of names
and values, but it does not functionally change anything.
GLib 2.53 deprecated g_object_newv() and GParameter. If we want to stop
using those types without resorting to pretty convoluted pre-processor
dancing, we will need to bump up the dependency inside GTK+.
GLib has deprecated GParameter and g_object_newv(); until we switch to
the new g_object_new_with_properties() API, and bump GLib required
version, we should simply ignore the compiler warnings.