It does a pretty good UX job in terms of mirroring the big OS's, I played with it a couple of years ago 🙂

I'm trying to replicate that colour picker component you shared awhile ago Ian and running into some obstacles. screenX and screenY seem to have the wrong values, don't update when the window resizes, and when I do draw something, it appears under the UI, rather than on top. Any pointers?

any chance to knock up a minimal example? Hard to guess whats going on without some code

Sure 👍 I'm really doing exactly the same code as your colour picker, but my colour picker is embedded in the frame on the right hand side. Anyway, I'll try and make one 🙂

Ah. Persisted for a bit before working on a testcase and made some discoveries. - It renders on top of the existing UI when batching is turned off. - Width and height are 0 when the component is instanciated, I should instead generate the image on

READY

-

ScreenX

and

ScreenY

are correct, but do not update on resize. So, mostly fixed (though disabling batching might be something to avoid). I'm confused about the resize issue though, because obviously all of my other components happily follow the window size change.

still might be worth having a simple test case, i wrote that previous component in like 5 mins, so its likely it doesnt honour certain things very well (like the batching for example - i seem to remember thinking to myself "this is gonna screw up batching")

Aha alrighty 🙂

if we have that brush component in a frame in a blank haxeui-kha app we can look at a) make it work better in isolation and b) possibly make changes to haxeui-kha to better facilitate this type of stuff

Awesome. Plus, we might get a sweet colour picker app 😛

i kinda remember thinking "the componentimpl in haxeui-kha should expose a 'renderMe' function"

(obviously not called renderMe 😄 )

the only issue with your colour picker is that its not "pure" haxeui, and therefore wont make it into haxeui-core

Oh yeah I didn't expect it to be, implementations would differ wildly

however, when haxeui-core gets a canvas component, then things like that would be possible across all backends

alot of that isnt directly related though

that is my example impl of how it will work

Pretty cool stuff. Personally, I can't see myself using a canvas component, because I may as well use the API of my chosen backend directly, but I can see how it could be helpful for beginners at least, and people who don't care about the backends.

well, or for things like that colour picker

Indeed.

that is the point of it...

there are times when you want to draw to a component, but you dont want to go through the backend directly... you could ofc #if kha, #if openfl, etc... but that makes things messy, and this is the entire point of the abstract of haxeui

Ah I see. Yeah, cool stuff. I just saw

haxeui-core custom-component <classname>

, is that functional? I'm getting

Invalid field access: length

(The CLI thing you've got)

i think it was at some point... i never really used it in the end... it was so quick to manually make one (two files) i never kept up with it

Aha yeah fair enough, it is easy to make components 😄

yeah, exactly, i think it was one of the 4am decisions: "wouldnt it be cool if ... ... ... ... ", next day "nope, not really"

😄

Yep, had those myself 😆 (And at 1am. I can't imagine myself at 4 crikey)