Thanks @User!

@User Thanks! Compiles and runs now.

@User - there are plenty of other mobile compatible haxeui based options btw (haxeui-openfl, haxeui-nme, haxeui-html5)... just a heads up 🙂

And also, heaps support for mobile is purely theoretical (and would be opengl only) , whereas kha has dedicated mobile backends (and it also supports metal).

good point yeah, no one seems to have "cracked" heaps on mobile yet it seems

cppia would work on mobile fine, there is really no reason it has to be limited to NME from my understanding apart from lack of documentation.

I noticed Hugh has started adding Metal stuff, but likely he will not say untill he feels it's useful.

to NME that is

objectively HL is likely cleaner than Cppia but I doubt it's any faster but not checked recently.

I think HL should be feasible on mobile to work well, there is not much that should stop it beyond dev filling in the gaps.

if there are any. Structually it's very clean from my understanding but extras like png and sdl are less clean and likely where more problems will arrise with linking stuff... but hate getting involved with all that stuff.

Heaps is focused on HashLink but you could probably get it to compile to cppia if you were that type of dev.

@User 4 questions: - Does haxeui with flixel backend support 9slicing for backgrounds? - Does haxeui with flixel backend support sprites from an atlas? - Is the mobile target working for flixel backend? - What is the correct way to make a button invisible and not interactable but still occupy space in the layout as if it were visible?

@User : - Yes - the whole flixel backend is using them (check pretty much any of the default styles in haxeui-flixel) - No - id like to add it, i think we spoke about this before, some code would be useful of general atlas use (outside of haxeui) and how you would forsee it being using inside haxuei - No - id actually totally forgotten about this, ill bump it up the list... weekend hopefully - Hmmm - there actually isnt a way (i dont think, at least not a simple one), i think maybe a new css prop... i think "display" would be the correct one

in fact, i think its two props "display" and "visibility"

I managed to do this one with flixel's visible property and haxeui's disabled property together

Otherwise I would have to create a box of the same size, but the component in case is a button which I don't dictate the size directly (depends on the text content) then it becomes annoying

yeah, i get the use case i think...

On the second answer, I forgot to comment: I was already using separate sprites for each ui element, but for non ui things I'm using atlasses. The need came when I wanted to use a sprite that is already in an atlas, in the UI as well. But I can always duplicate it meanwhile.

I think I might have asked this awhile back, but is there a good way to render custom components with batching in Haxe UI Kha? I've been looking into the batching code and see that

renderImageTo

takes a component and uses it's

_imageDisplay._buffer

(which surprised me, as I thought it would just take an image). Can I write to this

_buffer

somehow in my custom components class?

@User, I've found a bug on flixel backend

> On the second answer Right, but can i see some code of using an atlas in flixel? Dont have any exp with it > Can I write to this IIRC we spoke about this and thought it might be nice to have some overridable callbacks in the draw code, eg:

drawTo() {
    preDraw();
    // haxeui-kha does some drawing
    postDraw();
}

Something like that anyway > found a bug on flixel backend Ok, ill check it out in a bit

^^ @User / @User

also 5Mixer, are you sure renderImageTo is the right call? I dont think it is

i think this is the function you are after in haxeui-kha, no?

public function renderTo(g:Graphics)

drawTo() {
    preDraw();
    // haxeui-kha does some drawing
    postDraw();
}

This looks good

It is in my

renderTo

override that I was trying

renderImageTo

🙂

this is for the colour picker?

Yup, not a huge deal, disabling batching does fix it.