https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    instead it creates a new process for each completion request
  • b
    yeah, that makes sense
  • b
    also why its pretty slow
  • b
    not sure about it making sense, but it might explain this 😄
  • b
    i mean making sense in the sense that it can get its knickers in a twist a leak loads of processes
  • f
    Looking fantastic! Are there restrictions for sizing?
  • b
    not yet, but ive put it into haxeui core now, so things can be improved as it evolved rather than sitting in a project
  • f
    Perfect 😄
  • b
    there is also no native counterpart (yet), but should all be possible
  • b
  • f
    Yeah nice
  • b
    going to make a 1.1 release today... its about time, and i keep on putting it off
  • f
    That's great 😄 I'm looking forward to adding splitters and refining my UI later tonight.
  • b
    👍
  • b
    try and use the ones in core rather than the ones i sent you (although they are 100% the same at the moment)
  • f
    Yeah, I only used the tree code you sent 🙂
  • b
    cool - the tree isnt going to make it into core, and in fact, the tree that will make it into core will be nothing like the one i sent
  • f
    Huh, okay, interesting. I think I'm going to be mangling that tree code quite a bit. I'm thinking of showing assets in a folder as a grid, while leaving the folders expandable. May end up looking dodgy, we'll see.
  • b
    cool - well, before i officially release a tree view (and its native version), ill touch base with you and see what you think of its functionality, but the simple fact is that treeview i sent is very "just make it work"... in reality it should be using item renderers, proper styling, data sources, etc... and the bells & whistles haxeui offers
  • b
    i dont mind that treeview, and its certainly "good enough", but its not really how haxeui components should be designed if you want them cross framework... especially wrt to exposing it natively also (ie, that treeview is pretty much a "this is only a composite")
  • f
    Fair enough 🙂
  • b
    you can tell that because there is a load of code into the actual treeview component... 😉
  • b
    compared to the splitters:
  • b
    Copy code
    haxe
@:composite(SplitterEvents, SplitterBuilder)
class Splitter extends Box implements IDirectionalComponent {
}
  • f
    Ahh I'm excited to put splitters in my app 😄 There's something slightly frustrating about knowing a UI is very rigid. It should also let me support a wider range of screen sizes.
  • h
    I was working on splitters for my own app a couple months ago, wasn't so pretty lol
  • b
    they are fairly preliminary, but they are functional, and as i mentioned, they were written "properly" wrt to composite / native... so using them as a base inside core seemed to make sense rather than let them atrophy externally
  • f
    Splitters will be a good spot to use the new Kha cursors, when that's smoothed out a little. I saw a 'cursor' style property, maybe all that'd be needed for kha cursors is to detect that property?
  • b
    yup, haxeui-kha will need to make use of those changes you made
  • f
    Cool cool. I think Rob may have merged my pull request before it was ready for all platforms... I should probably message him about that 😄
1...314315316...1687Latest