https://linen.dev logo
Powered by
# haxe-ui
  • b
    right
  • m
    Windows will not be resizable
  • b
    so maybe just vw/vh and / or % width / height?
  • m
    Let me try that
  • m
    Is it possible to calculate a value in runtime and use it in the xml?
  • m
    Say the imageScale I use in each image depends on the Lib.current.stage.stageWidth for example
  • b
    the new imageScale isnt a css prop, so you would have to calc that yourself and set it
  • b
    but for things like widths and heights "vw" should work in css
  • b
    (which on openfl will be the screen width, which is the stage width)
  • m
    Got it
  • m
    600x1334 (this is the stageWidth x stageHeight for this test) Each square box is sized 78vw x 78vw
  • m
    1080x2400 (this is the stageWidth x stageHeight of this test, my android phone) Each square box is sized 78vw x 78vw as well. Shouldn't they be sort of the same size in regard to the stage's width?
  • m
    Copy code
    xml
<box width="78vw" height="78vw" styleName="border3">
    <image id="slotIcon" verticalAlign="center" horizontalAlign="center" />
</box>
  • m
    Ignore the icon's size inside the boxes
  • b
    im not sure if you can use vw in the width attribute since its a css measurement unit
  • b
    you can now update the data of the treeviewnode
  • b
    either use 
    myNode.text
    , 
    myNode.icon
    or 
    myNode.data = {...}
  • b
    i have some more changes (and a bit of a rewrite tbh) that i wanted to get in, but i didnt have the time - so they'll have to wait a little
  • r
    @bright-gpu-74537 Confirmed working as expected, thank you so very much!
  • b
    no worries, the internals are likely to change fairly soon, but from your perspective nothing should change when that happens
  • r
    I am not too fussed with breaking changes either; it is an experimental element after all
  • r
    once the datasource is hooked up, this will be an incredibly powerful piece of UI
  • b
    yeah, data sources and a native version are what id like to get working next... tbh, having a native counterpart would be useful as it means things have to be written "properly" (ie, behaviours etc), which currently isnt the case - its a composite only component
  • b
    but well, anyway, at least the latest changes will allow you to update data dynamically
  • m
    Hi, isn't this the case of the of the retina like displays (smartphones and tablets) that double the density even reporting half the screen size (or something like this)? I believe we have to set the 
    toolkit.scale
    manually, but Ian might have better insight on this...
  • b
    toolkit.scale was another thought i had, however, i wasnt sure it was the right approach since my guess was that this was some type of debug UI for a game that could be in different resolutions
  • b
    (although even then toolkit.scale might be more appropriate - depends i guess - we need more info)
  • m
    yeah, you're right, more info could be helpful in this case, but if it is not the case of a debug UI, trying to change the 
    toolkit.scale
    just to see if makes a difference may be worth a try
  • b
    yeah, i guess it depends on what "effect" guifes is after... should the windows remain proportional to the "game screen" in all aspects (ie, scale) or should larger resolutions of the "game screen" be able to show more info in the windows (ie, a % of the view size, but scale 1)
  • b
    ¯\_(ツ)_/¯
1...106310641065...1687Latest