This fixes a GTK+ 3.0 regression. In GTK+ 2, the render method
on GtkCellRenderer had a expose_area parameter, typically set to
cell_area. This parameter was used for clipping cell content to be
rendered to the cell area (and thus clipping to within the focus
rectangle). During the rendering clean up this parameter was removed
and no clipping put back into place.
Since expose_area was usually equal to cell_area anyway, it does not make
sense to reintroduce the expose_area parameter. Instead, we do clipping at
two levels:
- in gtk_cell_renderer_render() we clip to background_area. We cannot
clip to cell_area here because we want to allow cell renderers to
render in the background area (e.g. background color/effect).
- cell renderers should clip to clip_area when rendering cell
content individually (as they had to individually clip to expose_region
before).
Check (x, y) is inside background area. If yes, continue processing
and clamp the coordinates into cell area. This way we will properly
handle getting a cell (which is only used for setting the focus cell)
for clicks in the indentation area (in LTR and RTL mode) and clicks
in the focus rectangle area in case focus-line-width is large.
The cell's focus rectangle is located around the cell's aligned area.
To get to the correct coordinates for this rectangle, we have to subtract
focus_line_width from the found aligned_area.
Size requests should only ever need to return the screen's width/height
and max. This way, potentially large widgets (tree view or icon view)
don't need to do so many computations, but can stop when their computed
size has reached the screen size.
When setting no shape on an unshaped window, nothing changes,
so return early instead of recomputing lots of visibility
information.
Pointed out by Owen Taylor in bug 637156.
This function will enable events for all devices of a given
GdkInputSource, either these available at the time of the call,
or these that are connected in the future.
The xi2 device manager now handles slaves being detached and/or
attached to a master.
gdk_device_list_slaves() has been added so it is possible to
know how slaves relate with masters. The other backends (X11 and not)
don't neeed to to anything special here since their hierarchy is
fully flat.
When the slave device changes, the master takes the shape of the
new one, modifying its axes, this signal is more useful to catch
this situation than the n-axes property
This function may be used to know the hardware device that triggered
an event, it could resort to the master device in the few cases there's
not a direct hardware device to relate to the event (i.e.: crossing events
due to grabs)
gdk_enable_multidevice() has been replaced with gdk_disable_multidevice(),
so applications may call that function if they want to go back at the
previous behavior.
There would be usually little reasons to call that function, unless the
application is doing X calls itself that count on old fashioned core
devices.
