Stop trying to deal with "theoretical possibilities".
We can't possibly continue to be a faithful GActionGroup implementation
across dispose because dispose has a side effect of removing everyone's
signal handlers.
The code that we ran after the dispose chainup to do all of the fancy
signal emulation was therefore dead. The test that aimed to verify this
was buggy itself due to an uninitialised variable, so really, it never
worked at all.
We keep the re-ordering of the chainup from the original commit to avoid having
trouble with GtkActionMuxer and keep the checks in place that will prevent an
outright segfault in the case that someone else tries to use the interface
post-dispose.
https://bugzilla.gnome.org/show_bug.cgi?id=722189
With proper notifications, plus an accessor method for that state. This
allows client to just listen to notify::is-maximized instead of tracking
window-state-event.
https://bugzilla.gnome.org/show_bug.cgi?id=698786
This leads to disastruous results, since each menu is itself
in a GtkWindow, so holding down the menu key leads to a neverending
cascade of menus on top of menus.
https://bugzilla.gnome.org/show_bug.cgi?id=722106
Theming code gets confused when computing the spacing for 0px wide dots
and then divides by 0. And then cairo complains and stops drawing
anything forever out of spite and then we end up with a single color
screen.
https://bugzilla.gnome.org/show_bug.cgi?id=721800
The window-dragging code had a number of issues: The code was
starting a drag on every button press, never bothering to cancel
them. This leads to the odd hand cursor occurring between the two
clicks to maximize. We relied on GDK's multi-click detection, which
gives us triple-clicks when we really want sequences of double-clicks.
Lastly, we didn't propery restrict double-click handling to the primary
button, so e.g. if you had a window on an empty workspace, double-right
click on the titlebar would maximize it, which is not intended.
This commit solves all three problem by a doing our own double-click
detection, and only starting a drag when the pointer goes out of
'double-click range'. We change the way dragging is implemented for
menubars and toolbars to just letting events bubble up, so they
get the same behaviour as the titlebar. To make this work, we
have to select for pointer motion events in a few more places.
The behaviour of gtk_text_view_add_child_in_window() used to be
quite broken. It scrolled with the window during scrolling, then
jumped to the absolute position when the widget resized. Furthermore,
in 3.10 we broke the first feature, making it always be fixed.
The "proper" way to handle this is to always follow scrolling. This
is what the only user so far (gedit) wants, and if you want some
kind of overlay you should use GtkOverlay instead.
So, this changes the behaviour to something that is internally consistent
and works. I.e. all added widgets scroll with the textview as needed.
https://bugzilla.gnome.org/show_bug.cgi?id=711826
Modify the tracker so that it manages the visibility of
GtkMenuTrackerItem by issuing insert and remove callbacks to the
user of the tracker.
This works by treating the GtkMenuTrackerItem as a virtual section which
contains 1 item when the item is visible and 0 items when it is hidden.
For efficiency reasons, we only employ this trick in the case that the
item has a hidden-when='' attribute set on it.
https://bugzilla.gnome.org/show_bug.cgi?id=688421
Add an internal API for checking if a GtkMenuTrackerItem is visible,
along with a signal for reporting changes in that flag. The item will
become invisible in situations according to the new hidden-when=''
attribute, which can be set to 'action-disabled' or 'action-missing'.
This new flag doesn't actually do anything yet, and none of the
consumers of GtkMenuTracker do anything with it (nor should they). A
followup patch will address the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=688421
Refactor the code in the action observer remove function in order to
make way for the (efficient) handling of hiding of the item in the case
that hidden-when='' is given.
https://bugzilla.gnome.org/show_bug.cgi?id=688421
Strictly speaking, can_activate should always be set back to FALSE when
the action disappears from the muxer (since we can't activate it
anymore) but we forgot to do that.
This 'bug' could never cause a problem because 'can_activate' is never
directly queried for anything at all and the item would get marked
insensitive anyway. As soon as the action was re-added, can_activate
would be recalculated based on the new action before anything else could
happen.
All the same, this should be cleared here.
https://bugzilla.gnome.org/show_bug.cgi?id=688421
Remove a hash lookup from the separator sync logic (which is run every
time we change a menu). Instead, we do the lookup when creating the
section and cache the result.
This refactor will also help us in a future commit to add support for
hiding menu items based on missing actions.
https://bugzilla.gnome.org/show_bug.cgi?id=688421
This adds save/restore calls to the clear-to-transparent call in
the pixel cache, to avoid changing the default color of the
cairo_t. It also removes a call set_operator call that is no longer
necessary (it was trying to manually restore the state).
https://bugzilla.gnome.org/show_bug.cgi?id=721480
GtkApplicationWindow frees its internal action group on dispose for the
usual reasons: to avoid the possibility of reference cycles caused by
actions referring back to the window again.
Unfortunately, if it happens to be inside of a GtkActionMuxer at the
time that it is disposed, it will (eventually) be removed from the muxer
after it has been disposed. Removing an action group from a muxer
involves a call to g_action_group_list_actions() which will crash
because the internal action group to which we normally delegate the call
has been freed.
A future patch that reworks the quartz menu code will introduce a use of
GtkActionMuxer in a way that causes exactly this problem.
We can guard against the problem in a number of ways.
First, we can avoid the entire situation by ensuring that we are removed
from the muxer before we destroy the action group. To this end, we
delay destruction of the action group until after the chain-up to the
dispose of GtkWindow (which is where the window is removed from the
GtkApplication).
Secondly, we can add checks to each of our GActionGroup and GActionMap
implementation functions to check that the internal action group is
still alive before we attempt to delegate to it.
We have to be careful, though: because our _list_actions() call will
suddenly be returning an empty list, people watching the group from
outside will have expected to see "action-removed" calls for the
now-missing items. Make sure we send those. but only if someone is
watching.
https://bugzilla.gnome.org/show_bug.cgi?id=710351
A widget intended to offer contextual actions for a given view.
It allows packing children into the start or end as well as offering
a single centered child box.
https://bugzilla.gnome.org/show_bug.cgi?id=721665
Add gtk_tree_path_new_from_indicesv which takes an array of
integers with a length. Use "Rename to" annotation to rename the
method as gtk_tree_path_new_from_indices. This is needed because
the original method takes variadic arguments which is not supported
by introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=706119
GtkMenuItemAccessible was assuming that an accel label is
always the immediate child of a menu item. It also did not
deal with manually set accels. Fix both of these.
https://bugzilla.gnome.org/show_bug.cgi?id=721086
Improve the color swatch accessible to set a proper role
depending on whether the swatch is selectable or not, and
set the checked atk state when appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=721048
The initial state of GtkModelMenuItem is that of a normal menu
item, but the accessible we are using, GtkCheckMenuItemAccessible,
starts out with a role of 'check menu item'. Fix that up by
explicitly setting the initial accessible role.
GtkModelMenuItem does not emit the ::toggled signal when a radio
item is activated, so listen for property notification for that
property. We still keep the ::toggled signal handler, in order
to not break other uses of check and radio menu items.
https://bugzilla.gnome.org/show_bug.cgi?id=720983
GtkModelMenuItem emits no property notification, since none of its
properties are readable. But the toggled property is just a proxy
for GtkCheckMenuItem::active, so we should ensure that property
notification is emitted for the ::active property.
Ensure the hscrollbar & vscrollbar at gtk_scrolled_window_add() time,
this allows one to subclass GtkScrolledWindow with templates and add
children, as this will happen at instance initialization time before
the construct adjustment properties take effect.
And update the colorchooser a11y test to a) use GtkColorChooser
instead of the deprecated GtkColorSelection and b) match this
change. Pointed out in
https://bugzilla.gnome.org/show_bug.cgi?id=721045
This commit makes the label accessible implement AtkHypertext,
which returns a AtkHyperlink object for each link in the text.
At the same time, add AtkHyperlinkImpl objects as children
to the label accessible.
Also some private API to indicate that links have changed, and
call that from GtkLabel when needed.
Adjust expected output of the affected a11y tests.
https://bugzilla.gnome.org/show_bug.cgi?id=721410https://bugzilla.gnome.org/show_bug.cgi?id=721421
The get_end_index implementation was casting the accessible
to AtkText even though GtkLinkButtonAccessible does not
implement this interface. This did not show up in the a11y
tests because the they were not dumping the affected AtkHyperlinkImpl
properties. Oops.
Ignacio Casal Quinteiro reported a problem whereby an empty section at
the start of a menu has a separator placed after it. This was caused by
the implementation of the logic that separators should be inserted at
the top of all non-empty sections that are not the first section. This
logic is obviously incorrect in the case that the first section is empty
(in which case we would not expect to see a separator at the top of the
second section).
Change the logic so that we only insert separators when we see a
non-zero number of actual items in the menu before us.
https://bugzilla.gnome.org/show_bug.cgi?id=721119
If the platform data passed with actions and activations includes
a startup notify ID, we should read it and pass it down to GDK.
This ensures that the right startup notify is completed after the
signal emission, and that the user time of the GdkDisplay is properly
updated (which in turn makes sure the windows are not subjected
to focus-stealing-prevention)
https://bugzilla.gnome.org/show_bug.cgi?id=721304
This header, which is not universally available, is accidently made to be
included unconditionally during the refactoring of gtkapplication.c,
so restore the #ifdef check.
Applications need a way to fix or adapt the decoration layout,
for situations like split header bars. Setting the layout from
the theme with a style property did not offer a good way to do
this, and the ::show-close-button property does not provide
fine-grained control.
To improve the situation, move the layout string to a property of
GtkHeaderBar which is backed by a setting. This allows platforms to
set a default button layout independent of the theme, while applications
can override the default.
The style GtkWindow style property is now deprecated and ignored.
The button now claims its menu as a child for a11y purposes,
which makes it possible for ATs to see it when the navigate
the tree top-down.
Update the a11y test to match.
We go to extra length to set the desktop_uri to NULL when
desktop == home, but then we were adding the (non-functional)
place item anyway. Don't do that.
Fixes a tiny typo in commit f51c9d4154
which manifested itself in GtkSpinButton's panels being drawn with an
incorrect, not updated state.
This patch took me more hours than you might think! :P
https://bugzilla.gnome.org/show_bug.cgi?id=709491
The reason why some of the strings in gtkprintunixdialog.ui
were missing is that we did not extract translatable string
from <item> elements. Fix that.
gtkapplication.c has turned into a bit of an #ifdef mess over time, and
many of the current checks are incorrect. As an example, if you build
Gtk for wayland, and exclude the X11 backend, much of the functionality
required by wayland (such as exporting menu models) will be disabled.
Solve that by introducing a backend mechanism to GtkApplication (named
GtkApplicationImpl) similar to the one in GApplication. Add backends
for Wayland, X11 and Quartz, with X11 and Wayland sharing a common
'DBus' superclass.
GtkApplicationImpl
|
/--------------+-------------------\
| |
GtkApplicationImplDBus GtkApplicationImplQuartz
|
/-----------+-----------------\
| |
GtkApplicationImplX11 GtkApplicationImplWayland
GtkApplicationImpl itself is essentially a bunch of vfuncs that serve as
hooks for various things that the platform-specific backends may be
interested in doing (startup, shutdown, managing windows, inhibit, etc.)
With this change, all platform specific code has been removed from
gtkapplication.c and gtkapplicationwindow.c (both of which are now free
of #ifdefs, except for a UNIX-specific use of GDesktopAppInfo in
gtkapplicationwindow.c).
Additionally, because of the movement of the property-setting code out
of GtkApplicationWindow, the _GTK_APPLICATION_ID properties (and
friends) will be set on non-GtkApplicationWindows, such as dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=720550
We don't want the maximum size to be smaller than the minimum size. Not
just because it's wrong but also because when this happens the rest of
GTK gets mighty confused and infloops resizing to min-size and
max-size in turns causing a flickering window. Well, at least if you
run X without a window manager. Or your window manager hasn't finished
starting up.
Private RHEL bug finding this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1035409
This could happen if data was requested from a separate screen now that
multi-screen is no longer supported.
Ideally, we'd want to support copying to other screens, but that
requires solving in GDK as that's X-specific so cannot be well
abstracted by GDK (without the reintroduction of multiple screens).
https://bugzilla.gnome.org/show_bug.cgi?id=719314
Both GtkApplicationWindow and GtkHeaderBar listen for changes
of the gtk-shell-shows-app-menu setting, so they need to somehow
coordinate who is going to take action and show a fallback.
We prefer the menu button in the title over the menubar, so
let GtkApplicationWindow opt out if it finds that the header bar
has been configured to show window controls.
If we don't have a window icon, we hide the titlebar_icon,
we still add it, so we can't simply go by the number of
children when deciding whether to show the separator or
now. Instead, update the separator visibility as we create
the various buttons.
And deprecate the X11-specific version of it.
We call this new API _set_shadow_width() and not _set_frame_extents()
because we already have a gdk_window_get_frame_extents() with a
different meaning and different type of value.
https://bugzilla.gnome.org/show_bug.cgi?id=720374
This is one of the few cases where it makes some sense to blur
the line between and empty string and NULL: without this, it is
hard to reset the subtitle e.g. from a builder file. And we
have the has-subtitle property now to enforce subtitle size
allocation independently.
Only fill the location entry with the file name of the tree view's
selected file when the selection was done by the user.
When the file chooser's action is GTK_FILE_CHOOSER_ACTION_OPEN, it
selects the first file in the tree view once loading has finished. For
this case we don't want it to insert the file name in the location
entry, as it hinders efficient navigation using the location entry. To
achieve this, use a priv flag to keep track of whether the
selection-changed signal was caused by the file chooser itself.
https://bugzilla.gnome.org/show_bug.cgi?id=386569
It is a fairly common case to just want a title, and not
reserve extra space for a subtitle. This is much easier
to get right by setting a boolean property than by
constructing a custom title widget.
When setting a custom titlebar that happens to be a GtkHeaderBar,
we connect to notify::title to pick up title changes on the headerbar,
but we forgot to sync the title initially. Fix that.
You can still hover a mouse on insensitive elements; it's up to the
theme to disable that.
This is in line with the HTML/CSS interpretation of :hover.
Insensitive elements still cannot be clicked.
https://bugzilla.gnome.org/show_bug.cgi?id=719486
Failing to load a thumbnail returns a NULL pixbuf. Since the hidpi
patches this wasn't checked when creating the surface. Result: assertion
failure.
https://bugzilla.gnome.org/show_bug.cgi?id=719977
The bin window's background would have to be drawn in the bin window's
size and inside the pixel cache draw function to not cause transparency
issues.
But because it's unnecessary as the view window draws the same
background, we just skip it.
https://bugzilla.gnome.org/show_bug.cgi?id=709027
This allows themes do whatever they want as separators, with
paddings, borders and backgrounds.
If "wide-separators" property is true, then, instead of just draw
a frame, also render its background, and take into account the
padding property for its limits.
https://bugzilla.gnome.org/show_bug.cgi?id=719713
