https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    so will need to have keyboard events delivered only to that
  • n
    And possibly bubble up to parent objects.
  • b
    sure, i mean, not to all 3 of the listviews
  • b
    ill have a think / play
  • n
    Yeah, most of the problems would be solved by ability to mark an widget as something that grabs keyboard focus
  • b
    ive been putting off working on the FocusManager... but probably time to look at it again
  • b
    so... ... consider me conviced! :) Im still not sure i agree with your other uses cases, but thats your call, your listview example is spot on. And once that it working, then you could (ab)use(?) the same system for your other use cases
  • n
    Was some of the focus stuff removed? I remember that in earlier haxeui versions haxeui focus sometimes desynchronized from browser/html5 focus resulting in weird behaviour.
  • b
    im not 100% sure, it hasnt been worked on for a while, so maybe got broken somewhere
  • b
    its on my list to revamp it 😦
  • n
    Ok, thanks for all the work you have done so far. Even with more mature UI libraries there are times when you feel that some common behavior is missing and should be builtin.
  • b
    yeah, focus hasnt really been... ... .. erm... ... .. focused on properly
  • u
    Is there anyway way to know if a mouse click stays(for example if I want to drag something based on the mouse position)?
  • b
    I think you'll have to track that yourself with up / down events
  • b
    i would like to add dragging to core, but im wary that im adding a feature that wont work for some people and therefore, generally, wont be used
  • b
    i seem to end up wiring up a drag system quite often
  • u
    Ok good to know and it makes sense
  • b
    ^^ much nicer accordion.. other one was more than a little broken
  • f
    Super cool addition! That might actually come in handy for me
  • b
    Copy code
    xml
<property-grid width="250">
    <property-group text="Group 1">
        <property text="Property Default" value="bob" />
        <property text="Property Bool" type="boolean" value="true" />
        <property text="Property Int" type="int" value="100" />
        <property text="Property List" type="list" value="Item 1">
            <data>
                <item value="Item 1" />
                <item value="Item 2" />
                <item value="Item 3" />
                <item value="Item 4" />
                <item value="Item 5" />
                <item value="Item 6" />
            </data>
        </property>    
    </property-group>
    
    <property-group text="Group 2">
        <property text="Property Default" value="bob" />
        <property text="Property Bool" type="boolean" value="true" />
        <property text="Property Int" type="int" value="100" />
        <property text="Property List" type="list" value="Item 1">
            <data>
                <item value="Item 1" />
                <item value="Item 2" />
                <item value="Item 3" />
                <item value="Item 4" />
                <item value="Item 5" />
                <item value="Item 6" />
            </data>
        </property>    
    </property-group>
    
    <property-group text="Group 3">
        <property text="Property Default" value="bob" />
        <property text="Property Bool" type="boolean" value="true" />
        <property text="Property Int" type="int" value="100" />
        <property text="Property List" type="list" value="Item 1">
            <data>
                <item value="Item 1" />
                <item value="Item 2" />
                <item value="Item 3" />
                <item value="Item 4" />
                <item value="Item 5" />
                <item value="Item 6" />
            </data>
        </property>    
    </property-group>
</property-grid>
  • u
    @bright-gpu-74537 Really cool ! Did porperties exist before ? And is there any way to give the type field a typedef and have the property use a specific zml markup for said typedef ?
  • b
    prop grid is a new component im working on at the moment... nice idea to be able to give it a typedef... though i wonder if that should be an extension of PropertyGrid rather than the default behaviour
  • b
    whats zml?
  • u
    Xml. The android keyboard is poopy :P
  • b
    I could also see wanting to build it manually at runtime based on something entirely else.
  • b
    yeah, the "standard" use case i think would be to not link it to a typedef
  • u
    What do you mean by extension ? Is it like listeview is an extension of scrollview?
  • b
    well, something like "TypePropertyGrid extends PropertyGrid"
  • u
    Separating the logic would probably make sense but this depends. If it simpler to juste have it in one class thats fine. But if its too convaluted then we go the extension way. It pretty much depends on what you see extension giving you as a plus.
  • b
    i can just think, as @User said, that there are many times when i wouldnt want to have it as a type, and a load of, possibly "not that related" values... you could ofc bring them all into some type of typedef, but i think making that the default isnt the right way to go
1...154155156...1687Latest