So I’ve been tasked to try an animated approach at Drag’n’Drop to rearrange child widgets inside a specific container widget in libegg (EggSpreadTable), and I’m throwing this out in public just in case someone might have some better ideas than I do currently.
The EggSpreadTable is something like a GtkTable or GtkGrid that takes a list of widgets and displays them in a fixed number of columns, the spread table “spreads” out widgets evenly across the columns in order to consume the least height as possible (important thing to keep in mind is that widgets can shift across columns to make better use of space).
The desired effect is the one produced when running libegg/toolbareditor/test-toolbar-editor… which uses gtk_toolbar_set_drop_highlight_item(), an obscure and highly complex piece of code which is responsible for highlighting potential drop targets in the toolbar by animating other items out of the way.
My plan so far is a little abstract but I’m going to have to write code now and see if it works:
- When a drag’n’drop (DnD) operation is in effect, and “drag-motion” is being emitted, I think I’ll have to “lock” the spread table so that widgets don’t jump from column to column, this will avoid hovering a drag source at the end of one column and having the animation show the widget at the beginning of the following column, which I think would be unintuitive.
- When performing DnD animations, not only will we have to animate widgets up and down inside the potential “drop column”, but we’ll have to call gtk_widget_queue_resize() repeatedly whilst the spread table will have to grow in order to fit the new drag source into the column somewhere.
- To look more intuitive, when a drag begins the drag source widget will have to “slide out” of it’s parent spread table, which will require the same animation technique whenever a drag begins. Likewise, when a drag fails the widget should be animated back into place.
- Once a widget is successfully dropped in a said spread table (widgets can be dragged and dropped from one spread table to another), then the arrangement of widgets will still be invalid… the target spread table will have to unlock… at this point it’s also probably best to animate the rearranging of widgets (otherwise you get a nice animated DnD experience and when you drop you get this “snap” where widgets are rearranged in the target container).
- Another complication is that EggSpreadTable is a height-for-width container, the size and space that the target placeholder will use will depend on requesting the size of the the actual widget being dragged (it’s even possible the spread table will have to grow in width & height to fit the animation).
- And last but not least, of course it has to use GTK+’s horrid Drag’n’Drop apis.
The business logic will surely be horrid in all of this, many states will have to be managed and juggled while performing these various animations… not to mention the whole operation will require resizing of the spread tables in play (causing the whole interface to shift around, kind of like having a GtkInfoBar in play).
The toolbar code is evidently much more obvious, it only lines up a list of fixed size widgets in a row from left to right, when the widgets (tool items) don’t fit the toolbar anymore, an arrow is displayed and the rest of the items are placed in a drop down menu.
So all of this to say… anyone have any better ideas ?