Haxe

If <@151104106973495296> succeeds in completing the backend, I may try to do something with it :). (btw, if you are stuck or need pointers to know how you could implement some specific parts of haxe-ui in Ceramic, feel free to ping me <@151104106973495296> )

I have a question, would you mind if i renamed `surface` to `visual` in componentsurface?

I'm wondering if that would be more intuitive for a ceramic user to discover

but i think pan's suggestion actually seems fine cause it will be intuitive to both ceramic and haxeui users

so... call it what you want... core has no concept of it

right now i'm stuck on clipping and images

oh, there is no standard there... hxwidgets exposes a .window... haxeui-html an .element, kha a renderTo, etc, etc

generally, its about what is more "correct" for the backend... so "visual" sounds like the way to go

btw, eventually, id like to clear up your conflicts so you can extends visual... seems much nicer

am i right in thinking the only real conflict (public facing) is `.id`?

what i could do there, is put that in the ComponentBase class, and override it other classes, then you could, i think just use it as an override... i think that makes sense anyway

but I use ceramic's id separately as part of the backend

but are there any more public type properties?

i know "_data" is one in the ItemRenderer, but that can be changed to "_itemRendererData" with no real impact

so as it turns out, treeview on hxwidgets on linux is a teeny bit broken