https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • m
    The reason I'm doing this is because I've been working on resurrecting an engine called BabylonHx and it is doesn't have a GUI framework. I'd like to bolt HaxeUI on as the GUI implementation.
  • h
    font drawing directly in GL is going to be fun - I did some in a frag shader for a helloworld thing but doing it for real would have a lot of things to take care of - of course you could use textures for the letters rather than drawing them
  • m
    Yeah, to be honest I'm just going to borrow the code from another engine. I was looking at heaps implementation and it uses a bitmapped font and builds out a vertex buffer, rendering each letter as a quad with UVs mapped to the font texture.
  • h
    oh ok - makes sense
  • m
    Ya cool I've been able to figure out how to start debugging this using the heaps backend whew
  • b
    So @melodic-advantage-23638 - you are pretty spot on, native backends map haxeui-core components to some native widget framework (like wx, or qt, etc). Composite backends (which is basically all of them) simply implement a number of functions in ComponentImpl (and other "Impl" classes) and then all of the haxeui composite components are available to you
  • b
    the first steps i usually do are i copy the skeleton backend and just make sure that works... so copy it somewhere and rename to, dunno, "haxeui-gl", then 
    haxellib dev haxeui-gl /path/to/folder
  • b
    then i include that in a test project and make sure that i get all the traces...
  • b
    then i usually do something like 
    <box width="100" height="100" style="background-color:red" />
    and then start to implement the drawing, so for example, that one liner to work effectively, will need to implement 
    handleComponentPosition
    , 
    handleComponentSize
    , 
    applyStyle
    ... and then i just slow ramp up complexity but adding more boxes, nested, autosized etc
  • b
    and yeah, text is certainly going to be the most challenging, the basic way it works in core is haxeui will make a call t "getTextDisplay()", this is a class tree where part of it will live in the backend... and then its up to you to "honour" that text info that core sets, like x, y, text, style etc
  • b
    anyway, lemme know if you get stuck - if you managed to create any notes, that might be super useful for a new section in the guides i dont think writing new backends is common, but its certainly an important part of haxeui, so might be nice to have a guide
  • p
    > and yeah, text is certainly going to be the most challenging, the basic way it works in core is haxeui will make a call t "getTextDisplay()", this is a class tree where part of it will live in the backend... and then its up to you to "honour" that text info that core sets, like x, y, text, style etc Piece of advice, if you ever want to support anything fancier than ordinary latin text: use HarfBuzz. (Ie what everyone else already uses)
  • b
    yeah, tbh, generally what haxeui does it uses what the backend framework uses - but with this proposed "gl" or "lime" backend i dont know if thats has its own text stuff
  • p
    Lime has harfbuzz bindings.
  • b
    right, maybe this was about raw gl calls then, dunno, but there was a mention above about "text is going to be fun" (as in complex)
  • m
    Thanks, this is great info. I'll start by taking your advice, Ian, and create a new backend from the skeleton and go from there. I'll ask look at harfbuzz and see how the other backends might be using it.
  • b
    @hallowed-ocean-84954 - long shot here, but im trying to remember why i cancel the mouse over event when showing a tooltip... since i think you use tooltips the most then maybe it was something you found... and recollection? Also, what happens if you comment out this line: https://github.com/haxeui/haxeui-core/blob/master/haxe/ui/tooltips/ToolTipManager.hx#L69 Do your tooltips still work as expected?
  • h
    ok one issue I recall is that I have tooltips at two levels in an accordion - and there was a problem with only the top level one appearing not the ones for the sections of the accordion
  • h
    I remember reporting that and you tweaked something - might have been this ?
  • h
    @bright-gpu-74537 ^
  • b
    ah, yeah, i think thats exactly it
  • b
    thanks for the memory jog 🙂
  • h
    no worries
  • r
    @bright-gpu-74537 (attached) causes a crash on Heaps when the button is clicked, crashing at line 866 of heaps's h2d/Scene.hx, because the number of layers is larger than the number of children. The old instance 'd' is no longer in children, but the new one 'e' is.
  • r
    (CustomDialog is just a vbox containing a dialog containing a button)
  • r
    Is this just something I shouldn't be doing? Or is there another bug in Heaps?
  • r
  • b
    so i dont think you should be adding and removing dialogs from s2d yourself... haxeui handles that, also, whats 
    d.dlg
    ?
  • b
    ok, so yeah, looking at the gist you are kinda using dialogs incorrectly
  • b
    in CustomDialog, make it extends Dialog (and not VBox), also update the xml to the same (ie, remove the top level )
1...137213731374...1687Latest