Re: GtkToolbar drag and drop

[Marco Pesenti Gritti <marco gnome org>]

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

I think the ui requirements for the throbber case (I couldnt thing any
other plausible use case, if there are others it would be good to know
about them):

1 Keep the throbber visible at the end of the toolbar, after the
overflow menu arrow. I think this is a strong requirement, being a form
of feedback and not a faster way to access a function available from the
menubar.
2 Have an efficient way of achieve user tasks (add spinner to a toolbar,
remove spinner from a toolbar, move spinner from a toolbar to another).
3 Keep the user model the simpler is possible

So:

1 As you say this is a Con of your proposal. Prolly this alone would
make the api not usable for the spinner case :/
2 With the expanding item proposal adding/removing spinner would become
a two step task.
3 I have the impression adding an expandable space only item would make
the user model unnecessarily more complex. In fact you have to add an
additional item just to make another one work correctly (assuming it's
only useful for the throbber case here). Also this item seem to require
some abstraction to the user: toolbar items are usually "objects" (and
they allow to take actions, but the spinner is a special case too here),
not layout helpers.

IHMO allowing the user to put the spinner in a particular position in
the toolbar is not necessary. It's a special case compared to the other
items but it's possible to make it visible by highlithing the toolbar
frame instead of the position where the item will be added. I think this
would make clear that the action that is going to be taken is "Add the
spinner to the toolbar" instead of "Put the spinner in this particular
position". The higlight of the whole toolbar could be used also in other
cases (an hipotetical example, autosorted bookmarks toolbar).
It's by no means a perfect solution but I have the impression it would
be easier to use.

I think the pack_end make this possible. The pack_end area would just
not be considered a valid dnd target and the drop feedback of packend
items could be special cased. Obviously this isnt very nice from an API
pov especially considering the genericity of set_pack_end. Though I
wouldnt particularly like the GtkActionEmpty that would be necessary for
the toolbar editor use the empty expandable item too.

Sorry for the long mail, it's a complex issue, and I'm just brain
dumping :/

I'm ccing Seth and Dave, as they can give better feedback than me on the
user interface issues, I'm not really the best person to give advises on
it.

Marco