Removable USB drives or memory sticks should be powered down
when the eject button is pressed. For this, we need to call
g_drive_stop() instead of g_drive_eject(), provided the drive
can be stopped.
https://bugzilla.gnome.org/show_bug.cgi?id=723121
Add printer_compare() function for comparing printers according
to their names and locations. It is possible to search by multiple
keys separated by space or tabulator using logical conjunction.
Based on patch by William Hua.
https://bugzilla.gnome.org/show_bug.cgi?id=692931
The root window is a fairly X-centric concept, and it
really has no place in the GtkWidget API. Plus, this
is a rarely-used one-line convenience function with
poor documentation.
Instead of setting "use-header-bar" from gtk_about_dialog_new(),
override its default value by inspecting the properties at constructor()
time. This makes it work from bindings as well, since they don't use the
convenience C constructor.
https://bugzilla.gnome.org/show_bug.cgi?id=722574
GtkWindow has 4 (!) APIs for setting window icons, and we
have to try them all in the right order to find the right
icon. This commit makes it so, and keeps the icon list
manipulation inside gtkwindow.c by adding a private API
for getting a single icon at the right size.
https://bugzilla.gnome.org/show_bug.cgi?id=722515
It was only done so the background would connect visually to the popover
tail, but then it brings aliasing issues when the border is drawn over the
background. Instead, overdraw the tail, so it also fills the gap left by
the border.
If pointing_to starts falling outside of the parent scrollable allocation,
the popover will be automatically hidden, and shown back again when
pointing_to scrolls back to visibility.
If the rect a handle points to starts falling outside of the parent
scrollable allocation, the handle will be automatically hidden, and
shown again when the rectangle is visible too.
When all popovers are removed on destroy(), if a popover is nested into
(eg. with relative_to within) another popover, the removal of one can
lead to the other being removed while the hashtable is being iterated,
which would lead to undefined behavior in further iterations.
Then, use a GList to store popovers, iterating can be made more resilient
on these situations, and unless on pathological cases there's not going
to be as many of those popovers as to cause performance decreases at the
times those are iterated.
The popovers may return keyboard grabs to previous widgets, so if
called after unsetting the focus, the window may be left with a
dangling GtkWidget that would cause crash at later dispose() calls.
With only get_preferred_width and get_preferred_height implemented,
we end up calling the GtkBin height_for_width implmementation, which
knows nothing about the margins and paddings that GtkPopover needs.
As a result, a listbox added to a popover was getting cut off
at the bottom.
This property is TRUE by default, when a popover is modal, it
will automatically set a GTK+ grab on the popover, and grab
the keyboard focus into the popover.
Popovers are strange in the sense that they aren't attached to a
parent directly, they rely on the relative_to widget so the toplevel
is shared, and when they have a parent, it is the toplevel itself,
not relative_to. This also means that there are conditions where the
popover loses it's parent, so they must survive unparenting.
The previous code would be floating the last reference as soon as the
parent is gone, but it was non-obvious who'd own that reference. So
fix this situation by granting the ownership of popovers to their
relative_to widget, an extra reference may be held by the toplevel
when the popover has a parent, but the popover object will be
guaranteed to be alive as long as the parent lives.
This way, memory management of popovers is as hidden from the user
as regular widgets within containers are, users are free to call
gtk_widget_destroy() on a popover, but it'd eventually become
destructed when relative_to is.
When a popover is focused, the focus is forwarded so the first
child what would get the focus actually gets it. Also, implement
correct focus chain, so the keyboard focus stays within the popover
when navigating with keyboard.
This makes it possible to move/resize client-side decorated windows that are
otherwise obscured by a GTK+ grab somewhere else, either a popover within the
window itself or a modal dialog above the window.
This offers the same behavior, but GDK_WINDOW_TEMP windows aren't used
anymore, involving less translations from/to root coordinates, plus no
glitches in having handles snap to content as windows move.
If there is a GTK+ grab on the popover, ensure that it's removed when it's
unmapped. If no GTK+ grab was performed on the popover, this function will
do nothing.
Those functions aren't as useful anymore, hiding/showing can be
controlled by setting the widget visibility, and grabbing can be
achieved by performing a GTK+ grab.
GdkWindows are gone now from the API, the pointed_to rectangle
is from now on relative to the widget allocation. GtkTextView
and GtkEntry were updated to adapt to this change.
This is not as necessary now that bubble windows are popovers, if
a modal behavior is wanted on popover contents, a GTK+ grab on the
popover widget will suffice.
Popovers are transient floating widgets that are confined to the
window space. These have their own GdkWindow that is set on top
of the regular window contents, so they can be used for popup menu
alike UIs with custom popup/popdown/grabs behavior.
This new method allows getting a widget from a GtkStack when we know its
name, and will also return NULL if there is no widget going by that
name.
Usage example would be to check if a child with a given name exists
before calling gtk_stack_set_visible_child_name().
https://bugzilla.gnome.org/show_bug.cgi?id=722588
When running on quartz, it is no longer expected for applications to
provide their own application menu. Instead, they should simply ensure
that they provide "app.about", "app.preferences" and "app.quit" actions
(which many apps are already doing).
A default menu will be shown that looks like the one presented by all
other Mac OS applications, containing menu items for the above actions,
as well as the typical "Hide app", "Hide Others and "Show All" items and
the "Services" submenu.
If an application does explicitly set an application menu (via
gtk_application_set_app_menu()) then it will be respected, as before.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Add support for extracting strings from GMenu markup in GtkBuilder
files.
This means that we have to support translatable <attribute/> tags.
Unfortunately, <attribute> is also used by GtkTreeViewColumn and
GtkLabel for other purposes, and those other purposes use a value=''
(XML) attribute, so we must accept (and ignore) that in order not to
have errors. Nothing will happen in those cases because they do not
also specify translatable='yes', so we ignore them.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Add a new private API to GtkApplication akin to
gtk_widget_insert_action_group().
We'll use this to insert a few extra actions at the app level with a
separate namespace for the special items in the Mac OS application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Add a private hack to allow the insertion of the name of the application
into the label of menu items.
If it appears in the label of any menu item, "%s" will be replaced with
the name of the application.
We will use this for the "Hide myapp", "Quit myapp" and "About myapp"
labels typically found on Mac OS programs.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Allow the possibility for items to be marked with a special attribute and
expose this via GtkTrackerMenuItem. For internal use only.
We will use this to implement the special 'Hide', 'Hide Others' and 'Show All'
items and the 'Services' submenu in the Mac OS application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
By default, Mac OS scans menus as they are opened, updating the
sensitivity of each item in the menu.
The current code in gtkapplication-menu-quartz disables this behaviour,
preferring to manually control the sensitivity of each item in the menu
(when told by the tracker that it has changed internally).
Change the way that this works to more closely follow the usual Mac OS
regime.
This will allow us to construct a typical "application menu" on Mac OS
containing the items that are typically found there ("Hide", "Hide
Others", "Show All", "Services") and have the OS automatically update
their sensitivity.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
Add a custom title had the side-effect of showing the widget.
That is not right, adding children and managing their visibility
should be independent. The headerbar size allocation code also
made the assumption that a custom title is always visible.
With these changes, GtkHeaderBar should be usable in situations
where the centering functionality is not required, and it is
important to freely pack content at both ends, such as in nautilus.
https://bugzilla.gnome.org/show_bug.cgi?id=722340
Use a GtkHeaderBar for the credits and about buttons.
It makes less sense here than in other places to go back to
the buttons on the bottom, considering we only have a close
button, so we always use a header bar.
https://bugzilla.gnome.org/show_bug.cgi?id=720059
This commit introduces a private convenience API that derived
dialogs can call in their instance init. This is necessary to
make the setting work as intended in the face of 3rd party
dialogs derived e.g. from GtkFileChooserDialog, which are
created with g_object_new.
This setting will let us keep traditional appearance
of dialogs on platforms where this is expected.
The new setting is called gtk-dialogs-use-header, backed
by the Gtk/DialogsUseHeader xsetting.
This change makes it possible for GtkDialog to pack
its action widgets into a header bar, instead of the
traditional action area. This change is controlled
by the use-header-bar construct-only property.
https://bugzilla.gnome.org/show_bug.cgi?id=720059
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
