https://linen.dev logo
Powered by
# haxe-ui
  • b
    honestly, i dont know what the "right" (actually wrong in reality) approach is... i think its "menu items", "menu", "menu bars"
  • b
    so yeah, bottom up
  • l
    That defs fixed it
  • b
    either way, it'll get fixed... as presumably this happens with all backends... i doubt its a haxeui-heaps thing... so its unlike haxeui to impose a specific order on things (regardless what that order is)
  • l
    I think i had this happen on OpenFL C++ as well
  • b
    my guess is that it happens in every backend... its haxeui-core thing as far as i can tell
  • l
    Bummer!
  • b
    meh, its not so bad... just means ill have to make it not behave that way when i get a moment, i doubt its complicated ... just need one of those components to stop being so eager
  • b
    ill try to get it done over the weekend... shouldnt take long
  • l
    Looking forward to it!
  • m
    I'm back with another question about the proper way to use the 
    spacer
    element. http://haxeui.org/builder/?unksrt I have elements in my layout that I want to define certain elements to be of a certain size (in that example, the 
    box
    elements). And I Want to space them evenly across a container. It looks like using 
    <spacer height="100% />
    as you showed in http://haxeui.org/builder/?ivcshx works fine as long as you aren't providing hard dimensions for elements. In my example, the second blue box get's pushed way off the bottom (or worded another way, well past the 700px height that the box should be spanning).
  • m
    As a question, if I'm still trying to use the 
    <spacer>
    element incorrectly, Would there be an argument here for something like a 
    <fill>
    element that can be used inside containers (seems like maybe only 
    box
    , 
    hbox
    and 
    vbox
    elements, perhaps)?
  • m
    And one more piece of weirdness. I'm trying to some camera trickery to get the render order situated. I'm removing the main camera and re-adding it (to get all the HaxeUI stuff to render on top of my other cameras). However, it seems to cause issues with text input fields. I'm having a hard time following how everything is rigged up.
  • m
    minimal project showing the issue
  • b
    Fill would be analogous to spacer... it sounds like your layout is wrong tbh - any chance you can create an example on the builder (or as a separate project). If im understanding what you mean correctly you can defo do it with haxeui
  • b
    yeah, textfields in haxeui-flixel are a little awkward as they are actually openfl textfields floating over the top of the flixel UI... this is because openfl has much better text support than any native flixel solutions - ill check it out - sounds like just an edge case
  • b
    OK, that should be fixed now in latest haxeui-core - was defo an "all backends" thing - also, ive made a few (unrelated) tweaks to haxeui-heaps, so you'll probably want to grab git versions of both
  • b
    Should be fixed now in latest haxeui-flixel
  • q
    Ian, I know I'm insanely late, but I just saw the pull for [HaxeFlixel] #2280 ❤️ I pretty much already can figure out what that was for. I'm not dead; I've just been tied up. I'll be back to writing in Haxe "someday".
  • b
    yeah, as you say, that was a while ago - welcome back to haxe 🙂
  • m
    I think this one does show the issue I'm referring to: http://haxeui.org/builder/?unksrt Given that I told the vbox to be 700px in height, I wouldn't expect the spacers to push elements out past 700px,but they do. (the third box in that layout is well outside the expected height of the vbox. It only seems to happen when you specify a height in another element (such as a box, or provide a height on a text input element)
  • b
    i think the problem there is that all of your %'s add up to 225%
  • b
    25 + 100 + 100
  • b
    haxeui is smart enough to work out that if you have 4 100%'s you actually mean 25%, but i dont think its going to understand to remove that additional 25% first
  • b
    if you change your 100%'s to 37.5 then it works as expected
  • b
    that said, im guessing it might be pretty simple to perform that calc: ie, if you had a 13% and 17% and 3x100% then, in that context, 100% would mean 23.3%
  • b
    in fact, im not sure that is right either...
  • b
    ill have a think about it, but for now, the best thing to do is make sure your %'s add up to 100
  • m
    Let me play with it a bit more now that I've read that. I think I'm getting a little confused in the situation where some elements have sizes (like boxes) and some do not have explicit sizes (like text input). Ill let you know how it goes. Thanks for the explanation!
  • m
    The thing I'm seeing here with the cameras is that the ui seems to partially stop registering mouse events. On windows, the buttons still work, it the text field no longer responds, and in Android, it doesn't seem like any of the ui keeps getting the touch events. I have a couple things I'm still trying, but the attached project at least exhibits the windows behavior in a minimal project. As an aside, thanks for all the help and discussion around this stuff. This project is really cool.
1...783784785...1687Latest