...unless they are labeled.
To implement this, keep track of the nesting depth of section boxes,
starting from 0 for the toplevel and the submenu ones, and only
insert unlabeled separators if the depth is at most 1.
When the adjustment changes (due to e.g. a mouse wheel scroll) we update
the prelight. The part that un-prelights the previous prelight was
broken by the the pixel cache, as it called update_prelight in the
middle of the scrolling operation, where the windows were moved
but the tree_view->priv->dy was not changed to the new value. This
caused the updates to the pixel cache to go to the wrong place.
We fix this by fully doing the scroll before we update_prelight().
https://bugzilla.gnome.org/show_bug.cgi?id=728284
GtkMenuTrackerItem::visible was removed a few commits ago.
It is not necessary to bind visible anyway, since the menu
tracker will insert and remove items as their visibility
changes.
Now that popovers may snap to any side with enough space, make enough
room on every side when requesting size, so that there's no w/h differences
at the time of setting the child allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=729097
When activating an item using mnemonics GtkRecentChooserMenu does not select a
item before calling the item-activated signal thus
gtk_recent_chooser_get_current_uri() always return the last selected item
instead of the activated one.
Fixes Bug 495105 "Open recent file keyboard shortcuts do not work correctly"
The real reason for the problem that the just reverted change
was supposed to address is that testfilechooser uses show_all
to tease out places where composite dialogs don't properly
protect their internals against unintended showing. Well,
lets do that, then.
In iconic mode, model buttons will be styled like regular icon
buttons, preferring to show only the icon if one is set, falling
back to showing the label.
https://bugzilla.gnome.org/show_bug.cgi?id=727477
When rendering iconic sections, we want to use icons for verbs,
and we want to differentiate these in the menu model, to keep
the icon attribute reserved for nouns.
https://bugzilla.gnome.org/show_bug.cgi?id=727477
Instead of using GtkMenuTracker to flatten the sections into a single
linear menu, handle the sections ourselves by nesting boxes.
Each section gets an inner and outer box. The inner box numbers its
children in the way that the tracker instructs. The outer box
containes the inner box and the separator, if appropriate.
Having the two separate boxes will allow us to change the orientation of
the inner box if we want to pack widgets horizontally within a section.
Add the possibility of a GtkMenuTracker that performs no section
merging. Instead, it will report an item in the form of a separator for
subsections. It is then possible to get a separate tracker for the
subsection contents by using gtk_menu_tracker_new_for_item_link().
We have some API in GtkMenuTracker and GtkMenuTrackerItem that is
specifically designed to deal with submenus.
Generalise these APIs to take a 'link_name' parameter that we always
give as G_MENU_SUBMENU for now. In the future, this will allow creating
trackers for other types of links, such as sections.
Make this a property just like all of the other things and make the APIs
for accessing it non-private (but add a note that they are not intended
to be used).
This is not a great name to use in themes; instead, add the
menuitem class, so themes can use .button.menuitem for styles
that are specific to menuitem-like buttons.
We were not really handling all cases correctly here. We want
the suggested-action style class to only be set on headerbar
buttons, and it should be set on the default widget. Ensure
this by syncing the suggested-action style class with the
default style class. As a side-effect, setting has-default
on an action widget in ui files will now have the expected
effect.
https://bugzilla.gnome.org/show_bug.cgi?id=728846
GtkDialog has convenience API for adding action widgets that are
either placed in the action area or the headerbar. This commit
makes the same functionality available from GtkBuilder ui files
by specifying "action" as the child type.
https://bugzilla.gnome.org/show_bug.cgi?id=728846
When constructing from a menu model, use popovers by default.
This change has the potential to cause some size problems for
applications with big gear menus, so we're doing it early in
the cycle to uncover and fix those.
According to what i've been told, modelbuttons are supposed to look
flat, like menu items.
This is basically an improved copy of the menuitem styles.
https://bugzilla.gnome.org/show_bug.cgi?id=728810
This prevents checkmarks in modelbuttons from being styled as buttons
(apparently, modelbuttons apply "focused" to their children, unlike
normal buttons).
https://bugzilla.gnome.org/show_bug.cgi?id=728808
When making the entire window a drop target, as file-roller does,
we don't want to draw the drag highlight around the CSD window
decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=728526
Please enter the commit message for your changes. Lines starting
This should allow theme developers to use a very small width for
the resize handle, but still let users easily move the handle by
defining a wider resize area.
The additional resize area follows the "margin" style property.
https://bugzilla.gnome.org/show_bug.cgi?id=728073
Binding an object sensitive property with a check button active property will look like this:
<object class="GtkButton" id="button">
<property name="sensitive" bind-source="checkbutton" bind-property="active"/>
</object>
This is based on the original work done by Denis Washington for his GSoC project
This closes Bug 654417 "[GSoC] Add <binding> element to GtkBuilder syntax"
When selecting a swatch in a GtkColorChooserWidget the previously
selected swatch and the currently selected swatch are not redrawn. This
can leave the old swatch still marked with a checkbox even though a new
swatch has been selected.
Redraw the swatches after changing the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=727487
The documentation for the GtkWidget::size-allocate signal is missing the
description of the "allocation" parameter. Add the missing description
to the parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=726179
Use GSlice to allocate all types of segments:
- char
- toggle
- mark
- pixbuf
- child widget
Char segments are a bit more complicated because the length of the text
is determined at run time and stored in the 'byte_count' field. If the
text is long, GSlice will call the system malloc() anyway, so it's
better to always use GSlice for GtkTextLineSegment.
Toggle segments are also freed in gtktextbtree.c, hence the function
_gtk_toggle_segment_free() (for a later commit it would be nice to
rename those functions with the _gtk_text prefix).
https://bugzilla.gnome.org/show_bug.cgi?id=727908
There is a possible confusion with the sentence:
"@iter is inside a natural-language word"
The iter should be viewed here as the pointed character (i.e. on the
right of the iter), not as a position between two characters.
Instead of improving the documentation, another solution would have been
to change the implementation so it is interpreted as an iter position
inside a word, i.e. between two characters that are part of a
natural-language word. But maybe some applications rely on the current
implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=727908
We are keeping references on the widget we are handling as we
are iterating up, but that doesn't protect us against the entire
tree being axed from inside gtk_widget_handle_event.
https://bugzilla.gnome.org/show_bug.cgi?id=727644
Commit d05191a010 change the height
requisition to be completely dependent on the PangoLayout, but that
breaks when the font has special characters with different metrics.
Use the maximum between the two instead.
https://bugzilla.gnome.org/show_bug.cgi?id=728054
The use of border-width-set here was an attempt to differentiate
between explicitly set (from code / ui files) border width from
theme changes. But when we are calling gtk_window_set_border_width
to apply the theme value, the -set property gets set, and all
further theme changes are ignored. This has the effect of only
letting the default value of these properties get applied.
Fix this by unsetting border-width-set after applying theme values.
Because GTK does not invalidate windows that aren't mapped, we cannot
update the pixel cache when the window it handles isn't mapped. So we
add API to call when GDK windows get mapped/unmapped.
https://bugzilla.gnome.org/show_bug.cgi?id=726475
This commit makes it possible for GtkSwitch to indicate when
the underlying state changes with a delay, causing the switch
to temporarily go 'out of sync' with the underlying change.
https://bugzilla.gnome.org/show_bug.cgi?id=725648
