I would like to preface by saying that if this is not a demand for work but is instead either a registration of the fact that this is useful to me as well as a request to be allowed to re-implement gtk_widget_pickas a vfunc following it~s removal in this commit.
The commit does not state the reason for the removal so re-addition would presumably require converse-ation with those removing.
I am currently developing a 2d widget layout canvas widget and alteration in the z-order when selecting new node-s is desirable.
The rendering z-order is easily customisable with gtk_widget_snapshot
The current picking z-order is determined by gtk_widget_pick which uses the order of child nodes and it is not over-ride-able gtk_widget_contains is a vfunc but this can not be used to over-ride the picking order.
One can therefore re-parent a widget to alter the picking order however performing this at certain time-s can interfere with other operation-s.
An example is in the canvas widget where i wish that a widget is raised to the top of the z-order on drag,
the code is re-parent-ing the widget on drag start but this inteferes with the drag operation:
Here is a fully functional drag as reference ( the drag never releases regardless of the inertia of the pointer):
If this would better be discussed on a created merge request on gitlab then I can do so
The Gtk code may be brought to a state which support-s custom picking order in a variety of different ways
There is a process: itās called āopening an issue with a strawman API in GitLabā.
You need use cases in multiple applications, because we donāt add API just because somebody, somewhere, wants it for their own use case; GTK developers are a slowly renewable resource, and maintaining an ever-increasing API with restrictions on backward and forward compatibility requires being careful in what we add. This also means that a lot of times your requests will be denied unless you bring a strong case for them.
More interesting to me would be a look at why exactly the dragging is interfering with the order of child widgets in the list, that sounds like it could be a bug.
Hi so in the first video, any widget that a drag is initiated upon is unparented and then reparented in order to bring it to the front of the z-order which is intentional.
The widget has a GestureDrag upon it
So in time order:
when parent.raise is not called in child.drag_start ( as in the second video) the dragging behavior works as expected but when the reparenting process occurs between drag_start and drag_update, the issue occurs.
I tried looking at the EventController api but there did not seem to be anything allowing manual reinitiation of the drag process
For my own means I have had enough time to think of a solution by implementing custom rendering order in snapshot during the drag and the reparenting after the drag
( maybe this reveals that my issue was made public too soon)
Perhaps you can try the motion event, which triggers every time the mouse moves (including a click). You can call pick here to move the child to the end.
Why all the repeated raising and reparenting onto the same container? Likely what you really want to do here is take the widget out and put it in a GtkDragSource while it is dragging so it can drag properly between windows.
