Trying haxeui-hxwidgets

Hi,

so i wanted to try out the haxeui-hxwidgets back-end

i followed every instruction here : hxWidgets

after successfully installing everything i am getting :

image

it is looking for some Build.xml which i couldn’t find physically in that path.

I tried both methods from CLI and the Flash Develop Templates

haxeui create hxwidgets --flash-develop
haxeui create hxwidgets

image

i am using new-method branch.

thanks

Before you try and use haxeui-hxwidgets can you try the hxWidgets sample? hxWidgets\samples\00-Showcase

Once that runs then using the backend should be fine. Does the error still happen there?

EDIT: also, does that Build.xml file exist at the location its looking for it? Whats your path hxWidgets?

actually i tired that first, and got the same error

Error: Could not find include file "I:/SDKS/HAXE/haxe/lib/hxWidgets/1,0,3/Build.xml"
Error: Build failed
Build halted with errors (haxe.exe).

no it is not in the folder, it is looking for.
image

C:\wxWidgets-3.1.2

oh… im so dumb… when i created the haxelib i didnt include a load of required files… gimme a few mins, ill fix that

Ok, can you pull latest haxelib (1.0.4) and try again, it was actually just the Build.xml file i think

ok there another file missing too :smiley:


image

Doh… Right, that should be sorted now… I was also including ALL the generated .h files from the sample dir… :no_mouth:

finally the lib errors are gone;

now i have to deal with :
wxbase31u.lib(baselib_appbase.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'x86'

looks like vcvarsall.bat problem i guess.

1 Like

this is beautiful

1 Like

Perfect! So now thats all working, you should be able to use haxeui-hxwidgets :wink:

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 :wink:

thanks

these might be of use to you:

There is a styling one in there, but its blank. Its actually a great time to ask then: what would you be looking for in a styling guide? Personally i think this is the best resource: https://github.com/haxeui/haxeui-core/tree/new-component-method/haxe/ui/_module/styles/default - ie, the default styles - but maybe thats me

I want to attempt this kind of designs first, to see if i can get this result



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. :slight_smile:

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 ?

1 Like

Oh, wow, hxQt. I’m curious, is that ability to customize the main rationale for creating hxQt? What other advantages do you see of hxQt over hxwx?

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 :slight_smile: ). 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:

Cheers,
Ian

1 Like

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! :smiley: