From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <m.heiserer@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id DD650AF39
 for <pve-devel@lists.proxmox.com>; Thu, 28 Apr 2022 11:57:07 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id D34FB2F8EC
 for <pve-devel@lists.proxmox.com>; Thu, 28 Apr 2022 11:57:07 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [94.136.29.106])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS id 5F0232F8E1
 for <pve-devel@lists.proxmox.com>; Thu, 28 Apr 2022 11:57:07 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 28E2942F47
 for <pve-devel@lists.proxmox.com>; Thu, 28 Apr 2022 11:57:07 +0200 (CEST)
Message-ID: <028e1f50-21f9-c3c2-b9f7-d288672d4582@proxmox.com>
Date: Thu, 28 Apr 2022 11:57:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
From: Matthias Heiserer <m.heiserer@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
 Proxmox VE development discussion <pve-devel@lists.proxmox.com>
References: <20220316113418.748393-1-m.heiserer@proxmox.com>
 <6b2df114-d719-4b6e-4668-9768c642d1ad@proxmox.com>
Content-Language: en-US
In-Reply-To: <6b2df114-d719-4b6e-4668-9768c642d1ad@proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.820 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 NICE_REPLY_A           -1.857 Looks like a legit reply (A)
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: Re: [pve-devel] [PATCH widget-toolkit V2] ComboGrid: fix sorting
 when filtering
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2022 09:57:07 -0000

On 27.04.2022 12:01, Thomas Lamprecht wrote:
> nit, ant I don't want to be annoying, but can you please add a empty line
> below, and maybe even above the series-change log for easier visibility?
> I'd at least appreciate that quite a bit, thx!
> 
Sure!
>>   src/form/ComboGrid.js | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/src/form/ComboGrid.js b/src/form/ComboGrid.js
>> index 33c1d75..fa1078d 100644
>> --- a/src/form/ComboGrid.js
>> +++ b/src/form/ComboGrid.js
>> @@ -12,6 +12,9 @@ Ext.define('Proxmox.form.ComboGrid', {
>>   
>>       // this value is used as default value after load()
>>       preferredValue: undefined,
>> +    clearFilterOnBlur: false,
> 
> this changes the default of an ExtJS config that is used in other context though?
>
I think the idea was that the current behaviour (clearing filter when 
sorting) is undesirable in all grids and as default, but can be 
overridden. Meanwhile, the collapse listener covers the cases where 
clearing the filter is desired and already happens.

Depending on which you prefer, I'll send in a v2 with a/this short 
explanation included, otherwise I guess the best thing would be a custom 
child class for this functionality and use that in all the places where 
it definitely makes sense?