Thoughts for the future of IVD. Current plan is a merge with hui.

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;
+}