https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • r
    ah yes, I see what I did. My bad 🥲 I did have the wrong path after all. Sorry about that. But good that the loading from URLs with a redirect was found 😉
  • b
    so i think your path is wrong in the xml file... two secs, just verifying with your app
  • b
    ah, you found it at the same time 😄
  • r
    yeah, I missed that it was in a "ui" subfolder
  • r
    yeah haha
  • r
    I have images now! phew!
  • r
    I must be tired or something 😄
  • b
    cool - also, the rediect thing was a good find anyway as you say - also the "password=true" is fixed on git haxeui-flixel fyi
  • r
    oh fantastic!
  • r
    Just pulled the changes, and the password field is now working as expected. Thanks so much! Just looking at your fix; So that was actually done in the 
    OpenFLTextInput
    class. Nice! Does that mean the OpenFL backend had the same issue?
  • r
    oh yeah, and those images are loading from the URL too. very nice!
  • b
    > Does that mean the OpenFL backend had the same issue nope, so the haxeui-flixel uses an openfl textfield for its text input, mainly because its MUCH fuller than any other pure flixel text input, it does however come with its own set of issues (the biggest one is its not compatible with flixel clip rects... 😮 )... i have a solution for this but its not a simple one, and could be a can of worms
  • r
    that makes sense!
  • f
    how could that even be possible when build tools rely on it
  • f
    one thing that throws me is that the haxe-ui xml builder needs to know where things are at build time, but all my assets are somewhere else at runtime
  • f
    since I use 
    openfl.util.Assets
    or whatever to load all my files instead of flixel
  • r
    ¯\_(ツ)_/¯
  • b
    they are also available at compile time though right? I mean, is there any specific reason you want te build a UI from xml and runtime vs compile time? I cant think of a good reason if the xml files are available at compiletime (as they would be in your case)
  • b
    but if you really want to use build a ui at runtime (but again, its very rare) there is "RuntimeComponentBuilder"... obviously at runtime you lose all the "nice" things like @:build macros, etc, etc
  • b
    that shouldnt matter, the files are still there at compile time and "all" the haxeui macros do is turn that xml into code... take the haxeui component explorer for example, the xmls are used at compile time to build the UI, but are also used at runtime to show the source of the xml (ie, the tabs at the bottom that leads to the source of the xml)
  • f
    ah no what I mean is I have to think of the xml files as source not assets
  • f
    even though I think of it as data
  • f
    since everything in the 
    assets
    folder is going to get mounted at a different path at runtime, but I have to pass the current on-disk path of the ui xml to the macro.
  • b
    yeah, thats is true, but i guess thats is the nature of the asset packing in your framework of choice, you could certainly make it so that the resource name (at runtime) as the same as the resource at compile time (again, the component explorer does this)
  • b
    > even though I think of it as data thats not really that wrong imo - i mean, it is data, its data that is fed into a system that builds source from it
  • b
    @bright-gpu-74537
  • b
    Was it always like that?
  • b
    Sorry for pinging I just thought it was important
  • b
    i guess it must have been, i havent changed anything in ages, probably need to make it more "mobile friendly" in general
  • p
    Virtual dropdown height is defaulting to 0? http://haxeui.org/builder/?hocoky and adding dropdownheight crashes component http://haxeui.org/builder/?jxmvlk I believe this used to work so is most likely a change in the last month
1...118811891190...1687Latest