https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    hmmm, yeah, the ids in an item renderer will certainly be repeated
  • b
    each item renderer is cloned, so the components (and their ids, which is how default item renderers link data to components) will be repeated
  • b
    sounds like you might need a somewhat "cleverer" solution to id > component resolution
  • p
    Does it have unsynchronized/non-atomic reads/writes from/to static variables? Then it is not thread safe. Does it end up calling OpenGL? Then it is not thread safe. TLDR: HaxeUI is most likely not thread safe.
  • b
    ah, i just realised i replied to the wrong message, meant to reply to "i could live without python having a gui, but if i do have a gui id want it to work on java", and yeah, haxeui is almost certainly not thread safe... are there UI frameworks that are? You generally have to be very cautious with threads and UI
  • l
    my component resolution doesn't solely rely on id's. there are ways to get components via CSS selectors, class names and css class names. it can also find childs of components, so one should be able to write tests and get to all components of interest even without unique ids. and of course since you are testing "your" app, you can add ids or other identifying properties to components that would normally not need them.
  • b
    cool... i makes sense, but yeah, its totally "normal" for ids to be repeated, for sure. Maybe another option is to grab children by index too "and i click on the 2nd item renderer in the "mylist" listview"... something like that?
  • l
    well findElements returns an array of Element instances which can then be used to access any child by index and send mouse events or read or write properties
  • b
    gotcha
  • l
    it's not sending "do something to 5th child of x", but rather get all elements into your testcase and then do something with them. because you always want to be able to check for null, or property values in your test, so you need a reference to each component anyway.
  • l
    that also reduces the number of different commands that need to be sent between testcase and app
  • b
    yeah, i get it... i would love to maybe create a gherkin to vocab to that works on top of haxeium at some point... could be nice
  • b
    we use functional tests all the time at one of my clients (INPS) they are invaluable and the gherkin syntax makes it super easy for non devs to write tests
  • b
    lemme see if i can pull out a nice one
  • b
    this sort of stuff
  • l
    never used gherkin, so don't know how easy it would be... I guess if it's a higher level abstraction of what haxeium does, then one could probably write a macro that reads gherkin input and converts it into testcases
  • b
    exactly, i mean, at a basic level all of those test steps just turn into ruby code
  • b
    well, they call ruby code with parameters (the parameters are in blue)
  • b
    the only really interesting thing about gherkin / cucumber is the scenario outlines (ie the "Examples:" part) and inline tables... (ill see if i can find one of those)
  • p
    I very much doubt that there are thread safe UI libraries, given the amount of global state that might be maintained behind your back. And things the lib interacts with like OpenGL, etc.. A thread-safe UI library would probably be quite complex. (In Rust UI frameworks should be a bit more thread-safe, since using a non-thread-safe UI type in another thread will be a compile error)
  • b
    but, the fundamental issue is the same though, no? Say you have a progress bar and two threads trying to update it at the same time... How does rust protect against this? I mean, its just a race condition, and i dont know of any UI framework that protects all its properties in mutexes or locks
  • p
    Because it doesn't allow mutable references to be shared between threads without being wrapped in eg a mutex.
  • b
    ok, so i have a safe ref to the progressbar in each thread... what about its properties?
  • p
    Well, if the progressbar is wrapped in a mutex, the mutex remains locked as long as you have the reference. And you can't release the mutex without invalidating the reference.
  • b
    yeah, good point... not sure what i was thinking... i guess you can still very easily lock up the UI thread this way, but then thats easy enough to do without safety (or threads)
  • b
    anyways, i guess the point is: no haxeui isnt thread safe and i dont know of a ui framework that is (winapi isnt, qt isnt, wx isnt, etc)... ... ... ... rust may help (which isnt useful for haxeui)... ... ... and dont forget to only use linux! :p
  • p
    Unlike in let's say Haxe, the Mutex api simply doesn't allow for a reference to outlive the section were the mutex is locked.
    Copy code
    rs
fn foo(m:std::sync::Mutex<i32>) {
    let mut guard = m.lock().unwrap(); // lock mutex
    let r = guard.deref_mut(); // get mutable reference
    *r = 5;
    drop(guard); // release mutex
    *r = 6; // compile error
}
    > anyways, i guess the point is: no haxeui isnt thread safe and i dont know of a ui framework that is (winapi isnt, qt isnt, wx isnt, etc)... ... ... ... rust may help (which isnt useful for haxeui)... ... ... and dont forget to only use linux! :p yep that's pretty much the point (well ... only use a FSF™️ approved distro! /s)
  • b
    Copy code
    rust
    drop(guard); // release mutex
    *r = 6; // compile error
    that part is verrry nice that it would catch that at the compile stage
  • b
    would it catch anything if you didnt drop it? Or would that happen automatically when the gaurd went out of scope?
  • p
    drop
    is called automatically when the guard goes out of scope.
1...121912201221...1687Latest