progress-notes.txt

Using this to track what I have done in case I ever want to write something about it later.
Note: This includes the progress notes for XRB and T4Lwm

- Use a ton of the Rust book: https://doc.rust-lang.org/book/second-edition/
- Use a ton of the X11 Protocol Spec: https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html
- Spend a long time trying to figure out why "length in 4-byte units of 'additional data'" isn't correct, unless I fucked up (under "Information received by the client if the connection is accepted: ")
    - Eventually just ignore this property and dynamically read the input depending on the count of the properties and not a fixed length
    - Use StreamBuf to do this with lower overhead
- Use a bunch of Regex in Sublime Text (ie ([a-z])([A-Z])) to swap the opcodes from https://cgit.freedesktop.org/xorg/proto/xproto/tree/Xproto.h to CONSTANT_CASE
- Start working on the CreateWindow request. So many structures :(
    - Kept on getting error 14 IDChoice, so I got python-xlib and compared its xtrace to mine
    - I made them look exactly the same and still got errors. I think xtrace was leaving out some details
    - Use https://gist.github.com/jhass/5896418 to capture the traffic
    - Load into wireshark
        - Right Click -> Decode As... -> X11
    - Requests to create the window are the same... I think its because I am not creating some of the other resources, so let's get on that
    - Finally realize how values work... I was trying to use them like normal data instead of following the mask.
        - Learn about traits, and start using them (and make plans to use them with old stuff)
    - Properly implemented stuff. Fixed another place where I was using write_pad(0), aka writing 0 bytes of padding, and added a panic! if you try to write 0 bytes of padding.
    - DISPLAYED A FUCKING WINDOW LETS GO WOOOOO
        - Note: To get this working I have some resource IDs, like the ID of the window I create, statically set.
    - Fixed an issue where I was using >> to read in little endian for u16 and u32 when I should have been using <<
        - Wow, everything now haha
        - No more static resource IDs
        - Can now generate IDs
        - I bet the initial connection's length specification is even right...
    - Read about how deadlocking can occur if you are not constantly reading messages from the X Server
        - Create a new thread that constantly reads messages from the X Server and forwards them to the main thread
    - Work on implementing replies
        - Track sequence number
        - Implement GetWindowAttributes (first one I saw) and ListFontsWithInfo (returns multiple, so good for testing that feature)
    - Realize that I have made a huge mistake with how I am reading in and validating stuff. Go to switch to buffered reading of x characters then reading from that buffer.
        - This was actually a LOT to transfer too than I expected. What a pleasant surprise :)
    - Add ability to ignore messages from the X Server until you get a reply or error with the specified sequence number. Messages are stored for later, so you will not miss anything by using this.
    - Start working on all of the request types (not their responses though)
        - Get to SendEvent
            - Up til now I have been doing things manually to learn the protocol and because I wanted to include some human intuition.
            - I already did that, so I wrote a script to parse the protocol into code and used it for most of sending events
            - It still took some manual tuning, but far less
        - Get to PolyPoint and decide that it is stupid to be doing this all manually
            - Make the headers for the events manually (with a template tho) so the arguments can be intuitive
                - Also did the enums at this point (manually)
            - Have a script generate the mass of the body
            - Fine tune the body manually (ie variable request lengths, parameter name changes, etc)
    - Start working on getting all reply types
        - Use sublime text to convert the completed list of reply names to function names and stuff
            - Copy from ServerReplyType in enums
            - Change "[enum]" to "ServerReplyType::[enum] => reader.read_[enum]_reply(detail),
            - Use regex in Sublime text to convert the function to snake case (case sensitive)
                - `read_([A-Z])` -> `read_\L\1` to convert first letter to lowercase
                - `read_([a-z_]+)([A-Z])` -> `read_\1_\L\2` to convert following uppercase letters to snake
                - `\s+ServerReplyType::\w+ => reader.(\w+)\(detail\),` -> `    /** Reads TODO */\n    pub fn \1(&mut self, TODO: u8) -> Option<ServerReply> {\n        \n    }\n`
                    to convert the function names to function definitions
        - Modify spec parser to read replies. Make the vast majority of replies (although not all of them)
    - Work on object mappings. Ie Drawable.arc(...), GraphicsContext.set(...), etc
    - Work on the actual window manager. Get the a window reparented with a red bar at the top, wohoo!!!!!
        - This is super useful for debugging all my stuff and making useful bindings too, as I am getting it all to work well while making the manager
        - Fixed the way I was doing padding. Was using modulo wrong, oops
        - Weird that even though there is a list of pre-defined atoms in the spec the atom for window name for some applications is not in it
        - Weird that you have to send and react to Expose's for things to not get fucked up
    - Worked on tiling
        - Took a while to figure out how I was going to do it, and to make it work with Rust
            - Code would have worked in any other OOP language, but does not in Rust
            - Thats OK tho, I figured it out by not using Enums and properties for the first and second Tiled windows and instead used a Vector with at most 2 elements
        - Made tiling work of currently focused window (surprisingly hard)