For my filesystem its ok but its when I use it with gane hiearchy that it causes issues

single scrollview with expandable leaf nodes

its primative version of what i use now in hxIDE

if you want, i can send the treeview i use at the moment, but im not 100% sure how "drop in" it would be

that said, i would also like to know the issues with your approach, even though it seems strange, it shouldnt break imo

so its likely uncovered some bugs in haxeui-kha due to "non standard" use maybe? Care to open an issue if you get some moments?

Its ok. Thanks though

... ... fair enough

fyi, the "i guess thats not the end of the world" part was just about glScissor breaking the batching

sorry got a phone call. The reason I dont need it is I am phasing out haxeui in my engine/editor. Btw I know that your implementation was not mine and it was probably a bad implementation on my side, I just couldnt find a way to have children of children without scrollviews as it seemed to be the only component that could maintain a recursive hiearchy of stuff. I loved how haxeui worked and its flow and ease of access. But its easier to optimize and more direct to draw calls with zui and since I am basing my engine on kha it just made sense. Plus zui is used in production(i.e. with armorpaint). One of the big plus of haxeui btw is your accessibility and response to issues. I am not writing off haxeui for the end of time, just for now because I need to ship my dam thing 😛 There are advantages with zui that you just cant support(i.e. kromx now supports android/ios and armorpaint uses zui so input and interaction is "free" ). And when I say you cant I mean you have a lot of libs to maintain and I get that it is a huge challenge to do so. I also want to say that you have achieved a huge feat with haxeui and that its a really useful library !

sure, thats all fair enough... zui is probably very integrated with kha... though, i would like an example of how haxeui-kha isnt, just from the point of view of being able to improve it. Ill be rewriting the renderer and alot of the backend in general "soon" (since currently it totally trashes batching, which is something i only just found out about! 😮 ) so knowing how better it could be for any kha users is always a bonus 😉

also, not sure i understand about android / ios... haxeui-kha works there, but again, it trashes batching so without my "experimental/batching" branch things like listviews will be extremely sloooooow :/

Yeah, it is supported in android/ios but the interaction (i.e. uievents) wont be fired probably. We need to add them and since my timeline is for the end of march and I have boat loads of other stuff thats why its free with zui. But at the same time this is recent news though I would of probably said something differejnt relating to thsi last month 😛

For its integration with kha. The issue is I tried finding how draw calls are done, and I found them but things are mostly abstracted away while with zui everything is just there(i.e. I can see the draw calls for each component as they are just functions).

That because of the nature of the implementation. Its an immediate mode UI

yeah, thats fair... i mean, also haxeui is abstracted by nature due to its mulitple backends

yeah exactly. The abstraction is not bad except when you need more custom components that cant be serviced by already existing ones.

maybe thats documentation being shitty / non existent... i cant really think of an example where you couldnt make a custom component to do "anything"

how would you of done a recursive list object ?\

documentation isnt that bad. I can probably help with that

im not sure what you mean by recursive list object

like a tree?

yup

so the way i linked

a tree that can have a tree as child

sure, a normal n-level tree

this is how i did it:

and it just keeps going

the "label" hides / shows its children