Set the Mac key theme when creating a Quartz settings object instead of
having it the default when quartz is enabled.
This keeps compatibility with the GTK2 behavior that the Mac key theme
is not used for the X11 backend, which could now happen for a
multi-backend build.
Previously we were enabling some settings properties only if the X11
backend was enabled. This worked fine with GTK2 where only one backend
was enabled at a time, but now when multiple backends can be enabled,
this does not make sense.
GtkSwitch was listening for Space/Enter keyreleases itself, instead
of providing an 'activate' action signal, like e.g GtkButton. As a
side-effect, this fixes
https://bugzilla.gnome.org/show_bug.cgi?id=643321
In this patch we adress rows_reordered() and row_deleted() callbacks
(since some icon view subclasses manipulate the connected treemodel
from _init()).
We were breaking prematurely out of the loop that goes through
each file that is pending selection; not only does that loop
disable filtering and show hidden files if needed, but it also
selects the files themselves. So we need to walk the whole
list of files.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=643170
The monitor change detection code in _gdk_x11_screen_size_changed() and
process_monitors_change() goes to some length to make sure its only emitted
when there is an actual change to the data visible via the GdkScreen monitors
api.
However, commit 662e69ad added some code that always emits "monitors-changed"
in _gdk_x11_screen_size_changed when we have randr13 and get a ConfigureNotify
on the root window (even though we may already have emitted it in the
RRScreenChangesNotify event!).
As far as I can tell this is due to a comment in the bug referenced by the
commit (https://bugzilla.gnome.org/show_bug.cgi?id=601712#c4) where it says:
This version of the patch changes GdkDisplay to emit "monitors-changed" when
the primary monitor changes (see the change in _gdk_x11_screen_size_changed).
And, if you remove this part of the change the signal is not emitted when just
the primary is changed. However, this is not really the right approach. We
should just also check for if the primary changes in process_monitors_change()
to avoid spurious signal emissions.
https://bugzilla.gnome.org/show_bug.cgi?id=643216
Adding these cases here to cater to icon view subclasses that want to
access icon view APIs from the instance structure initializer instead
of properly waiting for the super class to initialize and adding renderers
from the ->constructor() vfunc.
The last paragraph still seems to be out of place though, as if it
was a previous attempt at an overview or part of some older text
elsewhere.
This overuses the passive too.
This avoids overflow when transforming a large value to a pango unit.
To reproduce the problem:
seq 200000 > test.txt && tets/print-editor test.txt
Then scroll to around line 140.000 to see it (depends on font size of
course).
