Yep i love this, and the speed it compiles with is way faster then anything. now i need to check styling of components for html5 targets, can you suggest me some sample codes or any reference to the styling part along with modules etc.
this is now my back up plan if those backends fail me then i will be working with hxWidgets
All looks doable to me… nothing jumps out as impossible, or even particularly hard (for composite backends like html5, openfl, etc)… eg: https://gifyu.com/image/30Bj
Native will be a little different, with wxwidgets at least, as the lib isnt that customizable (wxWidgets i mean) , however, there is a hxQt that im currently writing and therefore a haxeui-qt eventually - this will likely be much more customizable as Qt allows much more granular control over those things.
Its probably worth noting, that when haxeui-qt comes about it shouldnt be hard to switch to it… in fact, if you havent used anything specific to html5 (ie, a “pure” haxeui app) then you shouldnt need to change a single thing.
yes i understand wxwidgets that is an exception but the hxQt i guess once it comes i will be switching to it for ever lol, currently the workflow for OpenFL is really easy, it’s like directly design your complete screen in Animate and just export the classes for OpenFl which really helps getting prototypes out quickly but i wan to invest my time in something stable and HaxeUI is the one i know :D. so far wrapping my head around the app structure to follow and make some customization to components , once that is done i really want to make some cool UI samples for it to be showcased as samples, since everything is scattered :P. new api vs old one.
Edit : forgot to check that link , that is awesome , i like the smoothness . is it open sourced ?
Honestly, the main rationale was to “just do it”… They are very different beasts, wx is actually native, qt is a very good rendition of native (but 100% not native in anyway - well, kinda ). The main “goal” (if you can call it that) is, as you say, customization. Something that wx, or native platforms wont really allow (and maybe rightly so).
But since were talking about haxeui, hxQt will have nothing to do with haxeui (much like hxWidgets). haxeui-qt will leverage the externs in hxQt (ie, qt) and allow you to use that as a backend for haxeui - but the externs for qt will remain 100% usuable without haxeui… again, like wx:
Oh, I didn’t realize that hxWidgets (and soon, hxQt) could be used on its own, without haxeui-core.
I’m not very familiar with wxWidgets (I looked at it once a long while ago and it reminded me of Microsoft Windows MFC); is the hxWidgets API very similar to that of wxWidgets?
So, hxWidgets might be good for folks who already know wxWidgets but want to use Haxe.
Do you find that many users make direct use of hxWidgets, as opposed to haxeui-core?
Yup, hxWidgets is independent of haxeui anything. There are two layers:
wx.widgets.* (ie, wx.widgets.Button) - these are just externs for haxe (hxcpp) for wxWidgets and can be used as is - but working with externs, esp. c++ externs can be… … difficult.
hx.widgets.* (ie hx.widgets.Button) - these are nice haxe wrappers for the externs so you can just do new Button(...) and be done with it (and manages all the pointers etc). They also make things a little more “haxey” in the sense you have myButton.bitmap = ... rather than the traditional wx way of myButton.setBitmap(...)
As for people using hxWidgets over haxeui-hxwidgets, i honestly have no idea. I do think there are some for sure - just no idea how many.
Main “problem” with just using hxWidgets is you are now locked into wxWidgets which is certainly the main goal of haxeui: no framework lock in… well, except haxeui ofc!