Re: GtkToolbar drag and drop

[Marco Pesenti Gritti <marco gnome org>]

> 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.

> So here is a patch that implements this (including Mac OS X style
> sliding) with the difference that
> gtk_toolbar_highlight_drop_location() takes an extra "height"
> parameter so it can work with vertical toolbars.
> 
> It would be nice if someone would review the patch.
> 
> 
> Questions (mostly for Marco, I guess):
> 
>         - Is this API usable for the toolbar editor, ie. will it be
>           possible for the toolbar editor to generate the correct
>           width and height for the new item?

Yeah, in general I think it should not be a problem. Instead of creating
the item on drop, we create it on moving and get his size. I'm not sure
how to generate the size for expand items though.

>         - would it be better to pass in the new GtkToolItem instead of
>           the (width, height) pair? This would allow more flexibility
>           in the exact highlighting algorithm since the toolbar could
>           know everything about the new toolbar, not just its width
>           and height.

Pro:

- More flexibility in highlighting algorithm
- Possibly better highlight for expand and pack end items
- Somewhat nicer api. User just need to pass the item without having to
worry about size.

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

When the api is decided, I can port the editor to the new api, to
confirm that there are not problems ...

Marco