-
Notifications
You must be signed in to change notification settings - Fork 0
/
progress-notes.txt
65 lines (64 loc) · 5.9 KB
/
progress-notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
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)