…from priv->button. My refactor to g_signal_disconnect_by_data()
included this widget, when I shouldn’t have as both modes use it.
In GTK+ 3, this broke opening a CB by keyboard that was in menu mode,
if it had been in list mode initially (e.g. due to the theme).
Fix by moving to disconnect_by_func() and only removing in each mode’s
destroy() method the signals that it set on the button in its setup().
https://bugzilla.gnome.org/show_bug.cgi?id=788577
This gives consistent behavior with e.g. Qt, Mozilla's suites and
LibreOffice (with non-truly native backends like "gen" and "gtk",
but unlike "gtk2" and "gtk3" ones that probably use true GTK menus).
This behavior is expected by at least some accessibility users, and
it seems good to behave like other common applications and toolkits
in this area. There should be no issue in doing so either for current
users, as it only enters the submenu instead of not doing anything.
https://bugzilla.gnome.org/show_bug.cgi?id=778811
Ditch two items that were white and so weren’t visible on our standard
theme anyway, and use the new space to test extra grid-mode properties.
Note if we do this then, as before, set the ListStore on the CB before
before appending to it, that (at least in GTK+ 3) gave warnings like:
Gtk-CRITICAL **: gtk_menu_attach: assertion 'left_attach < right_attach' failed
I didn’t look into that yet, but it may indicate that attaching items
vs. recognising their spans don’t occur in the correct order. For the
purposes of testing this, I just create the CB after filling its model.
We need floating-point division… Otherwise, only fully-on inputs can
produce any output. This fixes some of the colours wrongly being black.
While here, remove the unused rowstride variable, to shush a warning.
ComboBox warned in the doc for :row-span-column that the value must not
exceed :wrap-width, but :wrap-width does not interact with the number of
rows; it’s the :column-span-column that’s relevant.
Also: Warn that spans must be > 0 for rows too, & that column spans <=
:wrap-width are also not useful for items at menu column positions > 0.
Rrefer to items having spans, not values, as we’re already talking about
values in the model (& rows in the menu). And clarify :wrap-width a bit.
Various disconnections had the wrong flags and/or data, so we failed to
disconnect a pile of signals, shown by 0 returned by the disconnect_*()
functions. Fix this, and use the nicer disconnect_by_*() while here.
set_transient_for(toplevel) was only called in list_setup(). It was easy
to make a test showing a NULL :transient-for instead of the correct one.
So, move the call from list_setup() to real_popup(). Also do the same
for window_group_add_window(), which means not calling it redundantly.
(I tried using a ComboBox:parent-set handler, but the Inspector’s CB
didn’t like that: it calls popup_for_device() twice and closes on button
release. Anyway, using popup() is much more concise than a new handler.)
The screen for the list-mode popup_window was only being set in
set_popup_widget(), i.e. when changing modes, so if the ComboBox was
moved to a different screen later, the popup would appear on the
original one, which is wrong.
Worse, this broke opening some combos in the Inspector in GTK+ 3.
Fix this by moving the call to set_screen() to real_popup(), so
the popup_window is put on the correct screen each time around.
https://bugzilla.gnome.org/show_bug.cgi?id=468868https://bugzilla.gnome.org/show_bug.cgi?id=786771
Bad actors, such as our very own FileChooserButton, may connect to the
:popped-up property and alter the model as the menu becomes in/visible.
We were getting an iter to the model while popped-up, then doing
popdown(), then using the iter, which may have just been invalidated by
the errant notify::popped-up handler. If so, we quickly crash fatally.
This is clearly bonkers, but until such patterns are removed, we have to
work around them. So, set_active() from the clicked item while it is
known to be valid, by moving the call to set_active() before popdown().
While here, change set_active_iter(iter) to set_active_internal(path) to
avoid pointlessly going through the iter to get the path we already have
https://bugzilla.gnome.org/show_bug.cgi?id=729651
In gtk_container_real_set_focus_child(), we try to scroll to the
position of the new :focus-child if we have h or v adjustments.
gtk_widget_translate_coordinates() returns FALSE if neither widget is
realized or in other situations that cause output parameters x and y not
to be set. Thus, if the caller did not initialise x/y and uses them even
if the function returns FALSE, they are using uninitialised variables.
In gtk_container_real_set_focus_child(), we did not check the return
value but merrily went ahead and used x and y regardless. This is UB, as
caught by Valgrind, as well as being pointless.
The trivial fix is to exit early if (!gtk_widget_translate_coordinates).
https://bugzilla.gnome.org/show_bug.cgi?id=776909
Our ::query-tooltip handler first checks whether the pointer is over any
of the icons, returning their tooltip if so, and if not chains up to
Widget::query-tooltip in order to show the text for the widget overall.
But ensure_has_tooltip(), which exists to update :has-tooltip based on
whether ::query-tooltip is needed, only set :has-tooltip to TRUE if any
icon had a tooltip, without caring whether the widget as a whole does.
That is asymmetrical and meant that if the Entry had a tooltip, but
subsequently all icons had their tooltips unset, :has-tooltip would be
set to FALSE, and hence the tooltip for the widget would become lost.
The fix is to set :has-tooltip to TRUE if the widget has a tooltip of
its own, and we only need to check the icons if that is not the case.
https://bugzilla.gnome.org/show_bug.cgi?id=785672
Some files that this script will process might have UTF-8 items in
there, which can cause problems on Python 3.x as it is more strict and
careful on unicode issues.
Fix this by:
-Doing what we did before on Python 2.x
-Opening the file with encoding='utf-8' on Python 3.x
The TextIter is passed by pointer for efficiency. We neither need to
modify it, nor should we leave it possible to accidentally do so. So,
it should be passed as a pointer-to-const.
We do not need to go through the heavyweight process of constructing a
TextLineDisplay just to get the direction out of it, when we can simply
use TextIter API to get the text and then get its direction using Pango.
Adapted from a patch by Mehdi Sadeghi for GtkSourceView:
https://bugzilla.gnome.org/show_bug.cgi?id=779081#c20
