Introduce a new debug category "actions" and write some messages from
GtkActionHelper about if we can find the actions or not.
We will probably soon want to add some similar messages to
GtkMenuTrackerItem.
https://bugzilla.gnome.org/show_bug.cgi?id=733965
This leads to an assertion failure, because parent window is never registered
in the first place, widget's own GdkWindow is. But that window is unregistered
in a generic fashion by GtkWidget code, so there's nothing for us to do here.
https://bugzilla.gnome.org/show_bug.cgi?id=733766
So far, gtk_window_set_focus just did not work when called on
a hidden window. Change it to record the desired focus widget
for hidden windows, and apply it when the window gets shown.
This is similar to how we tread other window properties that
can't be set before the window is realized, like maximized
or fullscreen.
This is related to
https://bugzilla.gnome.org/show_bug.cgi?id=734033
The previous code for computing the clip rectangle forgot to respect
the text-shadow CSS property. This is usually not very visible because
text shadows usually don't extend the ink rectangle by very much.
See attached testcase for an example.
Although there is the "changed" signal, it is more correct to notify the
"text" property too. It can be useful for a small text view, where the
text is saved e.g. to gsettings with a binding to the text property.
The "text" property includes only the text, not child widgets or images,
so the notify signal is sent too many times (also for child widgets and
images), but it's not a big problem.
https://bugzilla.gnome.org/show_bug.cgi?id=624791
Currently, when loading an image from a GResource or file we don't take
the scale factor of the display into consideration, and let
GtkIconHelper scale it accordingly.
While this in general works for non-scalable images, we can take
advantage of the native loader's scaling for e.g. SVG images, and load
them at the right scale factor automatically.
This is achieved by switching to a pixbuf loader instead of using the
native function.
https://bugzilla.gnome.org/show_bug.cgi?id=733416
This allows subclasses to render things below and above the text
in the text view. This allows e.g. GtkSourceView to highlight the
cursor row and to render overlays for colum 80. This used to be done
by rendering before/after chaining up to the parent, but that doesn't
work anymore since the view now renders a background, and due to the
use of the pixel cache.
This reverts commit 1ac13435b7.
We want to instead replace this with special vfunc for drawing
below/above the main text so that gtksourceview can use it.
This was silently broken - the code was just assuming that the
text cell renderer is item no. 6 on the list of all cells. That
doesn't work so well if the cell renderers are set up elsewhere
and get rearranged.
Fix this by keeping an explicit pointer to the the text cell.
For images without a concrete size but with an aspect ratio, we took the
wrong code path.
(I even copied the documentation that said "Otherwise" but didn't put an
else clause there, go me!)
Now that widget paths are allowed to have a state, use that state when
querying style properties. This uses a fast path in gtkcssprovider.c and
that is great.
Header-bar and action-bar buttons used to be bigger then others
now everything is as big as those, maintaining two different sizes
for default widgets depending on the placement is a maintainance
nightmare and having controls the same size is good from a usability
point of view.
The toplevel_window was never set, and the only place where it
was used was causing us to hide tooltips needlessly. So removing
it is a double win.
https://bugzilla.gnome.org/show_bug.cgi?id=733321
Add yet another tab for showing information about a widget that
does not quite fit into any of the other tabs (not a property,
not style information, etc...).
For now, we show the widget state, as well as the default and
focus widget for windows.
GtkArrow is deprecated and is not used internally anymore by the
menu button. Document also the fact that if no direction is specified
then the view-context-menu icon is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=733441
People expect to be able to call gtk_widget_show_all on the dialog
to make action widgets visible, as seen e.g. in
https://bugzilla.gnome.org/show_bug.cgi?id=733431
To keep this working, we can't always set no-show-all on the
action_box. Only set it when the action_area is not used and empty.
The accel label in menus was getting a small allocation that
caused its draw code to always omit the accelerator string.
Fix that by setting halign to fill. To keep the menu label
left-aligned, set xalign to 0 to compensate.
Make gtk_widget_path_append_for_widget() add the state flags of the
widget, too.
This enables the ability to select pseudoclasses on all elements in a
selector.
Don't take a state when constructing the CSS matcher. Instead, rely on
the newly introduced state in the widget path.
This way, the state can be queried not only on the first element, but on
all elements of the widget path.
Set the widget path state flags with the state flags of the style
context.
We do not update the state flags but replace the previous one because we
want to be able to have save()/restore() unset state flags.
Make backdrop insensitive state more similar to the focused
windows one, mostly to make dark variant more usable and
focused -> backdrop transition less distracting.
Add left/right/top/bottom style classes according to which edge(s)
of the progressbar the progress is adjacent to. Only for a fraction
of 1.0 will we set more than one edge.
