gtk_tree_view_column_unset_tree_view() resets column->priv->tree_view to
NULL.
The function is called when a column is removed, but later from the same
function we would call _gtk_tree_view_column_unrealize_button(), which
expects column->priv->tree_view to be != NULL, causing these critical
warnings
Gtk-CRITICAL **: gtk_widget_unregister_window: assertion
`GTK_IS_WIDGET (widget)' failed
This commit moves the call to unset the tree view after the button is
unrealized.
https://bugzilla.gnome.org/show_bug.cgi?id=695473
We assumed that we didn't have to update the combo box if the dialog got cancelled,
as it should simply retain its previous contents. But this assumption doesn't work
as the dialog is brought up with the 'Other...' item - we don't want the
combo box to keep showing 'Other...' if the dialog is cancelled.
The test from the previous commit now passes.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
There is this bug:
1. Start with a file chooser button in SELECT_FOLDER mode, and select a folder from the combo box.
2. Click on the button's combo box, select 'Other...'
3. You get the file chooser dialog. Cancel the dialog.
4. The file chooser button's combo box still shows 'Other...' instead of
showing the selection from (1).
This is a test to ensure that the original selection is restored.
The test fails right now.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This is surprisingly tricky, since the (None) item *has* to be a visible item while
the combo box is *not* popped up, so that it can show its contents. But the item
has to be *not* visible when the combo box is popped up.
Also, update the whole button's selection, not just the underlying dialog's, when
the combo box changes its selection - based on a patch by Paul Davis in
https://bugzilla.gnome.org/show_bug.cgi?id=691040#c20
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This way the internal labels will show the correct selection even if nothing
has been selected programmatically.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We didn't change it when the file chooser button's dialog was inactive, and so
the actual file chooser button would not visually reflect the current selection.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We do some gymnastics to pull the string out of the GtkButton or the GtkComboBox that is
being used in GtkFileChooserButton to show the current selection when the dialog
is inactive - namely, we look for the subwidget with the correct ATK role, and pull its
accessible name.
Currently the test fails; this is https://bugzilla.gnome.org/show_bug.cgi?id=691040#c18
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
In the case of checking for local_only, g_file_is_native() is not useful, since it
will return FALSE for something in a FUSE mount.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Since FUSE locations can be handled safely by applications show these mounted locations regardless of whether gtk_file_chooser_set_local_only()
is set to TRUE
https://bugzilla.gnome.org/show_bug.cgi?id=586367
We do this by making the ::populate-popup signals a little more
flexible. They used to just accept a GtkMenu as argument, now
they can take a menu or a toolbar. To not break the expectations
of existing callbacks, we only emit ::populate-popup with a toolbar
if the :populate-toolbar property is TRUE.
Now, even if the handles being rendered are small, the handle touch
input shape will be as wide as the visible part of the rendered asset, and
high enough to cover both the handle and the height of the line where
the selection bound is.
Also, make handles have the same virtual distance to the line top/bottom
when a drag starts, so the handle doesn't jump to another line after a
too short threshold.
Don't set handles mode to none if the event has send_event set.
For consistency with GtkEntry, also make GtkTextView keep the
handle mode on buffer changes.
We block signal handlers areound GtkEntry signal emission and if those
signals get used to call functions on the completion that cause a
reconnection of the signals, then the reconnected signals will not be
blocked anymore (so they might get emitted?) and unblocking the old
signal id will later cause warnings.
Fixes spurious warnings in gtk/tests/filechooser tests.
When setting contents of the clipboard and ownership or user data changes, we
end up calling clipboard_unset() to fully cleanup the previous clipboard state.
This call will itself call clear_func() for the previous user_data, and always
reset both 'get_func' and 'clear_func' to NULL.
So it's actually not possible to have 'get_func' being non-NULL once we have
called clipboard_unset(), so just remove that condition check and the code
inside.
https://bugzilla.gnome.org/show_bug.cgi?id=694924
icon_info_dup() is now called also for GtkIconInfos that already have
a pixbuf, so we must make sure that we correctly carry that from
the original icon_info to the copy.
