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 BA2DA23A8E for ; Fri, 10 May 2024 16:36:25 +0200 (CEST) Received: from gaff.inri.net ([168.235.71.243]) by 9front; Fri May 10 10:33:50 -0400 2024 Received: from [127.0.0.1] ([168.235.81.125]) by gaff; Fri May 10 10:33:50 -0400 2024 Date: Fri, 10 May 2024 10:33:49 -0400 From: Stanley Lieber To: 9front@9front.org In-Reply-To: <311B1A9C352DEB4C4D8AA17ED1105F07@eigenstate.org> References: <311B1A9C352DEB4C4D8AA17ED1105F07@eigenstate.org> Message-ID: 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: decentralized scripting callback manager Subject: Re: [9front] [PATCH] rio: resize border and scrollbar based on font Reply-To: 9front@9front.org Precedence: bulk On May 10, 2024 10:21:55 AM EDT, ori@eigenstate=2Eorg wrote: >Quoth Stanley Lieber : >> On May 10, 2024 10:10:29 AM EDT, Jacob Moody wr= ote: >> >On 5/10/24 01:20, Kurt H Maier wrote: >> >> On Thu, May 09, 2024 at 07:14:06PM -0500, Jacob Moody wrote: >> >>> >> >>> we do not currently do any sort of scaling in the UI for larger dis= plays=2E >> >>> I think we should be looking at a more general solution to this pro= blem, >> >>=20 >> >> scrollbars and borders should be arguments passed to rio and then >> >> exposed in env or elsewhere >> >>=20 >> >> every other attempt at 'general solutions' to ui scaling have been >> >> miserable goddamn failures and I really really don't want to live >> >> through it again >> >>=20 >> >> khm >> > >> >Alright then where's you're code for a solution here? I don't >> >want arguments to every fucking program for scaling=2E >> > >> > >>=20 >> rio provides the borders, so every program in that rio that uses rio's = borders would inherit the same settings=2E >>=20 >> sl > >this is, unfortunately, not true, and is one of the uglier >warts in rio=2E > >Both rio and the programs agree by convention that rio will >paint into the outermost 4 pixels of the window=2E > >Programs will explicitly subtract 4 pixels from their drawing >region, which rio will later paint over=2E Unless they're running >outside of rio, in which case they will subtract off 0 pixels=2E > > i don't think this really contradicts what i said (the programs are still = tacitly relying on rio's border behavior), but yeah, this falls under that = situation where a lot of stuff kind of hodge-podge decides how much of rio'= s behavior to anticipate, and what to throw away in favor of managing its o= wn graphical business=2E sl