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 3D8E922304 for ; Fri, 10 May 2024 16:38:57 +0200 (CEST) Received: from gaff.inri.net ([168.235.71.243]) by 9front; Fri May 10 10:37:30 -0400 2024 Received: from [127.0.0.1] ([168.235.81.125]) by gaff; Fri May 10 10:37:30 -0400 2024 Date: Fri, 10 May 2024 10:37:29 -0400 From: Stanley Lieber To: 9front@9front.org In-Reply-To: References: <311B1A9C352DEB4C4D8AA17ED1105F07@eigenstate.org> Message-ID: <8E455CAF-5BC0-4E0E-9104-C4B3094A081A@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: stateless factory SSL over AJAX dependency service-aware solution Subject: Re: [9front] [PATCH] rio: resize border and scrollbar based on font Reply-To: 9front@9front.org Precedence: bulk On May 10, 2024 10:33:49 AM EDT, Stanley Lieber wr= ote: >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 w= rote: >>> >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 di= splays=2E >>> >>> I think we should be looking at a more general solution to this pr= oblem, >>> >>=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 = own graphical business=2E > >sl > haha, wait, i see what you mean=2E four pixels is four pixels=2E=20 sl