Howdy!
Heres my “every 6 months haxeui release cross post”, enjoy!
Cheers,
Ian
Howdy!
Heres my “every 6 months haxeui release cross post”, enjoy!
Cheers,
Ian
Hey Ian,
This looks awesome, I may need to take another look at HaxeUI.
I’ve got two thoughts though:
New release and he snags a wife to boot. Good job and congrats!
Yeah, ive got some idea about splitting it up in the “views” and only loading them (as semi self contained .js files), but ill need to have a play with it… the idea should also work for other haxe targets (like cppia for example)… Ive run some tests and i can defo load things externally, just just little bits of code. Ill need haxeui externs to give the tires a real nice kick (externs which dont exist yet, so ill need to generate them).
So yeah, scrollviews are essentially handled internally by haxeui, this is the nature of the composite views. Any chance you can expand on what feels wrong about them? (feel free to move this to the haxeui community or the haxeui channel on the haxe discord )
Cheers,
Ian
It looks like the DOM is being treated as a drawing surface of sorts and all positioning is being done programmatically with Javascript. What triggers the handleSize
, handlePosition
, and handleClipRect
functions? Is it the process()
function in ValidationManager?
Are there docs on the lifecycle of a component?
Essentially, yeah, so you mark a component as invalid, in various ways, layouts for example might changes it size, etc. This add its to the invalidation queue, this queue gets processed every frame if its not empty (via CallLater, which is requestAnimationFrame on html5), this calls validate on the various invalid components, these components, eventually end up calling handlSize for example, which lives in the backend.
© 2018-2020 Haxe Foundation - Powered by Discourse