https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • r
    For the most part it's easy enough to get it to do things, but often when I've had a problem and shown code, the cause of the problem is that you're not supposed to do it like that
  • r
    So definitely having a bunch of "how this is intended to be used" things would be handy
  • p
    I have this @:bind(sourcetxt, KeyboardEvent.KEY_UP) function updatetxet1(_){ destinationtxt.text=sourcetxt.text; } If sourcetxt is dynamically added how can I do this. I always use the bind meta. Should I just add a getter/setter on dynamic field?
  • b
    What behavior?
  • b
    you cant use bind meta if the component is added at runtime, bind builds up code at compile time, so the component will need to be known then
  • b
    i think the general question was: how to remove (and optionally destroy) ceramic "things" (visuals i think)... 
    App.app.scenes.main.remove(component.visual);
    doesnt seem to do anything (visually) - but NotBilly knows his backend better than i do ofc 🙂
  • b
    Ah right, a visual with no parent is still visible
  • b
    Setting visual.active = false is the way to go
  • b
    (If you plan to reuse that visual later, otherwise just destroy())
  • b
    cool - he did mention maybe that was the prop... and what about if you wanted to remove and destroy... like "i dont need this anymore"
  • b
    ok, destroy, gotcha
  • b
    out of curiosity, what does "remove" do then?
  • b
    It removes a visual from its parent, that’s it
  • b
    gotcha... but still draws it?
  • b
    Yes
  • b
    I have been wondering about changing this behavior or not but that certainly would be a breaking change
  • b
    maybe: 
    function remove(x, deactivate:Bool = false)
    ?
  • b
    ¯\_(ツ)_/¯
  • b
    might just be me, but removing an item from a parent and it still rendering seems counter intuitive, remove (to me) kinda implies "remove from display" also
  • b
    so maybe 
    function remove(x, deactivate:Bool = true)
    - but as you say, breaking change
  • b
    This kind of api is not really ceramic-style
  • b
    And no that’s not the same thing
  • b
    Think about the DOM in html
  • b
    Oh well forget that my point is not even one
  • b
    whats not ceramic style? Default params?
  • b
    Calling a method that change the state of the object
  • b
    i guess with docs its not an issue, but personally, i would certainly be a little "huh?" when i removed a visual and it was still rendering, but im sure some docs on remove would clear it up easy enough
  • b
    gotcha
  • b
    In general, I think it's more readable to have 
    thing.active = true
    than a 
    true
    argument that doesn't mean anything unless you already know the context, check the documentation of the 
    remove()
    method etc...
  • b
    And regarding Ceramic, most settings on visuals and entities are vars/properties
1...155915601561...1687Latest