Clojurians Log v2

what's the reason OnXXX take drawables instead of single drawable. imo no implicit conversation here is better, since (translate x y elem) and [(translate x y elem)] has different origin and bounds

(ui/origin (test-ui ...)) is [0 0]. maybe it wrap another layer of "container"? (i dont know the right terminology) what should i do if i want (test-ui ...) have origin [10 10]

wrap on something to translate also change the bounds. https://clojurians.slack.com/archives/CVB8K7V50/p1695499993982809 IMHO only translate / scale / other layout related function will change where the element should display and how large the size. on and others like style and color shouldn't change location/size

after investigate the code, i see OnXXX record take drawables as parameter, and the wrapped ui's bounds became a big rect including every drawables and the empty space between them. i am building a infinite canvas UI, figuring out how to group multiple drawables and preserve the empty space

> IMHO only translate / scale / other layout related function will change where the element should display and how large the size. on and others like style and color shouldn't change location/size consider the difference between:

(ui/on
 :mouse-down (fn [mpos])
 (ui/translate 10 20
               elem))
;; vs
(ui/translate
 10 20
 (ui/on
  :mouse-down (fn [mpos])
  elem))

in term of where the mouse-down can trigger. i dont think they should different. why include the top left empty space in first case? i also expect

(->> elem (translate x1 y2) (translate x2 y2) (bounds))
=
(->> elem (translate (+x1 x2) (+ y1 y2)) (bounds))

that's maybe arguable for translate, but translation is not the only element that shifts the origin

Another way to think about it is if you have a component with a translated child element at offset 10,20. If the child element has an origin at 10,20 and the component has an origin at 10,20, then when you generically walk the tree of elements using ui/origin and ui/children, then the offset will be double counted.

Having the origin of the component at 0,0 ensures that the origin isn't double counted.

https://github.com/phronmophobic/membrane/discussions/43#discussioncomment-2441082

Fwiw, many of the UI elements used to work the way you suggest and it caused weird bugs and edge cases due to the double counting problem.

I still think both ui/bounds and ui/origin are overloaded in their meanings and should be split into simpler concepts, but I haven't gotten around to it yet. A workaround is that it's fairly tractable to create a new protocol that uses ui/bounds and ui/origin the way you expect and extend it to the types in membrane.ui that you care about.

If the origin of a component is the same as the origin of it's child element, then what should ui/children return? How do you generically walk the tree of elements while keeping the current origin offset?

I know these questions sound rhetorical, but I am actually open to new ideas here. I would like to make a "membrane.ui2" someday that is backwards compatible with membrane.ui that includes some ideas for improvement I've learned along the way.

thank for your information, i need to draw some diagram to see.