These have been introduced in Leopard and default to int and unsigned int.
In 64-bit Snow Leopard they are long and unsigned long. This caused issues
with the getRectsBeingDrawn message which needs a pointer to a NSInteger
(long on 64-bit!) but we passed in an integer. Surprisingly this problem
was visible when compiling with -O0 (segfault), but *not* when compiling
with -O1. Other messages were NSInteger is now needed have also been
adapted.
Since NSInteger and NSUInteger are not available on Tiger, a define
has been added to add typedefs for these when they have not been defined
by the system headers.
(cherry picked from commit b2b70e5a8d)
Add dummy for _gdk_input_window_crossing (). Set both input_window_destroy
and input_window_crossing pointers in the Impl struct.
Reported by John Ralls.
(cherry picked from commit 42ac226877)
Copying to the clipboard is not a buffer mutation, so calling
gtk_text_buffer_begin_user_action() and _end_user_action() is only
confusing apps which connect to these signals in order to build undo
stacks or otherwise track buffer changes. Most likely, these apps
either didn't notice the bugus undo step or simply work around it.
(cherry picked from commit 0a49865ec4)
The default value of the icon-spacing style property was 0, which
is just not good. Themes are of course free to change this anyway.
Bug 610381.
(cherry picked from commit 9ce6db1297)
When the foreign window already has a GdkWindow, we forget to take
an extra references, leading to crashes later on. Patch by
Karl Tomlinson, bug 607061.
(cherry picked from commit beddf67e56)
Patch from bug #591186. It won't have any effect in this branch as the
whole XP-and-later theming code is broken and disabled, but when/if
that is fixed, then this patch should help.
This is exposed by overshooting in a HildonPannableArea. Leaking
a GtkTreeRowReference also means leaking the whole model, since
the GtkTreeModel reference count is increased for each row
reference.
Fixes bug #607770 - Leak in GtkTreeView with HildonPannableArea
(cherry picked from commit 52acceef56)
If e.g. the right edge of the leftmost rectangle is near MIN_INT, and
the left edge of the rightmost rectangle is large then subtracting these
can lead to an integer overflow, making the resultant "width" falsely
positive, thus returning a very wide result instead of the expected
no-intersection result.
We avoid the overflow by not doing the subtraction unless we know the
result will be positive. There are still risks for overflow if x + width
or y + width is larger than MAXINT, but we won't ever overflow for valid
rects now.
This may fix#607687
(cherry picked from commit 3c618f2f1f)
We need to do this because otherwise the implicit button grab for this
(native) window will not deliver the button events not selected for
by this window. This is a problem because non-native child windows may
select using a wider event mask, and we can't emulate these events if we
don't get the native events.
Fixes bug #607508
(cherry picked from commit 3d9d002bed)
Any old cairo_surface referencing the old impl window will be wrong
when we make a window native, so drop it.
This fixes bug #599511
(cherry picked from commit e31a6d1fea)
When a cairo surface is requested for direct window access (i.e. not
when double-buffering) we can't really track when the actual drawing happens
as cairo drawing is not virtualized. This means we can't properly flush
any outstanding window moves or implicit paints.
This actually causes problems with e.g. abiword (bug #606009) where they
draw without double-buffering. If you press down it scrolls the window
and then draws the caret, but the caret drawing does not flush the
outstanding move from the scroll, so the caret gets drawn on the wrong
screen.
We fix this by never allowing either implicit paints or outstanding window
moves on impl-windows where any windows related to it has an outstanding
direct cairo surface. Luckily this is not very common so in practice this
doesn't matter much.
(cherry picked from commit 841fa47715)
It may happen that a window gets destroyed during painting, if so
we should not draw the implicit paint double-buffered pixmap to it
as that will cause a BadDrawable X error.
This fixes bug 600865
(cherry picked from commit f96e51db46)
We were getting our refcounts tangled up when setting drawable clips on
GCs with CSW, leading to a pretty bad pixmap leak. See bug 606143.
(cherry picked from commit d32b061895)
Commit 9e7c91bf83 added a bit too many
LDFLAGS to the build of gtk-update-icon-cache, revert it to only use the
required ones. Bug 605036
(cherry picked from commit 3921834b96)
This adds LDFLAGS everywhere where they were previously pulled in via
other libraries. This is however unsupported by modern linkers.
You can trigger these failures by building with gold (or, I'm told, with
very new ld).
(cherry picked from commit 9e7c91bf83)
Not removing the signal handler caused crashes if the adjustment
survived longer than the scrolled window and still emitted signals. This
could happen inside WebKit.
(cherry picked from commit ff1343a594)
Using X properties on non-toplevel windows is somewhat exotic,
but some people seem to do it, so better to keep it working.
See bug 604787.
(cherry picked from commit 7a9a3077e4)
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=604289
In order to respect this properly, we have to restore the original
behavior by watching a flag to check if the user has already set this.
* gtk/gtkassistant.c: fix the bug by introducing a flag to check for
non-automatic value setting
* tests/testassistant.c: updated the "generous assistant" to permit
quick manual testing of this feature
They don't need double buffer combination since they have no
client-side children, and creating pixmaps for them is risky
since they could disappear at any time.
May fix bug 598476 and 603652.
It may happen when turning a client side window into a native window
that the window, or some of its children with the same native parent
have extension events enabled, and thus have an input window enabled
for the native parent which needs to change as the window is made
native.
We fix this by temporarily disabling extension events on all the affected
windows while we create the native window, and then reenable them afterwards.
This fixes: https://bugzilla.redhat.com/show_bug.cgi?id=544624
(cherry picked from commit 159214173d)
All kinds of lines (lines, segments, arcs, etc) need to take into
account the line properties (width, miter limit, joins, caps, etc)
to get proper damage extents.
This is not really possible to do, but we can make it likely to work
with some ad-hoc estimates.
Fixes bug 603904.
(cherry picked from commit 98a9c5c69a)
The fix in 786b589d95 for the
"Cannot click buttons more than once without moving the mouse cursor"
did not correctly handle setups with multiple screens in one display.
We need to handle the case where the first XQueryPointer returns
a different root window than the default one.
This fixes bug 597386 (agaion)
(cherry picked from commit 48fc0f36c2)
We don't really need to filter these out, it was just a leftover
safety check to not override the GDK_POINTER_MOTION_MASK.
Furthermore when we changed behaviour to not always select for native
pointer motion it is actually wrong. We'll still get normal motion
events for the toplevel which we will emulate as button motion on the
child, but the button motion mask will not be inherited by implicit
grabs which makes us not get any motion events during grabs.
This fixes bug 601473
(cherry picked from commit b509f28559)
Check that the child of a popup menu item is actually a GtkAccelLabel
before setting its "accel-closure" property.
(cherry picked from commit 25a8c7316d)
Although it isnt' allowed by the XEMBED protocol, its possible
that the plug window will be reparented out of the socket without
the socket having done so. See bug 123569. Patch by David Jander.
(cherry picked from commit 84254039f2)
If you add a new ui node that was recently removed it will still be
in the tree, but marked dirty. In this case we previously just used
the old node, which meant it wouldn't get the same position as if
the dirty nodes had been processed first (and deleted) before the
new node was added.
We handle this by detecting this case and reposition the node as if
it was new.
https://bugzilla.gnome.org/show_bug.cgi?id=603128
(cherry picked from commit 7b19640d8f579da5d802d2a6f72128a6f29a5f33)
The previous implementation was modifying the passed in window ("private") rather than deriving information from it. Also the type hints are now forwarded like in the X11 implementation instead of ignored.
The effect of the unfinished client-side-window porting was e.g. a crash with Dia's navigation window which happened to create a window with an apparent depth of zero.
When we just invalidate some area from the app we don't need to clear
windows with no exposure mask, because that wouldn't have happened pre-csw
anyway. Additionally we can avoid such clearing for native windows in cases
where the xserver already did the clearing like on exposes or when resizing
toplevels.
This means we don't fully redraw a GtkSocket when it resizes, thus
avoiding flicker in gnome-mplayer as reported in this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=598050
(cherry picked from commit 9e51c10edc)
Backends that support native window background setting (and that clears
new window areas to this color/pixmap) should set this to true.
Currently only X11 supports this.
(cherry picked from commit 39993f147f)
When moving or scrolling a window with native children, there is no
need to expose the areas that are copied by the windowing system
as part of moving/resizing the native windows anyway.
(cherry picked from commit 4cd5c98942)
Clearing will directly modify the contents of the window, so we need
to flush any outstanding moves or double-buffering.
(cherry picked from commit 8c1ea38d84)
Run gtk_icon_view_layout() if necessary before attempting to paint the
icon view items during an expose event. This ensures all the items have
valid sizes, as some themes don't take kindly to negative dimensions.
Previously the filename would get re-set on the button if one cleared the selection,
as an async cancellable was not getting canceled in that case. Patch with
contributions from Milan Crha <mcrha@redhat.com>
Signed-off-by: Federico Mena Quintero <federico@novell.com>
The root window width and height have already been correctly
initialised in _gdk_root_window_size_init() to cover all monitors, so
don't incorrectly re-initialise using GetSystemMetrics(SM_C[XY]SCREEN)
which only gives the size of the primary monitor anyway. (See MSDN.)
This fixes at least gdk_screen_get_{width,height}() which indirectly
affects at least the positioning of combo box pop-up menus on multiple
monitors.
When GtkMisc padding is set on an image, the optimization for only
recalculating size after a clear() breaks, since the requisition is
not (0, 0). We need a separate 'need_calc' flag.
Zero width/height is unsupported and will magically be turned into one.
For instance, gtk_widget_size_allocate() will eventually do this magic
on the value stored in widget->allocation.
However, if we don't do this magic conversion early, then the value
returned from gtk_window_compute_configure_request() will not be
comparable with whats stored in widget->allocation. (I.E. they will
differ if width or height are zero).
This is dangerous, as we do such a comparison in gtk_window_move_resize().
Currently a change from e.g. 10x1 (current allocation) to 10x0 (new size)
will be expected to produce a ConfigureNotify, when it actually won't,
thus never thawing the frozen toplevel.
Fixes bug #588059
We need to do a final XQueryWindow to get the coordinates inside the
windows rather than in the parent window.
This fixes bug #597386, "Cannot click buttons more than once...", which
failed due to the grab tracking stuff getting the wrong coordinates as
per the above.
Thanks gcc :
gdkwindow-x11.c:1731: warning: passing argument 3 of
'XReconfigureWMWindow' makes integer from pointer without a cast
/usr/include/X11/Xlib.h:1871: note: expected 'int' but argument is of
type 'struct GdkScreen *'
Signed-off-by: Pascal Terjan <pterjan@mandriva.com>
The convention for landscape pages, and required by PostScript
Language Reference Manual, is for landscape printing to rotate user
space 90 degrees counterclockwise. Part of bug 596423
Like the other GtkSettings already registered, these are influenced from
the outside and cannot be properly tested. The defaultvalues test
passes again now.
gtk_tree_model_build_level() always needs to emit row-inserted when
requested, this should not depend on whether the level has a parent
level or a virtual root, which is a check whether or not we need to
reference the node in the child model. Furthermore, we also need
to emit row-has-child-toggled after row-inserted when appropriate.
When gtk_tree_model_filter_row_changed() pulls in the root level, it
must request build_level() to emit signals for this. The refilter
function uses row_changed to process the changes, so build_level() in
the first call to row_changed() might pull in multiple new nodes in this
scenario, for all of these signals need to be emitted. Of course,
build_level() will then also emit the signals for the node row_changed()
is processing, we should not emit a duplicate signal, this is now
accounted for.
Add a unit test for this. For this small functionality to block the
row-changed signal has been implemented, so that we can simulate calls
to the refilter function using the current visible column setup.
_gtk_tooltip_handle_event, which is called for many events in the GTK+
main loop, calls gtk_tooltip_set_last_window, which keeps a weak
reference to the last window we passed through. If the window being
set is the same than the last one there's really no need to update our
weak reference, so add a check for that and exit early.
These event types propagate up the hierarchy anyway, so this means
we avoid setting it unnecessarily. This is especially important
for button press event, since only one client can select for this
on each window, causing X errors if two clients do it.
This detection code is not 100% reliable, but it should fare much better
than the current code, which just compares the device name to a fixed
set of strings. Many applications depend on erasers being recognized
reliably, so we start by checking for a device name containing the
substring 'eraser'.
Signed-off-by: Thomas Jaeger <ThJaeger@gmail.com>
This has two advantages:
1) In many backends, this is faster as we can terminate the window
hierarchy traversal earlier
2) When used in gdkdisplay.c::get_current_toplevel() to get the
current toplevel that has the pointer we now correctly return
a toplevel with the pointer in it where the pointer is inside
some foreign subwindow of a toplevel window.
The second advantage fixes some bugs in client side event generation
when the pointer is inside such a foreign child window.
Based on first patches by Christian Hergert. Change
screen_get_monitor_geometry() so that it translates the layout of the screens
from Cocoa layout to GDK layout. In Cocoa, the screen locations
are specified in Cocoa geometry, as well as that GDK uses a different way
to place individual monitors in the root window. For now only monitors
that are laid out horizontally are supported (see the FIXMEs in the source),
in bug 596238 we will track future work to get things fully right.
Modify _gdk_quartz_window_get_inverted_screen_y() to take the differences
in screen layout between Cocoa and GDK into account. Also this function
is subject to future work.
Explicitly handle resizing by leaving all events in the lower right 15x15
corner to Cocoa, if the window shows a resizing indicator. Some
applications may have widgets allocated in this area. Generally, these
widgets are likely larger than 15x15 so they can still be hit. Often
scroll bars are found in this area and these can also be manipulated by
other means. Since this is the only way of resizing windows on Mac OS X,
it is too important to keep it broken.
When we grab the pointer we need to request more events than what is
specified, otherwise our event emulation stop working and you won't
e.g. get crossing event unless you specified motion event mask.
F-Spot needs this as it draws on a foreign (screensaver) window, which
used to work.
I believe this is safe, because in all typical cases the expose
mask will not be set, so we won't do anything, and its what we used to
do.
Check for 'auth-info-required' attribute from printer attributes to
find out whether an authentization of user is needed.
Change password dialog of print backend to be able to require informations
requested thru 'auth-info-required' (#566522).
This patch tests availability of remote host before getting ppd file
for selected printer (#586207). It also adds a state message for
failure of getting details.
progress-border and invisible-char style properties had wrong amount
of colons for gtk-doc (signal markup instead of properties), so the
Since tags didn't seem to get picked up.
GtkEntry:invisible-char also had a wrong Since: 2.22, fixed to 2.18.
Make the quartz backend support the new queued translations. We do this
by keeping our own copy of the region that has been set to need display.
Using this region we can intersect by the given area, translate this and also
set needs display for the resulting area.
With Bug 302240, a check was added to avoid keynav to unrealized
radio buttons in the group, but that's not the right check - the
check should be on MAPPED instead, since a widget can be realized
even if it, or a parent, is hidden. Bug 595599
When filtering out the events for "window" from the events we got for
our "impl_window", don't forget to adjust the returned number of
events because it might be smaller than what XGetMotionEvents has
returned, and free coords we allocated too much. Also if we filtered
away *all* events, return FALSE and get rid of the allocated history
entirely. Together fixes all sorts of mishehavior when painting in
GIMP, from coords going wild to plain crashes and infinite loops.
When a SIGPIPE signal is raised during printing with lpr,
application should not be killed by the signal but a standard
error-workflow should be performed (bug #503776).
On startup, the root window got assigned the size of the main screen.
But, the GdkScreen has the width of all screens/monitors connected to the
machine. Change this so that in _gdk_windowing_window_init, we assign
the width/height of all monitors to the root window width, height.
Should fix bug 594738.
The quartz backend simulates the semantics of XGrabPointer, as a part of
this it checks the event mask of the grab. However, implicit grabs on X
do not go through XGrabPointer and thus the quartz backend should not check
the event mask for these. This fixes various "the UI got stuck" cases.
Applications using non-double-buffered drawing using cairo (e.g. Abiword)
can draw directly to the window using cairo and thus manage to avoid
the automatic flushing of outstanding moves. This can cause redraw
inconsistencies like bug 593507.
We fix this by always flushing when exposing non-double-buffered widgets.
If we move, resize or otherwise change a window from inside a (double
buffered) expose handler we can run into issues with double buffered
paints that have already been ended but have not yet been commited
to the window from the implicit paint pixmap.
For instance, any copies of source regions due to a window scroll need
to take these into account, and any operation that causes some drawing at
a destination covered by the implicit paint region would be overdrawn
when the implicit paint is ended.
So, before we do any window-hierarchy changing operation while an implicit
paint is in effect we flush all moves and already commited paints.
When a window is moved or resized from a double-buffered expose handler
we can't really just copy the window region around, as the window
will be overdrawn with the double buffered region when the expose returns.
Instead we remove all regions with outstanding implicit paints from the
region to be copied and just mark this area as invalid to be redrawn
later.
This fixes bug 594880.
Its not correct for recurse gdk_window_process_updates_internal, as
the outer instance will overdraw the inner. So, protect against
gdk_window_process_updates() being called while in an expose
handler.
This shouldn't be a repaint problem, as eventually the idle handler
will cause the updates to be processed.
Some recent versions of libtoolize output a version blurb like:
libtoolize (GNU libtool 1.3110 2009-07-01) 2.2.7a
Don't get confused by the numbers inside the parens.
We used to handle zero height/width specially in the non-double buffered
case due to the weird behaviour of XClearArea in this case. However
this is undocumented, incompatible with what happens on double-buffered
drawing, and just not a good API. So, we drop this behaviour, having
fixed gtkclist.c which used this.
There are two issues here. First of all an ignored update didn't
use to unset update_idle which could cause all further idle repaints
to be ignored. (Bug #591583)
Secondly, if we ignore the process_all_updates we may end up not updating
the windows in update_windows unless something else triggers an update.
So, we handle this by checking for recursions and scheduling a new update
at the end of the outermost process_all_updates.
Fixed the button-sensivity patch done to GtkComboBox to account for
changes in appearance (changes to the appears-as-list style property).
Also, in list-mode, the event box that has been created below the cell
view also needs to have its sensitivity updated.
Commit 3f306a4042 made it possible for
gtk_tree_view_top_row_to_dy() to be called recursively. (In a different
way than was already guarded for). This caused a single test case in
the scrolling test suite to fail. We now also guard for recursive calls at
the beginning of gtk_tree_view_top_row_to_dy().
Rework the sort and filter models to store their reference to the parent
element as an array index instead of a pointer to an array element.
These pointers could become invalid with any array modification, whereas
indices do not.
If we have a level with zero visible nodes and the first node becomes
visible in that level, then parent has just become a "real" parent node.
In such a case we need to emit row-has-child-toggled. This only applies
to non-root levels that have a parent. This problem was also found when
writing the unit test, the respective cases in the unit test have been
corrected.
This fixes bugs:
Bug 372010 - Filtering not working properly
Bug 525965 - Filtered and sorted GtkTreeView is missing rows
When a filter function is used that determines the visibility property
of a node using whether or it it has children, the state of this node
very likely changes when the filter model receives a
row-has-child-toggled signal. Therefore, we need to handle state
changes in the row-has-child-toggled handler.
The license field was introduced later on, so some out-of-tree loaders
may not set it. And Solaris printf() doesn't take NULL for a string...
Bug 594178.
Add a function to obtain the effective context id, and reset the slave
only when the effective context id is different from the current context
id, when setting a client window and on focus in. This might fix
bug 593868 and bug 567124.
Also use a different means to check that the given mark is in the text
view's buffer. This will also play nice with anonymous and NULL marks.
Suggested by Paolo Borelli.
When unsetting the old buffer always set the buffer on the layout to
NULL. More importantly, clear the pending scroll. (The scroll is
handled in an idle, when not cleared an idle handler might touch the
layout later on, possibly corrupting the BTree). Unref the buffer after
removing the selection from the clipboard, not before. Patch merged
from maemo-gtk.
In gtk_text_view_queue_scroll() we need to verify if the given mark
exists in the text view's current buffer. When not done, this can
result in corruption of the BTree data structure. Patch merged from
maemo-gtk.
Updating the IM spot location in gtk_text_view_value_changed() might
invalidate the layout, so we need to make sure that we update it before
validating the layout again. Otherwise, the layout will be invalidated
right after validating it (possibly resulting in a failed
onscreen_validated assertion). Patch merged from maemo-gtk.
Likewise to other cell renderers, GtkCellRendererToggle now properly
follows the insensitive state of the widget requesting rendering. It
does this by checking the state of the widget pointer, not by using
GtkCellRendererFlags (there exists an insensitive flags). Later on, I
think we should move to using GtkCellRendererFlags and not the state of
the widget requesting rendering. Patch merged from maemo-gtk.
If the cell view is insensitive, it needs to properly propagate this
insensitive state to the cell renderers using cell renderer flags.
Merged from maemo-gtk.
This was removed long ago by the patch in bug 101235. On a hindsight,
all other scrollable widgets are processing exposes at this point, which
completely makes sense to me, so I am putting it back.
The check for a possible implicit paint flush before queueing an
antiexposure was wrong. An implicit flush doesn't actually NULL
the implicit paint, se we have add a flag to explicitly track if
it is flushed.
Passing region into _gdk_gc_set_clip_region_internal takes ownership,
so don't use it after that. We can just as well just move the usage
above the call.
Generally you only need to work around bugs in one specific app, so we
don't want to affect the applications that application will start.
Thus we unset GDK_NATIVE_WINDOWS after reading it.
For toplevels, never apply clip as shape, instead apply shape.
This way we don't have to re-set it all the time as the window size
changes. Furthermore, this change fixes unsetting a shape on a
toplevel window which didn't actually unset the shape before.
Additionally we never apply clips as shape if the shape would just
be the same as the regular window size. This means we won't unnecessarily
add a useless shape to most native child windows (and additionally this
helps apps that do weird X stuff that don't expect these shaped windows).
I.e. we use:
impl_iface = GDK_WINDOW_IMPL_GET_IFACE (private->impl);
And then use impl_iface instead of the full macro when calling vfuncs.
Also, in some places we avoid getting the iface multiple times.
Change default values returned by gtk_print_settings_get_printer_lpi()
and gtk_print_settings_get_resolution{_x, _y}(). New values are 150 for
lpi and 300 for resolution (instead of 0) (#590861).
Special case \r\n in gtk_text_buffer_backspace since \r should not be
reinserted even if we are deleting one char at a time. Also add
corresponding unit test. Fixes bug #544724.
Such paths (eg. a child node that is collapsed) should be ignored. This
is fixed by checking the return value of _gtk_tree_view_find_node(),
which returns a partial return value (the parent node) when it returns
TRUE. Also added a unit test.
Reorder drawing in gtk_tree_view_bin_expose() so that the tree lines are
drawn after the cells have been drawn. This is because cell-background
is handled in the cell renderer, so the tree lines need to be drawn
after this.
Contrary to what was believed before, do_validate_rows() does need to
queue a normal resize (including a redraw) when it has to. The redraw
is required because of the size of the tree has changed because new
row(s) have been validated.
Block 2BUTTON and 3BUTTON press events using a button press event
handler in GtkCellRendererSpin, so that they won't be eaten and
processed by tree view.
Previously the rightmost button with a proper response id was activated,
this is now only done if there is no default button set.
With this patch the right widget gets activated when there are multiple
widgets wth response ids conforming to is_stock_accept_response_id() as
the selected widget is made the new default widget before showing the
overwrite confirmation dialog.
For instance, two clients selecting for button events can cause BadAccess.
This fixes bug 592624, where a gdk_window_reparent caused us to re-set
the event mask, breaking the workaround for the mozilla BadAccess bug.
When updating the clip region on cairo context (due to window changes or
paints of different sizes) we reset the old clip region, but this was
erronously done inside a cairo_save/cairo_restore pair, which made the
reset not take effect.
This fixes bug #592263.
Instead of doing some magic in gdk_draw_drawable() to avoid double
offsetting when calling gdk_draw_drawable on the impl we call
the vfunc directly on the impl. Thus removing the weird magic from
gdk_draw_drawable().
I tested this with the testgtk test "text", where if the original magic
code is disabled typing a newline in the middle of a text line causes
the double offset issue to appear.
When the clip mask is completely inside the drawable clip region we
don't change the clip at all. However, we did set region_tag_applied,
so when the drawable clip was removed we removed the original clip mask.
This is no good, so we fix that by returning early in this case.
Fixes issue reported in bug #592752.
The fallback pixbuf rendering case ends up calling gdk_draw_image() on the
destination drawable wrapper, which resets the previously set clip region.
So, we need to manually get the impl and draw on that directly.
This fixes bug 592752 where we don't clip pixbuf rendering on non-render
Xservers.
Some applications make weird assumtions on Gtk+ that do not work anymore
with the new client-side windows support. For instance SWT/Eclipse reorders
the stacking order of the X windows directly without telling gdk this,
which breaks gdk drawing as gdk now relies on knowing the stacking order
for window clipping.
This introduces a GDK_NATIVE_WINDOWS environment variable, which if set
causes Gtk+ to always use native windows. Its more compatible with
pre-csw Gtk+ behaviour if you do weird X-specific hacks, although it does
limit the size of GdkWindows to 65535x65535.
In validate_visible_area() it was assumed that gtk_tree_path_prev()
would always return the correct path of the preceding node. This is
obviously not true. The if-clause has been removed so that we now
always use _gtk_tree_view_find_path() to get the path from the tree,
node.
GtkCellRendererAccel also needs to acquire the GTK+ grab in addition to
a GDK keyboard grab. With the GDK keyboard grab, KeyPress and
KeyRelease events are delivered as usual, although we only want to
receive them for our grab widget.
Make the tooltip code a bit more robust for a case that only occurs when
GTK+ is used from a language binding. It looks like this case appears
because the memory management / ref counting is handled differently in
some of the language bindings. Instead of asserting, we will fail
silently. Also fix a think-o in gtk_tooltip_start_delay(). Patch from
O. Andrieu.
The previous code would trigger on an unmodified 'S' key for a
'Super+S' accel. The current code avoids that at the cost of breaking
combinations like 'Mod4+Super+S' which are too exotic to worry about...
Bug 591526
Shift-click inside an existing selection reduces the selection to the
range from the insert mark to the clicked point instead of removing the
selection. This makes GtkTextView more consistent with GtkEntry.
gdk_window_get_geometry calls the native function for all non-native
windows. This returns coords relative to the native parent. We need
to convert this to be relative to the client side parent.
This fixes DnD coordinates in firefox (bug 588437).
If antiexposures are queued and then we do the outstanding moves
we will queue translations that will affect incomming exposes
wrongly wrt the antiexposure. So, make sure we process the outstanding
moves before doing the antiexposure.
Additionally this commit adds a bunch of comments about how the
expose handling works and fixes a small bug that made us always
flush outstanding moves a little to early than necessary.
Set the input_window_destroy and input_window_crossing methods of the
GdkWindowImplIface on Windows. Add implementation of
_gdk_input_crossing_event that is mostly dummy, though.
Apps may change the window hierarchy while recursing over it by
destroying windows from the expose event handler. We need to copy
the children list and ref all the children while recursing.
This fixes some crashers in gedit (bug #589367, bug #591434)
The X11 queue_translation operation uses NextRequest to get the serial
of the XCopyArea operation where the translation should end. However,
if the gc passed to gdk_draw_drawable has a non-flushed clip region
(which it commonly has now for the window clipping) then the next
operation will be the GC flush, not the XCopyArea.
To handle this right we now pass in the GC to be used to
queue_translation and ensure that it is flushed before calling
NextRequest().
When we copy the region we need to also re-expose the areas of
the copied region that was not also in the destination.
And, we need to do this invalidation after the move, as the
move also moves any invalid area.
If there are outstanding moves in an area that intersects
the source of an outstanding move we need to move the invalid
area correspondingly, otherwise we will expose the wrong area
as the outstanding move copy will happen before we expose
the invalid area.
When moving an area we move any invalid region in this area to the
new place, but there really is no need to remove the old invalid
area as it would just be invalidated again (being newly exposed).
Previously, this flag wasn't cleared properly when the notebook lost
focus, but only when the notebook was focussed again later.
As this flag is only used to advance correctly focus pages by grabbing
focus to the new page after switching the page, this is not good.
In particular, it can cause a focus grab when programmatically switching
the notebook page and the focus is inside a completely different widget.
A previous attempt at this fix in
6e0af6c252 has been reverted in
dfe0c8c0ca because it didn't work
correctly.
This extends the usage of the native clear region call such that its
called also for windows that have parent relative background all the
way up to a native window. That way we get true background relative
background clearing even to a foreign parent, which means that some
transparent notification icons look right again.
GdkDrawable->draw_drawback was replaced with a new vfunc
draw_drawback_with_src that is now called from gdk_draw_drawable.
However, some code seems to call the vfunc directly (see bug #591288),
so make it chain to the new call.
Note that such direct vfunc calls are a bad idea and won't work for all
cases.
This moves the native show/hide calls to the generic code
for calculating viewable rather than in its own separate code
called from gdk_window_show/hide. This simplifies the code a bit,
but most significantly it means things are correctly shown when
they become viewable for other reasons than a show/hide call.
For instance, this fixes bug 590442 (gvim embedding) where the
toplevel GtkPlug is mapped by the embedder and we didn't previously
pick up that the native children became viewable and should be shown.
Print when Enter pressed in Name entry or Command Line entry in the
print dialog (#564695).
Add gtk_printer_option_set_activates_default() function and
gtk_printer_option_get_activates_default() function to control
behaviour of GtkPrinterOptionWidget.
We used to invalidate the whole window when raised, but this is
unnecessary much, we now just invalidate the visible area minus the
previously visible area.
This also fixes a problem where expose calling raise caused a loop (#588438)
This never worked before csw since the root window is never
set as IS_MAPPED, but with the new viewable check (which is
true for the root window) we could erronously queue exposes
on the root window.
This happened unexpectedly in bug 589369, where metacity
got a GraphicsExpose event on the root window due to some
graphics operation, queueing an expose which would be handled
by clearing that area. That is fixed with this commit.
When printing, increment page sequence before rendering of the page,
not after (#590084).
In opposite case it runs "end_page" function with wrong parameters when
drawing a page in another thread.
Add gtk_widget_get_visible(). For symmetry reasons and for convenience
when a widget's visibility state is available as a boolean condition,
also add gtk_widget_set_visible() (which simply calls show()/hide()).
Previously, this flag wasn't cleared properly when the notebook lost
focus, but only when the notebook was focussed again later.
As this flag is only used to advance correctly focus pages by grabbing
focus to the new page after switching the page, this is not good.
In particular, it can cause a focus grab when programmatically switching
the notebook page and the focus is inside a completely different widget.
Checks for details request before sending a job to a printer.
Shows busy state indication (cursor + status field).
This avoids printing to wrong printer (bug #576601).
This seems to more or less fix the build. On Tiger there are still issues
with libresolv missing on the link line, I will figure out what's up with
that soonish.
Properly invalidate iterators in iter_next, iter_children,
iter_nth_child and iter_parent when FALSE is returned. ListStore was
actually already mostly in order as the GSequence pointers are very
strictly checked, but to be a little stricter we've added stamp = 0
lines. TreeStore did not invalidate its iterators, so stamp = 0 lines
were added where appropriate. Unit tests have been added to check this.
Fixes bug 586374, reported by Mike Gemunde.
gtk_tree_view_enter_notify() now "ignores" the synthesized crossing
events. The synthesized crossing events always have (0, 0) as
coordinates, which messes things up. This patch does not fix all issues,
at least it makes the behavior much more reasonable again. Watch bug
555109 for further discussion on the issue.
Added checks to see whether the passed iterators are not the same in
convert_child_iter_to_iter() and iter_to_child_iter() functions in both
the sort and filter models.
Fixes bug 573321, suggestion by Vadim Godunko.
Adapt gtk_tree_view_get_path_at_pos() and
gtk_tree_view_get_drag_dest_row() to just return FALSE when bin_window
is NULL and not hit a warning. Makes this case consistent with the tree
view not having a model. Documentation has been updated to clarify
this, unit test has been added.
Fixes bug 539377, based on a patch by Bjorn Lindqvist.
Instead of failing with warning on !tree_view->priv->tree, return
silently when tree_view->priv->model is NULL. Clarified in the
documentation that for invalid paths (and every path is invalid when no
model is set), the function will fail silently although the current
cursor will be unset.
Fixes bugs 498010 and 546005.
Includes a test case for bug 546005 to start with, logic provided by
Paul Pogonyshev and Bjorn Lindqvist. In the future, we should maybe
merge treeview-scrolling.c with this one to create one large monolithic
tree view tester.
Instead of refiltering the recently used files we should rebuild
the list altogether when the current GtkFileFilter changes; this
allows us to keep showing the maximum amount of recently used
files.
Fixes bug:
http://bugzilla.gnome.org/show_bug.cgi?id=514260
gtk_tree_view_discover_dirty_iter() and gtk_tree_view_discover_iter()
have been in the tree forever, but unused since 1.3.8 or so. I guess we
no longer need them, so removed them. Fixes a compiler warning as well.
Bug #509650. Checks if all the predecesors (the parent widget,
his parent, etc) are visible. Only reports ATK_STATE_SHOWING when
all parents are visible.
Signed-off-by: Li Yuan <li.yuan@sun.com>
This lets us do this:
1. click on a folder in the shortcuts pane
2. start typing a filename
Then, the typed filename will actually go to the filename entry, like
the user expects. (Or to the search entry, in case the user clicked
on the Search shortcut.)
Also, removed the obsolete callback that made "/" and "~" typed in the
shortcuts pane bring up the location entry.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
People often do this:
1. Bring up a SAVE dialog
2. Click on a folder in the shortcuts pane
3. Start typing a filename
4. Oops! The interactive-search entry in the shortcuts pane appears.
With this, the shortcuts pane will not bring up the interactive-search entry. Then it
will be clear that you are not typing in the right place.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
We get the real pixmap size and use as cairo surface size rather
than doing some magic to try to get clipping on the right hand size
(and the magic looks wrong anyway).
The previous code could result in the width/height being to big for
the cairo 28.4 fix point size and thus not drawing anything.
This fixes bug #588076.
When the fallback for gdk_draw_pixbuf (gdk_drawable_real_draw_pixbuf)
is called with a window destination we have already applied any clip
regions and offsets for the window, but the window we get is a wrapper
and not an impl. We have to ensure we really draw to the impl, as
otherwise the pixbuf drawing will be clipped by client side subwindows.
This fixes bug 588553.
gdk_window_input_shape_combine_mask() can accept NULL for the mask
parameter, but it wasn't checking for NULL before passing the
resulting GdkRegion to gdk_region_destroy(). Fixes#589275
When the region is empty we can return early, because there
is no more area to remove. This happens often for children
of scrolled windows (i.e. things that are clipped out.
Previously, do_validate_rows() validated 300 rows per iteration. While
this is usually not problematic, as the typical tree view contains less
than 100 rows. Tree views with a lot of columns or complex cell
renderers could take inacceptably long, like:
- Epiphany's location bar entry completion has multiline and marked up
text in every cell. Validating a single row took ~1.5ms here.
- In the list view in Nautilus, When enabling all columns, validating a
single row would take ~3ms.
With 300 rows per iteration, that made those examples take 500ms/1s in a
signle main loop callback, and this obviously caused responsiveness
problems.
Now the code uses a timer and limits the time for validating rows to
30ms. This can cause less lines to be invalidated per call, so the
function might be called more often, but generally results in more
responsive applications.
Add the following functions based on a patch from Christian Dywan:
- gtk_widget_set/get_can_focus()
- gtk_widget_set/get_can_default()
- gtk_widget_has_default()
To fix this I replaced the code that creates an internal buffer
at init and construction time with code that creates a buffer
at _get_buffer() time, this is the same as GtkTextView does and
fixes the crashes for me.
We grab the default to the apply, forward or close buttons, as
appropriate. Also, make sure that the logic for setting the focus
to the best place on page change is applied to the initial page.
Add a tooltip that shows the full path of the current folder, to avoid
ambiguity. We only show the tooltip when the expander is collapsed to
avoid cluttering the full file chooser.
- gtk_widget_has_focus() for GTK_WIDGET_HAS_FOCUS()
- gtk_widget_get_sensitive() for GTK_WIDGET_SENSITIVE()
- gtk_widget_is_sensitive() for GTK_WIDGET_IS_SENSITIVE()
Implement _gdk_win32_window_destroy() by just renaming
_gdk_windowing_window_destroy(), removed superfuous stub.
Also cleaned up implementations of gdk_win32_window_set_background()
and gdk_win32_window_set_back_pixmap() - removed stuff now done at the
respective gdk_window_*() function.
Resurrcetion and adaption of find_window_for_mouse_event(). The window
receiving the WM_MOUSEMOVE, WM_?BUTTONDOWN is not necessarily the one
interested in GDK_(ENTER|MOTION|LEAVE)_NOTIFY
http://bugzilla.gnome.org/show_bug.cgi?id=588373
Also added some more more TODO_CSW and disabled print_event(): it can not
cope with the new _gdk_windowing_got_event() eating/morphing events.
The scrolling and region moving code needs to avoid drawing when the
window is mapped, which it did. However, it also needs to avoid
drawing when any of its parents are not mapped, which it didn't so
switch to using gdk_window_is_viewable().
This fixes the index rendering in evolution (#588169)
When we ungrab the pointer we don't get enter events for the window the
pointer is in at the time of the ungrab, so we manually query for the
window the pointer is in. The same thing actually happens on re-grab if
the previous grab was !owner_events (meaning we don't get crossing events
for windows other than the grab) but the new grab is owner_events (and
thus non-grab windows need to get crossing events).
This factors out some common code and enables it also for the re-grab
to owner_events case.
Paper size combo and orientation combo can be added by
gtk_print_operation_set_embed_page_setup_dialog() to GtkPrinUnixDialog
now. This function induce calling of
gtk_print_unix_dailog_set_embed_page_setup_dialog() after creation of
dialog. These two functions control embed-page-setup-dialog properties
in GtkPrintOperation and in GtkPrintUnixDialog.
There is also new function gtk_print_unix_dialog_get_page_setup_set()
which says whether page setup was set by user.
Selected page setup is stored as default page setup in
GtkPrintOperation.
New class is added, its name is GtkCustomPaperUnixDialog. The class
manages custom sizes. It is derived from GtkPageSetupUnixDialog's
CustomPaperDialog structure.
Page layout preview is modified, so, it shows dimensions of current
page setup (mm or inch - depends on locale). It also shows the name of
actual paper if page setup dialog is not embedded (paper size combo is
not visible).
gtk-demo is actualized to include this new feature.
If we get a nonlinear enter/leave notify on the toplevel we need
to set nonlinear in all the events we send, even if the in-toplevel
tree is linear.
This fixes combobox menus popping down immediately when you click
(not hold). (bug #587559)
Adds a 'model' type buffer for GtkEntry in which the actual
textual data is stored. GtkEntryBuffer can be subclassed.
Among other things, this allows GtkEntry to be used for secrets
that need to be stored in non-pageable memory. It also allows
buffers to be shared by entries.
See bug #576801.
We really need to wait for the MapNotify from the xserver to ensure
that the window has been mapped, as it may be delayed by the WM, network
or similar things.
This fixes a problem in the /ui-tests/keys-events gtk test
Add internal API for the default button box layouts to so we don't
need to call deprectated GTK+ functions (which are invisible with
GTK_DISABLE_DEPRECATED).
This is more important in the client side windows world, as clip masks
may be used for clipping to non-native subwindows. This fixes a bug
in aisleriot where it uses masked pixbuf drawing and it ends up drawing
over the moving card subwindow.
It turns out that mozilla, as per the gtk2xt code selects for input on
the socket with a mask of 0x0fffff (for god knows why) which includes
ButtonPressMask, causing a BadAccess if someone else also selects for
this. As per the client-side windows merge we always normally selects
for button press so we can emulate it on client side children that
selects for button press. However, we don't need this for GtkSocket,
so we unselect it here, fixing the crashes in firefox.
Turns out pygtk build broke due to the argument addition to draw_drawable.
So, we now add a new vfunc for the new draw_drawable and are thus
backwards compat.
we now use gdk_offscreen_window_set_embedder() instead of a signal
to get the parent. This also replaces set_has_offscreen_changes.
Rename "parent" in all embedding related names to "embedder" to make it
more obviously different than the normal parent.
Rename gdk_window_get_offscreen_pixmap to gdk_offscreen_window_get_pixmap
to match the other offscreen calls.
Rename gdk_window_offscreen_children_changed to gdk_window_geometry_changed
as this is more descriptive.
Going from print-to-file to a real printer and back used to nuke
an app-provided uri; now we keep the initial settings around to
avoid that. Fixes bug 587086.
We emulate visibility by unmapping (in X) all mapped (according to
gdk) windows that are not visible (all parents mapped). This is because
there may be client side windows inbetween the native windows in the
hierarchy, so you can't know a native window is visible just because
all the parent native windows are mapped.
However, we don't want to unmap foreign windows, as that may cause all
sort of unexpected issues. This should be safe, because generally the
parent of a foreign window is a native window (e.g. a socket), so its
gdk visibility state is the same as the Xserver one.
This fixes an issue with the GDM notification area where the unmap of
the plug caused spurious UnmapNotify events that confused GtkSocket and
caused icons to become one pixel wide.
Last commit was bad, as it didn't clip against client side
children. This implements such clipping first and then
only clears the rectangles that need to be cleared.
This is how cairo works with native children.
This fixes an issue where the drag target outline is visible on the
evolution folder treeview when it isn't with native windows.
Without this we can't draw to them, which caused problems for e.g.
gnome-settings-daemon clearing the background when the desktop
background changed.
Note: We don't actually clip away child windows from the root window,
the clip is just based on the size of the root window.
Reserving toggle space is nice for consistency in main menus
and context menus, but it gets in the way in special situations,
such as combo boxes, tabular menus, etc.
GtkNotebook used gdk_window_get_pointer() incorrectly, as it already
had coordinates from various GdkEvents. Using get_pointer() means
that you get pointer positions *after* the event has happened, which
leads to visual out-of-sync results, or inadvertently detached tabs if
you click on them while your machine is being slow.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
Don't pass the click on the button through to the scale when the
dock popup will be moved, otherwise we could end up changing the
sound in unexcepted ways (to zero for vertical popups at the bottom
of the screen for example).
gtk/gtkmenuitem.c: Override custom_tag_finished() for "accelerator" and search
the correct toplevel GtkWindow to attach accelerators to menu items.
gtk/gtkwidget.[ch]: Added _gtk_widget_buildable_finish_accelerator() to allow
subclasses to specify a toplevel window to associate with when parsing <accelerator>
tags
We do want to have consistent padding in menus in menubars and context
menus, but the menus used in comboboxes don't need the extra padding.
Add private GtkMenu API for turning this off. Bug 564063
Setting a tooltip on a widget unfortunately triggers several roundtrips
to the X server. We reduce this overhead by only doing it if the
widget is visible, and by deferring to an idle. See bug 585626.
The virtual method list_shortcut_folders returns a GSList * of GFile *.
In turn, gtk_file_chooser_list_shortcut_folders() converts those to strings.
However, the delegate in gtkfilechooserutils.c was calling
gtk_file_chooser_list_shortcut_folders() every time, so we were trying
to convert invalid data.
Now we have an internal function that deals with GFile *. That
function is called by the delegate, and the conversion is done only
once by the API entry points.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
We can't set the sort column when we load the GtkFileChooser's settings, as the
file models may not have been created yet. Wait until the models are actually
present; then we can set the sort column.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
In the destroyed window case in do_synthesize_crossing_event we didn't
return a value which can cause infinite "loops". Always return FALSE
to make sure the idle doesn't run again.
Doing this directly had some issues with picking going recursive in
clutter-gtk. Furthermore, doing it in an idle means we can coalesce
multiple calls (which is common due to widget changes) in the same
toplevel to just one call.
You can call this if you have offscreen children and the geometry of
them changed. This will cause re-picking of the active window sending
enter and leave events as needed.
We want to be able to map any window coordinate to a root coordinate, not
just the origin, because you can't rely anymore on a simple translation
from window coordinates to parent with offscreen windows. This lets
us e.g. pop up menus in the right place even if they are popped up from
a no-window widget.
We use the offscreen signals for getting parent, picking
children at a point and mapping coordinates between windows
embedding offscreens and offscreens.
This means we have two hierarchies more or less, one visible to apps via
the standard APIs and for drawing where the offscreens are their own
separate toplevels, and another one for event handling where embedded
offscreens appear as if they were children of the embedding window.
3 signals are for offscreen windows
get-offscreen-parent: Get the parent window an offscreen is embedded in
to-parent: Convert coordinates from offscreen to parent
from-parent: Convert coordinates from parent to offscreen
1 signal is for the window embedding offscreens:
pick-offscreen-child: This picks what (if any) offscreen is at a specific position
The last signal is only used if you call gdk_window_set_has_offscreen_children
to tell gdk that the window has embedded offscreen children.
Add get-pointer signal for offscreen window pointer getting
Apps using offscreen windows can connect to get-pointer on offscreen
windows in order to make gdk_window_get_pointer() return correct
values.
Add get-offscreen-parent signal
Add signals for from-parent and to-parent coordinate mapping
Add pick-offscreen-child signal
We returned the innermost child that has the pointer, which is not right.
Only the direct child that has the pointer in it should be reported (if any).
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.
Use the same code path to get a CGContext for both gdk_draw_* and
gdk_cairo_create and make sure we unlockFocus in both cases. This
fixes the broken rendering in GtkRuler. Also use an average of flush
intervals when checking whether we can flush or not, since otherwise
we get too sensitive and block almost all explicit flushes that are
caused by mouse movements for example.
Unfortunately the old GdkWindowObject is public and accessed
from macros, etc. So, we publish a limited copy of GdkWindowObject
and use the full one internally when building gdk.
In the new world offscreen windows are not put in the hierarchy, but are
rather toplevels for themselves. Offscreen hooks don't make any sense
in this model.
It often happens that we move region A to B and then we move a subset
of B to C. When possible we'd like to replace this with a move from
A directly to C, and a suplimentary move from A to the areas of B not
overwritten by C.
Getting an optimal move combiner seems quite complicated, but this
simple approach gets most of the interesting cases right and isn't
all to complicated.
There is no need to copy something that is already invalid and will
be marked as invalid in the destination anyway, so we remove this
area from the region to copy.
The expose translation is useful for tracking how outstanding
invalid (exposed on server) areas are copied, and how we need to
compensate for that on the client side to redraw the right area.
So, we should queue the translation at the time we actually move
the bits on the server side, not when moving the window on the
client side.
Also, clean up some naming of parameters.
We now copy outstanding window moves directly on the window and
not to an intermediary pixmap, this means our previous code to
combine window copies was wrong (it relied on each copy not
destroying the source date).
Furthermore, we can't just remove all the update area from the
destination of the outstanding moves, as sometimes things get
copied into that area and then used as the source of another
copy.
We replace the previous window copy combining with a naive
version that just queues each move, just to get things right.
Further work to optimize copies is possible.
Also, we don't remove copy destinations that are used as source
for later copies.
We also clean up the memory management by not having
move_region_on_impl taking ownership of the passed in region.
Apps that set no exposure mask rely on the system clearing things
to the window background, so we need to do this ourselves.
Also, don't do this on foreign windows, as they are not controlled
by us. In fact don't do exposes on foreign windows either.
This is required for the GtkSocket code, as it shows the plug child
even though the current cached state is (wrongly) that its already
mapped.
This makes blink work for non-local case in testsocket.
Native descendants of a virtual children are not automatically destroyed
with the parent as if it was a native window, so we need to handle
the native recursion tracking manually in _gdk_window_destroy_hierarchy()
It turns out that XCopyArea handling of obscured source regions is
buggy. It clears the destination area even outside the GC clip
region. We work around this for the pixmap->window case as that
can happen in gtk+ and is easy to work around.
X Bug report at:
http://lists.freedesktop.org/archives/xorg/2009-February/043318.html
Some apps really need to set custom event masks on native child windows,
for example emacs sets the event masks with gdk, but then reads out
the raw X events via a filter, so gdk event emulation doesn't work for that.
When we get motion or button events we map back from the event position and
window to the toplevel before doing anything, because a toplevel native window
could e.g. overlap a child window or whatever.
These are generated when we get an implicit grab on a native
child window, and we can't filter them with _has_grab() because
they are sent before the button press event where we detect
the implicit grab.
This makes clicks work in the flash plugin again
It turns out we really have to ignore grab/ungrab events or we'll
report double crossing events when we grab or ungrab.
However, we also can't ignore crossing events from grabs from other clients
as that leads to missed enter/leave events on e.g. alt-tab in metacity.
Fortunately we now track grabs very precisely, so we know with certainty
whether we have a grab at the time (serial) of the native crossing events,
and only if we do we ignore them.
If we get crossing events with subwindow unexpectedly being NULL
that means there is a native subwindow that gdk doesn't know about.
We track these and forward them, with the correct virtual window
events inbetween.
This is important to get right, as metacity uses gdk for the frame
windows, but gdk doesn't know about the client windows reparented
into the frame.
For instance if we grab the pointer and then check if its grabbed
so that we know to ungrab we don't care that the grab is not
yet active, so report the steady state (i.e. the last grab)
Having GDK_WINDOW_CHILD windows with root as the parent apparently works,
and metacity uses it. The current gdk_window_get_toplevel() returns the
root window for that, which is wrong, so we check that explicitly.
This causes all sorts of weirdness with pointer_over_window
being the rootwindow and then crashing gdk_window_get_toplevel() later.
With this metacity stops crashing madly.
To avoid drawing the window background of other windows in the area
where the window was we set the bg to none recursively. However, this
is quite costly it the moved window has many siblings. Furthermore, it
is uncommon that siblings overlap, so this cost has little gain.
So, we only set bg None on the parent, which means that there will
be some more flicker in the uncommon case of overlapping siblings.
These are sent when someone else grabs the pointer, and we don't
want to miss these expose events. For instance, we missed enter
and leave events on alt-tab.
There were some issues with these wrt out-of-sync grab information
in the client, but that should now be handled. So, it should work
or at least be fixable if we find some bug.
After a successful grab/ungrab we wait for an xserver
roundtrip until we change the tracked grab in GdkDisplay.
This way that data is always up-to-date wrt events comming in.
Get rid of invalidate_maybe_recurse and process_updates. Implement
_gdk_windowing_{before,after}_process_all_updates(), and keep track of
when we're inside process_all_updates in the common code so we know
when to flush windows. Implement
_gdk_windowing_window_process_updates_recurse by means of
setNeedsDisplayInRect: displayIfNeeded. Use the added window argument
in begin_paint_region to get the right window (the paintable is always
the impl window now).
Replace them with two new functions
_gdk_windowing_{before,after}_process_all_updates() that are called
around the guts of gdk_window_process_all_updates(). Add empty ones
for X11 (nothing more needed), quartz ones will be implemented next.
We use this in the added windowing function
_gdk_windowing_window_process_updates_recurse. The X11 implementation
just calls _gdk_window_process_updates_recurse directly, but at least
quartz will need to do some more work.
This fixes a problem where we used to set them on a native window, but we
never unset it becase when the pointer moved to another native window
we just set the cursor on that window. Always setting on the toplevel
fixes this.
This reverts commit 7cc15ec6ea1504133dfe6febbdb12615550bb966.
Its risky to convert all the events in a go like this, as it
increases the out-of-order issues. It also isn't a full solution
to the motion hint issue as it will only work for the events
we happen to convert. It would be better to use serials to
handle motion hinting.
This is the first stage in tracking keyboard grabs in the common code.
This lets us handle destroying or unmapping virtual window with a
keyboard grab.
If we only convert the first then motion hint emulation won't
work since we don't see the next motion even until we've
fully handled this one.
However, this changes a behaviour that has been like this since
the mists of time. I don't know if it could cause other issues.
I haven't seen any yet though.
There was a performance problem with the old flicker fixing
approach. For moved windows we copied the window data to the double
buffer pixmap and then back to the window with the rest of the
expose data. In some cases the copy from window data to pixmap was
very slow because the pixmap was allocated in system memory and
the window in video memory.
The new approach is to delay all window moves and then replay them
after the expose has drawn to the double buffer pixmap but before
drawing it to the window. Furthermore, we remove all exposed areas
from the destination of the delayed moves so we won't copy something
just to then immediately draw over it.
This makes scrolling in firefox fast, and it makes tests/flicker not
show any (detectable) flicker.
We return the raw window drawable, so its likely the app will do some
weird stuff to it, like draw using non-gdk operations. We don't want
the app to see any half-drawn state, so flush everything.
This fixes a scroll issue in firefox at least.
This fixes a mismatch in save/release gstate for the CGContext. If
this function is ever used for pixmaps, we need to add support for
that, probably will have to do so soon.
The one that puts windows outside the screen and moves them in when
showing. It might not be needed anymore and the workaround doesn't
work with the client-side window branch anyway because the window is
already mapped when we get showed for some reason.
If we do this there is a short window where we think there is a grab, and
if we generate a client side pointer motion event in this time (e.g. from
a window move) we could be delivering that according to the grab. But in
the Xserver that grab is infinitely short as it sends Press and then
Release immediately.
To see a problem from this, try using the scrollwheel to quickly scroll
in the testgtk list of buttons.
This is basically the same fix as was done for
gdk_window_move_resize_internal. We make sure not to move the native
child window contents twice and we don't copy data that was overwritten
by the moving of the native child windows.
Whenever a native window is moved this causes an immediate change in
the window (the window content is copied). This change conflicts can
conflict with outstanding moves or other cached changed, so we need
to flush all outstanding moves in the related windows.
To simplify the code for window move/resize the toplevel version was
split out to its own function.
Move native windows after recomputing so that we get the right new
shape before moving (and the implied copy). This means we're not
copying too much data.
Take into account the area of a moved window that contains native
subwindows, as these affect things in two ways:
First of all we shouldn't copy the original window location, as that
is copied by the native window move.
Secondly, we can't copy things that would end up copying from the
native window move destination, as the data that used to be there is
now destroyed by the native window move.
It can happen that another native window is re-shaped over the region to
be moved, this will not destroy the data (since we're unsetting the background
when we reshape), but it will mean we need to read from this window.
We already used INCLUDE_INFERIORS, but that only handle subwindows. We fix
this by doing the copy on the toplevel, offsetting the copy to compensate for
this.
All the calls that unset private->parent failed if that was
not a native window (impl), instead we need to find the impl window
for the parent. Add some helper functions for this and use them.
For move/resize of child windows, we really need to recursively unset
on the parent, because moving the window could expose other native
children of the parent.
In do_shape_combine_region, only unset background if we're changing
the bounding shape (i.e. not the input shape)
There is no need to do all these computations when moving toplevels
as that can't really change any visible regions. Nor will it cause
any exposes we need to handle.
move_region_on_impl() - doesn't need to copy anything if dx/dy == 0
Ensure that we queue an update when invalidating an empty area but we have outstanding moves
Temporarily unset background when moving native child windows
The history before this was kind of twisted as several different
approaches were tested, so that was all squashed into this initial
commit to hide the uninteresting changes and files that were later
removed.
Revert commit f4090b5c84, as that
conflicts with the client-side-windows work. Furthermore, that
change is already applied as part of the client-side-windows work.
2009-04-02 10:06:01 +02:00
557 changed files with 242760 additions and 153481 deletions
In version 2.18, GDK has been changed to use client-side windows. This
means that there is no longer a 1-1 correspondence between #GdkWindows
and windows in the underlying window system. In particular, it is no
longer correct to assume that each window has an associated XID.
Code that makes this assumption can sometimes be fixed by calling
gdk_window_ensure_native() on the windows in question.
Calling gdk_x11_drawable_get_xid() (or GDK_WINDOW_XID()) from the
X11-specific API on a non-native window will explicitly call
gdk_window_ensure_native(), so old code using this will continue to
work. A small gotcha is that the GDK_WINDOW_XID() call is no longer a
trivial accessor for the XID of the window, and thus must not be called
from another thread without taking locking precautions.
</para>
<para>
GDK looks for the <envar>GDK_NATIVE_WINDOWS</envar> environment variable
and makes all windows native if it is set. It also tries to be more
compatible with the way prior versions worked in some other ways.
</para>
<para>
Some applications assume that they can just operate on the X windows
corresponding to their GDK windows without ever telling GDK. One
example that we've seen is changing the child window stacking order
using XRestackWindows(). Fixing this properly requires to fix the code
to use GDK functions to achieve whatever it is trying to achieve.
To make this easier in the case of stacking order changes, we've added
a gdk_window_restack() function.
</para>
<para>
One change that can cause problems for some applications is that GDK
is more aggressive about optimizing away expose events. Code that does
more than just repainting exposed areas in response to expose events
may be affected by this.
</para>
<para>
Problems can also occur when using cairo for drawing. One thing that can
go wrong is clip handling. If you ever need to reset the clip region on
a cairo_t (i.e. use cairo_reset_clip()), you have to to use
gdk_cairo_reset_clip() instead. The reason for this is that the cairo_reset_clip() call will remove the initial clip region that limits your drawing to
the client-side window at hand, so you will end up drawing over stuff
outside the window. You also need to use gdk_cairo_reset_clip() if you
use a cairo_t that was not allocated in a double-buffered expose handler
and keep it in use after window hierarchy changes (resizing, moving,
stacking order changes). The easiest fix for this kind of problem is to
simply create a new cairo context for each expose event.
</para>
<para>
Due to a weird API in XClearArea the gdk_window_clear_area() call handled
a specified width or height of zero to mean "to end of window" for
non-double-buffered drawing. This has been changed to be consistent with
the docs and what happens in the double-buffered case. All code in GTK+
that relied on this has been fixed, but it is possible (although unlikely)
that third party applications rely on this. If you need to do this, just
implement it yourself using gdk_drawable_get_size().
url="http://www.gtk.org/documentation.html#Tutorials">http://www.gtk.org/documentation.html#Tutorials</ulink>. You can also find other GTK+ tutorials there.</para>
<para>A packaged verion of this tutorial is available from
<para>A packaged version of this tutorial is available from
<ulink url="ftp://ftp.gtk.org/pub/gtk/tutorial/">
ftp://ftp.gtk.org/pub/gtk/tutorial</ulink> which contains the tutorial in
various different formats. This
package is primary for those people wanting to have the tutorial
available for offline reference and for printing.</para>
various different formats. This package is primary for those people wanting
to have the tutorial available for offline reference and for printing. Note
that the packaged version may be older than the online version.</para>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
