wingo VS byteorder

I've been using X11 on my Framework laptop for years. No desktop environment at all. Just my regulard old school window manager[1]. No KDE or GNOME. But also no XFCE.

The only thing I had to do to get scaling working for me was set two environment variables[2].

I was indeed worried about this when I bought the laptop. Prior to this, I avoided anything with resolutions higher than 1920x1200. But it turned out that everything mostly worked with a couple tweaks.

I think the only real issue I've run into is `git gui`. As I understand it, the GUI toolkit it uses doesn't support scaling? Not sure. I ended up working around it by just increasing font sizes. I suppose this exposes the weakness that is probably impacting you: the scaling on my laptop is being done by the GUI toolkits, not the display server or compositor. (I don't always run a compositor, but when I do, I use `picom`. Mostly just to avoid tearing.)

[1]: https://github.com/BurntSushi/wingo

[2]: https://github.com/BurntSushi/dotfiles/blob/ea3a88e6160f4244...

I used Wingo (https://github.com/BurntSushi/wingo) for a while and it did the floating/tiling mix pretty well.

I also used StumpWM (https://stumpwm.github.io/) for years, primarily in purely-tiling mode. The killer feature for me was that you (the user) define frames on the desktop, and then windows are placed into frames rather than resizing and re-jiggering everything whenever a new window opens.

Yeah I remember activities from over a decade ago. I don't recall ever being able to get it to work right.

I ended up writing my own WM instead: https://github.com/BurntSushi/wingo

That's why I went and wrote my own window manager that breaks this aspect of EWMH so that workspaces can be changed independently on each head: https://github.com/BurntSushi/wingo/

Wingo

Switching to a desktop environment is a no-go for me. (I wrote my own WM.) So I'm very likely going to be spending quite a bit of time trying to find a configuration that works for my eyes. I don't mind putting in that time, I'm just hoping that I can find something that works. But others might bounce off. This is actually why I have historically not purchased laptops with HiDPI displays, specifically to avoid dealing with this problem. I made an exception this time because there are so many other great aspects of the laptop.

Ditto, I guess? :P (But obviously with the position on the Unlicense flipped.)

To address your indictment head-on: you suggesting the 0BSD as a better alternative is really missing my point. The 0BSD is not an alternative for my use case. The Unlicense is one of the very few overt "political" acts that I inject into the software I produce. Its purpose is to make a statement. The 0BSD doesn't do that IMO, so it's not actually an alternative that meets my advocacy goal.

You and Rick Moen seem to have the same apparent blind spot for this. See my conversation with him that started here (which might also clarify some aspects of my own position): https://github.com/docopt/docopt.rs/issues/1#issuecomment-42...

And finally, note that my dual licensing scheme is exactly a response to the "problems pointed out by quite a few people": https://github.com/BurntSushi/byteorder/issues/26

If you want something more convenient and higher-level, you can (and frankly should) use the byteorder crate, which has a bunch of structures and traits to make dealing with byte order simpler. The only thing it's missing is the ability to adapt (wrap) a stream but that's about it.

Of course in C you can get a pointer to the value and iterate over the raw bytes in memory to print them one at a time, but that's above and beyond just using %x. The easiest way to do this in Rust that I can think of is by using the byteorder crate.

If you're reading and writing numbers a lot, consider using byteorder. Otherwise, you can see how read_u8 and write_u8 are implemented.