https://linen.dev logo
Join Discord
Powered by
# ceramic
  • b
    You have a div inside another one
  • b
    the child div will always have priority over its parent
  • b
    The parent will catch events only if it doesn't hit the child it contains (given that the child also listens to the same event)
  • b
    If you don't want your child to steal focus, then your child shouldn't listen to the pointerOut/Over events
  • a
    The child isn't listening to them afaik 🤔
  • b
    I doubt it
  • a
    oh, hmm, it looks like you're right
  • a
    okay, so there's something here with haxeui that i'm not understanding
  • a
    thanks for talking me through this
  • a
    it might be that haxeui is applying event handlers in a way that may conflict with the ceramic behaviour here
  • b
    im not sure thats accurate
  • b
    my understanding (which may very well be wrong), is that in ceramic, in this example, you would only get a "inner" flash, accurate?
  • b
    Right, in Ceramic there will be only one element that catches the click
  • b
    But there is a way around it
  • a
    👀
  • b
    A visual can override 
    interceptPointerDown()
    or 
    interceptPointerOver()
    to block an event from being catched by a child, from a parent
  • a
    I did see that api, but, i'm not sure if it would work well with haxeui because it would require me to 1) the base type to a custom type, which i guess isn't super difficult but a user may not intuitively know they can treat 
    HaxeuiVisual
    the same as a ceramic visual 2) I don't think this workaround would work in haxeui because components would some times have children which need pointer events
  • b
    Well, for 2) you can use the logic you want to block, or not the event
  • a
    haxeui backends don't have custom logic for a per component basis, unless there's a haxeui api that i'm unaware of
  • a
    and the main issue here is only 1 visual will get the event (in either) circumstance
  • b
    no, thats accurate, they can cancel events though, but thats handled at the core level... ish
  • b
    thats exactly the problem... if you had 10 visuals, all nested and all had handlers and clicked the "last" one, i would have expected 10 events to fire (assuming the mouse was in the bounds ofc)
  • a
    a visual does have a hit test with an x/y coord, could a potential workaround be I map screen events to componentimpl and just check if the mouse is in bounds?
  • a
    maybe its easier said than done
  • b
    you could, but its a rats nest, you need to think about overlapping components, etc
  • b
    i do it in kha (since it doesnt have any sprites or visuals or whatever) and it more complex than "is in bounds"
  • a
    another potential option.. hmm
  • a
    Every event attachment, i could attach the event to each child of a visual? 😅
  • a
    just loop over the children and add it
  • a
    ah, no nvm, it would still be only 1 event
1...878889...124Latest