Re: GtkToolbar drag and drop

[Soeren Sandmann <sandmann daimi au dk>]

Marco Pesenti Gritti <marco gnome org> writes:

> > It turns out I misunderstood this. The issue is that the current dnd
> > implementation simply ignores pack_end items, ie. you can't drop new
> > items at the pack end location. James explains it in the bug:
> > 
> >         The idea of items packed at the end was to support things like
> >         throbbers in nautilus or web browsers.  If you are customising
> >         the toolbar of apps like this, you most likely want to ignore
> >         the throbber completely, which is why I implemented
> >         find_drop_pos() as it is.
> 
> I'm not sure what Jamesh mean with ignore here. In epiphany we provide
> the ability to add/remove the throbber. The highlight in that case
> is certainly confusing. Probably it would be better to highlight anyway
> the real position where the spinner will go, regardless of the drop
> position.

The toolbar currently assumes that you don't edit throbbers. So the
question is how to best add that functionality. Owen has two different
suggestions in http://bugzilla.gnome.org/show_bug.cgi?id=116297 . I
see a few problems with both, but I don't see any other possibilities:

      (a) Give find_drop_pos() an extra boolean out that indicates
          whether the new items is dropped at the end. The editor
          would do something like this on drag motion

                index = gtk_toolbar_find_drop_pos (toolbar, ..., 
                                                   &is_pack_end);

                if ((new item is throbber && is_pack_end)   ||
                    (!new_item_is_throbber && !is_pack_end))
                {
                        highlight_position();
                        accept_drop();
                }
                else
                {
                        unhighlight_position();
                        don't_accept_drop();
                }

          The problem with this is that this would reject perfectly
          good drop positions when the new item is pack front and the
          drop position just happens to be slightly closer to the
          throbber than to the last pack front item. 

          This problem might be solved by giving find_drop_pos() two
          extra booleans, "find_end_positions" and
          "find_front_positions", which when FALSE would indicate that
          the caller was not interested in the corresponding
          positions.

      (b) don't have the pack_end() property at all. Instead use an
          expanding, blank tool item to force things to the end.

          Pro: 
                - would allow users to customize their toolbars even
                  more, by adding "flexible space" to the toolbar.

                - Would allow users to put throbbers in the middle of
                  the toolbar and regular items at the end.

                - would be a substantial simplification of
                  gtktoolbar.c

          Con:
                - Throbbers and other items at the end of the toolbar 
                  would be the first things to be unmapped/relegated
                  to the overflow menu, instead of as now the last
                  things.

> >         - would it be better to pass in the new GtkToolItem
> >           [to gtk_toolbar_highlight_drop_location]?

[...]

> Unless there is an use case where you want to pass something different
> then item width/height, I cant see any con.

I'll do that, then. (The only con I had in mind was something like
"maybe the toolbar editor can only generate the new item when the drop
is actually finished" -- I'm not sure what I was thinking ...)


Søren