We had already set the image to be hidden in the .ui file.
This patch removes the image altogether, and deprecates the
property, setter and getter.
If an image is explicitly put with the setter, it is still
shown, so to not break existing users of this API.
Based on a patch by Jon McCann.
Try to do a better job of keeping example content
from being too wide. It is often rendered as <pre>
text so the only time we can wrap it is in the source.
It is best to full break lines at all punctuation and
to try to keep the width under 70 chars or so.
We don't want the size request to change as icons come and
go (thinking e.g. about the caps lock warning). Just make
sure that we have enough room for showing the icons.
Improve the algorithm to determing popover placement:
If it fits in the preferred direction or its opposite,
do that, otherwise use the direction that causes the least
of the popover to be cut off.
Add api to allow explicitly setting a GtkPopover instead of
a GtkMenu as the popup of a GtkMenuButton. Also, add api to
instruct the menu button to construct a popover when given
a menu model.
We set the style class "menu-button" on the button only when
it pops up a menu, to allow different treatment for the active
state of the button in the two cases.
https://bugzilla.gnome.org/show_bug.cgi?id=723878
cairo_rectangle_int_t replaced by GdkRectangle whenever it is used.
Also, rect parameter in public method gtk_popover_set_pointing_to
made const.
Bug #723394
Replace GTK_TYPE_WIDGET with more specific GTK_TYPE_FLOW_BOX_CHILD
for GtkFlowBox::child-activated. This matches signature of
child_activated slot in class struct.
https://bugzilla.gnome.org/show_bug.cgi?id=723716
The properties are declared read-write, but only the setter
was hooked up. This was leading to criticals in test apps using
the prop-editor.c code. Complete the implementation by adding the
getter side too.
This adds a new function, gtk_popover_new_from_model, which creates
a popover and populates it with suitable content according to the
menu model. The current implementation uses GtkModelButton for the
individual items, and a GtkStack for submenus.
https://bugzilla.gnome.org/show_bug.cgi?id=723014
Similar in spirit to GtkModelMenuItem, this private GtkButton subclass
can connect to a GtkMenuTrackerItem and present itself as either a
regular button, a check button, or a radio button. Activation and
state tracking is done through the GAction that is associated with
the menu tracker item.
https://bugzilla.gnome.org/show_bug.cgi?id=723014
Popovers aren't direct children of the widget they point to, but yet
they act as children of it, so do the same with state propagation,
so the flags that propagate across the hierarchy reach popovers too.
Anytime ::grab-notify comes across, the popover visibility and GTK+
grab ownership are checked, so the popover is hidden when it loses
the GTK+ by any reason.
Previously we did a semi-successful job at ignoring it. Unfortunately
this job was bad enough that we could lose the direction.
We still allow passing in the enum values, because we want code like
this to work:
set_state_flags (get_state_flags() | SOME_FLAGS)
Heavy duty can prevent this idle function from being called before
the window is destroyed, so make sure that the source is removed
when the window is finalized.
https://bugzilla.gnome.org/show_bug.cgi?id=723771
This hideous hack is necessary so far because the main users of
GtkScaleButton are also clutter users, so the GtkScaleButton popover
will be very likely shaped against a clutter-enabled native window.
https://bugzilla.gnome.org/show_bug.cgi?id=723556
Popovers no longer sets a shape, unless this function is called. This
function exists so widgets that are potentially placed on top of other
native windows can get a popover that's nicely shaped, even if it has
no border shadow around.
https://bugzilla.gnome.org/show_bug.cgi?id=723556
Since realize does a lot of the heavy lifting of setting up
csd, we have to re-realize the window if we go from no-custom
titlebar to a custom titlebar or vice versa.
https://bugzilla.gnome.org/show_bug.cgi?id=722919
When gtk_window_set_titlebar is called, we need to set up
client-side decorations properly, and the easiest way to do
so is to realize the window again. Really, you should call
set_titlebar before the window is realized.
https://bugzilla.gnome.org/show_bug.cgi?id=722919
10b5ec20 made sure not to set focus_child to NULL all the way up to the
top, but only up to the common ancestor. However, it would never set it
on the common ancestor itself, which would therefore remain with a
focus_child set when it shouldn't.
A manifestation of the bug: focus column headers of a treeview, press Tab.
Now pressing Shift+Tab will go to another widget and not the column
headers, and Tab will (appear to) do nothing, all because the treeview
still has a focus_child set to column headers after a grab_focus().
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=723402
This reverts commit ba6128f8af.
This change breaks emacs drawing entirely. Since GtkFixed is
somewhat of a legacy widget anyway, lets just not bother doing
this modernization there, at least for now.
Showing tooltips on top of a transient popup does not work
out well, and is not really necessary here. At the same time,
remove the unnecessary repetitions of properties. In particular,
setting the label of the buttons here defeats the scale buttons
use of symbolic icons.
https://bugzilla.gnome.org/show_bug.cgi?id=723181
disconnect_by_func() is slow, and this becomes particularly evident
when disposing a number of widgets (and their associated style
context) at once, such as when using a language binding which
uses a GC.
https://bugzilla.gnome.org/show_bug.cgi?id=723183
It seems that alternate implementations of GtkFileChooserWidget
never materialized. The split between GtkFileChooserWidget and
GtkFileChooserDefault is awkward. The immediate problem is that
it makes it difficult to document the keybinding signals. So it
makes sense to drop the abstraction and just have one thing.
https://bugzilla.gnome.org/show_bug.cgi?id=723157
The button press/release handlers did invariably return FALSE, even
though it shouldn't if a row was found on the event coordinates. Also,
use GDK_EVENT_* defines for the return values.
The minimal size if no child widget was present/shown was far too small
to have enough room for the arrow width plus border radii, so
gtk_render_frame_gap would spew warnings about the gap being out of
boundaries.
Fixes issues seen in
https://bugzilla.gnome.org/show_bug.cgi?id=723031#c2
If the grab is released during button press, the button release is
just then sent to the widget below the pointer. Depending on the
widget implementation, this could already trigger actions if the
widget does not perform any kind of button state tracking. It is
safer to ungrab on button release so no extra actions are possibly
triggered, and the behavior is uniform across widgets.
But the opposite situation may also happen, that a popover is
shown/grabbed on a button press event, so it'd get the sole button
release event after being shown, so prepare for that case by making
popover ignore single button release events with no preceding button
press.
Fixes issues seen in
https://bugzilla.gnome.org/show_bug.cgi?id=723031#c2
