https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • a
    those presumably wouldn't change, or is the issue that, that schema is useless because of how one would typically use haxeui?
  • b
    but it doesnt make sense to build just "haxeui core" components, because thats not "all of them"
  • a
    ah I gotcha
  • b
    for example
  • a
    you're coming from a 'it's a half-baked solution' perspective, you'd rather an actual good solution
  • b
    its not a half baked solution, its just not how haxeui works... i could add a static "button" schema, sure... but what if you extend a button and created a "BetterButton", well, that could certainly be used in xml, and everywhere, but the schema wouldnt show it, in fact it would highlight it as in an issue.
  • b
    (its worth noting that, that these arent issues, ive sorted them, i just dont know how to "present" them to the end user without interaction)
  • a
    ah yeah, I think I understand the issue now. Could you use macros to track components that extend core components are offer at least the 'base' completion?
  • e
    would it not be possible to make a way to generate a schema from the current project?
  • a
    so if BetterButton exists, you create a schema for 'Button' if you detect it extends Button
  • b
  • a
    ah, I'm just on the train and browsing through the chat 😅
  • b
    the problem with generating from the "current project" is that DCE works, so, i assume you'd want completion for things you havent used
  • e
    -dce=none
    ?
  • b
    no
  • b
    are you saying that, in order to generate a decent haxeui schema i have to include all classes? That doesnt make sense, it has to be a separate process
  • a
    oh that's really awkward, yeah
  • a
    can you not run macros prior to dce?
  • e
    or dce=std, the default?
  • e
    std only does dce on the standard library
  • b
    its doable now and works fine... but its an additional "haxe generate-schemas.hxml" type thing
  • a
    this is a project level define, you can't really Bake this into usability
  • b
    none of the above, the generation of haxeui xsd cannot be part of your normal compile, that much is for sure, not if you want completion of things you havent "used"
  • b
    100%
  • b
    Copy code
    --macro haxe.ui.macros.SchemaMacros.buildComponentsSchema('assets/haxeui.xsd')
--macro include('haxe.ui.components')
--macro include('haxe.ui.containers')
--macro include('haxe.ui.containers.dialogs')
--macro include('haxe.ui.containers.menus')
--macro include('haxe.ui.containers.properties')
  • b
    if you do this, you will have nice haxeui-core schemas... if you change something, you'll have to do it again
  • b
    you'll also have to link the output schema to your xml file
  • b
    if you have some custom components, you'll need to include them (currently)... i have an idea, about a verrrrry slow classpath scan
  • b
    but again, this has to be outside your "normal" compile, as maybe you didnt use... dunno, "property-grid", but you want it in completion
  • b
    i can only run macros on things that "exist" as far as the compiler is concerned, if something is dce'd something, it simply doesnt exist
1...127812791280...1687Latest