This way, we don't create lots of cell accessibles when creating the
first one (because surely one is the parent/child of another who again
is a parent/child of another who again....)
Nobody was reffing those related object in the first place and that
was causing random crashes.
And if somebody had reffed those related objects, they'd have caused
reference cycles.
https://bugzilla.gnome.org/show_bug.cgi?id=726838
This fixes an issue where the theme-provided border-width prevents
dialog contents from lining up properly with the headerbar. To make
this work in message dialogs, we have to explicitly set the border-
width of the action area to 0.
In select-folder mode, we are putting the directory name into the
entry ourselves. Then the entry appends a /. If we react to this
'spontaneous' change of the entry by clearing the list selection,
this will in turn make us clear the entry. We don't want that.
https://bugzilla.gnome.org/show_bug.cgi?id=726855
Setting windows undecorated was broken by some of the recent
shadow width changes. We need to ensure that shadow width is
zero for undecorated windows, then things work again.
If the delete event ends up destroying the widget, unsetting
priv->delete_event_handler will happen on invalid memory, so
unset it before the widget is possibly destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=726825
Widgets should only call set_realized() after having created and
registered their GDK windows. In this case, the creation of the style
context (or more exactly: figuring out the scale factor for it) requires
knowing if the widget is already realized. Which it isn't.
https://bugzilla.gnome.org/show_bug.cgi?id=726717
expected a valid semicolon
sounds kinda not so great. Make it say
expected semicolon
Unless somebody can tell me the difference between valid and invalid
semicolons?
We had a margin of 30 before/after the text. Put that add around
the icon as well, and separate the icon and text by 30 pixels.
This does not affect the appearance of message dialogs without
icons.
If a textview had lateral windows that might displace the text window, the
handles and popovers would appear displaced. Those lateral windows aren't
affected by RTL/LTR settings, so just checking for left/top is ok here.
We want to present a clean, rounded top when there is nothing
else to show, but many dialogs in applications rely on showing
information in their title, so add a label and show the title
when it is not empty.
Add gdk_device_get_last_event_window(), and use to implement the window
tracking we need for synthesizing crossing events for sensitivity changes
and gtk grabs, rather than keeping the information in qdata and updating
it based when GTK+ gets events.
https://bugzilla.gnome.org/show_bug.cgi?id=726187
Stop ignoring various crossing events from grabs:
Enter events with type GRAB/GTK_GRAB/GTK_UNGRAB/STATE_CHANGED:
Ignoring these events was added as a workaround for synthesized
events not having the right coordinates (see bug 555109) but
now they do have the right coordinates. (see bug 704456)
Leave events with types types GTK_GRAB/GTK_UNGRAB:
Ignoring these events was added because since we were ignoring
the enter events as above, ignoring the leave events meant we
could lose the prelighted row in a grab-triggered leave/enter
pair. (See bug 653676. It's also now impossible to
reproduce the leave events that were reported in that bug as causing
problems.)
Leave events of type GRAB.
Ignoring these events was added without a ChangeLog entry in 2001,
possibly to keep the prelight from flashing when activating menus.
But ignoring these events could lead to stuck prelighting, and we don't
do it for any other widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=726209
The bug this patch is fixing is that currently if you have a GtkPopover in
clicking off the popover to dismiss it on a GtkTreeView (which triggers
a synthetic enter event on the GtkTreeView) will leave the GtkTreeView
in a confused state until the user moves the mouse again.
That doesn't make sense.
And it causes issues, because when holding down the tab key, we
show/hide a lot of windows and cause a lot of map/unmap events that
stall the event pipeline.
We did not set an input shape on the window, so the region outside
the invisible border where we draw the outer edges of the shadow
were still part of the window, as far as clicks and cursors were
concerned. Fix this by setting an input shape that makes all clicks
outside of the resize borders go through to the underlying window.
https://bugzilla.gnome.org/show_bug.cgi?id=726125
And let GtkPopover use it as its GtkAccessible implementation, this
accessible sets the POPUP_FOR relationship to the relative-to widget,
and keeps track of changes there.
https://bugzilla.gnome.org/show_bug.cgi?id=725864
As those are internal children, there's no signal that GtkWindowAccessible
could catch when those are added or removed, so make GtkWindow use the private
GtkContainerAccessible methods to add/remove the child accessible when that
happens.
https://bugzilla.gnome.org/show_bug.cgi?id=725864
As discussed on desktop-devel-list [1], "There should be an intuitive,
consistent, immediate way to jump to the widgets that live in the
header bar." F10 has been suggested for this as it is already used to
active menubars.
F10 will focus the custom titlebar widget if the window has one and it
isn't already focused. If the titlebar widget doesn't exist or is
already focused then F10 focuses the menubar if there is one.
[1] https://mail.gnome.org/archives/desktop-devel-list/2014-February/msg00176.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=725141
It turns out popovers are already smart enough to cope with this
situation, so let popovers be internal children so things that rely
on gtk_container_forall(), like DnD, work without modifications.
https://bugzilla.gnome.org/show_bug.cgi?id=725727
