GtkHeadeBar checks the window type hint to determine if the regular
buttons such as menu, maximize or iconify should be visible in the
header bar.
However, an application may very well use a "normal" toplevel window and
set it transient and modal afterwards. In such a case, the iconify
button would remain visible, and the user can hide the window, but being
a modal, the parent window would remain insensitive.
Check for the window type, modality and transient relationship to decide
whether or not the regular toplevel buttons should be visible in the
header bar.
https://bugzilla.gnome.org/show_bug.cgi?id=767052
When we emit ::draw, the widget should not have alloc_needed set
anymore. If this happens, it indicates a broken situation. Add a
warning to help tracking down why this might occur.
See https://bugzilla.gnome.org/show_bug.cgi?id=765410
When filechooer is re-used (instead of being created and destroyed
every time it's needed), it might happen that the directory the
application wishes to initially show is the same directory that
was shown last time the filechooser was used. In that case, make sure
filechooser knows that it does not need to do its default "select $pwd
or $home" routine.
https://bugzilla.gnome.org/show_bug.cgi?id=766122
adds a paragraph to gtk_text_view_get_pixels_below_lines(),
describing how it can be used together with
gtk_text_view_get_pixels_above_lines() to get the total
amount of line spacing between two paragraphs.
https://bugzilla.gnome.org/show_bug.cgi?id=747206
If the popover's relative-to widget is unparented/reparented, we end
up unparenting/reparenting the popover as well. In that case, at the
moment of reparenting, the widget might have been visible (and is
thus mapped again), but priv->window hasn't been set yet.
We must first set priv->window, and then call gtk_window_add_popover(),
that way gtk_popover_map() has its prerequisites straight.
https://bugzilla.gnome.org/show_bug.cgi?id=766323
gtk_widget_set_parent() will map the widget if the parent is mapped
and the widget is both visible and child-visible. As we currently
only set the child visibility after adding the child, we immediately
map all children that are added to a mapped stack, even when they
are not actually shown. Avoid this by setting the child visibility
before adding the child, so widgets are only mapped when shown.
https://bugzilla.gnome.org/show_bug.cgi?id=766737
Use g_drive_is_removable for external drives detection. Current heuristic
fails in some cases (e.g. when removable drive is attached before login),
see Bug 765457.
Bump GLib version accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=765924
When starting a rubberband selection from an empty area, we could run
into crashes if the selection moves over the rows and then back out
to unpopulated area. Handle this case without crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=766336
Use .marks-before/after to indicate the presence of marks.
As Lapo points out, compatibility with the previous names
is not really that important, since everything else changed
around it.
https://bugzilla.gnome.org/show_bug.cgi?id=766440
Warn about the situation when we've found a resource or file path,
but gdk-pixbuf fails to give us a pixbuf. This generally means that
either pixbuf loaders are not found or the shared-mime database
is missing.
It turns out that it is too hard (and in some cases, impossible)
to get this information from node positioning, so bring back the
.scale-has-marks-above/below style classes on the main node.
This should allow us to fix the 'pointy sliders'.
https://bugzilla.gnome.org/show_bug.cgi?id=766440
GtkScrolledWindow leans towards using the minimum size of its child
widget, unless the scrollbar policy is GTK_POLICY_NEVER. This is
probably fine for most GtkScrollable implementations out there.
Especially when using GTK_SCROLL_MINIMUM, which is the default for all
implementations inside gtk+.
However, this is not good for GTK_SCROLL_NATURAL children. eg.,
VteTerminal's minimum size is 1x1 and natural size is the number of
visible rows and columns requested by the user. We really want to use
the natural size unless the user has resized the window to change that.
https://bugzilla.gnome.org/show_bug.cgi?id=766569
This code tries to add the minimum content size, if one is set, to the
GtkScrolledWindow's size requisition. This is obvious from the check
for non-negative values of min-content-height and min-content-width.
Using MAX needlessly makes the code harder to read by implying that
there is more to it when there actually isn't.
Fall out from 0d9ebb501dhttps://bugzilla.gnome.org/show_bug.cgi?id=766569
When we are beginning to calculate the height, if the vscrollbar_policy
is not GTK_POLICY_NEVER, and there is no min-content-height, then we
need some small non-zero value to get started. The idea is to always
ask for at least enough to fit the horizontal scrollbar.
Simply put, this should be the mirror image of the corresponding width
calculation code.
Those who got used to the buggy behaviour might notice that their
GtkScrolledWindows are not as tall as they used to be.
Fall out from 55196a705fhttps://bugzilla.gnome.org/show_bug.cgi?id=766530
Sometimes on wayland we're seeing a frame draw before the first tick
callback, where the window position has not yet been updated.
With this change, the window is properly positioned as soon as
gtk_stack_start_transition returns.
https://bugzilla.gnome.org/show_bug.cgi?id=766405
Fix testsuite/a11y/about.ui GtkAboutDialog :
"CRITICAL **: atk_hyperlink_get_start_index: assertion 'ATK_IS_HYPERLINK (link)' failed"
That is set widget->priv->accessible as soon as accessible object is generated.
When accessible object is created accessible->priv->widget is set,
if widget->priv->accessible is not , then _gtk_label_accessible_update_links
exits early, thus without creating the links on the accessible side.
(This as it checks for the widget to have the accessible set before proceeding).
https://bugzilla.gnome.org/show_bug.cgi?id=766458
GTK used to not emit GtkWidget::style-updated on widgets that weren't
realized. This sped up construction of complex widgetry in the early
days of GTK3 where we instantly invalidated on every change.
We don't do that anymore, so in theory (and in my limited testing with
widget-factory) this shouldn't be a prolem anymore.
What is a problem though is that postponing style-updated leads to 2
problems:
(1) Unrealized widgets will not emit style-updated which may cause them
to not properly update their state and return wrong values from
get_preferred_width/height() etc
(2) Emitting style-updated during realize can happen too late.
When a widget is not made child-visible by its parent (common
examples: notebook, paned) it will also not be realized when the
parent is initially shown. However, when they get realized later
(after a resize of the parent), they will emit style-updated (and
potentially queue a resize) during size-allocate.
https://bugzilla.gnome.org/show_bug.cgi?id=765700
Cancelling the gesture causes the last_event pointer to become
invalid. Make a copy of the event so we can keep using it
regardless of the gesture state.
At one point, the sidebar was using gtk_treeview_set_tooltip_column,
which expects tooltips to be markup. With the listbox-based sidebar,
we don't do that anymore. So don't escape the tooltip text.
https://bugzilla.gnome.org/show_bug.cgi?id=766175
We're measuring both the width of the minimal and the maximal value for
the value gadget, but only give the value the minimal width for its
current value, resultnig in an always left-aligned value.
Fix this by assigning the width of the value gadget to the value layout
and letting pango align the text inside the layout.
https://bugzilla.gnome.org/show_bug.cgi?id=766120
Menus are placed vertically by definition, it does not make much sense
to support horizontal axis for scrolling.
Use GDK_EVENT_STOP/GDK_EVENT_PROPAGATE instead of TRUE/FALSE and add a
default case to return GDK_EVENT_PROPAGATE for unhandled events.
https://bugzilla.gnome.org/show_bug.cgi?id=765939
On X11, we get both smooth and emulated scroll events, whereas other
backends such as wayland will give smooth events only with touchpad
scrolling.
Discard emulated scroll events so that we get consistent behaviours
between backends.
Allow for both horizontal and vertical smooth events for scrolling so
that horizontal scrolling still works without emulated scroll events as
well, again for consistency between gdk backends.
https://bugzilla.gnome.org/show_bug.cgi?id=765939
Some compilers we support, such as pre-2013 Visual Studio, does not support
for INIFINITY, log2() and exp2(), so check for exp2() and log2() during
configure, and use fallbacks for them and INIFINTY if they are not found.
https://bugzilla.gnome.org/show_bug.cgi?id=766207
Children tend to call back into the scrolled window while being removed
and that doesn't work too well if the scrolled window is destroyed
already as Christian Hergert found out.
Depending of float rounding during target calculation, the size of the
GtkRevealer can be set to zero will the animation is not finished.
If the GtkRevealer is in a GtkPaned, it will be hidden and so the animation
will be stopped before it is finished.
In this case, force the emission of the child-revealed signal to let
client code know the animation is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=765973
This was another very frequent use of qdata. Since we typically
have only one or two display objects, storing the display-settings
association in a simple array is faster than using object data
or a hash table.
Christian Hergert reported seeing webkit crashes with recent
GTK+. The stacktrace points at the CSS machinery calling into
GtkSettings to get the font name, and then getting surprised
by a property notification that triggers style validation.
To avoid this, query the font name xsetting right away when
we get set a screen.
This will almost certainly overwritten before the widget gets
to the screen, but while we are doing this, we might as well
use the same state that we initialize the widgets state to.
Instead of creating 2 pango layouts in every draw() and on in
_get_content_size (and calling into gettext twice in both cases), just
keep the layouts around and create them in only one place.
I was somehow under the misconception that we'd get GdkEventSettings
events for all the xsettings at startup. That is not in general true,
so we need to make sure that we check for the xsettings value before
we use them, or derived fields. Update all the private getters to
do so; and fix settings_update_font_values() to cope with font
descriptions that might miss the family or size.
I mistakenly assumed that gtk_settings_init was already doing
something to trigger a notify for all properties. It doesn't,
so we have to ensure that settings_update_font_values() is
called at least once.
https://bugzilla.gnome.org/show_bug.cgi?id=765966
The fallback code for rendering builtin checks, radios
and expanders was using border parameters. With the generic
gadget borders using the same parameters, this was giving
double borders.
Before commit 6c1bee2377 we were setting an attribute of GtkNotebook
to track the pressed button if the pressed button happened on the
tab itself.
Later in the motion handling code we were checking whether the private
pressed button attribute was set or not in order to handle a tab dnd
or not.
In commit 6c1bee2377 the code changed and set the pressed button
variable unconditionally, which means, a motion event from within the
tab content triggered a tab reordering.
This happened only if the children hierarchy have a widget that bubbles
up both button press event, which sets the private pressed button
attribute; and motion events, which started the tab dnd checking the
private pressed button attribute.
A widget that experienced the regression was GtkListBox.
In order to fix it, set the button pressed variable only when it press
the tab itself, not the content.
https://bugzilla.gnome.org/show_bug.cgi?id=764395
Specifically, this URI is not supported on Windows, but GFile will
do its "best" and turn it into GLocalFile("$pwd/network"), with
spectacularly bad results.
https://bugzilla.gnome.org/show_bug.cgi?id=765858
We only keep one align flag per child, so it seems odd to
keep separate h/v expand flags. Just keep one expand flag
and interpret it according to orientation. Allow setting
the expand flag for child widgets too, though, so we can
make widget expand without interfering with the recursive
widget expand flag.
Update all callers.
Use the new possibility of expanding child widgets to make
the label of check and radio buttons expand. This fixes
unexpected behavior of these widgets in RTL in some places.
https://bugzilla.gnome.org/show_bug.cgi?id=765742
In RTL, we want to interpret GTK_ALIGN_START and _END
in the opposite way. Since we don't give gadgets a text
direction, just allow setting an align_reverse flag
to the box gadget.
If there was a piece of text in the cell, then when the edit
entry is shown for that cell, it should have a piece of text
in it roughly at the same location.
Therefore, when child widget is enlarged (child preferred
size exceeds cell size), extra width should be added by
extending either left or right edge depending on text direction.
If after that the child sticks outside of the treeivew visible region,
try to push it back inside (breaking its alignment with the
cell), again, giving preference (i.e. adjusting it last)
to either left or right edge depending on text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=765471
This avoids the g_source_remove(), g_source_destroy(),
g_timer_source_new(), and g_source_set_name_by_id() in the common case.
Instead, we reuse our previous source and update the ready time to our
new deadline. We lose the coalescing with g_timeout_add_seconds(), but
that is not going to help in the common case anyway (unless you have
three hands and can scroll multiple pixelcached backed widgets at once).
https://bugzilla.gnome.org/show_bug.cgi?id=765640
In non-composited environments, we were ending up with all-black
drag icons, because nothing was drawing the background of our new
toplevel. Fix this by drawing background when we are not composited.
We don't do this when composited, since we want to allow transparent
icons.
GtkPlacesView currently provides no example of
server addresses, which may confuse users.
To fix that, add a helper popover with some
guidance on server addresses.
https://bugzilla.gnome.org/show_bug.cgi?id=756570
The documentation clearly says that the widget is not destroyed,
but we were in fact failing to keep it alive, since it was still
a child or the icon_window when we destroy that. Fix this by
reparenting the icon_widget out before. Also, deal with the
possibility that the application might destroy the widget
halfway through, for whatever reason.
There are various functions to access links based on their index for
a11y. We can spare quite a few lines of code by just using
g_list_nth_data instead of iterating over the list ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=765496
We perform lots of gadget allocations that require allocating a
GtkBuiltinIcon. One notable example is the scrollbar for a scrolled
window.
In the process of doing this, we often calculate baseline information that
isn't necessary. With how much this code path gets exercised, its worth
catching the result for the common case, which is that the font-description
has not changed and we are using the default language the application
was started with.
This simply caches the previous result and verifies that we can reuse it
with pango_font_description_hash() and a simple language check.
Numbers below are scrolling through a textview with GDK_KEY_Down.
Before:
SELF CUMULATIVE FUNCTION
[ 0.08%] [ 9.26%] gtk_builtin_icon_get_preferred_size
[ 0.01%] [ 8.82%] pango_context_get_metrics
[ 0.02%] [ 0.16%] gtk_widget_get_pango_context
[ 0.06%] [ 0.06%] pango_context_get_language
[ 0.01%] [ 0.02%] g_type_check_instance_cast
[ 0.02%] [ 0.02%] strlen
[ 0.02%] [ 0.02%] pango_context_get_font_description
[ 0.02%] [ 0.02%] g_list_foreach
[ 0.01%] [ 0.01%] gtk_css_style_get_value
[ 0.01%] [ 0.01%] itemize_with_font
[ 0.01%] [ 0.01%] pango_context_get_type
[ 0.01%] [ 0.01%] get_base_metrics
[ 0.00%] [ 0.01%] pango_font_metrics_unref
[ 0.01%] [ 0.01%] g_list_free
[ 0.01%] [ 0.01%] gtk_builtin_icon_get_type
After:
SELF CUMULATIVE FUNCTION
[ 0.08%] [ 0.18%] gtk_builtin_icon_get_preferred_size
[ 0.02%] [ 0.02%] pango_font_description_hash
[ 0.00%] [ 0.02%] gtk_widget_get_pango_context
[ 0.00%] [ 0.02%] g_object_get_qdata
[ 0.00%] [ 0.02%] g_datalist_id_get_data
[ 0.02%] [ 0.02%] gtk_builtin_icon_get_type
[ 0.01%] [ 0.01%] pango_context_get_font_description
[ 0.00%] [ 0.01%] - - kernel - -
[ 0.01%] [ 0.01%] pango_context_get_language
[ 0.00%] [ 0.01%] gtk_css_style_get_value
[ 0.00%] [ 0.01%] gtk_css_gadget_get_style
https://bugzilla.gnome.org/show_bug.cgi?id=765486
When decelerating the kinetic scroll, we can get into a position where it
looks like we are stuttering. This happens because the amount we move is
so little that it takes multiple frames to make forward progress by one
pixel.
This prevents that by detecting when we have reached the slow stutter of
the deceleration and simply stops the deceleration phase immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=765493
This has several benefits:
- Less code in GtkApplication. The accels handling is something
self-contained, and GtkApplication now delegates the work.
- For the accels functions, there is now a distinction between static
functions and functions in the gtkapplicationaccelsprivate.h header,
which makes the code easier to understand, because we have a good
overview just by reading the header.
- The struct _GtkApplicationPrivate is now easier to find instead of
being in the middle of the file.
https://bugzilla.gnome.org/show_bug.cgi?id=764879
These will become the functions present in the
gtkapplicationaccelsprivate.h header.
The gtk_application_accels functions deal with detailed_action_name's
instead of action_and_target's. action_and_target is an implementation
detail of Accels.
The added function prototype is temporary, it'll be removed in a later
commit.
https://bugzilla.gnome.org/show_bug.cgi?id=764879
When the current cursor_row is taller than the page_size we get from the
GtkAdjustment, the previous code would not actually cause any scrolling,
so make sure we just take the row after or before the cursor_row in that
case.
https://bugzilla.gnome.org/show_bug.cgi?id=765261
These runtime checks were being performed whether or not we were in a
debug build. Using GTK_DEBUG_CHECK() will compile out of production
builds, as it will result in something like:
if (G_UNLIKELY(0))
which the optimizer can prune.
https://bugzilla.gnome.org/show_bug.cgi?id=765284
This first adds a common autotools module that can be included by
the Makefile.am's to generate the file lists and the g-ir-scanner/
g-ir-compiler command lines to build the introspection files.
The autotools files for gdk/ and gtk/ are then updated to generate
the full file lists needed to build the introspection files, with
the full command lines for g-ir-scanner and g-ir-compiler as NMake
Makefile modules that can be used to build the introspection files
for Visual Studio builds.
https://bugzilla.gnome.org/show_bug.cgi?id=765195
Add a way to associate a detailed action name with a shortcut.
If the action name is set, update the accelerator whenever
accels change on the window that the shortcuts window is
associated with.
https://bugzilla.gnome.org/show_bug.cgi?id=764975
https://bugzilla.gnome.org/show_bug.cgi?id=765134 shows
a stacktrace where we end up with arrow_gadget being NULL
despite the conditions for its presence being satisfied.
This commit makes sure we call update_arrow_gadget() whenever
any of the conditions changes. This should fix the reported
crash.
broken from my previous commit about rounded corners, dialogs
doesn't use the "window" node, but the "dialog" node, so use the
.background styleclass in the selectors which is more generic.
1) g_print() can be redirected
2) g_print() does some extra processing, such as character set conversion.
Specifically, on W32 it will detect system codepage via GetACP(),
and will convert UTF-8 output into that codepage, even though
the output should stay unchanged (whether gtk-builder-tool interprets
strings from ui files as UTF-8 is a separate matter).
https://bugzilla.gnome.org/show_bug.cgi?id=765118
When clearing the icon helper, we need to invalidate it. Otherwise the
previous icon keeps lingering along.
This is not relevant inside gtkiconhelper.c where other code causes the
invalidation, but happens when external code calls
_gtk_icon_helper_clear().
https://bugzilla.gnome.org/show_bug.cgi?id=765066
Fixes a couple bugs...
- Pixel font sizes in css would render as point sizes.
- For em font sizes, where the parent size was set and not default, we would
incorrectly convert a pixel value from points to pixels.
We'll always grab the default font size in pixels so we don't keep confusing
things.
Worth noting that gtk css font-size will still behave differently than the
web. Pango interprets font-size differently.
Because of our port of css animation and css transition to
progress tracker, we should not think of animated styles as
immutable objects that can map any timestamp to css values.
Rather, timestamps can correspond to different values depending
on the value of GTK_SLOWDOWN over the course of the animation.
To keep animated styles and style animations totally immutable,
we will not share styleanimations between animatedstyles, and
make a new copy of a styleanimation for each timestamp.
Not the ideal solution for this problem, but in practice leads to
much better performance on lower end hardware.
Stack does a double draw on the first frame of its animation, of
both the old contents (into a cairo surface) and the new contents.
Homogeneous stacks only need to reallocate contents on the first
frame.
On lower powered hardware where our frames will be a good deal
slower than the refresh rate anyway, we can assure a smother
experience by waiting a frame to start tweening where frame duration
will be more consistent.
glade-previewer places a gtkwindow inside another toplevel gtkwindow,
updating the shadow width for the client induces a busy loop where the
parent will grow continuously until it crashes gnome-shell/mutter.
To avoid the loop, do not update the shadow width if not dealing with a
toplevel window.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=761651
A naive way to perform an action on all parent nodes of a given node
could be to do:
while(gtk_tree_model_iter_parent(model, &iter, &iter)) {
/* perform some action on iter here */
}
However, since gtk_tree_model_iter_parent() will initialize the iterator
pointed to by the second parameter before performing the lookup, this
will not work.
Explicitly document this behaviour.
Signed-off-by: Wouter Verhelst <w@uter.be>
https://bugzilla.gnome.org/show_bug.cgi?id=573380
We use a label_sizing_box to make sure the headerbar can always contain
both a title and a subtitle without resizing when showing/hiding either
of them, but we should only do that for the height; the min width of the
label_box can be larger than that of the label_sizing_box.
Commit cdc580463e made it so that
unresizable windows can't be smaller than a set default size but it
lost the logic to ensure these windows remain at least big enough to
comply with their requisition.
https://bugzilla.gnome.org/show_bug.cgi?id=764174
We were missing all of the status directories, and a few sizes.
This was causing us to not find image-missing on systems without
hicolor icon theme (this basically only happens on Windows).
https://bugzilla.gnome.org/show_bug.cgi?id=764378
e8aa9b0440 introduced a new debug mode
that highlights resizes. Unfortunately it has the side effect of
always queueing redraws even when the debug mode is not enabled.
Make the redraw conditional.
While this commit was found to make emacs windows shrink (and it was
reverted in the gtk-3-20 branch for that reason), that was the only
observed breakage, while the reversal broke several of our unit tests.
Closer study of the emacs sources revealed that it does some really
unsupportable things like doing its own X event handling behind GTK+'s
back and freely mixing sizes of GtkWindows and GdkWindows obtained in
various ways. I've filed a bug against emacs with suggestions for how
to avoid the shrinking window, regardless of this commit.
Original commit message:
It seems this branch is not needed anymore. It was originally added in
1999 to support gtk_widget_realize(), but all those reasons seem
obsolete today.
Instead just call gtk_widget_realize().
If you end up at this commit when bisecting:
There is no bug that made me remove this code, it was purely meant to be
cleanup / dead code removal. I seem to have introduced a new bug or
bisecting wouldn't have let you here. So it seems we should just revert
this commit.
Since we are really only interested in the center point of the
slider allocation, the pre-computed slider geometry is perfectly
fine, just use it always. This avoids the complication with
gadget visibility.
The slider gadget may be turned invisible as side-effect of
gtk_range_calc_slider(). If that happens,
gtk_css_gadget_get_content_allocation() returns { 0, 0, 0, 0},
which leads us to calculate a negative allocation for the highlight
node. Avoid this, by just reusing our already calculated slider
allocation in this case (it is not technically the same as the
content, allocation, but the difference hardly matter here.
https://bugzilla.gnome.org/show_bug.cgi?id=764022
As the elements in the enum are not explicitly numbered, inserting an
element between some other elements shall change the values of elements
after the insertion. So append the new element at the end.
Anyway, no code should rely on the position of an element in an enum.
https://bugzilla.gnome.org/show_bug.cgi?id=763850
Some other widget might have mapped and raised another child window of
the toplevel in the meantime, causing the popover window to be covered.
Raise the popover window to avoid the issue.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=763627
The trash is monitored for state changes - going from empty to non-empty and the
other way round. Monitoring is done by handling change signals from a regular
file monitor. On each signal, an enumeration of the trash contents is started in
order to see if it is empty or not. This causes issues when many files are
trashed, because the gvfs trash backend is flooded with enumeration requests,
resulting in CPU usage spikes. In order to fix this, the "item-count" attribute
of the trash should be queried instead.
Replace asynchronous enumeration with asynchronous information query and update
the trash state based on the "item-count" attribute. Emit state change signal
only when the state actually changes.
https://bugzilla.gnome.org/show_bug.cgi?id=763600
When loading a per-theme settings.ini file, look for it in
the same directory where we found the gtk.css file for the
theme. Previously, we were always looking in
$prefix/share/themes/THEME/gtk-3.0/, even if the css was
loaded from somewhere else.
https://bugzilla.gnome.org/show_bug.cgi?id=641354
With this change, we now look in
$XDG_DATA_HOME/themes/THEME/gtk-3.x
$HOME/.themes/THEME/gtk-3.x
$XDG_DATA_DIRS/themes/THEME/gtk-3.x
GTK_DATA_PREFIX/themes/THEME/gtk-3.x
https://bugzilla.gnome.org/show_bug.cgi?id=641354
When animating, we might be changing the size allocation of the previous
stack child. However, we were not querying the size in the process
meaning you would often see warnings about allocating the size without
knowing what it should be.
This simply adds an innocuous size request, since responding to last_child
sizing requests is not all that critical in the transition.
https://bugzilla.gnome.org/show_bug.cgi?id=763900
This isn't an issue at the moment. Only exporting to a file can fail
by setting by setting an error and it happens to correctly return
GTK_PRINT_OPERATION_RESULT_ERROR regardless of this code.
Still, let's make this block of code more correct to prevent future
changes from introducing broken behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=763731
We've changed our API here; what these applications are doing
used to be fine. Don't make users suffer for this by spamming their
logs in a stable release. We'll keep the warning in master.
https://bugzilla.gnome.org/show_bug.cgi?id=763796
backdrop wasn't in the mix, added and adjusted other widgets
styling not to be overridden by it when not needed.
Spotted a typo making the backdrop base color white in the process.
Some applications set both a default size on their gtk window and a size
request on the corresponding gtk widget.
Until now, the default size was ignored for fixed size windows, so this
had no effect and remained unnoticed, but with the recent change for
client-side decorations, the default size is now used even for fixed size
windows, which can cause the resulting fixed size window to be much
smaller than expected with the size request.
For fixed size windows, if we have both a size request and a default
size set, prefer the size request as before.
https://bugzilla.gnome.org/show_bug.cgi?id=763749
if (orientation) doesn't make a lot of sense but C doesn't complain and
instead evaluates orientation to TRUE for GTK_ORIENTATION_VERTICAL
(since that's 1), thus inverting the value sizes.
commit c3dc0d80f1 fixed the behavior of
GtkContainer widgets requesting an IMMEDIATE resize-mode.
However, GtkWindow has been stomping on resize-mode during realize()
since commit addcc64b9c. The combination
of factors that led to this not being a visible problem during all this
while is uncertain, but this now causes the Shell to continuously try to
relayout its ShellEmbeddedWindow (a GtkWindow subclass).
This commit separates the resize-mode as set internally by GtkWindow
from the one set with the external API, so that GtkWindow only changes
it when it had not been set before by the subclass.
https://bugzilla.gnome.org/show_bug.cgi?id=763650
The implicit grab may be finished so the pointer lies on top of the other
scrollbar, in this case one scrollbar should lose the hovering state, and
the other should gain it. So we must check for proximity in both indicators.
Besides the ::drag-failed handling in order to trigger the window creation
hook, add some handling of the application/x-rootwindow-drop mimetype, so
the same effect is achieved if the tab could be dropped in a destination
accepting this mimetype.
https://bugzilla.gnome.org/show_bug.cgi?id=763387
This makes toplevels pseudo-transparent wrt this mimetype, so if
the drag source offers this mimetype and not another that was
managed by the destination-side widget hierarchy, the window will
be an acceptable target for this mimetype, allowing it to trigger
whatever is meant to in the source side.
https://bugzilla.gnome.org/show_bug.cgi?id=763387
Don't make the popup follow the slider while it is open; that
makes interaction with it unnecessarily hard. Also move all the
popups inwards a little bit, so they are not flush with the
scales, which looks untidy.
https://bugzilla.gnome.org/show_bug.cgi?id=763380
We were not taking the scrollable borders into account when
requesting size for the scrolled window, which could lead
to underallocating the scrollbars at size allocation time
when we *did* take the borders into account.
This is most notable with treeviews, where we have the
headers as borders, and was causing the treeview-crash-too-wide
reftest to fail.
The tree walk holds a tree iter, which will become invalid
when we either remove the row that it points to or remove
all rows.
Reset the tree walk in those cases to avoid a crash that
was pointed out by Bastien Nocera.
This widget is a bit unusual in that it is a box that acts as
the drop target, while the visible content is a child of the box.
Propagate :drop(active) to the child to make the highlight visible.
We previously considered any click inside the trough if it
hit an area that the slider might cover. Bring this behavior
back; the trough of scales is otherwise just too narrow to
hit easily with a click.
Consider this bug:
1. Open a file chooser; switch it to $HOME
2. Start typing "~/Dow" with some file that *does* exist in your $HOME
3. Delete the inline-completion selection (e.g. the "nloads" after "~/Down").
4. While you are at "~/Dow_" hit Tab. No completion will occur.
This happens because of the following.
Say the GtkFileChooserEntry is in the process of loading $HOME,
because _set_base_folder() was called. If the entry contains no text,
then the FULL_PATH_COLUMN of the file system model will be set to
unprefixed filenames from $HOME, like
.ssh/
Documents/
Downloads/
somefile.txt
Later we avoid reloading the folder if g_file_equal(old_folder, new_folder).
However, the FULL_PATH_COLUMN gets populated in completion_store_set()
out of the actual filenames that GIO returned, plus the chooser_entry->dir_part.
If the user starts typing "~/Dow" then dir_part changes to "~/", *but*
the folder won't be reloaded since it is also $HOME. However, the completion
machinery assumes that FULL_PATH_COLUMN will contain prefixed entries like
~/.ssh/
~/Documents/
~/Downloads/
~/somefile.txt
So, we add an invariant that chooser_entry->dir_part and
chooser_entry->current_folder_file must change at the same time, and
must not get out of sync: If any of them changes, then the
completions are regenerated.
The adjustment double properties allow values from -G_MAXDOUBLE
to G_MAXDOUBLE, which leads to overflow when calculating
max - min / 10. To avoid that, simply use a fixed page_size of 1.0.
The contents node was not getting state updates at all, and the
trough node was missing some state updates as well, because we
were not calling update_trough_state() in all the places where
it is needed.
...hopefully when needed.
By default I assume a left hand side placement on ltr languages
and the opposite in rtl, for other placements left/right style
classes can be used.
Under Wayland, popovers use subsurfaces, and we end up getting
configure events for these delivered to the toplevel they're in.
To avoid triggering resize loops, ignore configure events that
are not for the toplevel window itself.
https://bugzilla.gnome.org/show_bug.cgi?id=763351
The default value for the double-click key in the
org.gnome.settings-daemon.peripherals.mouse schema is 400.
Use the same value as the declared default for the
gtk-double-click-time GTK+ setting, to avoid pointless
differences in corner cases.
https://bugzilla.gnome.org/show_bug.cgi?id=720950
The sidebar in the object page was using up more space than it deserves.
Replace it with a combo box in the subheader. Now that we have more space,
put the CSS node tree and the style properties in the same page again.
And add a default color like it was before.
This also fixes other issues with scale values interacting with scale
mark labels, which were buggy at least since 3.18.
When opening the value editor for any GtkAdjustment properties
in the inspector, the popover stretches out for miles, since
it reserves enough space to draw MAXDOUBLE. This is not useful.
Limit the space we reserve to 8 digits.
We're seeing loops where the size of some status icons constantly
dithers between 24 and 25. Since I couldn't track down exactly
where the one extra pixel comes from, just stop reacting
to single-pixel size changes.
https://bugzilla.gnome.org/show_bug.cgi?id=758893
We used to always make the labels in message dialogs selectable,
which is a bit problematic wrt. to keynav - the label can
unexpectedly 'turn blue', which irritates some people.
With the new gtk-keynav-use-caret setting, we can now only
make the labels selectable when it is required for accessibilty
reasons.
When changing tool button contents according to the toolbar-style
property, we need to update the style classes to ensure that the
visual style matches.
https://bugzilla.gnome.org/show_bug.cgi?id=760560
gnome-session takes an "app id" for client and inhibitor registration,
This app id is supposed to be a desktop file id (complete with the
.desktop extension), but gtk+ currently uses g_get_prgname ().
This commit changes gtkapplication to use the application id instead,
which is a much more natural fit. gnome-session is going to be updated
to stop using the .desktop extension, too, so everything is consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=763106
We weren't using the open flags on the other locations signal, which
makes impossible for applications like nautilus to act in the same
way that for any other location where the user can choose between
opening in the current view, in a new window or in a new tab.
Add a new signal with an open flags parameter and deprecate
the other-location signal.
https://bugzilla.gnome.org/show_bug.cgi?id=754743
One important aspect of non-resizable windows that we need to preserve
is that they shrink when their content requires less size.
Previous changes to allow the default size to be applied to fixed size
windows would have prevented all fixed size windows from shrinking when
their content requires less size.
Allow shrinking for fixed-size windows unless a default size was
specified.
https://bugzilla.gnome.org/show_bug.cgi?id=762974
It does not make sense to pass a for_size into the size allocation
machinery that is smaller than the min-size in that direction.
Warn if it happens, so we can track it down when it occurs.
added a min-height/width compensation too when in fine-tune mode,
so scale with marks and no labels doesn't make the scale node grow
when in fine-tune.
added a scale node padding compensation for the trough growth in
fine-tune mode, so now the scale node doesn't grow anymore when
mark labels are present.
We were failing to do that, leading to progress not disappearing
anymore after it was initially shown, in the gtk3-widget-factory
entry progress example.
If animations are disabled, the only difference we need to make is that
we don't have to start the transition. Size requests should remain the
same.
https://bugzilla.gnome.org/show_bug.cgi?id=762996
Previous commit to address the default size introduced a regression
with fixed size windows if no default size was given, the resulting
window would end up much smaller than its actual content.
kind of a workaround, this approach is pretty unmaintainable, I
hope we'll get a CSS property for spacing directly on the parent
container (a toolbar in this particular case).
See https://bugzilla.gnome.org/show_bug.cgi?id=762397
If a window is not resizable (with gtk_window_set_resizable ()),
the size given with gtk_window_set_default_size() is ignored.
The solution to this would be to use gtk_widget_set_size_request() but
that's a GtkWidget API and therefore does not take into account the
client side decorations when in use with GtkWindow.
Refactor the code so that gtk_window_set_default_size() (which is a
GtkWindow API) gives the expected result on non-resizable windows as
well.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762974
Will make GTK+ more willing to use CSD for all normal windows without
being asked to. Lack of desktop composition will, of course, prevent
it from using CSD (in theory).
GTK_CSD=0 will force CSD to NOT to be used whenever
possible (i.e. in cases where CSD is not specifically requested
by a window, by design).
https://bugzilla.gnome.org/show_bug.cgi?id=759899
When a gtk_widget_queue_allocate() on some widget increases the clip,
widget->parent's clip was not updated. This appraoch naively just
unions widget's new clip with widget->parent's clip.
This of course only works if widget and parent share the same GDK
window. In the cases where they don't we can't do anything and need a
better fix.
Fixes label-text-shadow-changes-modify-clip.ui reftest.
The check is not working for many containers anymore as they are not the
direct parents of their children. We want to allow this behavior in more
places.
We create and destroy gadgets inside the levelbar hierarchy here,
and if we don't explicitly remove their CSS nodes from the parent,
they stick around.
