https://linen.dev logo
Join Discord
Powered by
# ceramic
  • b
    I believe that with the intercept overrides you should be able to handle every use case, and it’s probably a much better option than rebuilding the whole touch/click logic yourself
  • a
    Would it? I don't think it would because it's an interception either way
  • a
    there's circumstances where you want nested events
  • a
    but anyway lemme quickly switch out the standard Mesh with a CMesh and see what effect it has
  • a
    it would likely be obvious after that if it will handle all situations or not
  • a
    okay, the parent intercepting causes no components to work 😅
  • b
    There are plenty of ways you can say « if the child reacts to some event, then I want the parent to react too »
  • a
    really? how if defining an event on a child steals from the parent? 🤔
  • b
    Because you know your child is a child, you can get the parent of the child and do something on it
  • a
    hmm...
  • o
    After years of flash/feathers/pv3d/away3d working on user interfaces back in the day, I would say it sounds like ceramics mouse control is not as flexible as required in many real cases, but it may force you to build faster apps, the last large project had a flat emulated display list starling render and used a single mouse event and tested against visible hits mixing starling and away, it ended up fast. Probably the best approach is to build virtual structures above ceramics so you can change how you handle events.
  • o
    to be more haxe ui
  • o
    but that is just my first guess
  • b
    Like, using/displaying « hover » state on the container visual can be done when that container hits OR if the child hits (you can get the parent from the hitting child)
  • a
    this is true, but from the haxeui perspective I have no context on what a child/parent "should" do
  • b
    Again, I have yet to see a case that can’t be handled by Ceramic
  • a
    so i'm not sure if a child needs to handle an event or if both a parent and child do
  • a
    that's all handled in haxeui-core, not in haxeui-ceramic
  • b
    I’m 100% sure you can cover haxe ui use cases with Ceramic without rebuilding a whole touch system
  • a
    i believe you, i'm just stuck and not sure how to approach this. You did mention that I can grab the parent which was something i didn't consider
  • a
    it looks like i can also call a parents 
    pointer
    event from a child
  • a
    but from the backend's side, i don't have this information on components to apply logic here
  • a
    haxeui-ceramic is like the physical buttons on a remote control, haxeui-core just "asks" me how to do the physical actions
  • a
    core handles all that logic
  • b
    Well I don’t know what are the exact rules for haxe ui, but if the rule is « every parent should catch every event » then if any child get an event, you walk up through each parent and change the state you need to change
  • a
    Hey, that actually wouldn't be too hard to test pretty quickly lemme try
  • b
    Nah don’t call built-in events manually, it could have nasty side effects. But you can build any custom logic as soon as one of your visuals receive an event
  • a
    dang it jeremy - that api is public! 😄
  • o
    Virtual sprite
  • b
    Well, to my defense I was alone using Ceramic for a while 🤣
1...888990...124Latest