Grabbing must stay a bit longer until all other backends than x11/wayland
catch up with GDK DnD, so ignore deprecation flags are used on those. The
uses of GdkDeviceManager can be entirely avoided though.
People might put all sorts of gunk in their .XCompose file, in
the hope that XLib makes sense of it. Even if we don't make sense
of it, we shouldn't abort, but instead ignore the lines we can't
understand. Pointed out in
https://bugzilla.redhat.com/show_bug.cgi?id=1301254
We connect to the titlebar widgets change notification regardless
whether it is internally created or not, so don't make the signal
handler disconnection conditional on that either.
We need to unset the titlebar manually before chaining up
in destroy, otherwise we trigger the template invariant
checking - GtkWindow would eventually unset it, but too late
for the invariants checking code in gtk_widget_destroy.
Presently, Gtk will only send a startup notification completion message
for the first window that is shown. This is not good for the case of
GtkApplication, where we are expected to participate in
startup-notification for all windows.
We have avoided this problem by manually emitting the startup complete
message from after_emit in GtkApplication.
Unfortunately, this causes problems for windows that are shown with a
delay. It is also a dirty hack.
The reason for the original behaviour is simple: there is a static
boolean in gtkwindow.c which controls it. We remove this.
Instead, clear the startup notification ID stored in GDK when sending
the completion message. GtkApplication will re-set this the next time
an event comes in which needs startup-notification handling. In the
non-GtkApplication case, newly shown windows will still not send the
message, since the cookie will have been cleared.
Finally, we remove the hack from GtkApplication's after_emit.
This will probably cause some regressions in terms of lingering startup
notification messages. The correct solution here is to always use
gtk_window_present(), including when merely opening a new document (with
a new tab, for example).
https://bugzilla.gnome.org/show_bug.cgi?id=690791
gtk_editable_get_selection_bounds() returns UTF-8 character offsets,
but gdk_pango_layout_get_clip_region() wants byte ranges, so convert
from one to the other.
With English, this is especially visible for passwords, which use ●
as the invisible character.
https://bugzilla.gnome.org/show_bug.cgi?id=761128
When the spinbutton grows larger, distribute horizontal size to the
entry and vertical size to the buttons.
Obviously, horizontal size only matters for horizontal spinbuttons and
vertical for vertical spinbuttons.
(1) Keep priv->text_allocation for the area used by the text
(2) Compute all text coordinates with the help of priv->text_allocation
As a side effect the get_text_area_size and get_frame_size vfuncs are
now unused. If we wanted them back, they should get a single use durig
size_allocate() and then their results should be stored for further
processing.
This complicates refactorings, so remove that feature. It's not used
anywhere and doesn't play well with nodes the way it's implemented.
If we want it back, we can add it back later.
Changing the visibility of child widgets in size-allocate does
not work well with out current allocation and layout machinery.
To avoid the visual fallout, just keep the arrow buttons visible
and only change their sensitivity.
https://bugzilla.gnome.org/show_bug.cgi?id=754868
We don't want to let baseline adjustment shift the child
out of the original allocation. This is purely a sanity
measure - in practice, the baseline should always be bigger
than the child_baseline.
We were adjusting the allocation to line up baselines before
calling gtk_widget_size_allocate_with_baseline, but that function
is doing this alignment internally anyway and expects to be given
a 'fill' allocation.
Move the allocation adjustment code down into
gtk_box_gadget_allocate_child where it only affects child gadgets,
not child widgets.
Make the theme follow our documentation for the various .csd and
.ssd style classes: They all go on the window node. For now, just
add the new selector; the old one will be removed when mutter has
been updated.
https://bugzilla.gnome.org/show_bug.cgi?id=760714
When measuring children while distributing a given height,
we must measure them for the given width that goes with
the height. Otherwise, things will go wrong if some of the
children do actual width-for-height. This was showing up
as misaligned images in anaconda.
https://bugzilla.gnome.org/show_bug.cgi?id=760967
It might have changed (eg. after a row being expanded, and the child
rows revalidated), so just update it here based on the last pointer
position.
Based on a patch by Maxim Reznik <reznikmm@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=760891
The pointer position is queried to properly trigger the prelight
updates on the new row below it. We store the last coordinates
though, and track crossing events to unset these, so it's safe
to just update_prelight() here on these.
Check that non-native window are indeed children of the event window and
only then confirm that they should be drawn.
Fixes Glade thinking that it's okay to have the draw function do
different things depending on what window to draw. (This should really
be fixed in Glade.)
There's no reason to insta-crash when something goes wrong. Just don't
do anything stupid.
Also, remove the SPCIAL_CONTAINER() exception. Every case where special
containers needed this, it is wrong and made containers draw children
multiple times.
The text view draw function was leaving its cairo context
with a transformation after drawing to all the border windows,
which lead mis-drawing in gitg. Avoid this by moving the
gtk_cairo_transform_to_window call inside the existing
cairo_save/restore calls.
https://bugzilla.gnome.org/show_bug.cgi?id=760942
Add a query implementation to opacity property. Also fix the assert in
gtk_css_style_property_register() to allow registering properties with
query but without assign function.
https://bugzilla.gnome.org/show_bug.cgi?id=760933
The build glue for collecting all the assets in Adwaita as
resources was assuming that they are all pngs, and tried to
preprocess them into embedded GdkPixbufs.
Fix it to leave svgs unmolested, so they can be recolored
at runtime.
If we fail to load the image for a -gtk-recolor() expression,
fall back to using the image-missing icon instead of crashing,
and include more details in the warning message.
Previously, we were only showing the size of the allocation
and clip area. But there is no good reason to hide the position
of these rectangles, so add them, in the traditional format
of X geometry strings: wxh+x+y
GtkShortcutsWindow is among the 'cheating' containers that iterate
over indirect children in forall, and this is now triggering
an assertion in gtk_container_propagate_draw.
For now, just exclude the cheating containers from the assertion.
Eventually, this needs a better solution.
Button state was being kept in two separate variables, which lead
to slight confusions in DnD that caused the notebook to ignore the
first click after DnD happened from (within) it. Unify these two
into one, which helps us keep better track of the really pressed
buttons.
gdk_rectangle_union will happily add all the worlds pixels
to the union if the initial rectangle is initialized to all
zeros. Therefore, explicitly check for an empty rectangle
before calling it.
Move code to properly reinsert the tab label to where it belongs.
The if has the distinction between reparented-to-dnd-window and
just-changed-the-gdk-window-to-draw-to right there.
https://bugzilla.gnome.org/show_bug.cgi?id=760754
The new function, gtk_render_background_get_clip answers the
question: what pixels are affected if I call gtk_render_background ?
The long-term goal is to have APIs that answer this question for
all rendering primitives.
Commit 8e975b2 (Bug 753969) introduced check of parent accessibility.
Consequently it is not possible to save file if executable attribute
is not set, which might happen for some gvfs backends. Let's assume
that the folder is accessible even if the attribute is not set.
https://bugzilla.gnome.org/show_bug.cgi?id=760881
The viewport itself doesn't move, so we cannot use it as the pixel
cache's background. Use the bottommost using element instead, which is
the viewport's child.
This might need adaptations in themes as we want the backgroud to be
opaque to speed up pixel cache performance.
Use gtk_box_gadget_reverse_children and gtk_css_node_reverse_children
to flip the children of the header_gadget and the tabs_gadget when
appropriate.
Add new CSS node tests to verify that the node order is updated
as expected in all cases.
When this is in use, there's essentially a bunch of dead code here.
When all backends are ported, we'll be able to remove grab/cursor
management plus a bunch of source-side event handlers.
... and remove the also forgotten void function that lingered around
with it.
Fixes opacity=0 parts like inactive spinners or sort indicators in
treeview headers being drawn since last commit.
Oops.
Previously, we had a special cae to draw subwindows of widgets.
This is not necessary as conformant widgets should be able to properly
render themselves when all windows need to be painted.
From now on assume that is the case.
We therefore paint nonnative GDK windows "inline" by just returning TRUE
for gtk_cairo_should_draw_window() for those windows.
This speeds up hilighting different rows in the listbox gtk-demo example
tremendously (by a factor of 10 or more) as the previous code was
O(<number of non-window subwidgets> *
<number of subwindows>) which in the listbox example were ~15,000 and
~2,000 respectively.
When using forall(), only list the revealer, which lists the box
containing all the children. When using foreach(), bypass revealer and
box and list all children added to the box.
Derived classes like GtkSourceView with their own ::key-event
handler need access to this, in order to make their keynav
as nice as the builtin one, wrt to caret visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=760748
And use it to handle kinetic scrolling in the GtkScrolledWindow.
However, dropping the delta check causes the X11-based kinetic
scroll to break since we don't have the stop event here. Correct handling of
xf86-input-libinput-based scroll events is still being discussed.
https://bugzilla.gnome.org/show_bug.cgi?id=756729
Since a41f02f9b1, GtkIMContextSimple
uses threads to load X Compose files. It does that every time a new
im context object is initialized, so we can easily end up with multiple
threads accessing the shared global_tables list at the same time.
Use a lock to prevent that.
https://bugzilla.redhat.com/show_bug.cgi?id=1276432
To ensure that the title moves to the other side as expected
in RTL, use GTK_ALIGN_START/END instead of GTK_ALIGN_FILL
when packing the title gadget into the vertical box, and
flip the alignment when the text direction changes.
Most uses of builtin icons (check and radio buttons,
expanders, etc) are placed next to labels, so they should
be properly positioned wrt to the baseline. Lacking anything
better, give the builtin icons a baseline that places the
center of the icon at the strikethrough position.
The 'mad hack' that GtkAccelLabel used to affect the GtkLabel
draw function broke with the introduction of gadgets, since
the positioning is no longer relative to the widgets' allocation
at the time of the call, but rather to the gadgets allocation.
Instead of coming up with an even madder hack to keep this
working, give the GtkLabel draw function knowledge about accel
labels.
https://bugzilla.gnome.org/show_bug.cgi?id=760663
Previously this setting would just invalidate the whole CSS tree and
thereby hopefully avoid all cache usage.
Now, we actually don't cause extra invalidations anymore, but instead
avoid ever inserting anything into the cache when this setting is set.
This essentially copies the previous cache implementation. With one
caveat: It is now attached to and maintained by the CssNode, not by the
CssStyle.
And this is important because styles may be reused in incompatible
situations which would cause cache collisions and lead to broken CSS in
weird situations.
For now, the split out style cache doesn't cache anything. This is
mostly to make sure that bisections of wrong caching behavior will
bisect down to the commit that actually adds caching.
Use a vertical box gadget for the overall expander, and a
horizontal one for the title row. This lets us get rid of
all the custom allocation code here.
So far, the box gadget is always allocating all children the
full size in the cross axis. This behavior corresponds to the
align-items: stretch behavior in
https://www.w3.org/TR/css-flexbox-1/#align-items-property
This commit implements the other modes described there.
While widgets have halign/valign properties that we can use for
this, the API for inserting gadgets has to change to take an
extra align parameter. All callers have been updated to pass
GTK_ALIGN_FILL, since that corresponds to the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=760668
From gtk_widget_path_iter_set_object_name documentation:
"When set, the object name overrides the object type when matching CSS"
Update gtk_widget_path_to_string to match this behaviour.
This is sometimes needed, and calling into actual icon theme
code just for it is confusing - the resulting icon does not
depend on the icon theme at all.
https://bugzilla.gnome.org/show_bug.cgi?id=760536
