GtkToolbar drag and drop
- From: Soeren Sandmann <sandmann daimi au dk>
- To: gtk-devel-list gnome org
- Cc: jamesh daa com au, marco gnome org
- Subject: GtkToolbar drag and drop
- Date: 29 Sep 2003 22:40:08 +0200
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.
Søren
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]