From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f171.google.com ([209.85.222.171]) by ewsd; Tue Nov 24 23:14:04 -0500 2020 Received: by mail-qk1-f171.google.com with SMTP id u4so2094919qkk.10 for <9front@9front.org>; Tue, 24 Nov 2020 20:13:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=38wtwY9xVGqv69X+gc/tvnQGwvVj/bM01ZGVETXXkbo=; b=eqNnPH7E03Qa4bdbObvcl/kMWGqqwyLzm5XX5/HabCiq2VIkyA2JqKdzNl8rdQeDAB zNYldfDU1qHsTBscd23uwjkD2/I/uVTGOE5EOA/aOX2Z00lQJ6+TZCa1tKajTHds6LOD kZwRTW6n+1rJLbd/2Hn1gnWkMGRRTy1/eLsIWktl5VODsEcYutPYCdu434AhAp2cBCt1 s4p1o5QSE7lqS+rHiy+0brxbdyL09X9aSH4bOf7P7rLWtD7Vwf18C31b9ZsnTwn9p/2+ S2PiAuilTN4XA1wYD1XZY9iiIckhTVP+6ItujhontYs20ZwIlN6s+XNfo0wOMZYvCW9G +RZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=38wtwY9xVGqv69X+gc/tvnQGwvVj/bM01ZGVETXXkbo=; b=mzhFAMjvVL/P92O8N5YWuglhBAAwBaPGybaP1E2WEimXbl9q2SBpVIRHPB1/U61ip+ wV6C/q44DHkJqFYe2lJB1PTCK1RXHMsEm/yDzrJYH9dI3bL+j/4yba5rroTqNSYesJBn fEXhSY7IXU5zyJg+YcEVmkbAQkzlfDVicbaVrxwvB8TSlGFwL3tr2FKVvoBWeF6cuiQD Igbi1HbKHK8SsvjUQ4UwajNazF/fK1WgdQBQ8RbWN9GzzZDCaa91JBNLGcmlFsKwwoHt 7bJ4LGjJ4Fv8I8BAaqtXUXYYZlwCJ05BuVy9Q0n/OG6++fq4JY9cO+1iNxkSj7Oe7FYf 1Nbw== X-Gm-Message-State: AOAM530O+0jfa3OEMZjQ39G1TOUfOPTnBhlX7Dr/1EvqLiPiJhwJTe6S K/VcSR2R4/v9UHjMuv+gsQvyMnvKhsw= X-Google-Smtp-Source: ABdhPJwGGxiWneMSC7lE7qOhIP/KCbBhspmWaykTf6DZN6jFkbnT4NlqoFHeHZlUE28EOR7Abm1Y0w== X-Received: by 2002:a02:6a59:: with SMTP id m25mr1077340jaf.132.1606263697043; Tue, 24 Nov 2020 16:21:37 -0800 (PST) Return-Path: Received: from ?IPv6:2601:246:4e03:dc20:79:306a:435a:e736? ([2601:246:4e03:dc20:79:306a:435a:e736]) by smtp.gmail.com with ESMTPSA id d23sm236119ill.56.2020.11.24.16.21.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 16:21:36 -0800 (PST) Subject: Re: [9front] rio: resize flash patch To: ori@eigenstate.org, 9front@9front.org References: <288D9AF57CE80B394F1E5B40EA69B2D4@eigenstate.org> From: Amavect Message-ID: Date: Tue, 24 Nov 2020 18:21:24 -0600 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <288D9AF57CE80B394F1E5B40EA69B2D4@eigenstate.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: anonymous configuration deep-learning deep-learning-based manager On 11/24/2020 5:35 PM, ori@eigenstate.org wrote: > Thinking about this a bit more -- I *think* I'm ok with > documenting that the holder of /dev/mouse is responsible > for refreshing on resize. > > If that's not something we want to do, it should also be > possible to write a message to wctl to claim responsibility > for refreshing a window, and making that explicit. > More accurately, that if /dev/mouse is open, then rio will not refresh the window image on resize (except for the border), for the reason that /dev/mouse sends resize messages. I have thought about what the Right Thing should be. Neither mouse nor wctl should be related to the act of drawing to the screen. That's /dev/draw's responsibility. But rio's design is to not exactly stand between the program and /dev/draw, so rio can't know anything. Maybe this is one reason (among many) why I've never seen a text terminal get replaced with a gui program anywhere else... Thanks, Amavect