From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 0D9896BBBD for ; Wed, 27 Jan 2021 15:39:45 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 034BD240D0 for ; Wed, 27 Jan 2021 15:39:45 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 7B35C240C6 for ; Wed, 27 Jan 2021 15:39:44 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 4C3564612A for ; Wed, 27 Jan 2021 15:39:44 +0100 (CET) To: Proxmox Backup Server development discussion , Dominik Csapak , =?UTF-8?Q?Dominic_J=c3=a4ger?= References: <20210119110915.18864-1-d.jaeger@proxmox.com> <31f19138-bb58-1854-35f9-ef3023bb2c74@proxmox.com> <20210127105545.GA8912@mala> <5c9d20b0-69ae-d181-3511-08878d899ff4@proxmox.com> From: Thomas Lamprecht Message-ID: <5ad33d3d-3d03-b228-025e-338373138d42@proxmox.com> Date: Wed, 27 Jan 2021 15:39:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101 Thunderbird/85.0 MIME-Version: 1.0 In-Reply-To: <5c9d20b0-69ae-d181-3511-08878d899ff4@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.064 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox-backup 0/4] remote edit: error message ideas X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 14:39:45 -0000 On 27.01.21 14:57, Dominik Csapak wrote: > On 1/27/21 11:55 AM, Dominic J=C3=A4ger wrote: >> Thanks for looking at it! >> >> On Tue, Jan 26, 2021 at 11:34:54AM +0100, Dominik Csapak wrote: >>> when we have the error icon, we'd not need the asterisk, >>> since they both show the error >> We could theoretically show the asterisk without any color, just to sy= mbolise >> "Required". But the error message shows this problem, too. So yes, it = is >> redundant in some way. >=20 > ok FWIW: one of my initial ideas which resulted Dominic to look into this was separation of the field required and the other field invalid states (out of range, not matching a regex, to long/short, ...). The rational consisted at least of (may have forgotten something, it was quite a bit ago): * By default conflicts with other tooltips. Yes, other invalid tooltips do so too, but they require input which normally happens after initial evaluation of the fields and their meaning by the user * less red and invalidity when opening a fresh inputpanel/editwindow while still keeping a visual hint about required fields * it's also a well established pattern and very common in user-interface,= thus not new for users. (just FYI) >>> >>> --- >>> fieldLabel: `
${gettext('labeltext')}
' >>> --- >> I could not get this to work yet and I am not sure if it is possible? >> The "Remote" field has xtype pmxDisplayEditField >=20 > works here (with the correct attribute ;) ): > --- > fieldLabel: `${gettext("Label")}<= /span>` > --- >=20 > but i noticed it's even easier to do: >=20 > --- > labelAttrTpl: 'data-qtip=3D"Some Tooltip Text"', > --- >=20 > puts that into the attributes of the whole label Doesn't this rather replaces the whole attributes, if any, and may thus h= ave some side effects (e.g., ARIA ones) depending on what the component had d= efined in this template? If that is guaranteed to be a non-issue this would be surely nicer.