After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 136112 - gdk_window_get_position() and embedded windows
gdk_window_get_position() and embedded windows
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: Other
2.3.x
Other Linux
: Normal minor
: Medium fix
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2004-03-03 21:19 UTC by Dan Winship
Modified: 2014-03-27 02:58 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description Dan Winship 2004-03-03 21:19:50 UTC
Dragging things into out-of-proc bonobo components works strangely.
The problem seems to be that

    _gtk_drag_dest_handle_event assumes that the parent of any
Comment 1 Dan Winship 2004-03-03 21:24:43 UTC
Er. Interesting epiphany behavior there...

As I was saying:

Dragging things into out-of-proc bonobo components works strangely.
The problem seems to be that

    1. _gtk_drag_dest_handle_event assumes that the parent of any
       TOPLEVEL window is the root

    2. The x and y coordinates of the GdkWindow associated with
       a GtkPlug plugged into an out-of-proc GtkSocket never get
       updated after the component is first realized, so
       gdk_window_get_position() always returns the same thing

So the drag-into-able area of the component is roughly the
intersection of where the widget was first realized on the screen,
and where it is currently on the screen.

Changing the gdk_window_get_position() call in
_gtk_drag_dest_handle_event to gdk_window_get_origin() seems
to fix it, and not break anything else, but I don't know if
that's the right fix, or if the GtkPlug GdkWindow problem
mentioned above needs to be fixed.
Comment 2 Owen Taylor 2004-03-13 16:28:37 UTC
Calling gdk_window_get_origin() here is generally a bad thing
because it's a round-trip, and we really, really want to avoid
per-motion-event roundtrips for DND. 

I want to do something better - probably add the requirement to
send ConfigureNotify events in window-manager style to a new
XEMBED spec and then flag GdkWindows as to whether we get
configure notifies, but for now, I've put in a quick fix
that special cases GtkPlug in gtkdnd.c 

Sat Mar 13 10:49:46 2004  Owen Taylor  <otaylor@redhat.com>
                                                                     
          
        * gtk/gtkdnd.c (_gtk_drag_dest_handle_event): For
        GTK_IS_PLUG toplevels, call gdk_window_get_origin()
        not gtk_window_get_position, as a hackround for not
        having accurate notification of window position for
        embedded windows. (#136112, Dan Winship)
Comment 3 Jochen Baier 2005-03-14 02:00:28 UTC
GTK_IS_PLUG () is not enough cause every plugged foreign window should be
treated like a plugged window. (for example gtk_socket_add
(window_id_from_evolution)  should be treated like a plugged window)
maybe "GTK_IS_SOCKED()" is better ;)

btw: everybody who get drag and drop working with konqueror plugged in a socket
will get a six pack of germany beer for free ;)  i really net a working dnd with
kde program swallowed/reparent.

(http://alltray.sourceforge.net)

prost jochen
Comment 4 Jochen Baier 2005-03-14 17:18:14 UTC
maybe GTK_IS_PLUG could be replaced with gdk_window_get_user_data(), if this
returns NULL it should be a foreign window. (like the code in gtksocket.c
function: gtk_socket_add_window)
Comment 5 Matthias Clasen 2014-03-27 02:58:18 UTC
closing out ancient bugs