[l10n] Updated Catalan (Valencian) translation

[l10n] Updated Catalan translation

Fix a typo in the README

GtkContainer: fix disconnection from frame clock

We need to disconnect the frame clock when we unrealize (at which
point the old clock is still alive) not in destroy(). Since there
is no common unrealize for containers, trigger this from GtkWidget.

GtkTickCallback: document use of G_SOURCE_CONTINUE/REMOVE for return value

Document that G_SOURCE_CONTINUE and G_SOURCE_REMOVE are the preferred
return values from a tick callback.

Don't compress motion events for different devices

A switch of device may be significant for an application, so don't
compress motion events if they are for different devices. This simple
handling isn't sufficient if we have competing event streams from
two different pointer events, but we don't expect this case to be
common.

Ignore window manager protocol messages for destroyed windows

If we get, for example, a _NET_WM_FRAME_DRAWN or _NET_WM_PING
message on a destroyed window, then we should just ignore it.

Small documentation fixes for frame synchronization

Found by Benjamin Otte

gdk_frame_clock_get_frame_time(): use gint64 for time

Merge with Merge GdkFrameHistory into GdkFrameClock

GdkFrameClock: update documentation

GdkFrameTimings: add documentation

GdkFrameClock: Clean up the public API

* remove gdk_frame_clock_get_frame_time_val(); a convenience
  function that would rarely be used.
* remove gdk_frame_clock_get_requested() and
  ::frame-requested signal; while we might want to eventually
   be able to track the requested phases for a clock, we don't
  have a current use case.
* Make gdk_frame_clock_freeze/thaw() private: they are only
  used within GTK+ and have complex semantics.
* Remove gdk_frame_clock_get_last_complete(). Another convenience
  function that I don't have a current use case for.
* Rename:
  gdk_frame_clock_get_start() => gdk_frame_clock_get_history_start()
  gdk_frame_clocK_get_current_frame_timings() => gdk_frame_clock_get_timings()

GdkFrameTimings: strip down to a minimal public API

Since we're not exporting the ability to create your own frame
clock for now, remove the setters for GdkFrameTimings fields.
Also remove all setters and getters for fields that are more
about implementation than about quantities that are meaningful
to the applcation and just access the fields directly within
GDK.

Merge GdkFrameHistory into GdkFrameClock

Now that GdkFrameClock is a  class, not interface, there's no real advantage
to splitting the frame history into an aggregate object, so directly
merge it into GdkFrameClock.

Change GdkFrameClock from an interface to a class

It's unlikely that anyone will want to have, say, a GtkWidget that
also acts as a GdkFrameClock, so an abstract base class is as
flexible as making GdkFrameClock an interface, but has advantages:

 - If we decide to never make implementing your own frame clock
   possible, we can remove the virtualization.
 - We can put functionality like history into the base class.
 - Avoids the oddity of a interface without a public interface
   VTable, which may cause problems for language bindings.

GdkWindow: make the frame clock an inherent property of the window

Instead of making the frame clock a settable property of a window, make
toplevel windows inherently have a frame clock when created (getting
rid of the default frame clock.) We need to create or destroy frame
clocks when reparenting a window to be a toplevel, or to not be a
toplevel, but otherwise the frame clock for a window is immutable.

Add gtk_widget_add_tick_callback(), remove GtkTimeline, etc.

Add a very simple GtkWidget function for an "tick" callback, which
is connected to the ::update signal of GdkFrameClock.

Remove:

 - GtkTimeline. The consensus is that it is too complex.
 - GdkPaintClockTarget. In the rare cases where tick callbacks
    aren't sufficient, it's possible to track the
    paint clock with ::realize/::unrealize/::hierarchy-changed.

GtkTimeline is kept using ::update directly to allow using a GtkTimeline
with a paint clock but no widget.

GdkX11DeviceManagerXI2: handle focus events not on a known window

If we get a focus event for a X window we don't recognize, just
ignore it and avoid a g-critical when
_gdk_device_manager_core_handle_focus() is called with a NULL window.

Reimplement _NET_WM_SYNC_REQUEST inside X11 backend

Deprecate gdk_window_enable_synchronized_configure() and
gdk_window_configure_done() and make them no-ops. Implement the
handling of _NET_WM_SYNC_REQUEST in terms of the frame cycle -
we know that all processing will be finished in the next frame
cycle after the ConfigureNotify is received.

Fix up for newer draft of wm-spec

* 64-bit quantities are consistently ordered low-32-bits / high-32-bits
* data.l[4] in _NET_WM_SYNC_REQUEST indicates which counter to update

video-timer: add simple example of PLL-style clock adjustment

The first version of the video-timer simply played back the video
according to the wall clock, and showed each frame at the neareste
presentatin time. But an alternative strategy for playing back
video is that if the frame-rate is an integer-divisor of the
display refresh rate, or very close to that, is to change the playback
speed to complete avoid frame drops and changes in latency.
(This would require resampling audio if present.)

Demonstrate this technique by adding a --pll option to the
video-timer demo.

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

video-timer: add a test case for display at a constant frame rate

Add a test case that simulates the timing operaton that goes on
when showing a constant frame rate stream like a video - each
frame is shown at the VBlank interval that is closest to when it
would ideally be timed.

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

Add gdk_frame_timings_get_predicted_presentation_time()

For an operation like synchronizing audio to video playback, we need to
be able to predict the time that a frame will be presented. The details
of this depend on the windowing system, so make the backend predict
a presentation time for ::begin-frame and set it on the GdkFrameTimings.

The timing algorithm of GdkFrameClockIdle is adjusted to give predictable
presentation times for frames that are not throttled by the windowing
system.

Helper functions:

 gdk_frame_clock_get_current_frame_timings()
 gdk_frame_clock_get_refresh_info()

are added for operations that would otherwise be needed multiple times
in different locations.

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

Add GDK_DEBUG=frames

Add a debug option to print out detailed statistics about each frame drawn.

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

animated-resizing: enhance output

Show the average and standard deviation of the latency in addition to
the frame rate. Add options to print the output in machine-readable form,
and to control the frequency and total number of statistics that will be
output.

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

animated-resizing: make circle size a #define

Clean up the code with a #define for circle size. This also allows
determining we're throttled by number-of-requests or number-of-pixels.

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

GdkWindowX11: Communicate gdk_frame_timings_get_slept_before() to the compositor

We want the compositor to do different things for frames where
"slept before" is TRUE. Communicate to the compositor that
frame is a no-delay frame (slept_before=FALSE) by ending the frame
by increasing the counter value by 1, and that the frame is a
normal frame (slept_before=TRUE) by increasing the counter value
by 3.

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

Add gdk_frame_timings_get/set_slept_before()

Add functions that tell us whether the main loop slept before we drew
a frame. Blocking with the frame clock frozen doesn't count as sleeping.
We'll use this to advertise to the compositor whether we
are drawing as fast as possible (and it should do the same) or timing
frames carefully (and it should do the same.)

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

GdkFrameClockIdle: don't start the tiemout/idle when in a frame

Don't start the idle if we're in the middle of painting a frame -
this will prevent us from getting the timing right when starting
the idle after the frame.

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

Add GdkFrameHistory and GdkFrameTimings, handle _NET_WM_FRAME_TIMINGS

In order to be able to track statistics about how well we are drawing,
and in order to be able to do sophisticated things with frame timing
like predicting per-frame latencies and synchronizing audio with video,
we need to be able to track exactly when previous frames were drawn
to the screen.

Information about each frame is stored in a new GdkFrameTimings object.
A new GdkFrameHistory object is added which keeps a queue of recent
GdkFrameTimings (this is added to avoid further complicating the
implementation of GdkFrameClock.)

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

GdkWindowX11: Only start a frame when we emit damage

Instead of communicating the start of a frame to the window manager
as soon as we begin a frame, start a frame only when we know we've
actually created damage to the contents of a window.

(This uses cairo_set_mime_data() as a notification mechanism - a
clever suggestion from Uli Schlachter.)

The advantage of this is that we aren't forcing the compositor to
do a frame cycle and send _NET_WM_FRAME_DRAWN - depending on how the
compositor is structured that might either cause it to do extra
work or it might send _NET_WM_FRAME_DRAWN early and upset frame
timing.

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

GdkDisplay: handle multiple calls to _gdk_display_pause_events()

Since events can be paused independently for each window during processing,
make _gdk_display_pause_events() count how many times it is called
and only unpause when unpause_events() is called the same number of
times.

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

gdk_display_get_event: don't unqueue events from the windowing system when paused

Unqueuing events from the windowing system when paused could result
in weird reordering if event filters resulted in application-visible
behavior. Since we now resume events when the frame clock is frozen,
we now no longer count on low-level event handling running while
event handling is paused.

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

GdkFrameClock: Reverse order of resume-events and afterpaint

Keeping events paused after the end of a frame put us in a
weird state where we had to process and queue events - so that
we would get the message from the compositor - but not deliver
them. Instead resume events before ending the frame.

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

Compress motion synchronized with the paint cycle

When we have pending motion events, instead of delivering them
directly, request the new FLUSH_EVENTS phase of the frame clock.
This allows us to compress repeated motion events sent to the
same window.

In the FLUSH_EVENTS phase, which occur at priority GDK_PRIORITY_EVENTS + 1,
we deliver any pending motion events then turn off event delivery
until the end of the next frame. Turning off event delivery means
that we'll reliably paint the compressed motion events even if more
have arrived.

Add a motion-compression test case which demonstrates behavior when
an application takes too long handle motion events. It is unusable
without this patch but behaves fine with the patch.

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

GtkScrolledWindow: use GdkFrameClock for kinetic scrolling

Use GdkFrameClock when animating scrolling via touch, rather
than a timeout.

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

Add a test of an animated resizing window

Add a test of a window with an animated size and contents. The
test accepts load factor command line argument to see how things
work as the drawing of the content requires more GPU resources.

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

GtkTimeline: Wrap around the progress correctly when looping

When we have a looping animation for something like an angle,
we need to make sure that the distance we go past 1.0 becomes
the starting distance for the next frame. This prevents a
stutter at the loop position.

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

GtkTimeline: introspection fixes, add :progress-type property

Fix up introspection information for GtkTimeline, install the
header has a public heaer, and add the property for :progress-type.

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

Hook GtkTimeline up to GdkFrameClock

Use GdkFrameClock for the timing of GtkTimeline. This require the
user to provide either a GtkWidget or a GdkFrameClock when creating
the timeline. The default constructor now takes a GtkWidget. If you
want to create a GdkFrameClock without a widget, you need to use
g_object_new() and pass in a GdkFrameClock and GdkScreen.

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

GtkTimeline: remove settable FPS

The frames-per-second for an animation should be controlled by how
fast we can process frames and the the frame-rate of the display; it's not
a meaningful app-settable property.

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

Add back GtkTimeline

Add back the GtkTimeline code that previously made private and
then removed. It will be hooked up to GdkFrameClock. This commit
purely adds the old code back.

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

Add an UPDATE phase and GdkFrameClockTarget, use for GtkStyleContext

Switch GtkStyleContext to using GdkFrameClock. To do this, add a new
UPDATE phase to GdkFrameClock.

Add a GdkFrameClockTarget interface with a single set_clock() method,
and use this to deal with the fact that GtkWidget only has a frame
clock when realized.

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

GdkFrameClockIdle: add throttling to 60fps

If the backend is throttling paints, then the frame clock will be
frozen at the end of the frame. If not, then we need to add throttling,
so wait until 16ms after the start of the frame before beginning the
next frame.

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

GdkWindowX11: start off with an odd frame-counter value

By starting with an odd frame counter value, we make the mapping
and initial paint of the window an atomic operation, avoiding
any visual artifacts from an unpainted window.

Possible improvement: start the frame when doing gdk_window_show(),
so that the same improvement occurs for windows that were previously
shown and are being mapped again.

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

Freeze the update counter for unmapped windows

When a window is unmapped, freeze its frame clock. This avoids doing
unnecessary work, but also means that we won't block waiting for
_NET_WM_FRAME_DRAWN messages that will never be received since the
frame ended while the window was withdrawn.

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

Use _NET_WM_FRAME_DRAWN to synchronize frame drawing

As part of the extended _NET_WM_SYNC_REQUEST_COUNTER protocol,
we get a _NET_WM_FRAME_DRAWN message for each frame we draw. Use this
to synchronize the updates we are doing with the compositing manager's
drawing, and ultimately with with display refresh.

We now set the sync request counters on all windows, including
override-redirect windows, since it is also useful to do synchronized,
atomic updates for such windows.

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

Switch to an extended form of _NET_WM_SYNC_REQUEST_COUNTER

By exporting two XSync counters on a toplevel window, we subscribe
to an extended form of the _NET_WM_SYNC_REQUEST_COUNTER protocol,
where the window manager can initiate an atomic frame, as previously,
but the application can also do so by incrementing the new counter to
an odd value, and then to an even value to finish the frame.

See:
https://mail.gnome.org/archives/wm-spec-list/2011-October/msg00006.html

The support for 64-bit integers that GLib requires is used to
simplify the logic.

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

GdkFrameClock: add freeze/thaw

Add the ability to freeze a frame clock, which pauses its operation,
then thaw it again later to resume.

Initially this is used to implement freezing updates when we are
waiting for ConfigureNotify in response to changing the size of
a toplevel.

We need a per-window clock for this to work properly, so add that
for the X11 backend.

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

GdkFrameClock: Make the phase explicit when requesting the frame

Instead of having gdk_frame_clock_request_frame() have
gdk_frame_clock_request_phase() where we can say what phase we need.
This allows us to know if we get a frame-request during layout whether
it's just a request for drawing from the layout, or whether another
layout phase is needed.

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

Use GdkFrameClock for relayout

Add a ::layout signal to GdkFrameClock and use it instead of an idle
handler to drive the restyling and relayout of containers.

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

Add GdkFrameClock

Add an object GdkFrameClock that we associate with a GdkWindow.
This tracks when the window needs to be repainted, and will also
be used for other operations in the future like relayout and
updating animations.

Based on a patch from Havoc Pennington:

 https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00004.html

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

GdkDisplayX11: Don't use substructure events in internal accounting

We may receive events because SubstructureNotifyMask has been selected
for the root window. (Most likely, this would occur because GTK+
is being used inside a window manager like Metacity or Mutter.)
This can confuse various types of internal accounting, so detect
such events and comprehensively ignore them for GDK's internal
purposes. We still need to generate GDK events for these cases
because you can select for substructure events with
GDK_SUBSTRUCTURE_MASK.

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

gtk3-demo: Fix up resource handling

We're not loading css files via resouce uris, as we want
to support editing, so we need to use absolute references
to any included resources.

Add new GtkIconInfo calls to the reference docs

Update README.in for the GtkIconInfo type change

GtkIconTheme: Add async versions of symbolic icon loaders

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

GtkIconTheme Don't leak pixbuf in symbolic icon cache

We need to unref the pixbuf we just put in the cache, because
symbolic_pixbuf_cache_new takes a ref.

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

Add gtk_icon_info_load_icon_async

This lets you asynchronously load icons. We need this for gnome-shell
to replace its current non-threadsafe use of GtkIconTheme.

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

Make GtkIconInfo a GObject

This is necessary in order to have async operations on it.
All the old copy/free functions keeps working, and g_boxed_copy on a GObject
also works, so this should be mostly compatible, but techncally its a minor
ABI break since the GType changes fundamental type. Changes like this has
happened before though, like with GVariant becomming its own fundamental
type.

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

Revert "Updated Malayalam Localization"

This reverts commit bff9de1adcb4ddef53d52fb1f296be35c2cda16b.

Updated Malayalam Localization

wayland: Add support for output device removal

Since we only receive an object id for the removed object we must try and
remove that from the list of devices based on that id.

wayland: Add basic multiple output support

Store the wl_output pointer within the the GdkWaylandMonitor structure.

filechooserbutton: Add tests for SELECT_FOLDER mode with the dialog active

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooser: Oops, cancel a file operation that was missing

In addition, remove a list of pending_cancellables that was no longer being used.

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooserbutton: Add a battery of tests for GtkFileChooserButton

These are generic tests that can test the button in all of its modes,
instead of hand-written tests for each combination.

Some tests fail currently.

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooserbutton: In SELECT_FOLDER mode, consider an empty selection to mean current_folder

If the user didn't explicitly select anything, BUT the file chooser button has
a current_folder set, do the same as what GtkFileChooserDefault would do:
return the current folder as the selection.

This makes the tests in tests/filechooser pass!

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooserbutton: Keep track of the current_folder while the dialog is inactive

This is analogous to keeping the selection while the dialog is inactive.

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooser: Fix cast

filechooserbutton: Remove unused function prototypes

filechooserbutton: Restore to an empty previous selection properly

If no file was originally selected in the GtkFileChooserButton, then its
internal dialog is brought up and cancelled, then we need to restore the
selection back to none.  GtkFileChooser, though, doesn't like to
select a NULL file, so call _unselect_all() in that condition.

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooserbutton: Add test for setting/getting the current folder; currently fails

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooserbutton: Fix preserving the selection after cancelling the dialog

The button's underlying file chooser dialog should not be used to store the file selection
while the dialog is unmapped.  Instead, the file chooser button now stores the
selection itself.

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooser: Remove some unused code

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooserbutton: Simplify the code to preserve the selection while the dialog is running

It used to fetch a possibly multiple selection from the GtkFileChooserDialog, and then
pick just the first item from the selection list.  But since GtkFileChooserButton
operates in single-selection mode only, it can simply use gtk_file_chooser_get_file()
instead.

Also, the right way to reset the selection for GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER
is with gtk_file_chooser_select_file(), not with _set_current_folder_file().

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooserbutton: Don't set a starting folder in the underlying dialog

Let the dialog decide by itself.

filechooser: Test canceling the dialog inside a GtkFileChooserButton

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooser: Add a couple of tests for GtkFileChooserButton; they fail now

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooser: Do tests with g_assert_cmpstr(), not g_assert(passed)

This lets us see exactly what failed, instead of just seeing a boolean error value.

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooser: Move some of the tests to GTestDataFunc

This code came from a home-grown testing mechanism, which didn't aggregate tests
into a test suite; it just ran them one by one.  Here we move some of that machinery
to GTestDataFunc for more flexibility in running tests.

Signed-off-by: Federico Mena Quintero <federico@gnome.org>

filechooser: Get the filechooser tests to build

Some are ifdef-ed out with BROKEN_TESTS, but at least the tests will compile for now.

Added scroll and touch events to GtkToolPalette

filechooser: follow the gtk-recent-files-enabled GtkSetting

Avoid showing the Recent files entry if the setting is FALSE.

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

recentmanager: follow gtk-recent-files-enabled GtkSetting

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

settings: add a gtk-recent-files-enabled GtkSetting

Backed by an XSetting, so g-s-d can set it according to the GSettings
value.

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

wayland: Handle wl_output in GdkWaylandScreen

Expose information about outputs in GdkScreen (gdk_screen_get_n_monitors
and gdk_screen_get_monitor_*).

Add opacity_group hack

This adds a way to get the gtk_widget_set_opacity liike behaviour
of retargeting GdkWindows and exposing every child in ::draw, without
actually having an alpha. This is needed if you're doing more complex things
such as cross fading of widgets.

We do this as a hack by using opacity values that round to 255 yet not
really 1.0 in order to avoid having some magical API call for this
mainly internal call.

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

wayland: skip pointer and keyboard events without a surface

Pointer and keyboard events can be received after the surface has been
destroyed, in which case the surface will be NULL.

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

gdkwindow: don't use last_slave for the source device if it is NULL

Some backends do not have slave devices, which means last_slave may be
NULL. Use the current device as the source device if last_slave is NULL
when synthesizing a crossing event.

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

wayland: set the "transient inactive" flag on tooltip surfaces

This prevents the tooltip surfaces from taking the focus away from the
parent surface.

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

tooltip: set the transient parent when using the Wayland backend

Set the transient parent window on tooltips so that they can be
positioned correctly when using the Wayland backend.

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

Update Arabic translations

gtkcellrenderertext: Sink floating entry before using as signal argument

Sink the GtkEntry assigned to the private structure of GtkCellRendererText
before signals containing it as an argument are sent out. This keeps
language bindings from sinking the reference and then destroying the entry
when the signal closure is finished.

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

Remove remnants of localization from gtk-demo

gtk-demo isn't localized at this point.
https://bugzilla.gnome.org/show_bug.cgi?id=681578

Clean up the opacity handling

This cleans up the internals but doesn't really change the behaviour.

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

Fix compiler warnings

Remove two unused variables.

Mention the de-facto standard filename extension

GtkBuilder files are commonly named .ui - mention that in the
docs.
https://bugzilla.gnome.org/show_bug.cgi?id=590325

Plug a few memory leaks

The accessibles for icon view items were not properly freed
in all cases.
https://bugzilla.gnome.org/show_bug.cgi?id=683311