
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi list,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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: <a href="https://imgur.com/gallery/S6w7yMG" class="">https://imgur.com/gallery/S6w7yMG</a> ).</div><div class=""><br class=""></div><div class="">My way: Edit the images to make the corners transparent (which will become the image on the right in the link above).</div><div class="">- Pros: 1) Brainlessly easy. 2) No risks of breaking anything we currently have, since the only changes are made in the abstractions themselves.</div><div class="">- Cons:</div><div class="">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.</div><div class=""><br class=""></div><div class="">Ico’s way: Make the xlets rendered after the border and GOP area.</div><div class="">- 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.</div><div class="">- 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)</div><div class="">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.</div><div class="">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.</div><div class="">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.</div><div class=""><br class=""></div><div class="">That basically summarises what we’ve been thinking, and we are looking forward to your input. Thanks!</div><div class=""><br class=""></div><div class="">Best</div><div class="">Shaoqian</div></body></html>