[pbs-devel] [PATCH proxmox-backup 0/4] remote edit: error message ideas
Thomas Lamprecht
t.lamprecht at proxmox.com
Wed Jan 27 15:39:43 CET 2021
On 27.01.21 14:57, Dominik Csapak wrote:
> On 1/27/21 11:55 AM, Dominic Jäger 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 symbolise
>> "Required". But the error message shows this problem, too. So yes, it is
>> redundant in some way.
>
> 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="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
>
> works here (with the correct attribute ;) ):
> ---
> fieldLabel: `<span data-qtip="some tooltip text">${gettext("Label")}</span>`
> ---
>
> but i noticed it's even easier to do:
>
> ---
> labelAttrTpl: 'data-qtip="Some Tooltip Text"',
> ---
>
> puts that into the attributes of the whole label
Doesn't this rather replaces the whole attributes, if any, and may thus have
some side effects (e.g., ARIA ones) depending on what the component had defined
in this template?
If that is guaranteed to be a non-issue this would be surely nicer.
More information about the pbs-devel
mailing list