We already take care to not track headers when the listbox is hidden,
because that can be very expensive during creation, so we might as
well skip reseparate() too. The only time we don't want to skip it
is when we're about to show the list.
This was added from https://bugzilla.gnome.org/show_bug.cgi?id=691979
where it was wanted in order to get a "all children filtered" kind
of row. However, the solution is not really generic enough, because
filtering can happen for other reasons than a full refilter (i.e. due
to a row change), and the partial fix you can get by counting children
after refilter can be achieved by manually doing it whenever you manually
called refilter anyway.
Its possible we should have some better solution for the "empty state"
though.
Historically the following states propagated to children:
GTK_STATE_FLAG_ACTIVE
GTK_STATE_FLAG_PRELIGHT
GTK_STATE_FLAG_SELECTED
GTK_STATE_FLAG_INSENSITIVE
GTK_STATE_FLAG_INCONSISTENT
GTK_STATE_FLAG_BACKDROP
However, several of these are problematic on containers like GtkListBox.
For instance, if a row is ACTIVE or SELECTED then all children (like e.g
a button) inside the row will *also* look active/selected. This is almost
never right. The right way to theme this is to catch e.g. SELECTED on the
container itself and set e.g. the color and let the children inherit
the color instead of the flag.
We now propagate only these flags:
GTK_STATE_FLAG_INSENSITIVE
GTK_STATE_FLAG_BACKDROP
Which make sense to be recursive as they really affect every widget
inside the container.
However, this is a CSS theme break, and while most things continue working
as-is some themes may need minor tweaks.
Now that we automatically set up the focus_vadjustment we only
need the adjustment to handle the page-up/down scroll length correctly.
We use parent_set to automatically pick up the adjustment from a
scrollable (i.e. viewport) parent which makes add_to_scrolled useless, so
it can be removed.
When adding with a viewport we automatically set the focus
adjustments on the viewport from the scrolled window, so that
when any child widget gets focused we automatically scroll to it.
This is generally nice, but its particularly important for GtkListBox
where focus changing is how we navigate between rows.
We also ensure that the adjustments are always set before adding the
child to the viewport, which we will need later to pick up the
adjustments on add.
Unhighlight rows if they are removed.
Drop the automatic drag motion based auto-scrolling. This is not really
right, as it e.g. hardcodes auto-scroll regions and assumes we're the only
widget inside the scrolled container. Its also imho in the wrong place,
autoscrolling if any should be done on the scrolled-window or viewport.
All the removed code is implementable outside Gtk+ though.
Use g_string_assign to avoid issues with assigning GString's internal
buffer back to the same string. This can happen when no translations are
available and _gtk_builder_parser_translate returns back the same
pointer that was passed in.
This fixes a regression from commit e9f182e37a
that caused GtkComboBoxText <items> from GtkBuilder to show up empty if
no translations are available.
https://bugzilla.gnome.org/show_bug.cgi?id=700629
-Avoid defining variables in the middle of the block
-Include fallback-c89.c in gtkrevealer.c in place of math.h as
fallback-c89.c includes math.h itself, and is needed for round()
Do not unref mount has we grabbed its pointer without taking
a reference.
Otherwise the following call to g_list_free_full on network_mounts
frees it a second time. Segfault in nautilus ensue.
https://bugzilla.gnome.org/show_bug.cgi?id=700979
gtk_widget_get_allocated_height returns the adjusted
allocation, so we can't use it as measure for how much
room to leave when drawing the window background.
The intention of the expand widget flags was to in fact propagate
legacy expand child properties as well. Due to implementation errors,
this was only happening in some cases, but not in others. To avoid
breaking old code assuming traditional expand flag behavior, this
commit removes all attempts to propagate GtkBox::expand.
This was discussed in
https://bugzilla.gnome.org/show_bug.cgi?id=698656 and
https://bugzilla.gnome.org/show_bug.cgi?id=628902
This patch was written by Tristan Van Berkom.
Focusing the text entry without selecting all the text is needed in
some places (GtkTreeView, and some uses of GtkSearchEntry) so
create a private helper to avoid replicating the hacks.
https://bugzilla.gnome.org/show_bug.cgi?id=700787
Work around this by introspecting gtkclipboard.c and gtkdnd.c instead
of the quartz alternatives.
Note that this is temporary: The implementation of GdkSelection
will make the quartz alternatives unnecessary. See bug 571582.
Mouse events that we do not handle should bubble up to the parent
widget, so they can be handled there, instead of disappearing inside
the button. Also use GDK_EVENT_{STOP,PROPAGATE} to make return
values clearer.
https://bugzilla.gnome.org/show_bug.cgi?id=696640
Instead of storing the rect in the bin window, store the row and column
the editable belongs to and compute the rect lazily. This way, we don't
need to keep the rect up to date.
Fixes /TreeView/scrolling/new-row-mixed/path-500 test.
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
Now that we're not drawing the GdkWindows by themeselves we need to
propagate into children in the same order as the windows were painted
otherwise apps can't rely on stacking order to overlay children.
This is still not 100% the same as the old behaviour, because we're
treating all windows that are part of a window at the same time (to allow
e.g. opacity groups), and we're only looking at order for the main
windows of a widget. However, this fixes at least the ordering
of the gnome-boxes fullscreen overlay toolbar.
https://bugzilla.gnome.org/show_bug.cgi?id=699970
Instead of making clients inspect the submenu action and decide what
to do based upon that, always request the submenu open and let the
tracker decide what to do.
Add a new class, GtkMenuTrackerItem that represents a menu item, to be
used with GtkMenuTracker.
GtkMenuTracker's insert callback now works in terms of this new type
(instead of passing reference to the model and an index to the item).
GtkMenuShell now handles all of the binding tasks internally, mostly
through the use of property bindings. Having bindings for the label and
visibility attributes, in partiular, will help with supporting upcoming
extensions to GMenuModel.
GtkModelMenu has been reduced to a helper class that has nothing to do
with GMenuModel. It represents something closer to an "ideal" API for
GtkMenuItem if we didn't have compatibility concerns (eg: not emitting
"activate" when setting toggle state, no separate subclasses per menu
item type, supporting icons, etc.) Improvements to GtkMenuItem could
eventually shrink the size of this class or remove the need for it
entirely.
Some GtkActionHelper functionality has been duplicated in
GtkMenuTracker, which is suboptimal. The duplication exists so that
other codebases (such as Unity and gnome-shell) can reuse the
GtkMenuTracker code, whereas GtkActionHelper is very much tied to
GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs.
supporting the full range of GMenuModel features for menu items turns
out to be two overlapping but not entirely similar problems. Some of
the duplication (such as roles) can be removed from GtkActionHelper once
Gtk's internal Mac OS menubar support is ported to GtkMenuTracker.
The intent to reuse the code outside of Gtk is also the reason for the
unusual treatment of the enum type introduced in this comment.
This adds no new "public" API to the Gtk library, other than types that
we cannot make private due to GType limitations.
Rename our internal GActionMuxer, GActionObserver and GActionObservable
classes and interfaces to have names in our own namespace.
These classes were originally intended for GIO but turned out to be too
special-purpose to be useful there, so we never made them public API but
have just been copying them around (without bothering to properly rename
them). Now that other people will be copying them out of Gtk, it's even
more important to prevent this namespace abuse from spreading further.
We were using gtk_menu_item_get_label() from a testcase to determine the
label associated with a menu item. Future changes to GtkModelMenuItem
will cause this to stop working, so try a bit harder to find a label
inside of the item.
GtkApplicationWindow would only update its list of captured accels
when realizing the window. This meant that keyboard shortcuts added
after the window was realised (for example, added by plugins) would
be non-functional.
Solve this by updating our accels every time the accel map changes,
not only when realizing the window.
https://bugzilla.gnome.org/show_bug.cgi?id=700079
Items that act on the selection should not be sensitive if the
selection is empty. This was already the case for the 'Copy file
location' item, but not for the 'Add bookmark' and 'Visit file'
items.
https://bugzilla.gnome.org/show_bug.cgi?id=699104
Usually, educated GtkContainers' forall() implementation returns children
in an order that's safe for the default draw() implementation in GtkContainer.
So for widgets with some stacking notions (eg. GtkOverlay),
_gtk_widget_find_at_coords() needs to recurse within containers in reverse
order so it finds the topmost widget.
As this function is used in both tooltips and DnD code, this improves behavior
of "floating" widgets wrt those two. This could for example be seen in the
"Transparent" GTK+ demo, where dropping text on the entry results on the text
going to the textview.
https://bugzilla.gnome.org/show_bug.cgi?id=699239
Also removed a bogus FIXME comment which might have been true
a long time ago. Clarification: the "domain" attribute specified
in the builder script overrides any domain previously set with
gtk_builder_set_translation_domain(), so the translation of items
here is perfectly correct and does not need to be fixed.
Bring back need_default_size. We need it to preserve this
documented behavior:
The default size of a window only affects the first time a window is
shown; if a window is hidden and re-shown, it will remember the size
it had prior to hiding, rather than using the default size.
With this patch, all of the window sizing tests in
gtk/tests/window pass again.
gtk_widget_preferred_size() is only useful if you want to quickly port a
widget from GTK2 sizing code to GTK3 but does not properly work with
height-for-width as used in GTK. So we don't want to encourage people to
use it. In particular we want people to convert to height-for-width
before adding baseline support to their widgets.
