https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    im not quite sure i follow what you mean
  • u
    I will share a screenshot
  • u
    The issue I was talking about is the scrollview doesnt go to the bottom i.e. the dark line doesnt go to the gray line.
  • u
    @bright-gpu-74537 ^^^^^^
  • u
    The number of items in a scrollview will affect the scrollview height
  • b
    OK, so you want to turn off autosizing?
  • u
    So autosizing adapts to the components contents ? Or should autosizing adapt to other components around it and not its contents ? If I deactivated autosizing it would take the rest of the span of available space I guess from your response. But then when I would add another component after that component the new component would be hidden by the listview?( I will test)
  • b
    autosizing adapts to the contents of the component
  • b
    if you wanted it to adapt to the size if its parent, you could use a % w/h...
  • b
    although that would "size automatically" (based on the parents size) its not, from haxeui perspective, what it considers "auto size", which as mentioned, is the size of the contents of the component, eg:
  • b
    Copy code
    xml
<vbox>
    <vbox>
        <button  />
        <button  />
        <button  />
    </vbox>
</vbox>
  • b
    all the vbox's will be the size of three buttons (plus spacing / padding)
  • b
    Copy code
    xml
<vbox height="100%">
    <vbox height="100%">
        <button  />
        <button  />
        <button  />
    </vbox>
</vbox>
  • b
    the vboxes will take up all available space, buttons will remain the same (autosized) size (ie, sized based on the contents of the button)
  • b
    Copy code
    xml
<vbox height="100%">
    <vbox height="100%">
        <button height="33%"  />
        <button height="34%"  />
        <button height="33%"  />
    </vbox>
</vbox>
  • b
    vboxes will take up all available space, buttons will take approx 1/3 of the height each
  • b
    in that last example, nothing is "autosized" (in the way haxeui defines autosized)
  • b
    but they will all resize automatically... 😄
  • u
    Ok. I think thats what was confusing me :P autoresizing
  • u
    Its logical.
  • n
    Any tips for dealing with Keyboard events? I tried registering KEY_DOWN handled to top widget and a few more but not getting anything. I guess the events get eaten by something.
  • n
    Seems to be working only when focus is on a text input widget, that's somewhat opposite of what I expected.
  • u
    @nutritious-boots-87264what framework are you using ?
  • n
    html5. After further investigation it seems it is caused by how keyboard events are handled by browser. There is no widget with focus so only way for getting the event is adding event handler to document. Good enough for global shortcuts but will get annoying if I decide to add shortcuts unique to each page in TabView. Maybe there is way of marking container as grabbing keyboard focus?
  • b
    should non focusable items be able to have specific keyboard handlers?
  • b
    Maybe im missing the use case, but it seems strange to have a bunch of vboxes all having keyhandlers
  • s
    From curious, There are advantages using HaxeUI instead of ReactNative?
  • a
    @stale-house-89863 It depends on your needs
  • a
    For mobile i'd pick #501539217327915038-native
  • s
    Hm.. I see, why not also for desktop? RN less mature for desktop and HaxeUI less mature for mobile?
1...152153154...1687Latest