From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 3F6EE385841D for ; Mon, 7 Mar 2022 22:07:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3F6EE385841D Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-591-Czv1IDWXPU2qFSGqRmN8TQ-1; Mon, 07 Mar 2022 17:07:05 -0500 X-MC-Unique: Czv1IDWXPU2qFSGqRmN8TQ-1 Received: by mail-wm1-f70.google.com with SMTP id v125-20020a1cac83000000b0037e3d70e7e1so225929wme.1 for ; Mon, 07 Mar 2022 14:07:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=xhCuPUQMtHNQeywe5hBfsD6xx67eb5omt229brfJJ+Q=; b=cK8z+FPMWTy+5EhvgfghkYo/zFQG/VJAHnvVeyoFIxctRnovzHYkA+Ia16El4jpNOL K7Po1ynfxHgiRyw1aGTruSqk/MRthfaMa8uFwkKaWz9Ty6FMWwrIfW68PTqzgF8nv/tr kvTIA2tTaUGTdnuldYnIf7ldplCV8X7exKYdq9HZJkZV6uupuxIcO1NRGjbqzQe3SehE uQb6x9ptarZYyFuM+Rqw3fWswlnIlgu/n09kX16EafMjoL9BX6nUXlpDsfs2CP6jqWmy HtV8ZVuTb9+X04jx5rdDyPoTxOdbzBjHMmMUxfCgkFwXv7vJY30LicllaDRvjv+tdBN/ yaFw== X-Gm-Message-State: AOAM531+Hu5p3xKoPCiAh/fAbk8jYSSEKi591DykOBytWJEsa6SzAv5U tzqTxChhiNDzhWLHrXexgUmg8Bb1VfnkRGfZBqVYzam4isGdxKQhE+ZsCbPhSAlDAjuRqUlUKeQ 49Q0Hc2DzqTbM9N/tXVE5WQ== X-Received: by 2002:a05:600c:4ec7:b0:389:bf36:ce3a with SMTP id g7-20020a05600c4ec700b00389bf36ce3amr876441wmq.118.1646690824599; Mon, 07 Mar 2022 14:07:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJy1NUTRIIzHnI83TC8155X3GhK1+NGzHtRvs/9a6e1TPKTX6Tr6ThgOh1TR2X+ClMS5Gyvclw== X-Received: by 2002:a05:600c:4ec7:b0:389:bf36:ce3a with SMTP id g7-20020a05600c4ec700b00389bf36ce3amr876430wmq.118.1646690824401; Mon, 07 Mar 2022 14:07:04 -0800 (PST) Received: from localhost (host86-134-151-205.range86-134.btcentralplus.com. [86.134.151.205]) by smtp.gmail.com with ESMTPSA id o7-20020a5d6707000000b001f067c7b47fsm17551407wru.27.2022.03.07.14.07.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Mar 2022 14:07:03 -0800 (PST) From: Andrew Burgess To: Tom Tromey , Andrew Burgess via Gdb-patches Subject: Re: [PATCHv2 15/15] gdb/tui: fair split of delta after a resize In-Reply-To: <87ee3hskd4.fsf@tromey.com> References: <87ee3hskd4.fsf@tromey.com> Date: Mon, 07 Mar 2022 22:07:02 +0000 Message-ID: <87fsntwh6h.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 22:07:08 -0000 Tom Tromey writes: >>>>>> "Andrew" == Andrew Burgess via Gdb-patches writes: > > Andrew> Currently, in master gdb, when a tui window is changed in size, the > Andrew> screen delta is mostly just added to the next available window. We > Andrew> do take care to respect the min/max size, but in most cases, these > Andrew> limits are just "the terminal size", and so, we end up placing the > Andrew> whole delta on the next window. > > This seems like a change that corresponds to the same change in the > patch to change how layouts are applied. That is, the resize-one-window > code and the layout-from-scratch code ought to agree algorithmically. > So maybe this should have been merged into that one -- though I'm not > really too picky about that kind of thing. Originally, I did try to do this, but in the end I decided not too as the amount of change seemed much bigger than needed. The problem is that we end up needing to add a mechanism to "lock" a window size - we have a layout with windows A, B, and C. The user sets the size of window B. With the code in my patch we set the size of B as the user requested, and then resize A and C around B. If we try to use apply, then, after changing the size of B, we need some way to tell ::apply that it must not change the size of B again. This is totally doable, at one point I had a version of this patch that did just this, but it was a big code change. I'd much rather push this smaller change, which allows me to get additional tests into place, then, if we want, we can try to refactor things later, and merge the two code paths together. Would this be OK? Thanks, Andrew