@mcc I'm told that app installation via adb will remain as is (no need for accounts, identification, payment, sharing any credentials / certificates with Google, etc). Obviously you need a second device for that so more involved, but apparently they're not completely killing "unapproved" app installation just yet.
Why in the world they failed to mention this in the announcement, I cannot imagine. I mean sure people would still be pissed, but maybe just a little less pissed?
@whitequark It suffers a little from "enormous raft of options for everything", but I'll take that rather than having no control over stuff I care about.
Also, something that I didn't realize initially -- on almost every setting that applies to the current book, if you long-press you can save it as the default setting.
@whitequark I use mine primarily for epub stuff (novels, etc), migrated from Kindle after Amazon disabled any ability to download your own purchases (DRM or not), so I haven't dug into PDF reading much. I've got a Pixel Tablet that I use for larger, color, or more random-access-desirable content (comics, manga, databooks, etc)
@whitequark If you're feeling adventurous, KOReader is installable on Kobo devices without too much convoluted nonsense and addresses some annoyances in their standard reader software (in particular having one global font size setting that I tend to have to change every time I open a different book drives me nuts): https://koreader.rocks/
@jacqueline Been there. Maybe someday I'll learn to always double-check the exact package when ordering. Less awkward than it being the other way 'round at least...
@r@miyuko@whitequark Yeah it's definitely a pain. I think if you're writing a modern terminal emulator you aim for somewhere between "xterm" and "xterm + the fancy stuff that newer gui terminals have added" and then spend a ton of time chasing down random stuff that doesn't work when you trip over it.
For #2, I think you can probably go a long way with either just line editing or clear-screen-and-repaint, but in either case getting actually width/height information is unlikely-to-impossible.
@miyuko@r@whitequark I think if your goal is for modern systems to work with your stuff, targeting the minimal vt100/xterm features needed is generally sufficient. The full baggage of ncurses/terminfo/termcap/etc is of questionable value.
Even more so if your expected terminal is local-only or modern-network-only. Strategies from the 70s to try to absolutely minimize the data sent to the terminal that made a lot of sense for 150-9600bps serial are much less relevant now.
@miyuko@r@whitequark To pop the stack a bit on this conversation, I do wonder if when running something in some kind of wasm container inside a browser, where you'd be bundling both the client and the terminal, if maybe a more direct approach -- say the client rendering into a local VGA-style character mapped framebuffer that'd be rendered more directly by the browser -- would be worth exploring. Or if jettisoning all the 70's technology is more trouble than it's worth.
@whitequark@ireneista@r@miyuko I definitely understand that threat models vary. Mine generally leans a lot more toward usability in these contexts. If it's so private/secure as to be effectively unusable that tends to defeat the purpose at least for me.
@ireneista@r@miyuko@whitequark Makes sense. Unfortunate that a number of such queries are pretty important for functional UX. That fun tension between privacy/security/usability.
The Zachtronics folks are back (under their new Coincidence Games imprint) with Kaizen: A Factory Story, so here I am building assembly lines for plastic food in 80's Japan. Whee!
@whitequark Thank you for listening to my talk, "I2C, we hates it, we hates it, we hates it forever."
But if you really like suffering, do consider operating your I2C bus at different voltages on different segments, with level shifters that have independent power control.
@whitequark Thinking further, I feel like the best advice for using I2C in designs is: (a) don't (b) if you must, limit it to exactly two devices per bus (c) you probably should ensure you can reset or power cycle the target though, just in case (d) in the event of b and c you now have a solid 40% chance of things mostly working (e) or you might get something like that QCT I2C controller that sometimes wedges on transfers of lengths it dislikes and remains that way until SoC reset...
@whitequark <trauma type="i2c"> Not familiar with the feature, but probably mostly because I avoid I2C like the plague, because I've never encountered an I2C bus without a cursed device on it (usually they're *all* cursed, usually in different ways). </trauma>
Share your cool vim tricks! I'm interested in learning more about cool core functionality that I'm probably missing out on (as opposed to elaborate scripting or plugin customization stuff).
Writes the codes. Recovering OS Engineer (BeOS, HiptopOS, Android, LK, Fuchsia). Embedded systems hacker. Hobbyist Digital Designer. Player of video games. Etc.