I'm trying something not very clean but may work for me. I'm trying to run the FlxGame with the same size as the stage, and if I can get the size of things in the UI, I can try to accommodate the content inside the FlxGame manually using offsets

hmmmm, sounds yucky 🙂

I know, sounds terrible

but without a text input / being able to run contained FlxGame ... .... .... what other options are there 😦

as i said, i hope to have some type of text input for haxeui-flixel over the weekend, but i cant promise anything

No problem... At least I can already use the app to suit my urgent needs already

Just wanted a clean version so that other people could use... But that can wait I guess.

> So I'm messing with the flixel backend now, and as I imagined it's not as complete as openfl. > - Seems like style background-color doesn't work. > - Menu bar looks odd (no background, just the menuItem button appearing) > - Font color for menuItems looks odd as well, they are white, when I hover over them they turn black permanently o.O > - I've tried aligning a vbox to the bottom of the screen and it just desappeared. Working example here (http://haxeui.org/builder/?pdzlam). After some testing, seems like most things having to do with vertical alignmente doesn't seem to work well (height, top, verticalAlign) > - Also in the example above I'm getting: haxe/ui/binding/BindingManager.hx:221: EUnknownVariable(frameRateSlider) I was in fact testing with the last release instead of the git version of haxeui-flixel. Changed it and tested again. These still happen: - Seems like style background-color doesn't work for boxes - I've tried aligning a vbox to the bottom of the screen and it just desappeared. Working example here (http://haxeui.org/builder/?pdzlam). - Also in the example above I'm getting: haxe/ui/binding/BindingManager.hx:221: EUnknownVariable(frameRateSlider) but it actually works anyway o.O

I think the only thing really missing to have everything working in flixel backend would be the TextField after all 😄, but it would be neat to have the xml layout behave correctly

yeah, text input is a bit of a show stopper, defo...

as for the others, i havent tested but none should not work...

do you have any of them in a test app or something that i can test when i get some time?

Should I point you to an update branch on my repo or do you prefer a zip?

Here is the updated repo branch https://github.com/guifes/flixel-animation-editor/tree/feature/flixel-backend If you have a hard time testing it (maybe because of dependencies) let me know and I'll strip the project down to what matters and send a zip here

ok, ill try it out and let you know when i get a few mins

thanks!

btw: just looked at your "Working example here (http://haxeui.org/builder/?pdzlam)." link, your root component there is a "box"... pretty sure thats not intentional

it means that each of its children will be drawn over each other - you'll notice in that link you cant use the menu, etc... if you change the root to vbox its works correctly... maybe thats the issue with your flixel version also?

>

css
> .checkbox .label {
>     ??? : ???;
> } 
>

@User I think this is great for general styles, but for the freshly implemented inline modifications for htmlText, this general rule won't work! I'll see if findComponent works, though I think I was getting

null

returned when I was looking for this yesterday (I'm actually using an

OptionBox

so I may need to do a

optionbox.findComponent(CheckBox).findComponent(Label)

to find it

But I agree having an "interpret as htmlText" would be a great addition to all instances of text in haxe ui

(or perhaps making all text

Label

components)

> but for the freshly implemented inline modifications for htmlText, this general rule won't work how so?

perhaps I misunderstood what you suggested, but if we apply rules in CSS, we can't divide the text into different sections with "something like this". Or is the CSS rule saying "treat this text as if it were htmlText"?

thats the css rule saying "treat this text as if it were htmlText"

so "auto" would mean "if it contains treat as htmlText", "text" and "html" are self explanatory

so really, "auto" should be enough, and would work as a default, but i can also be switched off with another rule, and textinput / textarea would be "text"

oh oh brillant, and that's already implemented?

nope

need to check a few things first

If you need help with the input text I can, especially starting this weekend