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.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 32C88213AA for ; Fri, 10 May 2024 21:18:23 +0200 (CEST) Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Fri May 10 15:15:46 -0400 2024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1715368534; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/3NLSiK75uNYCB0w6O9mXXwbp1r8HbGQnlcIwiZ+aag=; b=j6IxZI015OF+hJHPeyvzqAz3AFTb+Ag3YqCRKONq1a0Q0L73RX1FdGwKSsM0LWau1OiylB MgOCztmNbkX2anhEqIJwHw49tVNewlWrpJTXK9pDvus+gdflM19WBuhM3h5LDACEXmsv6D 0KsGvIs0KJM1TPX8OtLfZn60BLzPBAY= Received: from [192.168.168.200] ( [207.45.82.38]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 0bba600c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Fri, 10 May 2024 14:15:34 -0500 (CDT) Message-ID: Date: Fri, 10 May 2024 14:15:43 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: 9front@9front.org References: Content-Language: en-US From: Jacob Moody In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: virtual cache-oriented JSON over TOR core-oriented blockchain Subject: Re: [9front] [PATCH] rio: resize border and scrollbar based on font Reply-To: 9front@9front.org Precedence: bulk On 5/10/24 13:43, Romano wrote: > For whatever reason, I'm getting delayed mails from the mailing list. I > haven't investigated further. > >> I do not like merging hacks, I want to find solutions. This is only >> a problem when using the system over drawterm from a mac. > > No, it also is when I hook up my extrawide LG monitor, not via drawterm. > I gave one example. I also want to find general solutions but I don't > want to make the perfect the enemy of the good: sometimes things may not > be the best, but they do help with a large chunk of the problem. That's > probably why there are so many commits already to 9front that are self- > described hacks: they're not ideal, but they are better than before. This is not just a one time hack however, this sets a precedent. If we allow scaling patches for rio then do we also for acme and sam and mothra and every other graphical program? I don't want to make perfect the enemy of good but I also don't want to just make conventions without thinking about them properly. I don't think bad conventions in the tree create an environment that is better then before. > >> If all this discussion is going to be >> is you hamfisting this despite all these problems for it just being "well >> it kinda works not really but its a start" then we're going nowhere. > > That's not what I said: it works for me, not "it kinda works not really". > And it's not me ham-fisting (which is the first time I've seen it used as a > verb not an adjective) the patch by giving more details about how it helps > in my setup. That's not "all this discussion" is about. I think there has > been a good discussion, particularly the suggestion about using environment > variables and /dev/theme. Whether or not either of those is an approach that > would be acceptable is another matter. You are not listening to what I said, your patch does not work. I pointed out that there are assumptions about the rio border size. You *will* break programs with this. You don't just get to decide to ignore that problem and break people's shit. This is why I called what you did ham-fisting, this patch is clumsy and pushing for its inclusion after being told how clumsy it is is not how we do things here. By "all the discussion" I was referring to your previous email which basically boiled down to "yes I know there are issues but it works on my machine". You ask for review, I give it to you then you reject my review by giving anecdotal evidence and saying you can't be bothered to fix graphical programs that have assumptions about the border width. Again this is not how we do shit here. /dev/theme is not merged so you can not hang your solution off of that if you'd like it merged. Here's how I would approach this: 1. fix code assumptions about rio's border size, or use an environment variable or something. 2. Attempt a transparent scaling, perhaps something in libdraw that just stupidly does 2x upscaling of draw ops a. evaluate how much this sucks, maybe it works fine maybe it creates a shit experience idk 3. Failing that we give up and add $scale and make it every programs problem to distinguish what should be scalled (things like UI elements) vs not (fonts and images) I don't see any other appetizing option at the moment, perhaps someone else does.