https://linen.dev logo
Powered by
# haxe-ui
  • b
    i would have expected nothing to be visible since you are, essentially, setting the sub.xml width to 0
  • c
    Hmm I see
  • b
    so the fact something is visible is weird, the fact that the placeholder doest work is super specific and even weirder
  • c
    Hope that lead to something good for the framwork
  • b
    yeah, its defo something im looking into 👍
  • b
    fyi, this is the most minimal repro:
  • b
    so now I'm through with all ideas xD and sry that I have sprinkled you with all ideas
  • b
    Copy code
    xml
<hbox>
    <hbox width="100%" style="padding:5px;background-color:#CCFFCC;">
        <textarea placeholder="Foo" />
    </hbox>
</hbox>
  • c
    (far bettter
  • b
    no no, i appreciate it, and agree with what you are saying - using svg as a "default haxeui canvas impl" makes ALOT of sense
  • b
    the original GH issue is proposing to "remake" svg in essence... which, upon refection, is a shitty idea since it already exists natively (or at least better) in alot of backends
  • b
    I find the idea great, just in the execution I had doubts. Therefore, I have just the last few days thought about what might be a better idea and I came to SVG. As you say, most targets already support that natively. The hardest thing is when you want to implement new things, always the concept xD.
  • b
    agreed 100%, leveraging existing SVG support will make the canvas easier to implement with much better results too
  • b
    and with more possibilities. You can customize the shapes in the post. This may also make it easier to create animations.
  • b
    OK, so the first thing is ive added a debug warning (only for debug builds):
    Copy code
    WARNING: trying to use a % width in a child (id: box2) with autosized parent (id: box1)
    I wonder if its ill concieved...
  • c
    that will surely help
  • b
    ... and i can see whats going on with the placeholder... its around focus... it uses findComponentsUnderPoint... and since the parent hbox is width=0, it doesnt find it, so it sets the focus and unsets it, and that seems to cause issues
  • c
    makes sense from the behaviour I thought yesterday when depending on the text length and the click position the placeholder would work or not
  • b
    i think its actually a bug with findComponentsUnderPoint... well, an edge case at least
  • b
    eg:
  • b
    Copy code
    xml
<box width="0">
    <button width="100" />
</box>
  • b
    if you try to do findComponentsUnderPoint there it will skip the first box since its width is 0
  • b
    ... ... now im not sure if that is "good" behaviour or not
  • b
    technically the layout is wrong / weird
  • b
    and indeed if you did:
    Copy code
    xml
<box width="0" style="clip:true">
    <button width="100" />
</box>
    Then you wouldnt even see the button
  • c
    Well if the button still displays
  • c
    yes
  • b
    well, it does, but only because clipping is expensive, so components dont clip by default
  • b
    adding clipping by default for all components would be such a bad idea for what is essentially a dodgey layout
  • c
    Well if you have a parent with width="0" you would expect the childs to clip no ?
1...754755756...1687Latest