This also removes the (unimplemented) possibility to change a window to
non-native. This seems generally not very useful, and there are some problems
with it, for instance if two "users" need a window to be native and then
one of the "users" doesn't need it anymore it can't change it back, because
it is unaware of the other reason the window is native.
If a native window or a window with a native subwindow is moved or resized
then the client window moves and implicit paints need to be flushed since
the native window move will copy/overwrite data. This may happen while there
is an outstanding paint if the move is inside an expose event (weird, but
flash embedded in webkit hit this).
Right now we're asserting here, but the right fix is to allow this but
to not flush the parts that are currently in a (non-implicit) paint. This
means we flush all results from previous not-yet-flushed exposes, but not
the ones being drawn.
Add test for EISCONN error when testing whether a connection to CUPS server
is available (#576678 - patch by mark@ecs.vuw.ac.nz).
Signed-off-by: Marek Kasik <mkasik@redhat.com>
Correctly handle conversion to SAVE_TARGETS as a side-effect target
with no side-effect, by returning a zero-sized property of type NULL.
See section 2.6.3 of the ICCCM.
Dup the file chooser entry string because the string may be modified
depending on what clients do in the confirm-overwrite signal and this
corrupts the pointer.
GtkPrintOperation is now able to render multiple pages per sheet by its
own. The most important changes are in these functions:
* increment_page_sequence
* prepare_data
* common_render_page
* print_pages_idle
Patch also changes set of choices for 2 pages per sheet mode when
landscape orientation is used to "Top to bottom" and "Bottom to top".
Previously we would always align the top of the text with the label's allocation-plus-padding.
However, this makes a single-line label inside a GtkButton look badly clipped when the button
has a smaller allocation than its requisition. So, for single-line labels we respect the
alignment even if it doesn't fit within the label's allocation. But for multi-line labels, we
give preference to showing the first line, to give the user some context.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
