GitLab

If there are already a window state event for a given window queued
when the window state is changed, drop that event and queue a new event
with a changed_mask based on the state before last event that was queue
without compression.

https://bugzilla.gnome.org/show_bug.cgi?id=762468

Apparently, we can get X errors here. Ignore them.
https://bugzilla.gnome.org/show_bug.cgi?id=762907

Fixes bug 763023: in certain circumstances, XRRGetOutputInfo will return
a null pointer.  This commit adds a check to detect and handle this
return value.

This is mostly useful to have focus behave sanely on lack of WM, so avoid
any check there if we're positive there is a WM handling focus.

https://bugzilla.gnome.org/show_bug.cgi?id=677329

The fallback behaviour of get_work_area () divides the
screen width and height by the window scaling factor, but
those values are already scaled down.

https://bugzilla.gnome.org/show_bug.cgi?id=761474

The significant change here is a memory leak fix in init_xrandr15.
The rest of the changes makes init_xrandr13 and init_xrandr15 more
parallel, and simplifies init_multihead.

https://bugzilla.gnome.org/show_bug.cgi?id=762319

With the location entry up in the header bar in save mode, we can
end up with the search model being in use when the user types in
the location entry. In this case, we don't make the Save button
sensitive as we should.

Having two entries in the dialog is somewhat confusing anyway,
so just stop the search when the user starts typing in the location
entry.

https://bugzilla.gnome.org/show_bug.cgi?id=761757

We don't need to make assumptions about which model is currently
used since gtk_tree_selection_get_selection hands us the model.

https://bugzilla.gnome.org/show_bug.cgi?id=761757

Calling _gtk_file_consider_as_remote() with a NULL argument
results in warnings being thrown.

Note that query->priv->location being NULL is a state that does
not seem to be invalid by itself.

This could happen if you do search-as-you-type in a filechooser,
which has a filter that does not match anything *and* the current
"place" selected is "Recent".

https://bugzilla.gnome.org/show_bug.cgi?id=761552

In some situations (no header bar, save mode), hitting Escape
would not do anything because the entry ate the key event.
Fix this by telling the entry to only handle Escape when there
is something to do, such as switching back to the path bar.

https://bugzilla.gnome.org/show_bug.cgi?id=761026

The code for adjusting the center widget allocation in case
of uneven sides never worked right in RTL. This was finally
noticed for tabs with close button, which commonly use a
centered label.

We are no longer setting a margin on the content area, so put
one on the action area itself to prevent the buttons from touching
the edge.

https://bugzilla.gnome.org/show_bug.cgi?id=762315

This reverts commit bfedc3ba.

Too much controversy for this minor improvement.
See https://bugzilla.gnome.org/show_bug.cgi?id=756751

https://bugzilla.gnome.org/show_bug.cgi?id=761838

It does no good to iterate through a series of mime types to call a
function when the eventually-called function,
_gtk_quartz_get_selection_data_from_pasteboard() in this case, gives the
wrong answer and stops the iteration on all but one especially if that
one isn't first.

The one is "image/tiff" and the quartz pasteboard function will return
any image type Quartz knows about for it, so lose the iteration and use
only "image/tiff".

The gtk-query-settings tool was only added in 3.19.x, so we ought not try
to build it here.  Oops :|, ought to check closer before trying to cherry-pick.

Issue reported by Ignacio Casal Quinteiro.

This is the result of the message dialog title change.

Update the README.glade file to use current .ui file
names and locations as example.

This will be used by xsettings-kde to ensure GTK+3.x programs behave
consistently.

https://bugzilla.gnome.org/show_bug.cgi?id=688524

It looks like the gnome-continuous headers haven't quite
caught up yet, so try __NR_memfd_create instead.

If that doesn't work, i'll likely just add in a fallback
code path.

The tmpdir is used for a wide assortment of things, and
can easily fill up. If it fills then desktop will start
crashing with SIGBUS errors.

This commit changes the shm pool allocation code, to use
memfd_create, instead, so the shared memory files will
be anonymous and not associated with /tmp

https://bugzilla.gnome.org/show_bug.cgi?id=761095

Changing the visibility of child widgets in size-allocate does
not work well with out current allocation and layout machinery.
To avoid the visual fallout, just keep the arrow buttons visible
and only change their sensitivity.

https://bugzilla.gnome.org/show_bug.cgi?id=754868

When using the color chooser in editor mode,
gtk_color_chooser_set_rgba need to be propaged
to the editor

https://bugzilla.gnome.org/show_bug.cgi?id=761005

It might have changed (eg. after a row being expanded, and the child
rows revalidated), so just update it here based on the last pointer
position.

Based on a patch by Maxim Reznik <reznikmm@gmail.com>

https://bugzilla.gnome.org/show_bug.cgi?id=760891

As pointed out in https://bugzilla.gnome.org/show_bug.cgi?id=760964,
we should use the GLib facilities for determining the preferred
location for temporary files.

create_shm_pool doesn't need the width or height, it just needs
the total size.  By passing it in, we're requiring it to redo
stride calculation unnecessarily.

This commit drops the width and height parameters and makes the
function just take the total size directly.

https://bugzilla.gnome.org/show_bug.cgi?id=760897

Right now, we assume the stride for the image surface needs to
be 4 byte aligned.  This is, in fact, true, but it's better to
ask cairo for the alignment requirement directly rather than
assume we know the alignment rules.

This commit changes the code to use cairo_format_stride_for_width
to calculate a suitable rowstride for pixman.

https://bugzilla.gnome.org/show_bug.cgi?id=760897

create_shm_pool unlinks the temporary file a little,
too late. It should be unlinked before ftruncate()
is called for two reasons:

1) if ftruncate fails, the file is currently not
getting cleaned up at all
2) in theory, if the file is public some other process
could muck with it

This commit just moves the unlink call a little higher
up.

https://bugzilla.gnome.org/show_bug.cgi?id=760897

It is not something that can happen normally.
But if it does, we shouldn't crash.

https://bugzilla.gnome.org/show_bug.cgi?id=760680

Calling gtk_widget_propagate_state is enough to queue a resize if
needed

See da7a4089