Because GTK does not invalidate windows that aren't mapped, we cannot
update the pixel cache when the window it handles isn't mapped. So we
add API to call when GDK windows get mapped/unmapped.
https://bugzilla.gnome.org/show_bug.cgi?id=726475
This commit makes it possible for GtkSwitch to indicate when
the underlying state changes with a delay, causing the switch
to temporarily go 'out of sync' with the underlying change.
https://bugzilla.gnome.org/show_bug.cgi?id=725648
This commit adds API for dealing with multi-selection. It is identical
to the flow box API for this purpose. The implementation is still limited
to single-selection, and will be updated in subsequent commits.
It can happen that we get a size request when the main widget
is still NULL. Currently we hit a critical in this case, and
stumble on. We can do better.
Opening a new tab in nautilus is hitting this case.
https://bugzilla.gnome.org/show_bug.cgi?id=727643
We are getting bug reports from people who are irritated that
dialogs now have 'double headers' under any wm but gnome-shell.
As an example, xfwm4 seems to do ok with csd windows, and
on balance it seems better to have some invisible border issues
than to have double headers.
https://bugzilla.gnome.org/show_bug.cgi?id=727414
* Makes listbox background white instead of default grey
* Uses gradients or W32 theme parts to draw sexy selection/prelight
rectangle instead of changing selected/prelighted item background
* Removes blanket button text color, allowing buttons to inherit
text color from their parents. Non-normal buttons DO get specific
text color though. This partially fixes text color propagation from
listbox rows to their children.
https://bugzilla.gnome.org/show_bug.cgi?id=727244
The arrow is part of the background image drawn by the theme, don't draw
GTK's own arrow. This also applies to non-entry comboboxes.
On XP the arrow-and-nothing-else part does not exist (W32 XP theme draws a
white rectangle) and has to be subtituted for a simple dropdown button even
for non-entry comboboxes.
https://bugzilla.gnome.org/show_bug.cgi?id=727035
It seems that the dec-button no longer has a "bottom" selector-thingy to
select for. Use "last-child" instead.
Use .vertical to style vertical instance differently, as last-child/first-child
meaning is inverted there.
Increase (towards 0) margins a bit, to avoid clipping the pre-light rectangle.
Use dir(rtl) selector to style horizontal instance differently for RTL locales,
where first-child is "inc".
https://bugzilla.gnome.org/show_bug.cgi?id=727022
GTK_TREE_VIEW_TIME_MS_PER_IDLE is currently 30 milliseconds, meaning
that validate_rows will validate rows up until all the validations have
taken over 30 msecs. So it's likely to block redrawing via the clock
frame update mechanism, as that tops at 16.66 milliseconds per frame
(1/60th of a second).
Stop validating rows if we've spent more than 3/5 of our allotted budget
for inter-frame processing, so as to avoid blocking.
In the future, we would probably want to calculate how long we would
have left until the next frame, especially if higher priority idles
and timeouts have already consumed a portion of that allotted time.
https://bugzilla.gnome.org/show_bug.cgi?id=726871
A "typo" led to using a wrong GtkTreePath when converting the path of the
virtual root to check the ancestors, which would lead to either no checks being
performed, or maybe segfaulting when using an invalid path as result.
https://bugzilla.gnome.org/show_bug.cgi?id=722058
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
These AtkRelation types are added automatically for widgets with a label
specified (e.g. via gtk_label_set_mnemonic_widget, gtk_frame_set_label,
and gtk_frame_set_label_widget). When such specification is absent, the
accessible relationship must be manually set.
https://bugzilla.gnome.org/show_bug.cgi?id=726996
Commit faba7df4fe changed the logic in
apply_emblems() so that GtkIconInfo->emblems_applied would be set to
TRUE even in case there was no emblem info available, which confuses the
theme cache.
This commit changes the logic back, so that NULL is returned from
apply_emblems_to_pixbuf() when there are no emblems available, fixing
the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=726830
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
It may be unusual, but handlers of day-selected may want to transfer
focus somewhere else, without getting it reset back right after by/to
the calendar. This makes popovers demo work on the calendar again, for
one...
Make the popover temporarily undo the GTK+ grab, so it remains modal
to its window, but does not attempt to steal focus on other non-modal
windows that get the focus.
This was most confusing with keyboard navigation, as the focus would
remain stuck on the popover, and not move to the newly focused window
after the popover was dismissed. It didn't have as much effect on
pointer operations as only the first click would be consumed in order
to hide the popover.
There are early returns in this method before the completion timeout
is set later on, so set the source to 0 to avoid trying to remove it
later again.
https://bugzilla.gnome.org/show_bug.cgi?id=725824
This is not necessary for the popover itself, but helps tooltips
code confine the widget lookup within the popover if the pointer
is inside it, otherwise the widget lookup may turn out wrong for
motion events, starting the tooltip widget lookup from the toplevel
window, mistakenly triggering tooltips on the natural window
descendants (ie. the widget below the popover)
https://bugzilla.gnome.org/show_bug.cgi?id=724785
gnome-terminal is still using this setting, so we'll let
applications override it for another cycle. It is no longer
backed by a system-wide setting, though, and it will still
go away eventually.
This partically reverts b26c74e5da
gnome-terminal is still using this setting, so we'll let
applications override it for another cycle. It is no longer
backed by a system-wide setting, though, and it will still
go away eventually.
This partically reverts 7e3a494fac
Add documentation for GtkTreeView::move-cursor
Add links to GtkTreeModel::row-inserted and GtkTreeModel::row-deleted
in the documentation for gtk_tree_view_set_reorderable ().
https://bugzilla.gnome.org/show_bug.cgi?id=725560
If we aren't using a header bar then put a fake titlebar
box on it so we can round the corners.
One of the advantages of this is so that the styling of the dialog
is completely within one theme framework. This prevents skew between
the theming expectations from the window manager and GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=725345
This is a web service provided by Google that allows people to
share their printers (https://www.google.com/cloudprint/learn/).
In addition to being able to print to printers shared on Google Cloud
Print, there is an equivalent of "Print to file" in the form of "Save to
Google Drive".
The cloudprint module uses gnome-online-accounts to obtain the OAuth 2.0
access token for the Google account.
Currently it can discover available printers, get simple details about
them such as display name and status, and submit jobs without any
special options.
https://bugzilla.gnome.org/show_bug.cgi?id=723368
Restore the drawing order in GtkFixed to what it was in 3.8. With the
GDK drawing changes this will not be correct in some cases (un-windowed
children can now overlap windowed children and native children overlap
everything), but fixes Eclipse drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=725089
In the unlikely case that there is another GPL released in the future
it would be best if we link directly to the 3.0 version of the
license description instead of the alias to the latest
version.
Old code assumed that AT-SPI would keep track of references and
therefore tried to only hold weak references. On the other hand it also
tried to keep objects alive so it referenced objects very randomly. All
of that lead to cycles and leaking.
As AT-SPI does not keep track of objects at all, the treeview now does.
The refcounting looks as follows:
GtkTreeViewAccessible
=> creates per row/column
GtkTreeViewAccessibleCellInfo
=> which references 1
GtkCellAccessible
If there is only one cell, this accessible is a
GtkRendererCellAccessible, otherwise a GtkContainerCellAccessible is
created and that accessible holds references to the
GtkRendererCellAccessibles that are created for every cell renderer.
https://bugzilla.gnome.org/show_bug.cgi?id=554618
The new() function is supposed to return an empty fully initialized
GtkCssKeyframes object, while the alloc() function just allocates and
initializes static values. So alloc() can be used for copying or
resolving keyframes.
Fixes a memleak when resolving keyframes.
With the code as written, use-popover has to be set first,
before the model. To avoid this ordering dependency, re-set
the model when use-popover changes.
The convention we follow is that the PROP_foo define should
match the property name. Therefore, change PROP_MODEL to
PROP_MENU_MODEL to match "menu-model".
gtk_tree_view_remove_column was first removing the column from
its list, then call gtk_tree_view_column_unset_tree_view, which
would then call gtk_container_remove to remove its button from
the treeview. But the treeview remove implementation relied
on the column being still in the list in order to recognize
the button as 'special', so in effect the button was never
properly removed and thus, leaked.
Fix this by callling unset_tree_view before removing the
column from the list.
https://bugzilla.gnome.org/show_bug.cgi?id=724891
c287845240 was trying to fix
the memory leak caused by popovers begin destroyed in
gtk_window_destroy before chaining up to gtk_widget_destroy,
which unrealizes the window, and would clean up the popover
windows if the popovers were still around.
Fix this in a better way by moving the popover destruction
after the chaining up, so we unrealize first, and then
destroy the popovers.
Also, make _gtk_window_remove_popover unrealize the popover,
for symmetry with _gtk_window_add_popover.
This should fix
https://bugzilla.gnome.org/show_bug.cgi?id=724921
Normally, a GtkAboutDialog is shown using the convenience
API. But if you manually construct one and show it by calling
gtk_widget_show_all() on it, the license tab would show up
uninvited. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=724411
In practice this shape is only used to outline the popover when it is
above native windows, in the most normal full-csw case the shape won't apply
visibly, so popovers will still be able to cast a shadow there.
If there are native windows below the popover, the shape will exclude the
shadow, so there are no alpha contents above the window. One worst case that
might happen is that the popover lays above patches of native/client-side
windows, so the shadow could come and go around the border. But first let's
see whether that happens often or visibly enough before adding something more
convoluted.
The update of the needs-attention state is done via its own property,
so it doesn't need to be done via visibility changes.
This patch is largely the result of inspecting the code due to a warning
and not a result of testing. So if issues pop up that bisect back to
this patch, that's why.
And document the fact that the popover will get destroyed if
a NULL relative-to is given on a parented popover, if no extra
references are kept.
For gtk_popover_new*(), a NULL relative-to will leave the widget
as a floating object, to be sunk by a later call to
gtk_widget_set_relative_to().
https://bugzilla.gnome.org/show_bug.cgi?id=724407
The recursion in map needs to follow the actual physical
widget tree, otherwise we violate invariants. The generic
container map implementation uses gtk_container_forall to
operate on the children, and thus is not suitable for
containers where the children are inside some internal
container.
We should only eat button release events when the label is
actually selectable, since the comment indicates that we
want to eat the release events belonging to press events
that triggered a selection. This fixes problems with actions
on parent widgets that are triggered by button release,
as seen in this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=724541
Suprisingly, this bug has been there for a very long time.
I'm fixing it now because we now use a custom search entry
in the app chooser dialog, and this is causing the templates
cleanup test to fail.
The with_separators argument does not really make sense
for popovers, it was just copied from the menu implementation.
Drop it now, before it becomes part of the public API.
Dragging windows was not working on widgets in the titlebar
region unless they had the window-dragging style property
set. Fix this by looking at the region for motion notify
events as well as for buton press events.
The code setting up the button has been move a little later
in the dialog construction, with the effect that the entry
is already insensitive when we set up the binding.
We had already set the image to be hidden in the .ui file.
This patch removes the image altogether, and deprecates the
property, setter and getter.
If an image is explicitly put with the setter, it is still
shown, so to not break existing users of this API.
Based on a patch by Jon McCann.
Try to do a better job of keeping example content
from being too wide. It is often rendered as <pre>
text so the only time we can wrap it is in the source.
It is best to full break lines at all punctuation and
to try to keep the width under 70 chars or so.
We don't want the size request to change as icons come and
go (thinking e.g. about the caps lock warning). Just make
sure that we have enough room for showing the icons.
Improve the algorithm to determing popover placement:
If it fits in the preferred direction or its opposite,
do that, otherwise use the direction that causes the least
of the popover to be cut off.
Add api to allow explicitly setting a GtkPopover instead of
a GtkMenu as the popup of a GtkMenuButton. Also, add api to
instruct the menu button to construct a popover when given
a menu model.
We set the style class "menu-button" on the button only when
it pops up a menu, to allow different treatment for the active
state of the button in the two cases.
https://bugzilla.gnome.org/show_bug.cgi?id=723878
cairo_rectangle_int_t replaced by GdkRectangle whenever it is used.
Also, rect parameter in public method gtk_popover_set_pointing_to
made const.
Bug #723394
Replace GTK_TYPE_WIDGET with more specific GTK_TYPE_FLOW_BOX_CHILD
for GtkFlowBox::child-activated. This matches signature of
child_activated slot in class struct.
https://bugzilla.gnome.org/show_bug.cgi?id=723716
The properties are declared read-write, but only the setter
was hooked up. This was leading to criticals in test apps using
the prop-editor.c code. Complete the implementation by adding the
getter side too.
This adds a new function, gtk_popover_new_from_model, which creates
a popover and populates it with suitable content according to the
menu model. The current implementation uses GtkModelButton for the
individual items, and a GtkStack for submenus.
https://bugzilla.gnome.org/show_bug.cgi?id=723014
Similar in spirit to GtkModelMenuItem, this private GtkButton subclass
can connect to a GtkMenuTrackerItem and present itself as either a
regular button, a check button, or a radio button. Activation and
state tracking is done through the GAction that is associated with
the menu tracker item.
https://bugzilla.gnome.org/show_bug.cgi?id=723014
Popovers aren't direct children of the widget they point to, but yet
they act as children of it, so do the same with state propagation,
so the flags that propagate across the hierarchy reach popovers too.
Anytime ::grab-notify comes across, the popover visibility and GTK+
grab ownership are checked, so the popover is hidden when it loses
the GTK+ by any reason.
Previously we did a semi-successful job at ignoring it. Unfortunately
this job was bad enough that we could lose the direction.
We still allow passing in the enum values, because we want code like
this to work:
set_state_flags (get_state_flags() | SOME_FLAGS)
Heavy duty can prevent this idle function from being called before
the window is destroyed, so make sure that the source is removed
when the window is finalized.
https://bugzilla.gnome.org/show_bug.cgi?id=723771
This hideous hack is necessary so far because the main users of
GtkScaleButton are also clutter users, so the GtkScaleButton popover
will be very likely shaped against a clutter-enabled native window.
https://bugzilla.gnome.org/show_bug.cgi?id=723556
Popovers no longer sets a shape, unless this function is called. This
function exists so widgets that are potentially placed on top of other
native windows can get a popover that's nicely shaped, even if it has
no border shadow around.
https://bugzilla.gnome.org/show_bug.cgi?id=723556
Since realize does a lot of the heavy lifting of setting up
csd, we have to re-realize the window if we go from no-custom
titlebar to a custom titlebar or vice versa.
https://bugzilla.gnome.org/show_bug.cgi?id=722919
When gtk_window_set_titlebar is called, we need to set up
client-side decorations properly, and the easiest way to do
so is to realize the window again. Really, you should call
set_titlebar before the window is realized.
https://bugzilla.gnome.org/show_bug.cgi?id=722919
10b5ec20 made sure not to set focus_child to NULL all the way up to the
top, but only up to the common ancestor. However, it would never set it
on the common ancestor itself, which would therefore remain with a
focus_child set when it shouldn't.
A manifestation of the bug: focus column headers of a treeview, press Tab.
Now pressing Shift+Tab will go to another widget and not the column
headers, and Tab will (appear to) do nothing, all because the treeview
still has a focus_child set to column headers after a grab_focus().
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=723402
This reverts commit ba6128f8af.
This change breaks emacs drawing entirely. Since GtkFixed is
somewhat of a legacy widget anyway, lets just not bother doing
this modernization there, at least for now.
Showing tooltips on top of a transient popup does not work
out well, and is not really necessary here. At the same time,
remove the unnecessary repetitions of properties. In particular,
setting the label of the buttons here defeats the scale buttons
use of symbolic icons.
https://bugzilla.gnome.org/show_bug.cgi?id=723181
