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 5276199B95 for ; Wed, 11 Oct 2023 11:54:54 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3C4CB6E59 for ; Wed, 11 Oct 2023 11:54:54 +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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Wed, 11 Oct 2023 11:54:53 +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 EF6DC449DC for ; Wed, 11 Oct 2023 11:54:52 +0200 (CEST) Message-ID: <841632e7-f011-9bb9-f29f-60761e02699d@proxmox.com> Date: Wed, 11 Oct 2023 11:54:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Content-Language: en-US To: Thomas Lamprecht , Christoph Heiss Cc: Proxmox VE development discussion References: <20230804102646.34999-1-f.schauer@proxmox.com> <20230804102646.34999-2-f.schauer@proxmox.com> <2730c950-b0d7-45dc-af83-80ff808da9b7@proxmox.com> <4e4c00c7-5412-4bec-9952-8497f609b71d@proxmox.com> From: Filip Schauer In-Reply-To: <4e4c00c7-5412-4bec-9952-8497f609b71d@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.591 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -3.339 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 installer 1/1] fix #4869: Show state in management interface ComboBox X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2023 09:54:54 -0000 The green circle is not displayed correctly by the PVE installer as it does not have the corresponding emoji font package. However, the suggested circles for DOWN are rendered correctly. Alternatively we could use an arrow pointing either ⬆ (UP) or ⬇ (DOWN). https://unicode-explorer.com/c/2B06 https://unicode-explorer.com/c/2B07 These arrows are also displayed correctly by the PVE installer. On 10/10/2023 15:13, Thomas Lamprecht wrote: > Am 10/10/2023 um 14:56 schrieb Christoph Heiss: >> On Tue, Oct 10, 2023 at 01:55:43PM +0200, Thomas Lamprecht wrote: >>> UP -> 🟢 https://unicode-explorer.com/c/1F7E2 >> A green circle would be problematic/non-optimal for people deuteranopia >> (red-green color blindness). So maybe some other character/symbol >> distinctly recognizable as "being connected, up" - but purely >> color-coding things is not something that should be done IMO. > but those already get filled/not-filled as hint, i.e., this isn't just > purely color coding, that's why I explicitly used a *filled* green circle > for UP and for DOWN an *empty* one as preferred one due to vision > impairments like color blindness, like hinted ;-) > > But sure, if you have a better idea for this just say so. > IMO the proposed one should be clear enough, as not only color (useful > for the majority of people) but also form is distinct, and I saw such > circles being used to indicate on/off or plugged/unplugged already in > a few UIs (such things are not easy to search for, so sorry, no concrete > example), but that doesn't mean there might be something better that is > still practical for both TUI and GUI. > >>> DOWN -> ◯ (preferred, easier to differ for vision impaired people) or ⬤ >>> https://unicode-explorer.com/c/25EF or https://unicode-explorer.com/c/2B24 >> Do we really need to explicitly mark non-UP interfaces? I'd think the >> fact of it being not marked UP should provide enough context in this >> situation. > Yes, to give clear distinction to the UP state and make them more > distinct to each other, also to avoid text-alignment (visual symmetry) > problems (if the symbol prefixes the iface name, which I guesstimate > will look better).