https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    maybe you guys can all help each other... exciting more people writing backends... i was sure it would only ever be a "me thing"... now everyones at it 😄
  • m
    Maybe 🙂
  • m
    @elegant-twilight-61392 the most important thing to do is get one of the existing backends running that you're going to look at and put breakpoints in to help you understand what is calling what
  • m
    I had an "aha" moment the other day when I was trying to figure out how it all fit together... was in ComponentImpl onAdd function in the heaps backend, where it checks if the parentComponent is null and if so adds it Screen.instance.addComponent
  • m
    In the openfl version (I just checked) it's onAddedToStage
  • m
    That might not sound like it makes any sense yet, but openfl needs to have these things added to its list of things to render, and so the root components (which in openfl inherit from Sprite) need to be added to the stage
  • m
    In heaps it gets added to the h2d scene, and in my backend I'm creating a new UIManager so it'll end up adding it to that
  • m
    The other thing to take a look at is whether Godot will let you set up a clipping rectangle for its sprite like openfl does (scrollRect)
  • m
    As I believe this is how each component is masked to only render inside its parent's borders
  • a
    ask questions here if you get a stuck
  • a
    also I git cloned pretty much all of the main backends into a local haxelib folder next to my backend so I could easily command pallete to all the different implementations
  • a
    they all have unique ways of doing things so one of them may have the 'right way' for your backend as opposed to just one of them having all of the solutions
  • e
    damn, i cant make the 
    ComponentSurface
    just a typedef for godots 
    Control
    node ☚ī¸
  • e
    the ComponentCommon that extends ComponentSurface adds a _ready var, but _ready is godots on ready function basically
  • b
    billy had the same problems... you'll have to use composition for now... renaming an internal var like 
    _ready
    => 
    _componentReady
    isnt such a big deal
  • e
    Copy code
    hx
class ComponentSurface {
   public var node:Node;

   public function new() {
      this.node = new Control();
   }
}
    should work too, right?
  • b
    yeah, should be fine...
  • a
    tbh the inheritance ain't that awkward
  • a
    gives a good excuse for some conveniences
  • e
    it would probably help if i made 
    Node
    be 
    CanvasItem
    instead because while all `Node2D`s and `Control`s are `CanvasItem`s, `Node3D`s are not canvas items lol
  • e
    but i have to use either 
    Control
    or 
    Node2D
    because you cant directly instance a 
    CanvasItem
    , at least in the editor
  • a
    you want to have a unifying base type
  • e
    CanvasItem
    has all the relevant drawing methods
  • e
    so it doesnt matter if its actually an instance of 
    Node2D
    or 
    Control
    or really anything else that extends either of those
  • e
    pretty sure like 70% of the nodes you can create in the editor are based on 
    CanvasItem
  • e
    so i need the user to pass an instance of the 
    ToolkitOptions
    object (containing the root godot node to add things to), but is there a way to throw an error if they dont?
  • m
    I've only seen trace messages but I guess you could just throw an error.
  • m
    trace("WARNING: trying to add a component to a null root. Either set Screen.instance.root or specify one in Toolkit.init");
  • e
    yeah, but like where would i check this? HaxeUIApp extends AppImpl so i cant do it in the constructor
  • m
    That one is in ScreenImpl
1...140914101411...1687Latest