https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    I can't say in details as I didn't see @ambitious-knife-25690 's implementation, but there are 2 different things in Ceramic: - screen scaling, that you set up for the whole app - any visual can be transformed, including with a scale Given that haxe UI is rendered using a 
    Visual
    hierarchy, you can always scale that visual if you want it to be bigger or smaller
  • a
    yes, my intention was to expose the scaling fields to the user to decide
  • a
    but i figured for most cases, people would want their setup to scale how they setup their app from the beginning
  • a
    there's other neat things on a visual that i haven't explored yet
  • a
    like bindtonativescreensize etc
  • b
    im not sure thats accurate... i certainly wouldnt expect my app to scale as i resized the window
  • b
    but, i guess it very much depends on the type of app
  • a
    For a general purpose app that would be the case but for a game i think they would
  • b
    There is also a scaling (used by elements immediate gui) that you can use: 
    visual.bindToNativeScreenSize()
    , which will set the width and height of the visual to the native resolution of the window, and scale it accordingly
  • a
    like, in ceramic you set the default scaling setup at app entry
  • a
    so, it's completely configurable with a simple enum
  • a
    and i'll map the scaling props to component surface with getters and setters
  • a
    Ian, maybe there could be a macro for this
  • a
    Copy code
    hx
@map(this.surface.scale) var scale(get, set):Float;

/**
generates the following
**/
var scale(get, set):Float;
function get_scale() {
  return this.surface.scale;
}

function set_scale(value:Float) {
  return this.surface.scale = value;
}
  • a
    would be useful if someone needs composition
  • a
    or maybe have the setter options in the meta i dunno
  • a
    probably not needed considering backend development aint that frequent 🤣
  • b
    seems a little unneeded imo... its not hard to write the getter / setter, its more obvious also. And it would require a build macro on the componentimpl... and yeah, i doubt it would be used very often either 🙂
  • a
    just seems like it would be cause there's "suddenly" 3 backends being made at once
  • a
    nvm 🤣
  • b
    update for the validator system:
  • b
    im in no way say you have to use all these methods to let the user know about invalid data, but its nice you can 🙂
  • b
    apart from the UI stuff (showing hiding errors, etc - which im going to try and make semi automatic), this is the code for the validators:
    Copy code
    haxe
        var v1 = new RequiredValidator();
        var v2 = new EmailValidator();

        textfield1.validators = [v1, v2];
        textfield2.validators = [v1, v2];
        textfield3.validators = [v2];
  • b
    i also would like to be able to set this all up via xml, so will need to think about that a little
  • f
    hmm, I have a Error : ValueException if I do this on openfl and hxwidgets, didn't test others
    Copy code
    haxe
var dialog = new SaveFileDialog();
            dialog.show();
  • b
    "nothing to write" error?
  • f
    Hmm, maybe, in fact in my project, I don't plan to write anything, I plan just to have the save file path , because it's other programs that write the bytes
  • b
    yeah, you shouldnt have to have something to write... i dont think
  • b
    Copy code
    haxe
        if (fileInfo == null || (fileInfo.text == null && fileInfo.bytes == null)) {
            throw "Nothing to write";
        }
  • b
    🤔
1...144314441445...1687Latest