Re: [Nautilus-list] bin_window vs. window coords.

[Darin Adler <darin bentspoon com>]

On 2/21/02 10:38 PM, "Alex Larsson" <alexl redhat com> wrote:

> Darin. Can you describe this:
> 
> 2002-01-30  Darin Adler  <darin bentspoon com>
> 
> * configure.in: Bump eel version required.
> 
> * libnautilus-private/nautilus-icon-container.c:
> (rubberband_timeout_callback), (start_rubberbanding),
> (update_stretch_at_idle), (motion_notify_event):
> * libnautilus-private/nautilus-icon-dnd.c: (icon_get_data_binder),
> (nautilus_icon_container_position_shadow),
> (receive_dropped_keyword),
> (nautilus_icon_container_find_drop_target),
> (nautilus_icon_container_receive_dropped_icons),
> (nautilus_icon_container_get_drop_action),
> (nautilus_icon_dnd_update_drop_target), (nautilus_icon_dnd_init),
> (nautilus_icon_dnd_begin_drag):
> Use new eel functions that eliminate the funky interaction between
> the new GtkLayout and GnomeCanvas. Basically, all the functions
> that deal with window coordinates are getting bin_window
> coordinates instead. This should really be fixed in GnomeCanvas.
> 
> change a bit?

Here's the explanation: When I made this change I was under the impression
that events for a widget contain X and Y coordinates relative to the
widget's window. So that events for a canvas would be relative to the
GtkLayout window, not the bin_window that's used for the scrolling.

Since the rubberbanding got broken when I made this change, it means two
things:

    1) I blew it because I didn't test my changes
    2) Something's wrong about my mental model

I guess I really don't know when coordinates are relative to the window and
when relative to the bin_window. I had assumed the bin_window would never
really enter into it. And if that's so, the entire concept behind the eel
functions could be wrong.

I do know that whenever NautilusIconContainer wants to save window
coordinates rather than canvas coordinates, we want those to be window, not
bin_window, because the whole point is to be unaffected by scrolling. So
that part of what I was thinking was right. I also am pretty sure that the
rubberband_timeout_callback code that uses gdk_window_get_pointer is
correct, because it explicitly uses widget->window.

The part I probably got wrong was assuming I knew which window incoming
event coordinates were relative to. I'm thinking that what I really need to
do to get this right is to actually look at the window field from the event,
because that's going to accurately reflect which GdkWindow the X and Y
coordinates are relative to. So maybe the Eel functions should take a
GdkWindow parameter, or maybe even a GekEventButton parameter.

I can take care of this if you want me to. Let me know how you'd like to
proceed.

    -- Darin