[L2Ork-dev] Design decisions to make regarding the z-order of the xlets of objects

[Jonathan Wilkes]

On Sat, Jul 13, 2019 at 11:51 PM Coniine Dieu <coniinedieu at gmail.com> wrote:
>
> Hi list,
>
> Shaoqian here, currently working under GSoC with Ico to port K12 Mode to Purr Data. There are a few design decisions we would like to ask the list for opinions.
>
> Current problem we have: The K12 abstractions uses [ggee/image] to display an image in the GOP area. Since in the <svg> of Purr Data, the <g> of [ggee/image] is rendered after the <g> for borders and xlets, and the images have white background, the xlets of the abstractions will be covered up (like the left one in this post: https://imgur.com/gallery/S6w7yMG ).
>
> My way: Edit the images to make the corners transparent (which will become the image on the right in the link above).
> - Pros: 1) Brainlessly easy. 2) No risks of breaking anything we currently have, since the only changes are made in the abstractions themselves.
> - Cons:
> 1) Will need to re-edit all the image if we change the size of the xlets, change the length or width of the image, etc. Basically, EVERYTHING that changes the appearances of the abstractions will introduce another round of “brainlessly easy” work of editing the images. Even worse, we can’t let the users customise the appearances (like the size of the xlets) because we can’t edit the images on the fly.
>
> Ico’s way: Make the xlets rendered after the border and GOP area.
> - Pros: 1) This is more consistent with the Pd-l2ork 1.x branch, because 1.x draws the xlets last. 2) Much much more robust against future changes that maybe introduced for more flexibility and accessibility. All the Cons of my way won’t exist.
> - Cons: (Below is copied from Ico and I’s Slack chat so it seems terribly long. I don’t mean that my way has less Cons)
> 1) In <svg>, there is no way to specify the z-order with a number. The only way to change whether a <g> is on top of another is by changing the actual order in the DOM. In our current implementation, borders and xlets are put into one <g>, and whatever operation is done to the object (selecting, moving, etc.) it is done to both the border and the xlets as a whole. Now, to render xlets after everything inside the object, we need to make a sandwich: one <g> for border, at least one <g> for content (either GOP, iemgui or text node), and one <g> for xlets. Not only this introduces a lot more <g>s, but new logic need to be implemented to handle the operations on the objects, both on the C side and the JS side. To make it worse, relevant code seem to be all over the place.
> 2) It's probably not worth it. We risk breaking things as we're trying to change the underlying part of the GUI. Besides, to display helpful tooltips when the user’s mouse cursor is hovering over the xlets, the z-order of the xlets aren’t important at all. Just like how we now highlight the xlets on hovering, Pd only checks for the coordinates of the xlets.
> 3) It prohibits the user from consciously covering the nlets with ggee/image. Not sure why anyone would want to do this (perhaps during an animation?), but we should probably let the user decide.

Unfortunately, it appears that graph_vis is so complex that we can
essentially call it a "write-only" function at this point.

Given that, we could just create a js function
"gui_move_graph_to_front" and add a call to it after the gobjs are
drawn. It would go here:

https://git.purrdata.net/jwilkes/purr-data/blob/master/pd/src/g_graph.c#L1139

That function would just grab the relevant <g> for the graph and move
it to the top of the Z order for objects (but still behind the cords).

Drawback is that this adds a DOM mutation which may cause a re-layout.
But that's probably worth it in order to get proper Z-order for GOP.

-Jonathan