From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 5D8AC21CDE for ; Fri, 10 May 2024 16:03:29 +0200 (CEST) Received: from gaff.inri.net ([168.235.71.243]) by 9front; Fri May 10 10:01:19 -0400 2024 Received: from [127.0.0.1] ([168.235.81.125]) by gaff; Fri May 10 10:01:19 -0400 2024 Date: Fri, 10 May 2024 10:01:17 -0400 From: Stanley Lieber To: 9front@9front.org In-Reply-To: <1626b2be-8b05-45cc-9266-bb7a4f6b7076@gmail.com> References: <86F1A5CD218EFDC622FF2D79D79DD44D@smtp.pobox.com> <1626b2be-8b05-45cc-9266-bb7a4f6b7076@gmail.com> Message-ID: <2D1BB646-F070-4E3F-B963-3748C82FA77C@stanleylieber.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: strategy realtime-scale app-based locator Subject: Re: [9front] [PATCH] rio: resize border and scrollbar based on font Reply-To: 9front@9front.org Precedence: bulk On May 10, 2024 9:27:50 AM EDT, Kristo wrote: >On 10=2E5=2E2024 9=2E13, Romano wrote: >> I also can't imagine trying to go through all programs to see which >> rely on a specific rio border-width=2E > >Rio was probably the first 9 program that I ever hacked on and I do recal= l >that modifying the border size did unfortunately mess up some programs=2E= If >I had to guess now I'd say it was mothra=2E A lot of code has changed sin= ce >then though, sorry I don't have a machine to test with at the moment=2E > >Kristo > mycroftiv's grio has border widths implemented as command flags=2E i remem= ber seeing some weird behavior around the edges of some programs when i use= d it to diddle those values=2E if existing programs rely on bad assumptions, it's worth adjusting them to= remove the bad assumptions=2E sometimes you just have to do this, even tho= ugh it can be a lot of tedious work=2E that's why it's also worth figuring out where the best place to cut is=2E = one of plan 9's strong suits has always been careful choices about what to = omit, with various small pieces thoughtfully interacting to maximum effect,= sometimes going too far, and sometimes not going far enough=2E the importa= nt thing is to think before cutting=2E my experience with general scaling is that it seems nice when the physical= screen geometry and the desired resolution don't result in a fuzzy mess, b= ut this doesn't happen very often=2E specifying border size alone on the co= mmand line doesn't address all the other bibs and bobs like menus and scrol= lbars (fortunately, rio isn't overly ornate)=2E and of course, many progra= ms manage their own unique scrollbars, menus, fonts, etc=2E, usually hardco= ded=2E i can't help but admire the choice of cuts in sigrid's /dev/theme=2E if gu= i programs were modified to honor this convention, they wouldn't need to be= altered again in the future=2E and a theme file seems like a good place to= get specific about border sizes, etc=2E for example, the stuff phil9 has b= een woking on (mongrel, vdir, etc=2E) already honor /dev/theme=2E alternately, maybe we need some kind of heuristic based on screen resoluti= on? this would probably not make everybody happy, either, but might get us = close enough to subjective visual consistency to call the game=2E sl