diff --git a/thoughts.txt b/thoughts.txt new file mode 100644 index 0000000..f2c2bd0 --- /dev/null +++ b/thoughts.txt @@ -0,0 +1,143 @@ + +//Variables because c'mooon nobody wants to re-write the same color +// ten thousand fucking times +var standard-background: green; +var standard-background: blue; + + +//"&" specifier says that it's a style overlay for a class +//There is only one style slot, and only one class slot. +//But doing it this way means we can parse them in any order +// and re-reading them overwrites the old value (changes +// for like live editing style/core layout) + +&style-overlay +{ +state this.ivd-mouse-left-down: + background-color: standard-background; +state model.string == "help": + +} + +.class-name { + //defines a class +} + + +#instance -> model-name.children-field; + +//Maybe make it so that instances can't have bodies? +//it's kind of an annoying thing where they need to be abstracted later... + +//Then how would you even do styling/class declarations if you're just +// doing a straight element? Like is the element name an actual class name? +//Things work differently with the HUI model... + +#class-name-to-instance -> static; +//Would give you a single instance by binding to the static model + +//default is the entry state for the PDA + +table default +{ + unpack: hui-radios; //template state unpacking + + push: ivd-mouse-pulse:hui-radio-button, hui-radio-button-hover:self; + + loop: ivd-mouse-pulse:hui-radio-button:(self), action-name; + pops: ivd-mouse-pulse; //action optional + //But you can't pop from default... + + substate-name { + subs: ivd-key-f-down, camera/rotate, action-name; + } +} + +//Maybe even ditch the sigils... + +class hui-radio-button +{ +state hui-radio-button-hovered:self: + background-color: blue; +} + +style hui-radio-button +{ + background-color: green; +} + +bind hui-radio-button buttons.name; + +//okay but it's important to be able to do position-within on instances, right? +// + +bind hui-radio-button -> buttons.val +{ + position-within: radio-box-custom; //walks up parents of model to find binding class +} + +bind hui-radio-button -> experimentals.val +{ + position-within: hidden-options; +} + +//And this is where remoras became a thing + +remora remora-class-name +{ + +} + +//idk I like the old syntax........ and I don't wanna rewrite all those damn tests lol + +//but yeah the concept of a class is very different in hui vs IVD, in IVD it's currently just a template +// for elements, but in hui it's a way of identifying elements and binding behaviors... + +#bind operator +.class operator +@remora operator +&style operator + +%table operator? it looks kinda likea table... + +%default +{ + unpack: transition-table-template; + +} + +%default +{ + unpack: hui-radios; //template state unpacking + + push: ivd-mouse-pulse:hui-radio-button, hui-radio-button-hover:self; + + loop: ivd-mouse-pulse:hui-radio-button:(self), action-name; + pops: ivd-mouse-pulse; //action optional + //But you can't pop from default... + + substate-name { + subs: ivd-key-f-down, camera/rotate, action-name; + } +} + +//maybe just call that one table... It distinguishes it from the others well anyway + + +//can't you do like + +#element +{ + position-within: container-class-name; +} + +//And just... idk... put it in all of them? Like why does it need the model? +//Why do we need remoras? +//idk I'm tired. + +//Maybe position-within parent class like that causes it to bind to its parent model? + +#element -> parent +{ + position-within: container-class-name; +}