I already know what two libs i am using for those targets

OK, so then you are trying to hook into existing native UI libs? (ie, swing)

Yeah. I already have made a wrapper of Swing and there already exists a wrapper for html5

so then yeah, your pal is right, its not going to be easy (or possible) to have things visually consistent if you are using native libs... and i would argue thats correct, for native stuff the UI should be the same as the platform

you wouldnt want a windows looking UI on ubuntu (for example)

oh, does haxeui not do that? IDK what they meant by making it render more or less the same

well, haxeui has two different types of backends: native ones and "composite" one

and backends have different expectations than different targets?

so, haxeui core handles components, and it delegates to "backends" for drawing... in the case of native backends, the whole component is essentially replaced with a native counterpart

(it also uses a "behaviour" system... so when you say ".text", it actually runs a "behaviour", and that can also be replaced)

> so, at a very simple level its a mechanism that allows you to replace component properties at compile time, the example i always use is the difference between a composite button (lets say haxeui-html5) and a native button (haxeui-hxwdigets). So: > > You create a button (new Button()), lets saying in haxeui-html5 (but any "composite backend" is the same). All good, now you call .text = "bob". In a composite backend (which is the default), this will go away, create a haxeui label, add it to the button component. This will then invalidate the layout, the ButtonLayout will get refreshed, this will grab that haxeui label, position it where it needs to be, etc. Same concept with .icon. All pretty standard stuff so far. > > However, now consider a "native" backend (like hxwidgets). If the same code were to run, it would mean that haxeui would try to create a native button, it would then try to create a native label and add it to the native button... Now, best case scenario, this would be ugly an weird, worst case (as is the case in wx) it would crash, since you cant add children to a native button > > The solution to this is "behaviours", so ".text" can be "replaced" at compile time with a totally different "behaviour", and in the case of wx widgets, this behaviour can just set the "native button text", and completely bypasses all of the composite stuff (including the layout). It defo adds some complexity, but its what allows haxeui-core to support native and composite backends... you can essentially replace any part of the outward facing api (assuming its using behaviours) with anything you like

I think I'll have to discuss it with arman more, as I'm not sure interfaces is the correct solution. Will have to see 🙂 thanks for you insight

np - one thing i would say is that if you are aiming for a native UI (ie, a native, say, button) then dont even try to be consistent between platforms... its not going to work... or it will, but just really badly... OSX look naturally different to windows, and the user will HATE your UI if it doesnt match... however if you are going for a sort of composite type approach (like haxeui composites), then yeah, you can defo get a consistent look and feel

i guess it depends what the goal is...

I have two apps that do basically the same thing across web and swing... I would basically be doing the same thing as haxeui if I did use haxe, so I think a haxeui like solution would be good

then yeah, you probably want a backend type system.. where you core lib (haxeui-core) handles the components, layouts etc... but a) it draws nothing, that is delegated to a "backend" lib and also b) the whole component can be "replaced" (essentially) with something totally different - ie, native

that would also allow extension later down the line \o/ sounds like a plan

thank you!

np... good luck... lemme know how it pans out 🙂

Hmm alright

Hi Ian and all, there seem to be a regression in the latest Locale lookups, since the last edits (21.02) see http://haxeui.org/builder/?8d8b3aad

hmmm, i thought i tested that... 🤔

ill check it out later this eve...thanks! 🙂

I don't know if it's a bug or if it's supposed to happen but absolute boxes don't work if they're at the top of the hierarchy (). They work fine if they're contained in another box, though ().

I think it's more haxe builder box bug if I remember well. IRL, in your app, you shouldn't have this porblem

Well, I stumbled upon it because I couldn't display an absolute box but a box worked fine, in Heaps :/

(Just the box with a bkg color)

your main view also needs to extend the correct class