https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    I haven’t done anything, prioritizing text and my own project
  • b
    Aside from your fundamental structural issue, it was working fine last I checked
  • q
    Ah geez. So then neither issue got resolved? Is that what I understand?
  • b
    I don’t remember what the issues plural were
  • q
    Not ignoring the semi-implied query. Not in a condition to human interaction. I'll get back to you in a few days about it.
  • b
    That’s fine take your time
  • b
    monaco?
  • b
    the editor is yeah, wrapped in a haxeui custom component
  • b
    the minimap gives it away 🙂
  • b
    🙂
  • b
    not trying to hide thats its monaco 🙂
  • b
    at some point id like to create a full haxeui editor component that will work for all backends... sctintilla on wx for example
  • b
    the harder ones are the composite backends (openfl, kha, nme, etc)
  • b
    and also creating an API that works for monaco and scintilla
  • h
    Do you think it would be possible for it to translate the XML to valid Haxe code? I'm working with MVCoconut and it works really nicely with HaxeUI unless some abstractions start coming into play with the HaxeUI xml format. I think it's because MVCoconut tries to match the XML components with their Haxe-Class counterparts and sometimes the child structure doesn't really match how the Haxe-based code does it . . . . Or maybe there could be an option to translate it the standard XML to a format that represents the XML component structure literally? But aren't custom components a thing already that can use XML in Haxe code? Perhaps this means we can get an even smoother MVCoconut + HaxeUI integration? Thanks!
  • b
    hey, could you elaborate a little, im not sure i follow what "translate the XML to valid Haxe code" means exactly
  • h
    like what would the qualifying haxeui XML represent if you wrote it by hand in Haxe
  • h
    @bright-gpu-74537
  • b
    the component macros already do this
  • b
    ComponentMacros.buildComponent("assets/main.xml")
  • b
    Copy code
    xml
<vbox width="100%" height="100%">
    <hbox width="100%" height="10%" backgroundColor="0xff0000" style="min-height:50px" />
    <vbox width="100%" height="90%" backgroundColor="0x00ff00"/>
</vbox>
  • b
    Copy code
    haxe
{
    var c0 = new haxe.ui.containers.VBox();
    c0.percentWidth = 100.;
    c0.percentHeight = 100.;
    var c1 = new haxe.ui.containers.HBox();
    c1.percentWidth = 100.;
    c1.percentHeight = 10.;
    c1.styleString = "min-height:50px";
    c1.backgroundColor = "0xff0000";
    c0.addComponent(c1);
    var c2 = new haxe.ui.containers.VBox();
    c2.percentWidth = 100.;
    c2.percentHeight = 90.;
    c2.backgroundColor = "0x00ff00";
    c0.addComponent(c2);
    c0.bindingRoot = true;
    c0;
}
  • h
    That's what I was thinking -- I wonder if this can be combined with MVCoconut HaxeUI
  • h
    Right now I think MVCoconut tries to hack its own version of that, which is less than favorable making only basic containers and components compatible
  • b
    hmmm, right, im not 100% how coconut works to be honest, never used it, just looked at examples...
  • h
    This is the repo that it uses to wrap with HaxeUI This is single page example of a working demo: And this is along the lines of the kind of macro it's using to get it working: I want to take a deeper look into both eventually. Something tells me that that macro you have there could be the gate opener. I would love to combine HaxeUI and MVCoconut together to get the workflow of Coconut with the UI system of HaxeUI. Hopefully when I'm investigating both I can work with you and Juraj enough to get it rolling in a better direction semi-quickly.
  • b
    sounds good... ill jump into coconut at some point to at least understand what its doing under the hood a little, but i think you might be right in the sense that maybe the haxeui macros (or some derivative of them) might help
  • b
    any thoughts on how this looks? (websites are not my thing)... ive probably been looking at it too long, so some general "that looks wrong" type of feedback would be useful:
  • b
    (the component explorer - "Components" - im especially unsure of)
  • h
    The generator looks nice - I think it should expand to the full screen-width though! And perhaps a draggable border . . . The components explorer looks like it gets the job done nicely enough! If it feels a little awkward maybe something can be placed above the components like a title-bar or a search bar or something. I think the documentation section looks production ready for a first version 😁
1...979899...1687Latest