There are two scenarios. A widget sub-class owns a GtkEventController
and passes itself to it, or a controller owned by something else is
passed a widget.
In the second case, if the widget is destroyed before the controller,
we will have a crash when destructing the controller because we will
be accessing invalid memory. Adding a weak reference on the widget
addresses that problem.
This leads to a crash in the first case. When the widget is getting
destroyed, it will drop the reference to its own controller. The
controller will skip touching the widget because the weak reference
would have turned it to NULL. However, when the widget sub-class chains
up to GtkWidget it will try to free all the controllers in its list.
Unfortunately, all these controllers have already been destroyed. So
we need to guard against this too.
https://bugzilla.gnome.org/show_bug.cgi?id=745225
We were trying to start search when the user types anything,
but this is annoying more often than helpful, and interferes
with the location entry. So, stick with explicitly enabled
search (via the search button or Alt-S) for now.
Although gtk_list_box_row_grab_focus() is not a public function
it can be easily called by gtk_widget_grab_focus() with a row argument
which has been removed from the list box and has box == NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=744879
The height of the text buttons depends on the font height,
whereas the search button has a fixed-size icon in it...
Prevent unevent heights by putting them all in a size group.
https://bugzilla.gnome.org/show_bug.cgi?id=745263
The height of the text buttons depends on the font height,
whereas the search button has a fixed-size icon in it...
Prevent unevent heights by putting them all in a size group.
If a scrollbar is not shown (because of policies, or because it isn't
necessary), it doesn't make sense to start fade animations on its window
on captured motion events.
This was added a few years ago, as a way to have _no_ im context
at all. But it didn't actually work. Make it work, and streamline
the handling of none by moving it all to gtkimmodule.c.
As part of this, add context to the translated names of all
im modules we ship.
In order to provide a constant mtime between OS build and deploy time,
while also maintaining a hardlink content-addressed model independent of
timestamps, ostree sets all mtimes to 0.
The icon cache code currently ignores directories with mtime 0, assuming
they don't exist.
Track directory existence in a more precise way.
https://bugzilla.gnome.org/show_bug.cgi?id=745052
When loading SVGs from ICON_THEME_DIR_UNTHEMED GtkIconInfos,
such as those created for a GLoadableIcon, the size of the pixbuf to
load is set as a product of icon_info->scale.
But a few lines above, icon_info->scale is set to -1 for
ICON_THEME_DIR_UNTHEMED GtkIconInfos, so we'll end up always passing a
negative size to the GdkPixbuf loader, which is interpreted as the
nominal size of the image file.
Instead load the SVG at the desired scaled size in that case.
This fixes blurry icon in the notification panel in gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=744991
When loading a GResource-backed GFileIcon into a GtkIconInfo we
currently fail to populate the is_resource private field.
Also, since is_svg is set by looking at the filename, and
g_file_get_path() returns NULL for a GResourceFile, is_svg was always
FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=744991
Add a way to set a delay factor that can be used
to make the long press more or less sensitive.
Making this a factor instead of exposing the delay
itself preserves the value of the setting as an
overall 'slow down long press' setting.
As Sebastian pointed out, just resetting the initial slider
position was an incomplete fix, because it does not cause the
delta to be recomputed, which is important in this scenario,
because you've likely travelled some distance over the slider
before the long press kicks in.
Instead, explicitly record both the slider position and the
delta.
We record the starting position on button press, but only
start the zoom mode when the long press timeout kicks in.
Depending on circumstances, this can cause a noticable jump.
Avoid this by resetting the recorded starting position after
the long press timeout. Suggested by Sebastian Keller.
While a popover is hiding, the modal grab is already gone and the toggle
button is clickable again, but clicking again at that time will result in
gtk_widget_show() trying to show an already shown widget (although fading
out and hidden soon) and the toggle button activated.
So let the menubutton set the active status only if the menu/popover
widget wasn't already shown, and ensure this doesn't get triggered by
double/triple button press events.
As an implementation detail, the popover hooks the fade out animation
on ::hide. Destroying the popover right away here is not a problem, but
prevents the animation from actually running. ::unmap will be run after
the animation is finished, so destroy the popover there.
These have the same visual effect and timing than the gnome-shell ones.
During the hide animation, the popover has been made to take focus
elsewhere, and refuse to take any pointer/keyboard input until the popover
is shown again.
This has been based on work from Timm Bäder.
https://bugzilla.gnome.org/show_bug.cgi?id=741405
gtk_scrolled_window_allocate_scrollbar was calling
gtk_scrolled_window_allocate_child just to get the relative
allocation, overlooking the fact that that function is only
safe to call if the scrolled window _has_ a child. Unfortunately,
gtk_scrolled_window_allocate_scrollbar will sometimes get called
when that is not the case. Since we are really only interested
in the relative allocation, just get that directly. This
fixes a segfault in the style-properties-nth-child reftest.
Also try and clarify a few things about event propagation. Move
input-handling.xml into gtk-doc’s expand_content_files variable so it
automatically links to widget documentation. Add links from
gtk_widget_add_events() and friends to the new documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=744054
At the time of creating the indicator window, the scrollbar allocation is
poked and reused as the initial window dimensions. This usually happens
on two circumstances, either initially (so a ::size-allocate is emitted,
relocating the windows in the right places), or post-initialization when
calling set_overlay_scrolling() (so the scrollbars already have a valid
size allocation)
However, if the scrolledwindow is unrealized, and later re-realized again,
the scrollbars will already have a valid allocation, although 0,0 based
due to being contained in the previous indicator window. This comes out
wrong then, and the indicator window is given 0,0 based coordinates too.
Fix this by refactoring the scrollbar allocation code out of size_allocate,
and also use that given size at the time of creating the indicator windows,
this will provide the right widget-relative allocation anytime.
Currently, GtkGLArea will leak GError instances set during the context
creation, if an error is set.
If any error is set post-context creation, it should be displayed even
in the case a GL context exists; for instance, we can use the error
display facility for shader compilation errors.
Make that variable go from 0.0 to 1.0 where 0.0 means inactive (slider
is on the left) and 1.0 means active (slider is on the right).
The math is simpler that way and most importantly the value is
independent of size.
Add a button to allow restricting search to the current
folder (and subdirectories). This makes the search more
useful, and makes the file chooser more similar to
nautilus.
In search, we show files from differnt locations, and it makes
sense to show where they come from. This makes the file chooser
more similar to nautilus, too.
Folders that show up among search results were unexpectedly
returned even for GTK_FILE_CHOOSER_ACTION_OPEN. Change things
around so that we switch to the folder instead, which is the
behavior we had in GTK+ 2.x.
https://bugzilla.gnome.org/show_bug.cgi?id=744204
This is necessary to avoid unwanted drag cancel animations,
now that GtkNotebook is careful about cancelling a drag
when the dragged tab disappears unexpectedly.
The existence of OpenGL implementations that do not provide the full
core profile compatibility because of reasons beyond the technical, like
llvmpipe not implementing floating point buffers, makes the existence of
GdkGLProfile and documenting the fact that we use core profiles a bit
harder.
Since we do not have any existing profile except the default, we can
remove the GdkGLProfile and its related API from GDK and GTK+, and sweep
the whole thing under the carpet, while we wait for an extension that
lets us ask for the most compatible profile possible.
https://bugzilla.gnome.org/show_bug.cgi?id=744407
Now that we have a two-stages GL context creation sequence, we can move
the profile to a pre-realize option, like the debug and forward
compatibility bits, or the GL version to use.
gtk_list_box_bind_model() binds a GListModel to a GtkListBox.
This is a first step towards having GListModel support in Gtk. It's not
useful for large models, because GtkListBox always creates all widgets
for all rows.
One of the major requests by OpenGL users has been the ability to
specify settings when creating a GL context, like the version to use
or whether the debug support should be enabled.
We have a couple of requirements in terms of API:
• avoid, if at all possible, the "C arrays of integers with
attribute, value pairs", which are hard to write and hard
to bind in non-C languages.
• allow failing in a recoverable way.
• do not make the GL context creation API a mess of arguments.
Looking at prior art, it seems that a common pattern is to split the
construction phase in two:
• a first phase that creates a GL context wrapper object and
does preliminary checks on the environment.
• a second phase that creates the backend-specific GL object.
We adopted a similar pattern:
• gdk_window_create_gl_context() creates a GdkGLContext
• gdk_gl_context_realize() creates the underlying resources
Calling gdk_gl_context_make_current() also realizes the context, so
simple GL users do not need to care. Advanced users will want to
call gdk_window_create_gl_context(), set up the optional requirements,
and then call gdk_gl_context_realize(). If either of these two steps
fails, it's possible to recover by changing the requirements, or simply
creating a new GdkGLContext instance.
https://bugzilla.gnome.org/show_bug.cgi?id=741946
This guarantees we only create 1 extra style cascade in total for hidpi
and not one per style context.
Style cascades are now nested like this:
GtkSettings root cascade (scale == 1)
|
+-- GtkSettings per scale cascade (for any scale, no custom providers)
|
+-- GtkStyleContext custom cascade (for any scale, custom providers)
This requires a bunch of care when changing cascade-related properties
inside GtkStyleContext, so that it ends up with a properly setup
cascade, but I think I got those cases right.
The only thing we don't do yet is reverting to a GtkSettings cascade
when the last custom provider is removed from a custom cascade.
This property is necessary to ensure widgets automatically update after
the text scale factor is changed desktop-wide.
And if I'm already doing a property like this, I can make it
overridable. So now you can override the dpi per-widget with CSS like
GtkSwitch {
-gtk-dpi: 48;
}
if you want to debug things.
Long-term, we want to get rid of this property and insist on dpi being
96 everywhere and people can change the font size to get larger fonts.
GPUs generally have problems when you create a 35000px wide surface.
Luckily X catches this and sends a BadAlloc. Which GTK immediately
abort()s on.
Testcase included.
https://bugzilla.redhat.com/show_bug.cgi?id=1163579
This avoids showing the scrollbars if we are positive the child widget
is being manipulated, regardless of the pointer being close to any of these.
On the next motion event after finishing the operation, the scrollbar will
be shown if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=743894
is_visible() wasn't the right check to perform here before unmapping,
and gtk_widget_unmap() already avoids being doubly called by checking
gtk_widget_get_mapped() anyway.
In that case the scrolledwindow still gets events through the captured
handler, and can thus still control visibility, so hiding the indicators
in this case can only lead to flashing.
This will be used to just detect when an edge of the scrollable area is
reached - as opposed to the edge-overshot signal that is emitted when
the user scrolls past the edge.
https://bugzilla.gnome.org/show_bug.cgi?id=742848
If a side of the box is 0px wide, make the corners owned by the adjacent
sides. This avoids spilling over of unwanted colors from the 0-width
side into the corner.
This is the fix that should actually have been part of
7e5ac3a58d but my amazing amending skills
got rid of it when amending the test.
Arrange things so that gtk-xdg-hinting==-1 and gtk-xfg-antialias==-1
end up as CAIRO_HINT_STYLE_DEFAULT and CAIRO_ANTIALIAS_DEFAULT in the
cairo font options.
This will not change anything on Linux desktops where xsettings will
always provide values different from -1. But on other platforms, we
can benefit from getting the platform-specific defaults in cairo.
Based on the first patch in:
https://bugzilla.gnome.org/show_bug.cgi?id=735316
When a tab is dropped, we have to remove it from the notebook to
insert it elsewhere. This is expected part of the tab dnd operation,
and we need to differentiate it from 'spontaneous' removals which
cause us to cancel the drag operation.
when the dragged tab is being removed during the drag operation,
we need to cancel the drag. To do so, we have to keep around
a reference to the drag context.
This should fix
https://bugzilla.gnome.org/show_bug.cgi?id=732051
Add a gtk_drag_cancel() function that can be used on the
source side to cancel an ongoing drag operation. This can
be useful, e.g. if the data that is being dragged becomes
unavailable.
It is a bit misleading to have one of the places in the sidebar
selected while in search mode, since the search is not relative
to any location. So, unset the sidebar selection when we enter
search mode.
If the search entry doesn't consume the key event, don't
change to search mode. Otherwise, we interfere e.g. with
Ctrl and Shift keys for selection.
https://bugzilla.gnome.org/show_bug.cgi?id=743660
If the grab belongs elsewhere, the window won't claim the sequence right
away. The sequence may still be claimed afterwards when window dragging
starts, but simple clicks won't be consumed this way.
This makes it possible to close popovers when clicking on the title region,
while still permitting touch/button 1 interaction for every other purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=743257
- Specifically request GL version when creating context. Just specifying core
profile bit results in the requested version defaulting to 1.0 which causes
the core profile bit to be ignored and an arbitrary compatability context to be
returned.
- Fix GL painting by removing GL calls that have been depricated by the 3.2 core
profile.
- Additionally remove glInvalidateFramebuffer() call, it is not supported by 3.2
core.
https://bugzilla.gnome.org/show_bug.cgi?id=742953
Add helper for getting the main clipboard. This makes
the API usable for bindings (as GdkAtoms aren't usable through
gobject-introspection), and easier to use in C.
https://bugzilla.gnome.org/show_bug.cgi?id=712752
The property is useless to set (it only allows 'initial', 'inherit' and
'unset' as values), but it is used to track changes to the icon theme.
And as such, it can ensure that widgets can track when they need to
reload icons.
https://bugzilla.gnome.org/show_bug.cgi?id=743341
Gtk_container_cell_widget_set should chain up to its parent's set
function, not its parent's unset function. This was resulting in
accessibles being erroneously marked defunct after being created.
The GtkSelectionData does not own the model set with
gtk_tree_set_row_drag_data so change the out param to "transfer none".
This fixes a crash after multiple DnD actions due to the bindings
stealing a reference each time this function is called.
This also adds nullable and optional annotations for tree_model and path while at it.
https://bugzilla.gnome.org/show_bug.cgi?id=743193
Add ::next-match, ::previous-match and ::stop-search keybinding
signals that are bound to Ctrl-g, Ctrl-Shift-g and Escape. Also
add a gtk_search_entry_handle_event() function to handle key events.
Previously, we would not include any child widget on the first
allocation, which happens right after realize(), but before map(). No
widget is drawable at that point.
The rotation code in the draw_arrow function was assuming that the arrow
would be drawn pointing upwards but it was pointing to the right
resulting in the rotated arrows pointing in the wrong direction.
The recent refactoring caused a pi/2 rotation to be lost. Rather than
adding that back somehwere (to lose it again in the future), we just
draw the arrow pointing upwards as it is expected to do with a 0 angle.
Yes, I like playing around. To enjoy, add this CSS to your application
of choice (preferrably glade or something with lots of images):
GtkImage { animation: spin 2s linear infinite; }
You can thank me later.
The spinner is a regular builtin image now. There is no need to go
through the shadows code manually anymore as regular items do get
shadows automatically.
This also allows simplifying the actual spinner drawing code so that it
actually works.
The order in which properties are defined depends on the order in which
they are computed. And that means that properties can only depend on
other properties that are defined before them.
The next patches will need this reordering.
Instead of supporting every angle, just support top, right, bottom and
left and round the angle to one of those directions.
Adwaita overrides arrows anyway and doesn't even look at the angle, so
this should not be a problem.
Also, make it have a generic entry point with
gtk_css_image_builtin_draw().
The only feature lost so is the drawing of shadows for spinners, but
that will come back later.
The file chooser code now calls into the path bar in init,
starting an async operation. This unveiled that the path bar
code was not safe against being disposed early, by causing
a crahsh of the objects-finalize test.
Fix this by making the callback check for CANCELLED.
This was left unmodified when GtkScrolledWindow was made a windowed widget.
Displacing here by the widget allocation is not necessary anymore, since
we are invalidating the window set at these coordinates.
This patch is a simplification of a previous one by Timm Bäder.
https://bugzilla.gnome.org/show_bug.cgi?id=742243
GtkImageMenuItem always packs a GtkImage when it is synced with a
related action. This is unnecessary when the action doesn't have an icon
set and results in excess padding when a GtkImageMenuItem is put in a
menu bar (GtkUIManager does this).
Fix this by not creating the GtkImage for icon-less actions.
https://bugzilla.gnome.org/show_bug.cgi?id=742181
Just add a 3rd stop in the place where the gradients for the other
states have a 3rd stop. When running transitions between states, this
avoids cross-fades and instead uses the much faster gradient
transitioning code.
Instead of asserting, just print a g_warning() and try to work around
the problem.
I hope that g_warning() isn't too spammy for people that are hit with
it.
Also clarify the docs that not restore()ing after a save() is a bad
idea.
https://bugzilla.gnome.org/show_bug.cgi?id=743101
When creating the query path, explicitly specify if it's for a root node
or for a child. Relying on gtk_style_context_is_saved() is unreliable
(for example when updating the cache).
The last round of filechooser redesign work had left
search somewhat dysfunctional. This commit fixes things
up enough that search is once again a working feature
of the file chooser.
There are some cases where we can end up showing the path
bar without ever setting a file on it. One example is:
1) Open file chooser
2) Hit ~
3) Hit Ctrl-L
While this is a bit of a workaround, at least it makes sure
that we never end up with an empty space where the path bar
is supposed to be.
This gets rid of a bunch of awkward transitions. It's not a perfect
solution to the problem of "should we transition from this state" but it
gets rid of the ugliest offenders.
If this is done on dispose(), the widget may be destroyed (and its
controllers list NULLified) within _gtk_widget_run_controllers(),
causing warnings/crashes when it just tried to hop on the next
controllers.
Freeing the controllers here should be a safety net for implementations,
so it also makes sense to do this late. The widgets that choose to
free their controllers on dispose can still do so, and get
_gtk_widget_remove_controller() called for these as an indirect result.
g_utf8_get_char_validated() may return -1 or -2
return type is gunichar(guint32)
Therefore such checks like 'gunichar < 0' or 'gunichar > 0'
are always 'false' or 'true'(except when gunichar == 0).
Signed-off-by: Maks Naumov <maksqwe1@ukr.net>
https://bugzilla.gnome.org/show_bug.cgi?id=742774
If a gtk_style_context_invalidate() is called on a widget's style
context (which nobody should ever do, sheesh!) and we're animating, stop
the animations.
Fixes crashers in Nautilus.
When we get a leave event, we need to remove the over bit,
since we may not get motion events that tell us when we lose
proximity, but we don't have to fade out right away - that
will happen on its on due to inactivity a bit later. Having
the indicator stay visible for a bit feels more relaxed.
Since gsize doesn't work as a typename in a ui file,
we have to be careful not to pass pointers to wrongly
sized variables when getting the guint64 values out
of the model.
https://bugzilla.gnome.org/show_bug.cgi?id=742664
We still use symbolic icons for Copy, Cut, and Delete operations inside
toolbars and some menus, so it's worth pointing to the symbolic icon
names in the deprecation notices.
https://bugzilla.gnome.org/show_bug.cgi?id=741969
We need to clear the cache manually on full revalidates because
_gtk_css_change_for_child() will clear the full revalidation flags.
And then gtk_style_context_update_cache() will not do the right thing
(which is to clear itself).
Because we can switch from animating to non-animating pretty much
anywhere, do the check for animations unconditionally instead of trying
to cram it into the correct if path (and failing).
We now cache the results of lookups on the parent GtkCssStyle. This
allows sharing styles between widgets (recursively). However, this
only works if the styles can't potentially depend on siblings -
neither directly via sibling selectors or via position pseudo-classes
like :first-child.
Unfortunately, Adwaita currently uses first-child a lot, and in
particular for labels, which are the most common widgets.
The big benefits of this change are both less CPU - due to not needing
to compute styles again - and less memory usage - due to sharing of
the styles between widgets. Here's some nonscientific numbers I
collected while pondering the usefulness of this patch:
glade glade widget
demo demo factory
runtime styles styles
Adwaita before 19.1s 5800 1150
Adwaita now 18.9s 3800 970
Adwaita hacked now 14.5s 3100 910
simple before 11.3s 5800 1150
simple now 10.8s 1300 590
Adwaita: Adwaita as provided by GTK
Adwaita hacked: Adwaita with the first/last-child for GtkLabel removed
simple: A 250 lines simple GTK theme I use for testing
before: This patch not applied
now: this patch applied
glade demo runtime: Starting glade opening a large file and closing it
glade demo styles: GtkCssStaticStyle objects after opening glade with
the large file as per inspector
widget factory styles: GtkCssStaticStyle objects after startup as per
inspector
Previously we looked at the save/restore state when determining the
parent. This is wrong in the case where we're updating the cache though.
So we now save the parent in the style info.
After the parent changes in commit
3a337156d1 we need to refresh the cached
styles after the current style. After all, they now depend on the base
style.
After 3a337156d1 style lookups still used
the parent context's style as the parent style, even though after a
gtk_style_context_save() the root style of the style context is the
proper parent.
Testcase attached.
Instead of keeping an animated style everywhere, we replace it with the
static style when nothing gets animated.
Apart from making the code cleaner, this gets rid of a bunch of animated
style values that do nothing but wrap a static style.
The only style that is animated is the style of the unsaved primary
node. So there's no need to create animated style objects for the other
ones.
There is a bunch of ugliness in the code currently. Further commits are
expected to fix them.
For now, this is only an implementation detail of the animated style.
The idea is to use GtkCssStaticStyle as the result of CSS queries and
then put a GtkCssAnimatedStyle on top that manages the animations. The
neat thing about this is that you can cache the static values.
GtkCssStyle is the base class to be used for all types of styles that do
exist.
GtkCssAnimatedStyle is the only implementation so far, that is exactly a
copy/paste of the old GtkCssStyle code.
I removed it in 14f5ce7108 because I
thought it was unnecessary, but it wasn't. When we build a tree like
this:
.matches ─┬─ .doesntmatch
└─ .alsodoesntmatch
We would get the changes for the .matches part returned. This is however
only right if that node of the tree contains results. If results only
exist with the child nodes (all of which don't match), then this part
should not match either.
GtkCalendar can have an invalid date — mostly at initialization. This
means that GDateTime construction may fail. We need to handle that case
gracefully, like the old code did.
This fixes the `notify` test suite, which started failing with:
/Notification/GtkCalendar:
GLib-CRITICAL **: g_date_time_get_day_of_week: assertion 'datetime != NULL' failed
inside the Continuous builder.
This is so we can detect crossing events on the scrolledwindow widget,
which can be useful for toggling certain behaviors or not depending on
whether the mouse is on the widget.
If the first of the month was falling on a Sunday, we would not
render any days of the previous month, and instead show two weeks
of the next month at the bottom. Improve this by showing one week
of each.
https://bugzilla.gnome.org/show_bug.cgi?id=301835
Changing font size does not cause widgets to update their size
properly anymore, since we forgot an invalidation flag. The
problem can be observed e.g. by running gtk3-demo and calling
gsettings set org.gnome.desktop.interface font-name "Cantarell 22"
On the wayland backend, set up GDK_WINDOW_SUBSURFACE windows
for popovers. In the popover code, the popover-relative-to-parent
calculation had to be tweaked, and it's been made to always prefer
the given popover position, since there's no sizing limitations.
https://bugzilla.gnome.org/show_bug.cgi?id=738891
We were asserting priv->filename != NULL in various places,
which leads to apps refusing to work when HOME is set to a
nonexisting or nonwritable value. Since it isn't hard, just
make GtkRecentManager survive without a filename. We won't
save or read any recently used files in this state, but
thats ok.
https://bugzilla.gnome.org/show_bug.cgi?id=739038
Provide a mechanism for hiding the "Quit", "About" and "Preferences"
menu items from the normal places in a traditional menubar layout (in
the File and Edit menus) when the menu is being rendered in the Mac OS
menubar.
These items can already be found in the application menu.
With this feature, applications can now define a single menu to use in
all 'traditional' scenarios.
Use this new attribute in Bloatpad.
https://bugzilla.gnome.org/show_bug.cgi?id=741610
In addition to the fixed-size mode that is used by the text view,
add a mode in which the magnifier requests enough size to render
the entire inspected widget at the current magnification. In this
mode, the magnifier will update its size when the size of the
inspected widget changes. Also, make the magnifier redraw on its
own whenever the inspected widget draws.
There is no good reason to assign the value directly.
Also, this fixes d23f3254b7
where widgets that chained up instead of calling
gtk_widget_set_allocation() would not draw becaues of empty clip.
(1) Get rid of supports_clip flag. All widgets (implicitly) support
clip.
(2) Don't reset the clip to { 0, 0, 0, 0 } before the "size-allocate"
signal.
(3) Make gtk_widget_set_allocation() set the clip (to the allocation).
This ensures that eveyr widget has a clip set.
Note: It overrides previous calls to gtk_widget_set_clip(), while in
3.14 this didn't happen.
(4) As the clip is set by gtk_widget_set_allocation() now, don't set
it after the "size-allocate" signal anymore.
This fixes calls to gtk_widget_queue_draw() from inside the
size_allocate vfunc.
Override the gtk-shell-shows-app-menu and gtk-shell-shows-menubar
settings to FALSE, if we can detect that we are not on the same
session bus as the xsettings provider that we got these settings
from.
We determine this by comparing the bus ID of 'our' session
bus with the one reported in the Gtk/SessionBusId xsetting.
If they are different, then it very likely that we are in an ssh
situation where we see the forwarded X display, but not the
session bus. The D-Bus based menu exporting will not work
in this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=671802
The magnifier is now set enough height to show the line being currently
manipulated, which makes it just big enough to show the layout height at
that size and magnification.
- It is not possible anymore to trigger text DnD through touch, pressing
and dragging from within the selection will instead extend it. Text
shrinking is still available through the handles
- The selection mode for touch is per-word, char-level manipulation is
still available through the handles.
- Tapping within the selection will bring in text handles, and toggle
text selection popover.
This mode could also shrink the selection, plus the starting point would
seem somewhat arbitrary (actually dependent on the dragging direction of
the last selection).
Made this mode more consistent by only allowing it to extend the selection,
only in one direction for each operation, and so it keeps the current
selection as a minimum.
Instead of passing a GdkEvent and let the function figure out whether the
selection should be extended, let that to the caller and just pass a
boolean here.
Using the parent widget context is a leftover of the pre-popover
implementation, which used GdkWindows directly. This will make the context
reflect widget state, at the expense of changing the selector paths
that used to match the handles.
Checking the return value was valid for most gestures, but
GtkGestureLongPress, where the first press triggers internally an action,
but does nothing for the sequence to be claimed/denied, FALSE was eventually
returned, and the button/sequence functions would be incorrect when
::pressed is emitted.
So check that the sequence is being handled by the gesture, this is more
desirable than the return value as it's independent of sequence state,
and still will be FALSE for the cases we want to catch here.
When a RTL paragraph is not set to wrap, the right margin is not respected
because of the margins counted twice so we replace
display->width by PIXEL_BOUND (extents.width), the same quantity
without the margins.
https://bugzilla.gnome.org/show_bug.cgi?id=741702
GtkIconTheme doesn't scale icons beyond the size specified in the theme
anymore. This can result in arbitrarily large menu items when a theme
only provides large icons.
Force icons to always be 16x16 to ensure that menu items always have the
same height.
https://bugzilla.gnome.org/show_bug.cgi?id=741259
This drops the maybe_allocate_buffers that re-allocates buffers
at any point. Instead we just set have_buffers to FALSE and have
the buffers re-created when needed.
This also makes the buffer creation code imdeponent and makes it
clean up no longer needed buffers in order to handle being called
multiple times due to the above.
We also ensure we re-allocate the buffers when we're resizing
and the buffers are already created.
On creation, we call action_removed() in case the action was missing
from the start. Because we just created the action, 'can_activate' will
always be FALSE here and this function will therefore always do nothing.
We do want the visibility state to be updated though, for the case where
the action is missing but the item should still be visible from the
start.
Update the visibility directly instead of trying to call
action_removed().
https://bugzilla.gnome.org/show_bug.cgi?id=735122
We were only properly setting the "is-visible" flag to TRUE for menu
items with associated actions and not (for example) on submenus.
This was fine because the code for building GtkMenus from models
(correctly) assumed that submenus should always be visible and never
checked the property.
This is not true for the Mac OS code, which actually checked the
property and found it to be false for submenus.
Initialise the property to TRUE so that we get the correct value
reported for items that don't have actions.
https://bugzilla.gnome.org/show_bug.cgi?id=735122
All popover sides have extra margins to possibly hold the tail, this is
accounted for in gtk_popover_get_rect_coords(), and should be accounted
for too in the tail position calculation.
This fixes the gtk_render_frame_gap() warnings seen when a popover is
pushed far too close to window sides.
After b49c7c3421 we were no longer doing a
full revalidate after GTK_CSS_CHANGE_SOURCE changes.
This fixes spurious failures of widgets not properly updating when
changing the theme.
These functions, while added for use by the GTK inspector, are generally
useful to applications that need to resolve what action groups are
available to a particular GtkWidget.
https://bugzilla.gnome.org/show_bug.cgi?id=741386
Without this, the focus will not be inside the top_stack when
we switch to the statistics page and it shows the excuse. This
in turn will make the next page not take focus as expected when
switching away from the statistics page again.
Add notebook-like focus handling: Keep track of the last focused
descendent of each page, and focus it again when switching back
to the page. If there is no last focused child, we move the focus
into the page as if the user had hit Tab.
When using a completion with some custom cells in the cell layout,
if would often size wrong when first presented on screen.
The entry completion is the only place in the entire gtk code base
that calls gtk_tree_view_column_cell_get_size outside of gtktreeview
itself. It calls into the function before the tree view has done some
important validation on its cell state, the net result of which is
only the first element in the gtkcellareabox the entry completion uses
well actually have its size respected.
We now call gtk_widget_get_preferred_size on the tree view before
calling into the individual cell size routines, to guarantee that the
tree view has run its validate_rows routine and cell state is valid.
https://bugzilla.gnome.org/show_bug.cgi?id=741130
Use the new scrollable API for getting non-scrollable borders
and draw over/undershoot at the right place. In practice, this
means that they now appear below treeview headers.
Add a vfunc to return a non-scrollable border around scrollables.
This would be nicer as a property, but we can't add properties
to an interface without breaking 3rd party implementations, so
make this an optional vfunc, and handle it not being set.
