GtkToolbar drag and drop

The three remaining toolbar bugs on the 2.4 milestone are about drag
and drop:

	- 116297, handle pack end in gtk_toolbar_get_drop_index()

	Currently the toolbar can, given mouse coordinates, report the
	index a newly dropped tool item should be positioned at. At
	the moment this function doesn't handle pack_end items
	correctly. This is just a bug that should be fixed.

	- 116298, toolbar should not handle arbitrary targets

	The issue here is that the toolbar claims to handle arbitrary
	drags.  This means it will look like you can drop strings or
	colors or or dates on the toolbar.

	Owen suggests that we should define a new drop type of things
	that can be dropped on the toolbar, but the problem with that
	is that for example epiphany wants to drop URI's on the
	toolbar and have them turn into bookmarks. I can also imagine
	interfaces where it would be possible to select something and
	temporarily store it on the toolbar.

	I think it is fairly clear that the application needs to be in
	charge of deciding what can be dropped on toolbars.

	- 110919, shift existing items over

	This bug tracks a feature request that the toolbar should
	indicate drop locations by shifting the other items to give
	the user an idea how the toolbar is going to look after the
	item has been dropped, an idea taken from Mac OS X.

To fix these bugs, I propose this:

        * Make the application responsible for handling drops on the
          toolbar. This means remove all drag_motion handler etc. from
          the toolbar and require the application to implement it
          through the standard gtk_drag_* API.

          This would enable applications and toolbar editors to decide
          what can be dropped on a toolbar.

        * Add new API

                gtk_toolbar_highlight_drop_location (
                        GtkToolbar *toolbar, gint x, gint y, 
                        gint width);

                gtk_toolbar_unhighlight_drop_location ();

          This API would allow the implementation of Mac OS X style
          sliding toolbar buttons.

The alternative to the above is to just fix the current toolbar so
that it will only look like a drop target when the drag matches the
application-specified GtkTargetEntries. The two reasons I don't think
this is enough are:

        - If an application has two toolbars and a toolbar editor
          where some of the items can only be applied to one of the
          toolbars, we would need two different toolbar item drop
          types to distinguish the cases. Maybe this isn't a big
          problem in practice.

        - There would be no way to do Mac OS X style button sliding,
          because that feature requires that the toolbar knows the
          width of the new item.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]