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.
