From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <t.lamprecht@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) server-digest SHA256)
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id 0D9896BBBD
 for <pbs-devel@lists.proxmox.com>; 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 <pbs-devel@lists.proxmox.com>; 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 <pbs-devel@lists.proxmox.com>; 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 <pbs-devel@lists.proxmox.com>; Wed, 27 Jan 2021 15:39:44 +0100 (CET)
To: Proxmox Backup Server development discussion
 <pbs-devel@lists.proxmox.com>, Dominik Csapak <d.csapak@proxmox.com>,
 =?UTF-8?Q?Dominic_J=c3=a4ger?= <d.jaeger@proxmox.com>
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 <t.lamprecht@proxmox.com>
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
 <pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, 
 <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, 
 <mailto:pbs-devel-request@lists.proxmox.com?subject=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: `<div qtip=3D"sometext">${gettext('labeltext')}</div>'
>>> ---
>> 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: `<span data-qtip=3D"some tooltip text">${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.