#π NB's Riverside View
1 messages Β· Page 2 of 1
i'll give that a try when i'm okay with restarting my pc π
I'm actually quite happy with kha's scheduler though, seems way less jank than the haxe timer and everything seems to be running quite smoothly at 60fps
to the eye, everything here seems to be running completely fine
ctrl+alt+esc for instant restart cinnamon π no need to reboot pc at all
cleaned up my shutdown sequence thanks to the easy priority api from the scheduler π
this really is a cool project
whilst using ceramic i browsed the codebase quite a lot building up my project, and noticed various things
never really paid much attention to it
but now i'm doing it myself, the "tidyness" of ceramic really stands out
my codebase is an absolute mess π€£
things like when to destroy visuals was seperated in ceramic, but i never thought that was that important
but actually, its super important... you can end up with a random reference left over, a crash because you timed the destruction improperly etc
dialogs more or less working π
the fucking upside down dropdown was due to the vbox dimensions π€¦ββοΈ
xD
... I think i may have a fix for the infinite loop thing, but it is a change in haxeui core
@dense elbow https://github.com/haxeui/haxeui-core/pull/691 If you could review this change at some point it would be cool, i have no idea why no other backend doesn't have issues with scrollviews being performance limited but this change solves the issues on my side
at least i suspect so, i should test more, but will leave the pr there incase i forget x)
I don't feel or notice any difference with deferring the updates with call later in the ui, you notice it if you have traces though
will keep on testing it either way
maybe skip call later altogether and just insert at the end of the queue... wil try that π€
nah call later is better π
fuck tables seem to break with the change i made :/
wdym by "separated destroy"?
you mark visuals as destroyed and destroy them at the end of the frame
Ah, that's not necessarily true, but what is 100% true is that as soon as you call destroy() on an entity/visual, its destroyed field is true, preventing anything from binding back to it (like event handlers, autoruns...)
dispose() is doing what you describe
ah memory might be a bit muddled
What I mean here is that, let's say you have a stupid code listening to the onDestroy() event of a visual, and from that handler does do "visual.onSomethingSomething(...)`. That code will simply not work, it will explicitly tell you that you can't bind an event to a destroyed entity
There are subtleties in destroy() method that are handled with the entity macro
Like, imagine your base Entity class has the base destroy() method, super call of all subclass overrides of that destroy() method
This base destroy() method set's destroyed field to false (i'm simplifying a bit)
But what if you override destroy() in a subclass like this:
override function destroy() {
// destroyed is false here?
... do stuff specific to subclass ...
// destroyed still false?
super.destroy();
// destroyed is true now?
}
Ceramic destroy() method will become this:
override function destroy() {
destroyed = true; // Injected by macro
// destroyed already true right from the beginning
// even when super.destroy() hasn't been called.
... do stuff specific to subclass ...
super.destroy();
}
Well, I'm oversimplifying because actually destroyed field is backed by an int, not a bool, so that "currently destroying" and "destroyed and not destroying anymore" can be distinct states
Anyway, the idea is "as soon as you call destroy() on an entity, it's destroyed field will return true to prevent any post-destroy reaction to "bind things to it" which will leak forever
no chance im changing the invalidation loop for a backend... and im not even sure the change makes sense, it will delay all invalidation by one frame (and its already trigger on "the next frame")
yeah its fine the change only partially solved the problem and not completely :/
I forgot about daz's pr https://github.com/haxeui/haxeui-core/pull/665 so i'm gonna run this for a while and see if i run into the same issues
wow that's a super clever system, your system even prevents the silly actuality of forgetting to call super on destroy xD
Right, the macro insults you if you forget π
The gist of it: your biggest enemy is yourself xD
public static function getDpi() {
var display = SDL.getWindowDisplayIndex(App.window.window);
if (display >= 0) {
var arr = [];
#if scriptable
var dpi = SDL.getDisplayDPI(display, arr);
if (arr.length > 1) {
return arr[1];
}
#end
trace('DPI FALLBACK');
return arr[arr.length - 1];
}
return 96;
}
a trick for cppia client incompatible code that is defo going on the host
#if scriptable?
the scriptable define just simply lets you compile stuff for the client and the net outcome shouldn't actually be any difference
is that host or clien-
scriptable refers to the host
ah
cppia define refers to the client
examples of bad define names #1
scriptable and cppia as opposed to cppia (global) cppia_host and cppia_client
I should make host/hxcpp define combo so I don't make silly mistakes and forget at some point x)
but I'm still too dumb to parse this so I think I'll try and read the Tracy manual before bed π
bruh, pdf text can't really be changed on mobile or kindle so this is a terrible experience
pretty fast progress, you're becoming an old hand at haxeui backend creation now π
Its coming along, there are some real baffling things going on in other places though
look how broken treeviews are π€£
but clipping was probably my biggest "concern" and even though there are majorly confusing issues like above, i don't think they're going to necessarily be big deals?
I could be wrong there, but, we'll see
I redid the depth system to work a bit better with the way haxeui works >:)
I don't think it has any negative side effects either π€
Seeing how fast you display haxeui stuff makes me want to try to make my own version of haxeui-ceramic
YES
dude its so cool, you map a few things and 10 components suddenly work
just a lil slide show of some of the test pages I have currently
depth is not perfect (as always) but, i think the harder parts are mostly done. then its gonna be about figuring out why components are not initiatialising with the correct width/height and then mapping styles
Are there resources/docs that tell what should be implemented in a backend in details?
I have a casual little thing I've been writing whilst working on the backend, but other than that just other backends
you'll probably pick up the concepts decently just from reading the haxeui-ceramic backend
is haxeui-blank still up to date?
ya, that's what i used for haxeui-ceramic and the current one i'm working on
"docs" ... ... i keep hearing this word... ... one day ill have to look into its meaning π
ohohoho
I'm not sure what's going on with that bottom tabbar, maybe a different issue
but i think i've got depth good????
you sound like rob lol
i'm learning a lot with this in general
things that were confusing to me in ceramic land are now less confusing even tho i'm not doing anything there atm
i recon i could do stuff better in ceramic now
What did you find confusing specifically ?
simple things like clipping, depth, i got a decent done in there but these are things i've never dealt with much outside
depth in other haxe frameworks either didn't exist, or was very simple
i don't think i was that confused with ceramic in particular
more just had gaps in concepts ceramic used
i spent a while on kha many years ago, and things that I did over there are clicking for me better now as well
I see. Yeah the idea of depth range in Ceramic can feel a bit unnatural at first for sure
I couldn't ever figure out whether I could apply it to the haxeui component system or not
also, from previous conversations with you and ian, i've got my pointer events at a component level rather than screen level now
never knew you could actually map events in a haxeui backend either so i've mapped cancel propagation for haxeui - no idea if it uses it but its there in the html5 backend
i can't test haxeui windows because of a cppia thing - i think :/
Called from haxe.ui.containers.windows.WindowManager::bringToFront haxe/ui/containers/windows/WindowManager.hx line 132
Called from haxe.ui.containers.windows.Window::get_maximized haxe/ui/macros/Macros.hx line 643
Called from haxe.ui.behaviours.Behaviours::get haxe/ui/behaviours/Behaviours.hx line 306
Called from haxe.ui.behaviours.Behaviours::find haxe/ui/behaviours/Behaviours.hx line 152
Error : behaviour maximized not found
I'm getting this error theMaximizedbehaviour is on the host, so i'm wondering if there's some macro getting booped away somewhere
Called from haxe.ui.containers.properties._PropertyGroup.Builder::onInitialize haxe/ui/containers/properties/PropertyGroup.hx line 37
Called from haxe.ui.containers.Collapsible::set_collapsed haxe/ui/macros/Macros.hx line 694
Called from haxe.ui.behaviours.Behaviours::set haxe/ui/behaviours/Behaviours.hx line 236
Called from haxe.ui.behaviours.Behaviours::find haxe/ui/behaviours/Behaviours.hx line 152
Error : behaviour collapsed not found
Same issues with property grids as well :/
get the same issue with ceramic + haxeui
@dense elbow Any idea why this is happening? I thought it might be because of not setting component ready, but i've played a decent amount with that and couldn't solve it
issue seems to be components aren't being sized correctly on start
no clue, if i had to guess i would say that the text size is being reported back incorrectly
maybe you are applying the text style "to late" so there is a mismatch... ...
I did try adding call later to measure text but that made everything worse π
as for text style i'm just overwriting validateStyle like the other backends
oh no... could this be another cppia issue??
simple/Visual.hx:230: Depth changed
haxe/ui/backend/TextDisplayImpl.hx:77: 153,false
haxe/ui/core/Screen.hx:316: WARNING: Screen event "rightmousedown" not supported
haxe/ui/core/Screen.hx:316: WARNING: Screen event "rightmousedown" not supported
haxe/ui/backend/TextDisplayImpl.hx:62: set fontsize
last thing that occurs is set font size which should make it cause a remeasurement - right?
It's the opposite! the timer was too fast, adding a longer delay has the above effect but that's also not ideal
and it also seems to not apply for dropdowns :/
maybe i'll try using haxe timers instead of kha's scheduler
lol bad idea... infinite loop somehow
ahh nothing to do with cppia, commented out trace and forgot about that
didn't fix the other window issue, but was able to at least test it works if cppia has all the references to things
dragging is laggy because of the high call later delay for the text measurement
i also think pointer events are working as expected here
it was a really subtle issue
so close π
haxe/ui/backend/TextDisplayImpl.hx:76: Autosized Panels (Height),Label,284,284,true,0,18,18
haxe/ui/backend/TextDisplayImpl.hx:76: Autosized Panels (Height),Label,284,284,true,18,18,18
haxe/ui/backend/TextDisplayImpl.hx:76: Panel Title,Label,283,0,false,0,0,18
haxe/ui/backend/TextDisplayImpl.hx:76: Panel Title,Label,283,116,false,18,18,18
haxe/ui/backend/TextDisplayImpl.hx:62: set fontsize
haxe/ui/backend/TextDisplayImpl.hx:76: ,Label,0,0,true,18,18,18
haxe/ui/backend/TextDisplayImpl.hx:76: Panel Title,Label,243,116,false,18,18,18
haxe/ui/backend/TextDisplayImpl.hx:62: set fontsize
haxe/ui/backend/TextDisplayImpl.hx:76: Action,Label,71,71,true,0,18,18
haxe/ui/backend/TextDisplayImpl.hx:76: Action,Label,71,71,true,18,18,18
every value seems to look fine, wonder why the switch isn't in the correct location
da fuck is meant to be hiding this checkmark
visibility is mapped and so is alpha, so why can i still see the checkmark π€
I need to map removeImageDisplay :D
hm.. i already did nvm x)
ahhh forgot to remove it from a child list which meant it got collected for rendering indirectly
π
@dense elbow is there some kind of exhaustive list of what needs to be implemented by a haxeui backend?
(maybe I should ask that in #haxeui )
no such thing exists
just existing backends code
Like, for instance, in Ceramic, there is some sort of specification: all API that needs to be implemented as backend is provided as interface in a spec package.
(even though the interface isn't used when building the final app)
Ahh!! I was wondering what that stuff was for as i was browsing around the repo
can't seem to get images back on screen in the tabs... no idea where they've gone
note to self - commit more π
I'm setting up a base template project so i can easily spin up new projects when i want and i think i've fixed that weird fallback issue i was having with haxeui components
some behaviours still seem to not work though, guessing some kind of cppia issue there
can repro that on ceramic + cppia
so not unique to my stack at least
but i think I have enough done to at least start porting over some of my app
need to figure out why this particular behaviour isn't working but others must be working
so a quick look... it seems like clonable behaviours are fine and non clonable behaviours are not π€
unfortunately added clonable doesn't fix it π
CallMember haxe.ui.containers.windows._WindowList.WindowListItemLayout (0x5c32279e6164 0x5c322a4c3c60) 'get_paddingRight' fallback
CallMember haxe.ui.containers.windows._WindowList.WindowListItemLayout (0x5c32279e6164 0x5c322a4c3c60) 'marginLeft' fallback
CallMember haxe.ui.containers.windows._WindowList.WindowListItemLayout (0x5c32279e6164 0x5c322a4c3c60) 'marginRight' fallback
CallMember haxe.ui.containers.windows._WindowList.WindowListItemLayout (0x5c32279e6164 0x5c322a4c3c60) 'get_horizontalSpacing' fallback
nvm π
i'm very lucky, want my base project template to have git submodules so i can use it with gsm easily
but creating a project on gitea wasn't carrying over the submodules
they fixed it, so just a simple upgrade process and gitea continues to be completely cool
also haxe files now have the haxe logo π
@dense elbow https://github.com/haxeui/haxeui-core/pull/692 lemme know if this change breaks something for you, it works fine for me but i'm only testing in cpp land atm
2 imports jumpscare
yea, haxe 5 don't like the implicit import situation x)
it's a small change in theory
so it should all be fine...
but you never know
Gonna see if I can get a page from my app running in my framework
will use the moment to potentially refactor a bunch of stuff
just want UI transfered... no behaviour to begin with
π
getting traces i never hit in my haxeui backend
this is going to be a fun thing
@nocturne adder Heh, here's an example of something that i was talking about yesterday. Trying to port my app over to my new setup, went to use the mouse wheel and realised i never mapped it - wouldn't have noticed otherwise x)
xD
I can fully imagine you being like
" why is this scroll wheel not working ??? "
" oh . . . "
happens to all of us ahahahaha
yeah man, with framework building hat on you're thinking is different
something inconsequential like scroll wheel is not even on the rader
@agile snow I have the opposite of a load bearing trace π
a trace that breaks everything :D
gaaaah, having issues with haxeui and cppia
not sure what's going on... but if i reload the script i can't seem to load certain things again
buuut that's still pretty damn cool
Its working :D
if i reload the script i can't see the pages again :/
however it seems like the navbar itself can be reloaded fine... maybe something to do with navigationmanagers state...
yep... that's it
@:privateAccess haxe.ui.navigation.NavigationManager?._instance = null; added to the cleanup process
i'm not sure why it takes a bit of time to load up the orderpage, maybe its just a big xml so it takes a bit? but hey, the poc is all working 
ceramic is a decent bit faster at loading the page than i am
so something bottlenecking me i guess?
a classic
this whole trace breaking shit issue is getting a little annoying :D
var val = Sys.getCwd();
trace(val);
....... white screen
remove trace? completely fine!
wtf
what does your debugger say?
no errors or anything, not sure what the debugger should report
all traces run as expected, but i just get a big old white screen
what if you open it up with your debugger and set a breakpoint at your mainloop
or perhaps just make it immediately break, and see what it is at
perhaps it's stuck in a loop somewhere?
trace('[haxeui-simple] Error - Could not find image'); <--- fine
trace('[haxeui-simple] Error - Could not find image($filename)'); <--- white screen
if that doesn't give you any clue, it might be something memory related?
unpredictable stuff can happen if you have any misusage
very likely
pausing gives me an error
I see LLDB, so I assume this is native debugging?
yeah
Perhaps try another debugger that gives you a litttleee more information
you want to see the callstack, what each thread is doing and that kind of stuff
what should I use? I do get thread info here
where is __GI__clock_nanosleep called from?
HXLINE( 157) SDL_Delay(::Math_obj::floor(((_gthis->targetTime - elapsed1) * ( (Float)(1000) )))); seems like here's the closest i can get to it
that's expected stuff though, however commenting it out doesn't make any difference
wonder what the compiled code differences are
HXLINE( 32) ::haxe::Log_obj::trace(((HX_("[haxeui-simple] Error - Could not find image(",10,b5,75,95) + filename) + HX_(")",29,00,00,00)),::hx::SourceInfo(HX_("haxe/ui/backend/AssetsImpl.hx",0e,18,11,48),32,HX_("haxe.ui.backend.AssetsImpl",cf,ee,b0,8f),HX_("imageFromFile",81,cb,29,81)));
So that's with the $filename variable
HXLINE( 32) ::haxe::Log_obj::trace(HX_("[haxeui-simple] Error - Could not find image()",19,b9,88,31),::hx::SourceInfo(HX_("haxe/ui/backend/AssetsImpl.hx",0e,18,11,48),32,HX_("haxe.ui.backend.AssetsImpl",cf,ee,b0,8f),HX_("imageFromFile",81,cb,29,81)));
that's without
and filename is a String?
yes
weird...
yeah, how the hell do i figure this shit out
I'd love to help but I am not on linux atm
So that would be difficult unfortunately
Can't debug it XD
but this kind of RNG behaviour sounds like memory issues to me...
how does one investigate memory issues
try valgrind I suppose?
I do think it won't be smooth sailing
considering the GC and stuff, wouldn't be surprised if valgrind flags everything as misuse XD

π€£
oh very interesting, that only occurs when i DONT have the trace
==71571== LEAK SUMMARY:
==71571== definitely lost: 658,123 bytes in 3,138 blocks
==71571== indirectly lost: 7,884,372 bytes in 113,580 blocks
==71571== possibly lost: 25,455,557 bytes in 53,330 blocks
==71571== still reachable: 26,163,496 bytes in 29,507 blocks
==71571== of which reachable via heuristic:
==71571== newarray : 4,456 bytes in 13 blocks
==71571== suppressed: 0 bytes in 0 blocks
==71571==
==71571== Use --track-origins=yes to see where uninitialised values come from
==71571== For lists of detected and suppressed errors, rerun with: -s
==71571== ERROR SUMMARY: 434425 errors from 8386 contexts (suppressed: 0 from 0)
Well, i'm guessing that aint great
i wonder to what degree cppia is involved here
might need to use hxcpp and also face whatever issues occur on that side of the coin π
I'm not surprised XD
But I will say, this is highly suspicious.
That makes me think that your program is frozen or something?
Like truly frozen
But you did get traces?
Something weird is going on for sure...
it could be, its just hard to tell because the screen is flat white
also, daz has mentioned in the past that there's a way to extern things like cpp structs and still use them with haxe semantics
like null checking etc
do you have any idea on this? I might take a quick detour and redo my skia externs now that i'm not so blind
I don't know what that would be exactly.
cpp.Struct<T> sounds close to that. But it has some gotchas
Is that what you are referring to?
i'm not sure tbh
I just want to be able to null check some cpp types (or null them) in haxe land that makes hxcpp unhappy
public var image(default, set):Image;
function set_image(value) {
imageSet = true;
return image = value;
}
@:keep
@:unreflective
@:include("linc_skia.h")
@:native("SkImage")
extern class NativeImage {}
In file included from ./src/simple/Rectangle.cpp:15:
include/simple/Rectangle.h:63:26: error: cannot declare field βsimple::Rectangle_obj::imageβ to be of abstract type βSkImageβ
63 | SkImage image;
| ^~~~~
In file included from /home/j/Documents/Projects/cpp/TradingProject/haxe_modules/linc_skia/linc/linc_skia.h:12:
/home/j/Documents/Projects/cpp/TradingProject/haxe_modules/linc_skia/lib/include/core/SkImage.h:270:14: note: because the following virtual functions are pure within βSkImageβ:
270 | class SK_API SkImage : public SkRefCnt {
| ^~~~~~~
/home/j/Documents/Projects/cpp/TradingProject/haxe_modules/linc_skia/lib/include/core/SkImage.h:427:18: note: βvirtual bool SkImage::isTextureBacked() constβ
427 | virtual bool isTextureBacked() const = 0;
| ^~~~~~~~~~~~~~~
//more errors
Smells like either a race condition or hxcpp shitting itself
nah, if i understand things properly this is because i'm trying to use a cpp type by value that shouldn't be used that way
but in haxe land, we use things by value
gaaaah, i think what i'm gonna do is new project, and start from like step 2/10 for skia externs and just try and see if i can build it up closer to what the actual api is
which means saying bye bye to my project for a bit again π
maybe i'll hop back and forth a little
I think technically there's like 3 targets here that i'm trying to compile for.................. what a massive pain in the ass
==34546== LEAK SUMMARY:
==34546== definitely lost: 7,072 bytes in 159 blocks
==34546== indirectly lost: 5,232 bytes in 6 blocks
==34546== possibly lost: 6,065,029 bytes in 2,822 blocks
==34546== still reachable: 11,016,742 bytes in 23,521 blocks
==34546== suppressed: 0 bytes in 0 blocks
==34546== Reachable blocks (those to which a pointer was found) are not shown.
==34546== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==34546==
==34546== For lists of detected and suppressed errors, rerun with: -s
==34546== ERROR SUMMARY: 541 errors from 541 contexts (suppressed: 0 from 0)
Okay, with a completely simple setup, none of my old extern code and running on hxcpp instead of cppia, seems like we still have a bunch of errors
Don't worry about it
That is normal probably
It is very likely falsly flagging a bunch of stuff as "leaks" because it hasn't been collected by the GC
yeah, just don't have any frame of reference for this kind of debugging
my intent for using valgrind was not for checking leaks, but checking other memory related issues
my externs did need redoing anyway, so i'm not gonna stop just was curious about the state of this side of things
so far, only one cpp wrapper function :D
and everything is compatible between both hxcpp and cppia so far
@dense elbow ```hx
typedef ImageData = Image;
For a backend, is it possible to wrap `ImageData` in anyway? or does it have to be a typedef?
all backends seems to just pass the type to it directly can't find an example of one otherwise
i guess ic an just wrap the image into a class right here, can't I? π
i can be very silly sometimes
its funny, i just noticed how my goal of "keeping to the skia api" was leeching a bit in my framework on top of it
its completely unnecessary :D
Its fucking alive
Hxcpp and cppia both working
okay some really important information, if you're going to be constantly going back and forth between hxcpp and cppia. TURN OFF THE COMPILATION SERVER
I went on a wild goose chase for the last 2-3 hours because of that shit
hxcppia
I can hopefully drastically reduce the time i stare at the shitty out of date skia docs
well, we'll see, i know there's some things i'm probably gonna have to look at
any type is fine
class ImageData {} is also perfectly alright
oh, that explains a lot. I dont use the server at all
not even for code completion?
Well, that's the default in vscode
i meant compilation server
Yeah, I usually avoid compilation server. Got enough bugs already, no need to add more
I use it for cppia, drastically speeds up the recompiles
especially with haxeui in the mix
For sure you must restart it if you change your build params
But even when doing that, sometimes it does weird thing
Like I get a compile error on some type not being valid or resolved
Or even something that compiles but gives different output than if server was off
It's definitely not bug-free
(unfortunately I didn't managed to get a reproducible pattern, pretty random)
i really never considered it, it makes sense now that i'm looking at it in hindsight how i'd be able to relatively decently understand what issues were for cppia, but when i'd move to hxcpp and try to address the same errors in a similar way the solution i was applying wasn't working
but i was too unskilled to think that was a setup problem :/
nah
Curious, what code editor do you use,
Feel a bit empty/relieved now that i've got the hxcpp and cppia concept working together
could almost say i feel like i'm done, but aint no where close π
next up is starting to abstract away some of the cpp stuff of skia in my framework now and i think i'm still having shutdown issues with cppia so gonna tackle those next
I do not want to switch over to hxcpp one day and get silly can't compare to dynamic errors x)
sometimes these errors don't give a clear origin point
hm... NavigationManager in haxeui doesn't recollect its state on reload, so it doesn't understand that certain pages exist
sublime text
i basically need to either rebuild the correct state or make my own navigation manager
oh nice, navigationmanager just cares about the constructor so i think rebuilding this will be easy :D
oh, maybe not, it stores the reference to the item created in the last reload π
if (@:privateAccess nav.registeredRoutes.length == 0) {
trace("no routes registered");
var route = null;
var routes = ['blank', 'calendar', 'home', 'orderpage'];
for (page in routes) {
var val:Void->INavigatableView = switch (page) {
case 'blank':
Blank.new;
case 'calendar':
Calendar.new;
case 'home':
Home.new;
case 'orderpage':
Orderpage.new;
default:
null;
}
var route:RouteDetails = {viewCtor: val, error: false, preserveView: false};
if (page == 'home') {
route.initial = true;
}
nav.registerRoute('/$page', route);
}
oh man this is crazy even by remaking the routes in the scripts entry point, the items it seems to reference here is the old version?
Not sure how to address that at all
hm... might still have other cleanup issues
managed to sort it out
project is in a good place to remember to commit :D
basically everything in the foundation appears to be working now
hxcpp, cppia and hotreloading
property grids work now :)
still seem to have the weird invalidation loop bug but the behaviour bug has gone now with the rewrite
as long as i don't open a dropdown or click a scrollbar i'm okay xD
added a little convenience feature and playing with cppia a bit
if i do a hotreload, it will go back to the last page i was looking at x)
I'd like to figure out how to get it to instantly go back to the same page instead of having to play with timings, but, for now this is still nice
hahaha got it π no more ever needing to faff about what page i'm working on
think i managed to shave off around 0.1s of the recompile time by turning dce on full for the script side only
[71640:1108/161431.461908:ERROR:gpu/command_buffer/service/shared_image/shared_image_manager.cc:389] SharedImageManager::ProduceSkia: Trying to Produce a Skia representation from a non-existent mailbox.
Running my appp in ceramic to check things out and notice this lil error message referring to skia π
project isn't fully transferred over but with cppia my reload times are on average 50% less
managed to get tracy working properly and give me haxe code readings and... mother of god
why the hell is this a thing for me but not in other backends
π€
Will have to look when I get home, maybe I'll see if I can queue up haxeui events instead but I have no idea why there's so many
that's better
also see there's some low hanging fruit for things to optimise in here
madness tho
i wonder if queuing these events up would make much difference, it would basically be the same just moved... right?
yeah that's the fun part of tracy imo
you can very quickly tell (and also see) how small changes can have huge implications
i like it much more than chrome's profiler
wish we had a decent hxcpp debugger for the haxe side tho
I personally use remedybg
I really like it
i have a cpp debugger that works fine
its just i want to skip the whole find cpp file, search through the cpp code to find the corresponding haxe code dance
I remember Aiden used to work on mixed debugging for hxcpp
that would probably be ideal for what you want, but I think it is still very experimental (and possibly abandoned?)
yeah, i checked it out recently
gonna retry the hxcpp debugger and see if its okay, maybe i can just improve the workflow a bit
good luck π«‘
if i setup its own hxml i think its pretty okay
yeah, it seems to work fine if i don't use the same config as the rest of my project
okay, so i think i have a theory
what might be happening is i'm treating this invalidation cascade like "next..next...next...next"
if i were to just skip or batch the things somehow then maybe it would be better? π€
batch events instead.... π€
also, funnily enough those changes i made earlier and yesterday from tracy, has made a difference in hxcpp and made a drastic difference in cppia
still very hangy, buuuut its really cool
Before
Don't know how obvious that is but the page loads in a lot faster now
also, I seem to have gotten rid of the hanging completely
The page loading in DOES actually still hinder frames according to tracy, but the only thing i'm doing differently here is just simply managing it better, which inturn seems to also speed things up a bit
yeah, it was quite awful
still is not great, but certainly usable and app never seems to stop responding now
There is actually a change that i have pegged to do that i might push sooner rather than later
which might substantially help but for another time
release build feels pretty nice all things considering
not as efficient as i'd like but feel good to use regardless
pretty good stuff!
right now everything is very much immediate mode as well π
@dense elbow what's going on here, does anyone have any insights on what my framework isn't handling well in this chain of events
What i'm doing is, i'm opening a new page
that's the page^
There's something i'm not handling well and i cant see what it is
i can bare with it, but, its bugging me x)
maybe its something silly
is it doing that over and over?
i mean, the cloneComponent part... that should only happen once
well, i mean, in one chunk
just once from what i can tell, each pic is a frame
first and last frame just seems to be component validation
these blocks all seem to be ComponentBase.validateComponent calls
is validcomponent being called when the UI is idle (because it shouldnt be)
so i dont understand, whats the issue? I would expect a bunch of invalidations if things are.... .... well.... invalidated
it "locks up" during the load in
i don't get the same effect on other backends, so i'm wondering what i'm not handling properly but i can't seem to identify much in my framework
oh, so too many invalidations maybe... are you batching things? I mean, the whole point of callLater is you save up a bunch of callbacks and then execute them "at once"
its a way of syncing validations basically so if you invalidate a component 100 times, you should only get a single invalidation
class CallLaterImpl {
static var queue:List<Void->Void> = new List();
static var id:Int = -1;
public function new(fn:Void->Void) {
if (id == -1) {
id = Scheduler.addFrameTask(processQueue, 1);
}
queue.add(fn);
}
public static function processQueue() {
for (i in 0...queue.length) {
queue.pop()();
}
}
}
``` that's what i currently have for calllaterimpl
looks ok i think
its the best working version of call later i have
Schedule.addTimeTask(fn, 0,001) (like in kha) was a lot worse
but for that frame, this is all my framework really contributes
so i'm not sure what exactly i'm not handling very well here
me neither, scheduler looks alright, but its hard to know fully... usually a lot of nuance in these things
yeah, i suspect its something really simple and obvious
(i hate that calllater is an allocation to π )
but i don't have the full context of haxeui internals to easily understand
it feels weird that something like get_parentComponent is so expensive
is this cppia?
does it run better / different in release?
things do run better in release but i still feel that "chug" when changing the page
weird
im not fully conviced its the calllater tbh
it doesnt look wrong or anything
maybe i have some extra calls to parentcomponent, will investigate that one
or maybe you are invalidating things in the backend? Its quite rare to have to do that
i did do that early on but i removed them.. will double check that one
i call resizeComponent when adding one in screenimpl and i call comp.ready() when an item is added to screen in componentimpl
that seems fine / normal
only reference to parent is this:
public function hasChildRecursive(parent:Component, child:Component):Bool {
if (parent == child) {
return true;
}
var r = false;
for (t in parent.childComponents) {
if (t == child) {
r = true;
break;
}
r = hasChildRecursive(t, child);
if (r == true) {
break;
}
}
return r;
}
``` which i took from another backend to check if components were over
defo could be expensive, but thats not even calling get_parentComponent
this is using daz's fork of haxeui but i get basically the same issue on normal core
btw, may or may not help, but this is the new way in v3, which i might backport into v2, its defo better:
public override function onNextTick(fn:Void->Void) {
queue.push(fn);
if (!scheduled) {
scheduled = true;
if (tickDelay == -1) {
Browser.window.requestAnimationFrame((_) -> {
scheduled = false;
var copy = queueTickStart;
queueTickStart = [];
for (f in copy) {
f();
}
copy = queue;
queue = [];
for (f in copy) {
f();
}
copy = queueTickComplete;
queueTickComplete = [];
for (f in copy) {
f();
}
});
} else {
haxe.Timer.delay(() -> {
scheduled = false;
var copy = queueTickStart;
queueTickStart = [];
for (f in copy) {
f();
}
copy = queue;
queue = [];
for (f in copy) {
f();
}
copy = queueTickComplete;
queueTickComplete = [];
for (f in copy) {
f();
}
}, tickDelay);
}
}
}
you can ignore the queueTickComplete, queueTickStart and tickDelay
ah, call later change?
so basically:
queue.push(fn);
if (!scheduled) {
scheduled = true;
Browser.window.requestAnimationFrame((_) -> {
scheduled = false;
copy = queue;
queue = [];
for (f in copy) {
f();
}
});
}
calllater doesnt exist in v3... its Platform.instance.eventLoop.onNextTick(...)
oh interesting
So in those 3 frames ruleMatch is getting called ~1.5million times
could that be reduced some how π€
i mean, the css engine is pretty not optimized (i think Daz's fork is better) but 1.5M sounds like too many
ahh sorry that's not right
yeah, tracy doesn't automatically reconfigure the stats if you change frame with different settings
its around 300k
better but still seems high
hard to know though really
are invalidating anything in your backend?
can you zip it up, i dont need to run it, just have a quick scan
i think the backend is quite clean
nothing too complicated going on in this one
you can also take a peak at the readme π€£
did a simple test on try haxe array vs list and for some cases list was faster, i did question if list was a problem here
i think list is slower of modifcations...
i switched it to an array and it made little impact so i just fellback to list based on the little benchmark
i can move it back to array, its no biggy
list works better when you remove/modify from the ends
but costs more to add? Anyway, i doubt its the bottleneck
so looking, i do think its the call later impl... it feels smelly for some reason
is it the deferring to a time in the frame?
dunno, maybe its fine... its does mean that the frame task is always running, but i guess thats fine... it could just be with an empty queue
the evaluation of roughly 3 average fps over those 3 frames, time task vs that call later approach look the same in tracy
but the frametask "feels nicer"
hang on... i think you are running these callbacks in the wrong order
you are running them in the opposite order they have come in at
so that could mean you are causing a bunch of invalidations because things arent being validated in the order they were expecting (haxeui validation loop sorts things based in a validation depth)
add to the end and take from the top, isn't that the expected order? fifo
no, the order is the order they are added
add to the end and take from the end (which is what you are doing) isnt fifo
lilo* π
it should be fifo... they should be executed in the order they have been given to you
... better i take it?
lol
it makes sense... haxeui validation loop goes to some lengths to minimize validation by validiting, iirc, children first, then parents (or the other way round, i honestly dont remember now)... so that the children are "done" and wont cause revalidation
i think that change caused this
are you saying its worse, or better?
ok, well, its defo the right way to be doing things
maybe try array now
you shouldnt be reversing the invalidation order... defo not
so push and then pop?
i would just do this:
class CallLaterImpl {
static var queue:Array<Void->Void> = [];
static var id:Int = -1;
public function new(fn:Void->Void) {
if (id == -1) {
id = Scheduler.addFrameTask(processQueue, 1);
}
queue.push(fn);
}
public static function processQueue() {
if (queue.length == 0) {
return;
}
var copy = queue;
queue = [];
for (f in copy) {
f();
}
}
}
(written blind)
same outcome
Β―_(γ)_/Β―
yeeaaa π€£
no clue then, but almost certainly reversing the order isnt good...
if its worse, thats probably something else to look at
order wasn't getting reversed
it was
queue.add(fn1);
queue.add(fn2);
queue.add(fn3);
queue.add(fn4);
queue.add(fn5);
...
...
...
queue.pop() <--- fn5
queue.pop() <--- fn4
queue.pop() <--- fn3
queue.pop() <--- fn2
queue.pop() <--- fn1
oh?
so the result here is the same as the list
really bad naming...?
ok, then fine, wast that either... my bad... i assumed pop was the end
less verbose
A linked-list of elements. The list is composed of element container objects that are chained together. It is optimized so that adding or removing an element does not imply copying the whole list content every time.
yeah, it actually looks like a much nicer choice
anyway, as to the actual issue, no clue im afraid
i would put like one component there and a dummy counter and see how many invalidations you get
maybe there is something in the sheduler that is calling that task a bunch of times... hard to tell
it would appear here
very confusing place to be π
will try a simple page and see what occurs
but the only time i'm noticing the issues is when I load up a page with stuff
text measuring is getting called a decent amount of times as well
once the page has loaded in, its solid
its just that loading in phase
i'm not batching the objects, but could that make such an effect here?
draws*
honestly, no clue, it might not even be the calllater
if it ends up "fine" then i suspect its not about the render
that's what i thought
now to decide, what to work on next, the chart stuff or rewrite my exchange api
exchange api stuff is a bit boring
chart stuff is what i want to work on π
i should probably see if i can get windows to build
at least verify the cross platformness of it all
struggling to get it to compile for windows to match the linux setup, every successful compile i get, the lib file is massive or its missing apis that i need :/
worst part is, i have to hang around in windows to keep testing it x)
oh shit!!!
moment of truth π€
everything but text π
path = '/home/j/Documents/Projects/cpp/TradingProject/assets/fonts/Roboto-Regular.ttf';
cross platform is working!!!
I wish i could verify macos
text quality seems to be worse on windows than it does on linux here, maybe need some settings
i'm very happy with that, proof of concept works :D
the detail like text not being 100% is probably a simple setting issue either in my code or in the windows build process
yo billy, that trading app looks so good tbh
Thanks!
i think i may have found some kind of hint to the haxeui validation bug
this project is clean and just has my lib, as i wanted to start trying to build up the chart stuff and have 0.06 hotreloading is crazy af
seems like setwidth is getting called every frame for some odd reason
public var width(default, set):Float = 0;
This calls the setter every frame π€
switched it to @:isVar public var width(get, set):Float = 0; and that helped with that one
I'm getting eerie temptations to try and see if I can setup android but I may resist that temptation π
the part I hate the most about chart stuff is the axis labels
this shit is annoying as hell
early stages, but, it appears to me that my last attempt at charts was grossly overcomplicated π
it could also just be the case that this is the second or third time i've done this so its just easier
its also humourous that I asked claude: "can i get a 100 candle demo with natural movement" and it generated the above which is absolutely not natural market movement
but in a funny way, it could be perceived as natural from a computer pespective
That looks sick!
Also man you have balls of steel, I am pretty confident in my skill but I'd practically shit rocks if I had to build an application for stock trading. I just imagine some kind of error causing data to be shifted by like a tinyyy bit causing bad purchases / sales.
Oh this is skia? Sick!
cppia in action π
well, the primary use case for me is going to be journaling, but I do want a terminal and I did have to spend quite a bit of time getting the maths right over there
I can only imagine xd
the maths isn't necessarily hard, but, my maths skill is low and finding fees for things is scarce
from the ceramic version i had to make some assumptions to keep things flowing, so i actually appreciate the little reminder on that lol
the assumptions aren't massive, its more just assuming what the quote currency is going to be
but that's not flexible if you want to trade whatevers available
I mean do you have any issues with pricing
I've not gone in depth on stock trading but I know that the APIs to provide the data you might need are usually stupid expensive - people want to make trading bots and companies see a way to gain a lot of profit there...
ceramic version worked well enough for an mvp, but, the order pad was a bit odd with handling balance for posting orders. However, examination of trade completion, that was all accurate in comparison to the exchange I was using
and from a journalling and log perspective if the records are accurate that's not a terrible place to start from xD
crypto is still baby land so it's the time to jump on board
the window might be closing though, governments are starting to want to dig their claws in with regulatory measures π
every year it seems like there's some new policy that exchanges need to comply with that limits access to some degree
laws in a way hinder newer people, like take all the data regulatary things going on now
the people who can take the biggest advantage of this, already has the data, the law will prevent easy access for newer competitors, but i can almost guarantee you, that google has a way to ID you without you even needing to be emitting any data
Oh I do
but google probably does so more XDDD
lol
been listening to some business stuff and its very interesting to hear how marketing has been evolving
over there, obviously so, advertising is brilliant
if you have a niche, you can hammer into it seemingly quite simply
places like IG/Youtube/TikTok aren't considered as regular social media platforms but "interest media"
and the term just makes absolute sense
discord is kinda the last bastion of social media that isn't consumption based
that term makes alot of sense
I think of discord like old forums
it does, doesn't it! And if you have a thing you want to get out there, it really is a solid vehicle. Listening to the way its used (when the objective isn't to extort) I really can't see much problems with the model
because in practice there's no major difference between Google telling me about a product and a friend
I just wished Discord wasnβt a closed source platform that you canβt host yourself, or that at least the server data would be accessible more easily
What server data?
Just the messages, just like a forum is crawlable by anything that can fetch webpages
omg that looks so gooood
I'll probably do something like that one day if I ever get hint of something I don't like by discord
but no motivation for such a thing otherwise
ohhhh i remember the last time I got to this stage :D
managing the axis is a lot easier for components like this
still got some refinement to do
Looks clean!
much thanks! 90% of the cleanness is hidden away
but i'm very happy to have gotten back to this point
public var onDown:(x:Float, y:Float, button:MouseButton) -> Void;
function set_onDown(value) {
trace(visual == null);
if (value != null) {
visual.on(MouseDown, onPointerDown);
} else {
visual.off(MouseDown, onPointerDown);
}
return onDown = value;
}
"why isn't onDown getting called!?"
Took me too long to figure this one out π
didn't set the property definition π€£
just used grok for an evaluation on a multivitamin
and got one of those "which response do you prefer" things
bruh, option 1 said it was great and option 2 said it was pointless
da fuck am i meant to do with that
fml its been like 2 or 3 months since i did the event system
I completely forgot about implementing propagation control
i've had like 3 use cases for this, first 2 i added some booleans to remotely control
on the third one, i was like
right.. gotta sort this out..
wait a second?
didn't i set up some mechanism for this?
why isn't it working....
...
I wasn't fucking using it
it works so damn well
i can implement events that overlap each other in terms of input interaction but the child can block all parents from ever receiving it
fleshing out the setup for component behaviours
and with very little effort, we have a new horizontal line component with all the same behaviours :D
what's interesting is, i find the component behaviour setup messier than my last method, but waaaaaaay nicer to build with
hopefully I get to figure out some way to make it nicer the more I use it x)
i swear AI gets progressively worse every time it updates
questions that used to be fine now just do silly things
maybe its just degredation on free tiers
Yeah I don't know, I've been using only Opus 4.5 lately, and I get pretty good output from it most of the time
came across a situation where event system tripped up, had a visual that had 2 events on it. But I wanted the 2nd event to fire and prevent the first from activating
so added a priority system and a simple stopImmediatePropagation() setup
works nicely :D
I'm a bit stuck x)
For whatever reason I can't seem to get haxeui to work with my stack anymore
It either won't compile or I'm getting into infinite loops at runtime
I'm contemplating making my own ui setup :/
leveraging daz's already cppia compatible yogalayout externs
I don't wanna make my own ui setup tho π
the plot thickens
i'll have to sit on it for a bit, but, i basically can't work on my frontend currently
it's a bit of a big decision, will see if i can work on other stuff
I think regardless of what you decide to do, you should investigate those infinite loops, if you donβt want those to bite you again later
I've defo tried π
oh boy
Yeah I think the compiler folks lost the plot a bit when it comes to hxcpp / cppia with hx5
That's what I'm suspecting a little bit, it might be a haxe 5 thing in the mix as well
yep, I think the cppia codegen might have some issue
The infinite loop situation I can repro on hxcpp
but the compilation issues seem to be macro issues that were defo not there before
When you say infinite loop, it's infinite loop when running or when compiling?
when running, it gets into a loop of registering events
I see, then that's easier to debug than if that was on the compiler
You should debug your binary with visual studio
and pause it when running
I don't think this is a problem I can solve without Ian's context but I also don't understand where the source of the problem lies
yeah
haxeui's very big with a lot of behaviour hidden behind macros so its hard for me to dive deep into it
possible for sure
That's the main risk when you use a large library you didn't make yourself for sure
and tbh, i'm not sure how much of these issues are even issues with haxeui
a fair few, if not all of them might be constraints to do with haxe 5, cppia and β¨β¨β¨--macro include('haxe.ui')β©β©β©stuff
I don't really wanna stop using haxeui tho
so i'm a bit conflicted here
it's like ceramic vs skia all over again π
Iβm confused on how it just magically broke. Did you update anything?
it's usually dependency hell pulling some random ass module you shouldnt pull
some rogue import you shouldnt have somewhere
I remember I noticed the imports behaved a bit differently with hx5. maybe this coupled to macros is screwing you here
haxe, hxcpp, haxeui
but reverting to my last working version in commit isn't working because for some reason it can't find the commit
which is fine, because I have a fork https://github.com/jarrio/haxeui-core with my previously working cppia/haxe 5 stuff but it no longer works as well
so i have no idea what broke
I know something i did broke it, it wasn't magical, but that isn't useful
could that be it? I've tried a pretty barebones project and have similar issues
but yeah, its hard to debug when you don't know the internals of the library very well or macros
most likely haxeui core macro finds shit it didnt before
problematic eitherway
Playing around with making my own ORM
connection.find(table).where(age > 10 && age < 21).one().then(function(result) {
trace('id=${result.result.id} name=${result.result.name} age=${result.result.age}');
});
surprisingly little amount of macros & code to get this to work fine
age is a field on table
no type checking or anything like that, got a simple field check to catch spelling errors though
var foo = 30;
connection.find(table).where(age > 10 && age < foo).one()```
works but is a bit odd looking though
connection.find(table).where(age == 22 || age == 90).one();
//src/Main.hx:30: id=3 name=l age=90
``` this is cool
what does the object definition part look like?
what part?
the table definition?
possibly
table definition is simple atm
import db.types.ITable;
class Users implements ITable {
public var id:Int;
public var name:String;
public var age:Int;
public function new() {}
}
interface has no macros on it currently
ah cool
There's only one expression macro atm lol
and i'm not sure what else i'd need a macro for π
besides adding some type checking and some table creation stuff
public function new(table:T, connection:IConnection, builder:IQueryBuilder) {
this.connection = connection;
this.builder = builder;
switch (Type.typeof(table)) {
case TClass(c):
trace(Type.getClassName(c));
default:
}
}
oooooo this works?!
it traces src/db/TypedQuery.hx:32: Users
I thought that wasn't a thing
function objToClass(dbResult:Dynamic):T {
if (dbResult == null) {
return null;
}
var inst = Type.createInstance(tblClass, null);
for (f in Reflect.fields(dbResult)) {
Reflect.setField(inst, f, Reflect.field(dbResult, f));
}
return inst;
}
I'm guessing this kind of magic is unavoidable with database related things - right?
there's no way that's a valid key
Reflect.field(data.ogResult[0], 'COUNT(*)') is 3....
madness
con.find(table).update(name = "Billy").where(id == 1).execute().then(function(resp) {
trace(resp);
});
What do we think about this kind of query?
con.find(table).orderBy(table.age, DESC).get().then(function(resp) {
for (item in resp.result) {
trace('id=${item.id} name=${item.name} age=${item.age}');
}
});
id=3 name=l age=90
id=2 name=o age=35
id=1 name=Sam age=10
π
This is quite fun to make
macros are pretty fun to use
var obj = new Users();
obj.age = 28;
obj.name = "Logo";
con.find(table).insert(obj).execute().then(function(resp) {
trace(resp);
trace(resp.success);
});
Took longer than expected to figure out the insert setup but there we go
with that i can now read, write, create and delete
Me and Bob o are best friends
The mighty three
What is the purpose of execute? Could you chain insert and update for instance?
execute "runs" the query otherwise it continues to chain
currently you can chain insert/update
and that is defo undesirable, might have to fix that with a macro but not sure how to address that just yet
might just end up doing another class separation
currently its:
Database -> TypedQuery<T:ITable>
probably can do
`Database` -> `Action` -> TypedQuery<T:ITable>`
- insert
- delete
- update...
But i was more interested in getting meat of it done, i'm not gonna do that mistake myself
What's next to do for orms π€
maybe table creation π€
One thing none of the Haxe ORMs have is migrations
Obviously get the basics first, but it would be nice to finally get that
I think it would be doable because I have got it designed so that it can have additional backends, it would probably be a case of just mapping the db type back to haxe types
nothing fancy with my backend setup either, just an interface with build functions
when you say migrations could you expand on what you're talking about? Are you referring to things like altered tables?
Table alterations!!
I'm not sure how to go about handling deletions yet
I could just assume and boop it away, but I don't like that... its so easy to change these things in code and in turn very easy to just vanish data
maybe its okay, but i'll think on that one
maybe an explicit @remove meta on the field
got nullable fields marked with wrapping items with Null π
class Users implements ITable {
@size(100) public var name:String;
public var age:Null<Int>;
public var password:String;
@delete public var email:String;
}
opt in field deletion works
@rename("password") public var pass:String;
renaming done, a bit awkward but I'm sure the explicitness of it will have its upsides, flow here is:
apply the meta -> rerun -> rename variable to the value in the meta
we got the obj -> int <- obj setup done
I guess all I need to do is figure out the relationship query and then I should have a poc of a one to one relationship π
also, i think the syntax to using a query might not be ideal, i'll have to keep using it but i don't like something about it
it might make more sense to do something like
var user = new Users();
user.insert();
user.find();
I wonder if i coulld abstract away the promises in some way
I feel like you would be basically reinventing entities2 at this point
I am a bit, but e2 doesn't work on my haxe version and I am gonna making improvements where I can
I have an idea for the promise stuff but I'm trying to tackle the relationship stuff atm. Having some complications in figuring out how to evaluate the query
but if you have alternative ideas feel free to say, i'm not quite sure exactly what I want just yet so i just wanna play with things
I got the relationship query built but this is a new problem
mysql dumps the result into a flattened obj
I could match fields on the corresponding classes but then you wouldn't be able to have identical field names across objects which is a bit lame...
// Select
db.from(User).where(age >= 20).get();
db.from(User).withAll().then(...); // joins all relations
db.from(User).orderBy(user.age, ASC).get();
db.from(User).count().then(...);
// Insert
db.from(User).insert(user).one(); // insert from instance
db.from(User).insert(name = "J", age = 23).execute();
// Update
db.from(User).update(name = "Bob").where(usersId == 1).execute();
// Delete
db.from(User).where(usersId == 3).delete();
mvp of orm all done, gonna use it and see how it feels
how reasonable is it, to allow multiple database "types" at runtime? So being able to say, use both mysql and mongodb at runtime
Is that something people do or has any particular purpose?
conceptually I could see nosql db's covering sql and vice versa, just not sure whether I should actually consider it down the road
ecto (from elixir) lets you do that, it makes a lot of sense
it is pretty common to use multiple databases for cache, search, content, etc
you have a separate "repo" for each db type
a repo is basically the equivalent to your db
the repos are controlled by an adapter which would be the backend
you can also configure pooling and stuff there
oh, interesting, i'll not go down a path that would make that kind of setup harder then
I added a message counter to haxebot around a month ago, for multiple reasons, but the initial prompt was scammer related, I kind of wanted to build a list regular people who use the server
its really quite cool, In the last month I now know that 214 people have communicated on server
server has lots going on these days so its hard to just pick that up mentally
test
should text input cursor always be black?
seems wrong here
not sure how to handle that in haxeui though
text inputs properly working, haven't done double click highlights but I got a very solid foundation here
even got multiline working
no cut, copy, paste but I think for now they're more luxury until I actually find a moment where I want it
we got cut/copy/paste x)
text input feels good, gonna start bringing things together again
forking so many things to get haxe 5 things to work
as expected things aren't working perfectly, but, chart rework is presentable, exchange api is working and we can actually see things
its been so long since i've been able to see the app running, its very motivating and it also makes it seem like there's way less I need to do
centering stuff is hard
Not sure if you have seen it, but there is https://www.pencil.dev. Quite crazy if you need to cook designs/layouts and get a format that can be easily adapted into others
I just fed it 35 user-stories and it created all the necessary screens for that UX
oh wow, that looks pretty cool
we got some app flow going with the backend π
