this is a week or so worth of brainstorming. Looking at pulling everything sprite related into it's own little struct. And also doing a message everything arch

notes/MakingAnActualThing.txt

@@ -31,3 +31,23 @@ So for a sprite, which is a generic texture and position/size combo
 Images are similar, but instead of a "sprite" I made a computsprite because that's the only thing that uses them.
 
 Now if I had to shove these into a component / a set of components... I could have a component of the vertex type even?
+
+
+
+===== Sep 2020 =====
+
+Lets think about this for a minute...
+
+* We have components which are purely data...
+	* But can also have structs that impl functionality
+	* The data can be contained within traits. But it has to do all IO through the trait interface. ALL
+		* Problem, for example I have primitives like textured sprites, and also complex widgets which also have additional IO they they need. Like text input or buttons. I suppose This could all be made message based. So when the text input receives a focus, and then key presses it would update. When the enter key is pressed it could create a customer event for which another component is the listener... 
+		* Maybe this is the way to go... Have some generic structure that has a render(params), notify(event), update(delta) -> VEvent
+		* So if I had a textbox sprite it could notify(key events) render 
+* We can split up components in order to have sharable sets of data for shared functionality. e.g rendering
+
+[[paste]]
+
+
+
+So that article more or less talked about what I was thinking with the ECS. But they didn't really go into the separation of components. 

notes/paste.txt

@@ -0,0 +1,40 @@
+Content-Type: text/x-zim-wiki
+Wiki-Format: zim 0.4
+Creation-Date: 2020-09-09T22:41:18-07:00
+
+====== paste ======
+Created Wednesday 09 September 2020
+
+// If I were to have multiple systems
+/*
+
+One for rendering
+One for updating
+One for eventing
+
+Rendering is easy enough. It needs all the components necessary in order
+to generate the vertices. This includes the position, size, and vertex generator
+
+Updating can probably be multiple types, I imagine something that implemented an Updatable
+trait could then be used.
+
+So the big problem here is that I have two traits that I want to expose, BUT
+I have to put the concrete value in both containers... I don't think this is something
+that specs will like since it wants to be the only owner. No use in RefCell'ing it
+because that's just stupid
+
+What if I turn this on it's head and really embrace the systems. So for example I could have
+the User system. Ooof this is a big question actually...
+
+// Components that want to be updated
+Move
+
+// want to be drawn
+Drawable
+Geom
+
+Notifyable
+
+
+
+*/