there's a couple problems: • origin is not the same as top-left. I know they're mostly conflated in the current model, but they're different concepts. • the biggest issue is that using the top-left of all the enclosed elements as the origin is problematic for generic tree walking with origin and children.

I agree that they're not the same thing, my longer message wrote that and the earlier rant, there's 3 concepts imo: where do I start drawing my children, what's my collision top-left, what's the centre of my coordinator system relative to my parent

there's way more than 3

Haha there's always more

Those 3 seem most important but I could well be wrong

depends on the use case. the nice thing is that you can add more orthogonally to the rest.

Within-bounds uses origin as top-left I think, although it's not a common problem as it would be unusual to add a handler to a vector

But if you did, I think you'd want the minimal bounding rect not the rect to 0

if you look at how the event handling works. it calls within-bounds on every mouse click as it walks the whole tree

Or tbf better would be to check each contained components recy

Rect*

Re orthogonality that's what I've done, written a rough top-left protocol and extended it across all the basic types

I do want to revisit the model at some point

I'm hoping that I can add a ui2.clj and backport all the protocols to ui.clj. Users can upgrade their code as they see fit, no breaking changes, and everything happily coexists

Is backwards compatibility important already?

I don't want to break any existing code unless there's a good reason

and usually there's not a good reason since there are methods for making improvements without breaking anything

however, if there was a compelling reason, I would consider it

membrane is still in beta

I don't believe in "perpetual" beta. I am working towards a 1.0 where I can make stronger guarantees about backwards compatibility.

there's always a temptation to trigger events during drawing, but it's almost never the right choice.

It seems like you want to finalize text editing regardless of whether a frame gets drawn or even if there's no display at all (ie. testing, debugging, tooling).

The condition is on loss of focus, otherwise you're handing a dB for no reason, the only other thing I can think would be to denounce it but I don't like that

Hammering a dB*

*debounce

I agree doing it in draw is rough

yea, I definitely think taking action on loss of focus is a valid use case. just working towards the explanation of how to handle it

> when an event ISNT happening to this component. The general way to add a [:check-finalize] effect on every change to a component is wrapping a component with on-bubble, but that doesn't work for loss of focus since focus is a global, contextual property. Conceptually, the other problem is that events don't "happen" to components. There's the app state and effects that modify the app-state.

what kind of effect is happening during text editing finalization?

Want to write the text change back to the dB

the reason I ask is that there are multiple ways to go about it: • use add-watch. this is great for non-urgent cleanup. you can put all the app-states in a queue and use something like requestIdleCallback` to clean up when there's some spare cycles. • you can augment your effect handler's :set and :update intents to check if focus has changed and makes changes in a consistent way

Effect handler as in the global one?

there is no global effect handler. I'm referring to the main effect handler for your app.

Yes ok 1 sounds like the approach is had considered, 2 I hadn't considered but makes sense

Sorry global is imprecise, but the one specified once per app as you say

I would definitely go for add-watch for your use case.

You probably want to add debouncing anyway

you can do simple deduping with add-watch since you get both the old and new state

The problem with add-watch is that focus gets set to a gnarly route but I can add something to help me connect those routes back to aj easier description of which component is which

If that makes sense

if you're using core.async, then you can have a queue that gets the state, checks for changes, adds debouncing, maybe add a frequency limiter, etc.

Like push an id in somewhere and something to connect the focus path back to that

> The problem with add-watch is that focus gets set to a gnarly route but I can add something to help me connect those routes back to aj easier description of which component is which yea, that's a fair point if you're using textarea, there's a lower level component that can help:

(defui textarea
  "Textarea component."
  [{:keys [text
           border?
           font
           ^:membrane.component/contextual focus
           textarea-state]
    :or {border? true}}]
  (on
   ::request-focus
   (fn []
     [[:set $focus $text]])
   (textarea-view {:text text
                   :cursor (get textarea-state :cursor 0)
                   :focus? (= focus $text)
                   :font font
                   :down-pos (:down-pos textarea-state)
                   :mpos (:mpos textarea-state)
                   :border? (or border?
                                (nil? border?))
                   :select-cursor (:select-cursor textarea-state)}))
  )

however, you probably want the focus value to be related to the identity of the text property. you can either have your wrapper accept an explicit id (if you have one).

since textarea uses $text as its focus value, you can also just grab the value. something like

(component/default-get state-atm (-> @state-atm :membrane.contextual :focus))

Good point about the wrapper, does make it simpler to modify the focus

that would break if there's another component that sets* its focus value to something else

I don't understand the default-get snippet, is that a cleaner way than me explicitly writing the path [membrane/contextual : focus]

Sorry on phone I'll ask less stupid questions when I get back

it's a good question. default-get will look up the value of a reference in the state atom.

there's the builtin intents, :set, :update, and :get that work with references. component/default-get is the builtin handler for :get

usually, you're doing something like [:set $my-ref new-val] . there's a corresponding intent, [:get $my-ref].

I understand, my direct access method is in a way an implementation detail of the default effect handler right

I didn't know about those methods thanks

I think direct access is ok. There are some cases where having some indirection is useful, but it's sometimes easier to be direct.

my main point was that the focus value has the reference to the text passed to the textarea and the :get intent is how you can lookup the value of a $reference.

I haven't tested this code, but I would probably go with something like:

(defn is-textarea-focus? [x]
  (and (vector? x)
       (= :textarea (first x))))

(defui textarea
  "Textarea component."
  [{:keys [text
           border?
           font
           ^:membrane.component/contextual focus
           textarea-state]
    :or {border? true}}]
  (on
   ::request-focus
   (fn []
     [[:set $focus [:textarea $text]]])
   (basic/textarea-view {:text text
                         :cursor (get textarea-state :cursor 0)
                         :focus? (= focus $text)
                         :font font
                         :down-pos (:down-pos textarea-state)
                         :mpos (:mpos textarea-state)
                         :border? (or border?
                                      (nil? border?))
                         :select-cursor (:select-cursor textarea-state)})))

(add-watch state-atm
           ::focus-finalize
           (fn [k atm old new]
             (let [old-focus (-> old ::component/contextual :focus)
                   new-focus (-> new ::component/contextual :focus)]
               (when (not= old-focus new-focus)
                 (when (is-textarea-focus? old-focus)
                   (let [[_ $old-text] old-focus
                         old-text (component/default-get atm $old-text)]
                     (do-something-with-text old-text)))))))

thanks so much for your help, I'll roll with this approach see how I go.

I would love to hear how it goes. I've tried a few of these techniques before, but I still want to collect more user stories so that I can add helpers and improve documentation.