cairo_rectangle_int_t was replaced by GdkRectangle in commit
552c29b488, but the type of the pointing-to
property was not changed.
To avoid breaking old code that sets or gets the property with a GValue
of type CAIRO_GOBJECT_TYPE_RECTANGLE_INT, transformation functions between
CAIRO_GOBJECT_TYPE_RECTANGLE_INT and GDK_TYPE_RECTANGLE are registered on
the first call to gdk_rectangle_get_type().
https://bugzilla.gnome.org/show_bug.cgi?id=723394
To calculate the shadow width, we look at the value of priv->fullscreen
and priv->maximized.
Those fields will have the actual value only after GTK receives back a
window state event though, so they will be wrong in _realize(). Look at
priv->fullscreen_initially and priv->maximize_initially too, to avoid
the size changing right after realize, which would make the window
flicker if maximized at startup.
https://bugzilla.gnome.org/show_bug.cgi?id=747808
Libinput will use 0.0f on the "scrolling finished" event, so check for this
instead of rounding (<1 values are sort of frequent on touchpads). This
impedes bug #745315 to resurface after commit d563b943ed.
When the scrolledwindow receives scroll events, it ensures the timeout to
maybe start the "snap back to edges" animation is reset, but it does nothing
about the animation source. It must be reset just the same, to maybe be
started after the timeout fires up.
Added another :not() to fix the first and last swatches in the
first section of colorpicker.
Dodge the artifacts due to stacked anti-aliased rounded corners by
increasing the radius of the base object by 1px.
We were only updating window buttons when the headerbar was
a direct child of the window. That is not the case in more
complicated situations, such as the split headers in gedit
or polari. To fix such cases, make the headerbar itself listen
for state changes on its toplevel.
https://bugzilla.gnome.org/show_bug.cgi?id=747805
This used to do the right thing, practically ignoring those event
if they went all through the event handler, unless this motion event
triggered the cancellation of this gesture from the event handler
of another controllers.
In this case, the controller would be reset, but the motion event
would still go through its handler, setting again
current_button/sequence as the motion event has buttons in its
modifiers. This leaves GtkGestureSingle with inconsistent data
that may interfere with future runs.
https://bugzilla.gnome.org/show_bug.cgi?id=747469
The code managing scrollbars visibility was too pervasively checking for
mouse devices, leaving pen/eraser/cursor devices with no scrollbars at
all. Relax these checks a bit, and actually toggle full-width scrollbars
on pen/eraser devices, so it is an easier target.
https://bugzilla.gnome.org/show_bug.cgi?id=747608
Since windows can be intermediate containers this is somewhat redundant,
plus gtk_window_size_allocate() will do additional things like allocating
the popovers, which was mistakenly skipped by local plugs not chaining up.
https://bugzilla.gnome.org/show_bug.cgi?id=747553
This is a workaround for atspi-atk behaviour.
atspi-atk uses signal emission hooks. So it to already catches
signal emissions on creation of objects, before anyone could even
think of g_signal_connect()ing.
https://bugzilla.gnome.org/show_bug.cgi?id=746706
gtk_application_shutdown clears the impl member, so all
callbacks, signal handlers, etc that might still be triggered
between a shutdown call and the return from the mainloop
better be prepared to deal with impl being NULL.
strcasecmp() is unfortunately not universally available, along with
strings.h. Fix the build by replacing strcasecmp() with
g_ascii_strcasecmp(), and remove the strings.h include.
https://bugzilla.gnome.org/show_bug.cgi?id=747604
When a treeview is destroyed while rubberbanding is going
on, we crash because the rb tree is nuked before we want
to access it to stop the rubberbanding. To avoid this crash
end the rubberbanding early in destroy().
See
https://bugzilla.redhat.com/show_bug.cgi?id=1173904
It can apparently happen that we get focus in events
on windows after gtk_application_shutdown() has been
called. Avoid an unnecessary crash in this case.
See
https://bugzilla.redhat.com/show_bug.cgi?id=1176339
The coordinate translations here were not working properly
for window widgets inside the scrolled window, as can be
seen e.g. for the horizontal scrollbar of the 'Tree View'
example in gtk3-demo.
https://bugzilla.gnome.org/show_bug.cgi?id=747406
When moving over a non-expanded indicator from the outside, we were
not expanding it, due to on_scrollbar being true. This can be seen
e.g. when moving from the content pane over to the sidebar indicator
in gtk3-demo. We must still ensure that the indicator is expanded
when receiving motion events over the indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=747407
The gtk_label_set_text() and gtk_label_set_markup() functions have
various side effects that ought to be documented, especially for
non-C developers using properties directly.
https://bugzilla.gnome.org/show_bug.cgi?id=747121
This path is only intended to be triggered on events directed towards the
child of the scrolledwindow, so make it explicitly so. This avoids scrollbar
"over" state flashing when dragging finishes within the slider.
https://bugzilla.gnome.org/show_bug.cgi?id=746961
The "app_id" of a xdg_surface should be the ID that can potentially be
used to get the DBUS name or the .desktop file.
For GtkApplication programs this is often the ID passed when creating the
GtkApplication object, so when available lets use that.
As fallbacks, first try g_get_prgname as it often corresponds to the
basename part of the .dektop file for non-GtkApplication programs.
Otherwise use gdk_get_program_class, even though that string usually
doesn't conform to the expectations of xdg_surface.set_application_id.
https://bugzilla.gnome.org/show_bug.cgi?id=746435
If the icon happened to come from the drag site icon helper (ie. set through
gtk_drag_source_set_icon*), it would be referenced on the GtkDragInfo,
but not hooked into its context. This results on non visible drag windows,
until set_icon_helper() happened to be called on some path.
GtkRadioButton had a deficient copy of the focus sort code
in GtkContainer, causing focus to jump over the next button
in the list. Just use _gtk_container_focus_sort() here,
which fixes the bug _and_ saves 80 lines of code.
https://bugzilla.gnome.org/show_bug.cgi?id=746817
As of 74405cc, progress bars use a new design with values drawn on top
(or to the left) of the through instead of inside of it. This change
brought a number of regressions: the min-horizontal-bar-height and
min-vertical-bar-width style properties are not respected anymore. For
vertical progress bars, the value was drawn too close to the bar and not
centered vertically.
Fix this by respecting the style properties and drawing the value label
at the correct position.
Also, the xspacing and yspacing properties didn't server any apparent
purpose. Change their semantics to mean "the spacing between the label
and the bar". Hence, they only need to be added to the size request when
showing the label. Since we are changing semantics anyway, reduce their
default values from 7 to 2, to avoid and excessive gap.
https://bugzilla.gnome.org/show_bug.cgi?id=746688
As it is, GtkListBox model binding will work nicely as long as your
create_widget_func returns a floating reference on the newly-created
widget.
If you try to return a full reference (as any higher-level language
would do) then you will leak that reference.
Fix that up by converting any floating references into full references
and then unconditionally releasing the full reference after adding to
the box.
https://bugzilla.gnome.org/show_bug.cgi?id=746893
I managed to stall recent files today while trying to save a GTK
testcase in glade that contained enough spinning spinners that the CPU
was saturated just redrawing things.
I had to navigate the filesystem!
The direction in which the slider moves can be inverted by setting the
inverted property. But the draw method does not check this, instead it
checks if the direction of the widget is set to be right to left.
Call the should_invert function in order to determine if the direction
of the range should be inverted. It too checks the widget's direction,
but also checks the "inverted" property, and allows the range to be
drawn inverted even if it is vertically oriented.
https://bugzilla.gnome.org/show_bug.cgi?id=746712
Put the equality check in front. This allows better detection of when an
insert or delete needs to be emitted.
Also, only emit text-changed:delete if the deleted text is not the empty
string. Only emit text-changed:insert if the inserted text is not the
empty string.
https://bugzilla.gnome.org/show_bug.cgi?id=746706
Compute the new text and its length in advance. This way those
computations will not confuse us when they happen in the middle of the
actual action.
https://bugzilla.gnome.org/show_bug.cgi?id=746706
Compute the proportion of the range that should be filled to match the
fill level, and use it to compute the starting point and length of the
area between the slider and the fill level.
https://bugzilla.gnome.org/show_bug.cgi?id=734741
When recomputing CSS, we need a correct widget path in the fallback mode
where we're still using widget paths.
So we need to invalidate it everytime it actually changes, and not just
when emitting the style-updated signal.
Fixes css-match-regions reftest.
Clang complains that this check can never be true. Since this
is a argument range check which we do to catch bad input,
convince clang to not complain instead of taking it out.
clang complains that the expression involving sqrt() is not
constant, and thus refuses to accept it as a case label. So,
use precomputed values instead.
https://bugzilla.gnome.org/show_bug.cgi?id=746468
Break out a setter that manages the weak pointer, and
use it in finalize. This also fixes a bug where we were
forgetting to disconnect the right signal handler in
some cases.
The other Radio* widgets have this convenience method that removes the
memory management of the opaque GSList used to handle the group from the
API usable from language bindings (especially the ones not based on
introspection).
This commit adds gtk_radio_menu_item_join_group().
https://bugzilla.gnome.org/show_bug.cgi?id=671362
Some arguments, like the group and the label of a RadioMenuItem, can be
NULL: the RadioMenuItem has all the code to deal with them. The argument
validation is too strict, though, for instance doing:
return_if_fail (IS_RADIO_MENU_ITEM (foo))
if (foo != NULL)
set_foo (foo)
Which is obviously incorrect.
This commit also modifies the annotations of the API, to ensure that
language bindings do the right thing.
https://bugzilla.gnome.org/show_bug.cgi?id=671362
If we create a RadioMenuItem without a group, and then set a group, the
menu item will still be set as active, which means an inconsistently
drawn radio menu item - as the RadioMenuItem will set the active flag on
itself, but then it won't reset it when it gets a new group.
https://bugzilla.gnome.org/show_bug.cgi?id=671362
It turned out that using mwm hints to instruct wms to
create border-only decorations is not really working
universally. So, instead of doing this, render a solid
frame without shadow on the client-side to handle this
case.
https://bugzilla.gnome.org/show_bug.cgi?id=746222
Signed-off-by: Olivier Fourdan <fourdan@xfce.org>
If the widget has been destroyed since a DBus message had been sent,
we could be in a condition that the widget pointer exists but it does
not have a window.
This bails as if the widget didn't exist if there is no available
GdkWindow.
We also set the extents to 0 to be defensive since this is a vfunc
implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=746586
Since these part really are the same in all of the x or y direction
and we don't blur in that direction we can just blur one line and
repeat it during drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=746468
There is no need to e.g. blur in the x-direction for the top part
of a box shadow. Also, there is no need to extend the mask in the
non-blurred direction.
https://bugzilla.gnome.org/show_bug.cgi?id=746468
For radius 1px the current implementation rounds down to a 1 px box
filter which is a no-op. Rather than creating useless shadow masks
in this case we bail out blurring early.
Another alternative would be to make radius 1px round up to a 2 px box
filter, but that would change the rendering of Adwaita which is probably
not a great idea this late in the cycle.
https://bugzilla.gnome.org/show_bug.cgi?id=746468
Sometimes path nodes can survive longer than the style context that
created them. Don't crash in those cases.
Fixes startup of mutter.
Testcase included.
https://bugzilla.gnome.org/show_bug.cgi?id=746407
This allows monitoring the CSS tree. For now, moving a child to a
different position relative to its siblings while keeping the same
parent will cause a child-added + child-removed emission.
We need to properly track if a node needs to propagate invalidation
state information to its children. We didn't do this properly before and
that could lead to us forgetting to invalidate nodes in corner cases.
Do not propagate the TIMESTAMP change through the node tree, as that
causes lots of uneeded markings of nodes as invalid.
Instead, walk the node tree and find the nodes that have a non-static
style and only invalidate timestamps on those.
Only invalidate timestamps if the node is marked as invalid. We overload
the meaning of "invalid" as "tracks timestamps".
While I don't like the way this is written, it is an important
optimization because 95+% of nodes don't animate so timestamps don't
matter to them. But timestamps are invalidated 60x per second.
We don't return a NULL style to mean "no changes" anymore, instead
we check new_style == old_style to mean that.
Make sure the code reflects this, otherwise we'll send
GTK_CSS_CHANGE_PARENT_STYLE invalidations everywhere and screw up
performance.
Now that the widget node recomputes styles on update_style() we can just
call it during validate(). That way, we don't need the widget node to
manually compute its style.
If CSS values are queried from a widget, recompute them if necessary. Do
not emit style-updated until the validation phase however.
This way, we don't run into performance traps when style-update causes
invalidations that cause new style-updated to be emitted.
... and pass it to the API that computes new styles.
A special timestamp of 0 means "please don't animate" and is used when
no frame clock is available for a node.
This is mainly an attempt to merge the update_style() and validte()
vfuncs. Code is not there yet, but that's the idea.
Also, gtk_css_node_set_style() should not be public. And this gets
closer to that goal, too.
After measuring it, I realized the optimization never triggers for
Adwaita and rarely ever triggers for simple themes. So it is not
useful to keep it around.
This allows adding more API for it.
It also includes code that tracks modifications and invalidates siblings
and their positions whenever nodes get added or removed.
If we know the parent's get_path_for_child() implementation is safe to
be used with GtkCssNode because it doesn't do anything special, we do
that. Unfortunately that requires whitelisting vfuncs because the vfunc
is public API so anyone can override it.
Instead, use gtk_widget_get_path() which makes GtkWidget cache the path.
This is a temporary solution until we can get rid of widget paths.
This increases memory usage quite noticably.
The node declaration has the same functionality as
gtk_css_node_declaration_add_to_widget_path(). So instead of using that
function on a path, you can use the original path and the declaration in
a matcher.
So far the vfunc is kinda quirky (the path argument is an out argument
for something you have to free when you're done with the matcher), but
I'm about to change that.
We don't want to add the current classes to the widget path - which
might potentially be different after a gtk_style_context_save() - but
the root node's ones. So what better thing to do than actually using the
root node?
Instead of directly requesting the layout phase, register a tick
callback. This is what the docs suggest for animations and it's what we
need for the next commit.
... to a bunch of functions.
This requires a tiny change to the heuristics for the style cache - we
now cache styles when they have the same style provider as their parent
instead of when they have the default provider - but that change doesn't
have any effect in practice.
The parent refs the child, so gtk_css_node_set_parent() adds/removes a
reference.
We should probably refactor this so that we name the function
parent.add(node) instead of node.set_parent(parent) - makes the
refcounting more clear.
Instead of passing the style declaration, take the node's style
declaration. Add arguments to allow overriding the state for the one
case where this didn't work.
The code is confusing the stylecontext=>node transition, so I'll remove
it.
WIth the recent introduction of the parent style cachen, I'm not sure
it's worth it at all. Some crude benchmarking suggests a slight speedup
when removing the cache.
So no guarantees about adding it back later.
- GtkCssWidgetNode
for style contexts owned by a widget
- GtkCssPathNode
for style contexts using a GtkWidgetPath
- GtkCssTransientNode
for nodes created with gtk_style_context_save()/restore()
The functionality of it is supposed to grow, so better put it in a
custom file early.
This is just a naive split so far, the next patches will split things
further.
This commit adds the GtkTextTag:underline-rgba and :strikethrough-rgba
properties and the necessary plumbing to apply these colors in GtkTextLayout.
With this change, you can alter the color of underlines including those
of type PANGO_UNDERLINE_ERROR.
You might want to alter the underline color to differentiate between
spelling and grammer mistakes. In code editors, it is convenient to
differentiate between errors and warnings.
Note that the GtkTextAppearance struct is public ABI and has no spare
room for new fields, so we are resorting to some tricky packing to store
the colors in the unused pixel field of the fg_color and bg_color structs.
This packing is accomplished by the macros in gtktextattributesprivate.h.
Signed-off-by: Christian Hergert <christian@hergert.me>
https://bugzilla.gnome.org/show_bug.cgi?id=402168
It has been a long-standing request to interpret scroll events
with Shift held down as horizontal instead of vertical, and
some applications are already doing this on their own.
https://bugzilla.gnome.org/show_bug.cgi?id=132197
This causes pixman warnings, or worse.
Clearly, something is not quite right here, if we end up
redrawing tabs at a time when the allocation is set to (1, 1).
For now, avoid straining the error handling in the lower layers.
https://bugzilla.gnome.org/show_bug.cgi?id=746301
On popover_unmap(), perform the gtk_widget_unmap() call last, so the
GtkWindowPopover data is ensured to be alive throughout the function
if the popover widget is destroyed right on ::unmap.
https://bugzilla.gnome.org/show_bug.cgi?id=745829
This ensures the widget data stays live long enough to perform invariants
check after emission if the widget happens to be destroyed on a callback.
https://bugzilla.gnome.org/show_bug.cgi?id=745829
`bundle install` command on fedora 21 was failing
with following message:
Your Gemfile has no gem server sources. If you need
gems that are not already on your machine, add a line
like this to your Gemfile:
source 'https://rubygems.org'
After adding that line it worked again.
https://bugzilla.gnome.org/show_bug.cgi?id=746205
With the 3.0 transition, this code went from just querying the entry's
height request to doing a full size request.
Then it got code to revert the features that a full size request does.
And then it grew code that manually computed the baseline.
Avoid this and just do what happened back in the days: Do a regular
height request.
This changes the semantics of the get_frame_size() vfunc wrt its
behavior towards subclasses overwriting the get_height() vfuncs, but I'm
happy to live with that.
Applications forget to set the follow-state property and then some
themes used a style where normal symbolic icons have the same color as
prelit or selected backgrounds and that suddenly made icons invisible
and who wants that?
https://bugzilla.gnome.org/show_bug.cgi?id=746201
Rework the way we assign an accessible name to menu buttons,
to make sure we pick up a label, should the button contain
one, and only override the name with "Menu" as a fallback.
This reverts commit 63f59dde3a.
It turns out, the state was not just necessary for style computation,
but also for tracking RTL and LTR. And so it broke the reftests.
gtk_tree_selection_real_modify_range() has a g_return_if_fail() if the
start or end paths passed to it do not correspond to real tree nodes.
However, GtkTreePaths inherently do not have to be valid, so it should
be acceptable to call gtk_tree_selection_select_range() with
non-existent paths. Replace the g_return_if_fail() by a silent return,
and add a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
We need to filter out platform-specific sources from the files that we
use with the introspection scanner.
In this specific case I could have moved the gtkclipboard-quartz.c and
the gtkdnd-quartz.c files out of the $(gtk_base_c_sources) variable, but
doing a filter-out on the variable itself is more resilient in case we
eventually add files and we forget about the result.
Now that this is split in two separate gestures, both must be reset
when the WM grabs the pointer. Also, do on resize drags like on move
drags, and claim the gesture before resetting, so the ownership is
properly transferred across any other widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=745969
gtk_entry_set_completion() (and _gtk_entry_completion_connect underneath)
may happen when the entry has no toplevel yet. This window acts as the
"parent" for subsurface windows on wayland, and is indispensable to create
its backing wl_subsurface, so this resulted in non-visible popups there.
Fix this by ensuring transient_for is set before showing the popup.
https://bugzilla.gnome.org/show_bug.cgi?id=745463
This reverts commit fb9a6bb6d8.
In a recent test, I've found that Xfce and Mate now support
this, so they will not be affected by this requirement. And
adding the check back will solve the 'client-side shadow'
problem in KDE.
The page_setup of a GtkPrintContext or GtkPrintUnixDialog is nullable,
so all reference count changes to it have to be guarded against NULL
values.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
_gtk_rbtree_first() can potentially return NULL if the RB tree is empty,
which would result in NULL pointer dereferences in the GtkTreeSelection
code. Gracefully handle them.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
These vfuncs cannot be NULL: implementations are provided by GtkEntry,
and subclasses should not set them to NULL. Instead of conditionalising
the calls to the vfuncs, assert that they’re set and call them
unconditionally.
This prevents the possibility of a subclass setting the vfunc to NULL
and then a gtk_entry_get_*_size() call returning undefined values in its
out variables.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
They are a bit terse, and they should point to the preferred way of
overriding the theme, i.e. using a GtkStyleProvider for your
application, and custom style classes.
When the scrollbars are overlayed, the size requisition of the
scrolled window should not depend on whether the scrollbars are
visible or not. This was not quite the case, because we forgot
one case where scrollbar size was still added to the requisition.
Postpone until the last moment whether the target widget still
potentially uses updates from this sequence, or window dragging
actually applies because all gestures on the target went to denied
state.
This fixes window dragging on empty space in a headerbar that is
contained in a paned (as in e.g. gedit).
https://bugzilla.gnome.org/show_bug.cgi?id=745562
These types are not covered by g_test_register_all_types,
and having the types registered when a print dialog is used
helps in cases where GTK+ is dlopened.
https://bugzilla.gnome.org/show_bug.cgi?id=745065
GtkPlacesSidebar applies a sorting function on
the tree model that does not consider the case
of bookmarks, which are sorted by their indexes.
By adding the bookmarks corner case and comparing
then by their indexes, GtkPlacesSidebar can sort
the bookmarks properly in the order they're saved.
https://bugzilla.gnome.org/show_bug.cgi?id=744589
This signal can be emitted by GtkSearchEntry after search has been
cancelled, and other operation mode is set. It doesn't make sense to
populate the search model in that state anymore, so just avoid doing it.
https://bugzilla.gnome.org/show_bug.cgi?id=745479
The object might be destroyed when mid operation, causing crashes as the
query callback still expects the object pointer to be valid. Also, remove
the gdk_threads_enter/leave pairs, the callback will be executed on the
caller (UI) thread, so this is not necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=745479
The search engine might stay alive longer due to extra temporary refs, so
the signal handlers should be removed for the filechooser to ignore these
properly.
https://bugzilla.gnome.org/show_bug.cgi?id=745479
This file now uses round(), which was not available until C99, so include
fallback-c89.c instead of math.h, which includes math.h and does a fallback
implementation of round().
Avoid scrolling animation when scrolling to where we want
to insert the new folder, since adding the entry doesn't
do the right thing if the treeview is still scrolling.
An alternative would be to wait for the animated scrolling
to reach its target before starting the editing, but this
is easier.
https://bugzilla.gnome.org/show_bug.cgi?id=729366
This is not specified specifically by the attached controllers, so let
the scrolledwindow set the mask, as motion events with no buttons pressed
are interesting to it.
https://bugzilla.gnome.org/show_bug.cgi?id=745344
The gesture is hooked to the capture phase, so it works for buttons in
header bars and whatnot. In order to be friendly to the widget it is
capturing events from, an ugly hack is in place to avoid capturing
events when the target widget has a gesture that would consume motion
events.
This happens on button release, which is more convenient if the gesture
can be consumed by something else (eg. window dragging), and already behaves
correctly wrt cancelled gestures, broken grabs, etc.
This also allows us to unify pointer and keyboard behavior, popping up the
menu widget in a single place.
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.
