Yeah, its pretty arbitrary:

#define SNAP_TOLERANCE 20

so that's twenty pixels on each side of the center mark. Maybe we
should just double it for snapping to the center.

Sounds like it would work for me. I can maybe just poke at the #define
and experiment a bit.

My guess is that this value should be the same as the amount you need
to drag a maximized window to "shake it loose": see bug #93586.

Of course, right now that feature hasn't been incorporated and its
value is currently hard-coded too :)  So you probably want to
co-ordinate with Havoc on this.

Havoc fixed this in metacity by using the gtk-dnd-drag-threshold
setting (it is multiplied by 6). We can do this too, but it won't be
'shared' with metacity: if it get changed there, we won't know it...

I guess it's not particularly important the value is identical to that
in metacity, to be honest.  Just as long as they're both some sensible
function of the dnd threshold, so that somebody with mobility problems
sees an improvement if they have to bump up the value.

Created attachment 21980 [details] [review]
Proposed patch

With this patch, we now use gtk-dnd-drag-threshold to determine the
snap tolerance. I just did like in metacity and use a factor of 6 (6 *
gtk-dnd-drag-threshold), but maybe we should use a lower factor...

Hmm, I'd prefer to just calculate the snap_tolerance and stick it in
toplevel->priv so we don't need to keep getting it from the
GtkSettings buts its a bit of a pain in the arse 'cause you'd need to:

  1) Connect to "notify::gtk-dnd-drag-threshold" on the GtkSettings 
  2) Update for the new GtkSettings when we move to another screen.

Also, you can't do this until the toplevel has had its screen set.

Couple of other nits:

  + Don't use a magic number for the default threshold. Do:

      #define DEFAULT_DND_THRESHOLD 8

  + DRAG_THRESHOLD_TO_SNAP_TOLERANCE_FACTOR is a little long :-)
    Perhaps SNAP_TOLERANCE_FACTOR ?

  + Its common practice to do:

    g_object_get (G_OBJECT (settings),
                  "gtk-dnd-drag-threshold", &threshold,
                  NULL);

    Its a nice idiom because it puts the variable to hold the property
    beside the property name ... easy to read

Apart from that it looks fine - go ahead with whatever you think is
best.

Vincent, just checking in on this.  Has the patch been commited?

This looks good to me, I'd say go ahead if it hasn't already been done
and close this bug out.

I did not have the time to update the patch and I won't be able to
work on it before January. But be sure I'll do it :-)

Vincent: any update ?

Still busy :/
I should have more time in a few days.

Apparently still busy? :)

I committed something that should help with the original bug. But this patch
should still be updated. I had forgottent about it.

Sorry for the spam. Mass-marking some bugs to the 2.10.x milestone.
 Filter on "VINCENT WANTS THIS FOR 2.10" to ignore.

2005-01-12  Vincent Untz  <vincent@vuntz.net>

         Use gtk dnd threshold value for snap tolerance
         Fix bug #107776.

        * panel-toplevel.c: (panel_toplevel_move_to): updated to use the
        snap_tolerance in the private structure
        (panel_toplevel_rotate_to_pointer): ditto
        (panel_toplevel_calc_floating): ditto
        (panel_toplevel_update_normal_position): ditto
        (panel_toplevel_update_auto_hide_position): ditto
        (panel_toplevel_drag_threshold_changed): new, update the
        snap_tolerance when gtk-dnd-drag-threshold has been changed
        (panel_toplevel_update_gtk_settings): new, update the GtkSettings we
        watch and disconnect from the previous one
        (panel_toplevel_screen_changed): call
        panel_toplevel_update_gtk_settings()
        (panel_toplevel_finalize): disconnect the handler for
        gtk-dnd-drag-threshold changes
        (panel_toplevel_instance_init): initialize the new fields and the
        GtkSettings we watch