Re: long standing dnd bug fixes

[Bill Haneman <bill haneman sun com>]

Hi Owen and Tim:

DND stuff has been on my "must look at this" list for too long, but I
haven't had the cycles.  So I will put a matter to you for your
consideration... I'd be very grateful if you could give me your
off-the-cuff assessment with respect the the existing API and
implementation.

In order to satisfy the accessibility requirements (for instance as
stated in the '508' guidelines) that all UI actions have accessible
equivalents, we've proposed that "drag" and "drop" be (eventually)
exposed as AtkAction "actions" on UI components.  The semantics are as
follows:

"drag" == initiate drag operation using component (source of AtkAction)
as drag source;
"drop" == use source of AtkAction as drop target for currently active
drag operation.

It would be nice, but arguably not immediately necessary, if there were
a way to do this via the keyboard only, but exposing DND via AtkAction
as above would be mostly used programmatically by assistive technologies
(screen readers, onscreen/dynamic virtual keyboards, etc.).  From a
GTK+/ATK perspective the at-spi code would call :

atk_action_do_action (source_object_atkaction, drag_action_index);
...
atk_action_do_action (target_object_atkaction, drop_action_index);

where the indices were retrieved by querying atk_action_get_action_name
(source_object_atkaction, i).


The question for you is whether there are any known issues that would
prevent implementing this at the moment, e.g. is there a way to initiate
drag and drop actions on GTK+ components programatically (presumably via
emission of the appropriate signals) ?

If there are existing issues or suitable user signals do not exist we
need to examine this ASAP I think.

best regards,

-Bill

Timj said:

> On 4 Jan 2002, Owen Taylor wrote:
> 
> > Tim Janik <timj gtk org> writes:
> 
> > > 2) wrong drop position calculations within scrolled windows that have
> > >    non-0 scroll offsets (and probably other cases where parent->window !=
> > >    gtk_widget_get_parent_window (child)).
> 
> >  - A simple test case (sticking testdnd in a scrolled window)
> >    works fine with the old code.
> 
> the setup i use in beast is actually a VBox in a scrolled window (i.e.
> NO_WINDOW) which is drag destination.
> after a couple of hours poking, i believe the issue going on is:
> 
>           gdk_window_get_position (window, &tx, &ty);
>           new_allocation.x += tx;
>           x_offset += tx;
> 
>           if (new_allocation.x < 0)
>             {
>               new_allocation.width += new_allocation.x;
>               new_allocation.x = 0;
>             }
> 
> as far as the allocation is concerned, it is just size constrained,
> the required pointer offset is kept in x/y_offset.
> 
>           GtkDragFindData new_data = *data;
> 
>           new_data.x -= x_offset;
>           new_data.y -= y_offset;
> 
>                 gtk_drag_find_widget (tmp_list->data, &new_data);
> 
> this portion offsets the pointer relative to child->parent->window and
> then recurses to child, while:
> 
>           data->found = data->callback (widget,
>                                         data->context,
>                                         data->x - new_allocation.x,
>                                         data->y - new_allocation.y,
>                                         data->time);
> 
> only offsets the old pointer (still relative to widget->parent->window)
> with respect to the constrained allocation. it however fails to offset
> the pointer relative to widget->window via x/y_offset.
> 
> the apropriate fix is then:
> 
> diff -u -p -u -r1.77 gtkdnd.c
> --- gtkdnd.c    2002/01/04 18:28:18     1.77
> +++ gtkdnd.c    2002/01/07 07:47:12
> @@ -1342,8 +1342,8 @@ gtk_drag_find_widget (GtkWidget       *w
>         {
>           data->found = data->callback (widget,
>                                         data->context,
> -                                       data->x - new_allocation.x,
> -                                       data->y - new_allocation.y,
> +                                       data->x - new_allocation.x - x_offset,
> +                                       data->y - new_allocation.y - y_offset,
>                                         data->time);
>           /* If so, send a "drag_leave" to the last widget */
>           if (data->found)
> 
> it fixes beast, doesn't break testdnd, should be reasonably explained
> above and i had other changes pending in the same tree, so it's already
> committed.
> 
> >
> > Regards,
> >                                         Owen
> 
> ---
> ciaoTJ
>