My previous post on Drag-and-Drop in lists made some compromises in order to present the simplest, fully functional implementation. One of these was that we could only draw the drop target highlight around entire rows, whereas the drop really inserts the dropped row between rows. Lets try to do better!
Changing the target
In the simplified version, we made every row a drop target. This time around, we will change this and have just the list itself accept drops.
gtk_drag_dest_set (list, GTK_DEST_DEFAULT_MOTION|GTK_DEST_DEFAULT_DROP, entries, 1, GDK_ACTION_MOVE); g_signal_connect (list, "drag-data-received", G_CALLBACK (drag_data_received), NULL);
If you compare this to what was done before, you may notice another change: Instead of GTK_DEST_DEFAULT_ALL, we now just request the default behavior for motion and drop. We no longer request the default behavior for highlighting, since we want to handle that ourselves.
In order to do so, we need to connect to the drag-motion and drag-leave signals. These are emitted on the drop target, i.e. the list:
g_signal_connect (list, "drag-motion", G_CALLBACK (drag_motion), NULL); g_signal_connect (list, "drag-leave", G_CALLBACK (drag_leave), NULL);
Mind the gap
The basic idea for our improved drag highlighting is that we keep track of the two adjacent rows between which the drop will happen, and use the GTK+ CSS machinery to create a suitable highlight of the gap.
This requires a bit too much code to show in full here, but the idea is as follows: Find the row that is currently under the cursor with gtk_list_box_get_row_at_y(). Look at its allocation to to find out if the cursor is in the top or bottom half of the row. Depending on that, we pick either the following or the preceding row as the other member for our pair of rows.
row = gtk_list_box_get_row_at_y (list, y); gtk_widget_get_allocation (row, &alloc); if (y < alloc.y + alloc.height/2) { row_after = row; row_before = get_row_before (list, row); } else { row_before = row; row_after = get_row_after (list, row); }
There are some corner cases which I am omitting here, e.g. when the hovered row is the first or last row, or when we are hovering over ’empty space’ in the list.
CSS Highlights
I said we would be using CSS for creating the highlight. The easiest way to do so is to just add style classes to the two rows we’ve found:
gtk_style_context_add_class ( gtk_widget_get_style_context (row_before), "drag-hover-bottom"); gtk_style_context_add_class ( gtk_widget_get_style_context (row_after), "drag-hover-top");
And then we will use some custom CSS to create our highlight. In case you are wondering: #4e9a06 is the drag highlight color used in the Adwaita theme.
.row.drag-hover-top { border-top: 1px solid #4e9a06; } .row.drag-hover-bottom { border-bottom: 1px solid #4e9a06; }
This is again omitting the corner cases that I’ve mentioned before.
How did we get here ?
Dropping the row onto the place it came from does not achieve anything. It makes sense to mark the place where the drag started in some way to make this obvious. We can again use CSS for this, and add a style class to the dragged row in our drag_begin() method:
gtk_style_context_add_class (gtk_widget_get_style_context (row), "drag-row");
In order to give the row a bit a highlight when we are hovering over it, we add an extra style class to it in our drag_motion() handler:
if (row == drag_row) { gtk_style_context_add_class (gtk_widget_get_style_context (row), "drag-hover"); row_before = get_row_before (row); row_after = get_row_after (row); } else …
And here is the CSS for these classes:
.row.drag-row { color: gray; background: alpha(gray,0.2); } .row.drag-row.drag-hover { border-top: 1px solid #4e9a06; border-bottom: 1px solid #4e9a06; color: #4e9a06; }
Putting it all together
(Sorry about the broken cursors. We should really fix this in gnome-shell’s screen recorder.)
References
- The complete example, testlist3.c
- The GTK+ DND documentation
Exciting!
Do you see an easy path towards implementing scrolling within the drag & drop, and also constraining the dragged rows in the list container (instead of being able to even drag it out of the window)?
A design doubt I have is how to implement accessible and discoverable navigation and reordering. I am not sure whether just keyboard shortcuts is the way to go.
Thanks for these posts. It is very clarifying when a toolkit developer sees the toolkit from the application developer point of view.
Support for scrolling would ideally need some support from the toolkit. I want to look at it though. Maybe a future post.
As for accessible reordering – dnd is really not involved here. You could implement a ‘reorder mode’, in which the active row is highlighted and can be moved around either with up/down arrow keys or with some overlayed buttons.