https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    eg:
  • b
    Copy code
    button.style2 = {
                backgroundColors: [0xFF0000, 0x00FF00],
                backgroundStyle: "vertical",
                padding: {
                    left: none,
                    right: 20
                },
                width: "auto"
            }
            button.style2 = {
                backgroundColors: ["red", "#FF00FF", 0x00FF00],
                width: "100%",
                height: pixels(100)
            }
            button.style2 = {
                backgroundColors: [
                    { color: 0xFF0000, block: 0 },
                    { color: 0x00FF00, block: 5 },
                    { color: 0x00FF00, block: 95 },
                    { color: "blue", block: 100 }
                ],
                width: "100px",
                height: auto
            }
  • c
    nice to know! thanks!
  • b
    there will also be util functions to add to the global style sheets: 
    Toolkit.styleSheet.add("rule", style2)
    and i was thinking of static functions on component class also, so 
    Button.addStyle(":down", style2)
  • b
    i know ALOT of people like to style from code, which i still dont fully get, but either way, it should be easy for people to use it that way if they are more comfortable
  • b
    so quick question, im going to create a kenney ui theme, so its all done and people can just use it with a single like, something like 
    Toolkit.theme = "kenney";
    - themes themselves are haxeui modules, that can / will be use separately via haxelib, so im wondering what a naming convention should be, i was thinking 
    kenney-theme
    (haxelib name), but then i thought, should it be prefixed with "haxeui"? So, which of these makes the most sense (for a haxelib name):
  • b
    * kenney-theme * haxeui-kenney-theme * haxeui-theme-kenney * something else?
  • h
    oh . . . yeah that's a tough one. I like the idea of 
    haxeui-theme-kenney
    cause it could possibly model after how you'd expect to import it. Like 
    import haxe.ui.themes.kenney
    Otherwise: 
    kenney-theme
    seems cool too
  • b
    well, there would be nothing to import
  • b
    it would be a module.xml, a bunch of images and .css files
  • b
    Copy code
    xml
<module>
    <themes>
        <kenney parent="default">
        ...
        </kenney>
    </themes>
</module>
  • h
    Ah, so there's no chance a theme would ever need to have something imported? I assumed there was a possibility even with modules . . . That's nice to know anyhow!
  • b
    (in reality i might not extend it from default though)
  • h
    toolkit-kenney-theme
  • b
    toolkit?
  • h
    tktheme-kenney
  • b
    eh?
  • h
    based off of : 
    Toolkit.theme = "kenney";
  • b
    right, but thats just how you use it inside haxeui... i think it should either mention haxeui in the haxelib name (so its obvious)... or not (so its cleaner)
  • b
    adding Toolkit to it just confuses it more (i think)
  • b
    haxeui-theme-used-with-toolkit-dot-theme-kenney-version
  • b
    😄
  • h
    hahahhahahaha
  • h
    That one rings with me for some reason
  • c
    +1 
    haxeui-theme-kenney
  • c
    btw I always read tk as teamkill
  • b
    haxeui-theme-xyz is my preference too i think
  • a
    might be worth making it 
    enum abstract Theme(String)
    so people can get completion for pre-existing/default themes
  • a
    That format all though makes sense, is a little lengthy
  • b
    im not sure an enum makes sense though... the themes would be haxeui-modules, supplied as haxelibs, so they can be anything
1...197198199...1687Latest