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)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 8F8EF93495 for ; Fri, 16 Sep 2022 14:21:20 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 840932422A for ; Fri, 16 Sep 2022 14:21:20 +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 ; Fri, 16 Sep 2022 14:21:19 +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 230684449B for ; Fri, 16 Sep 2022 14:13:35 +0200 (CEST) Message-ID: <90a45125-5a7d-afe3-f339-620b29ed98d7@proxmox.com> Date: Fri, 16 Sep 2022 14:13:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Content-Language: en-US To: Thomas Lamprecht , Proxmox VE development discussion References: <20220808114816.265306-1-m.heiserer@proxmox.com> <67918266-9afc-0830-8bf8-2e7399a4dc42@proxmox.com> From: Matthias Heiserer In-Reply-To: <67918266-9afc-0830-8bf8-2e7399a4dc42@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.590 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.816 Looks like a legit reply (A) POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes 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 manager] fix #2435: GUI: LXC summary: Add privileged status and os type 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: Fri, 16 Sep 2022 12:21:20 -0000 On 09.09.2022 08:20, Thomas Lamprecht wrote: > Can you please split this into two commits, first the unpriv one and then the OS type one? > > Am 08/08/2022 um 13:48 schrieb Matthias Heiserer: >> --- >> >> I'm a bit unsure about the icons, there are probably better ones, but I couldn't >> think of/find any. One alternative for OS type would be the OS logos. > > That'd be nice(r) and make it stand out more. But, while we already got the Debian > one available (currently used for the apt repo gui), you'd need to assemble the other ones > yourself, ensuring to only pull the official ones with a compatible license. > > After a quick search I found a project[0] that would seem to provide the desired logos, > we could pull out the for us relevant one and ship it in manager, or alternatively create > a full new package with all logos and CSS files exposed, wouldn't be _that_ much more work > and possible a bit cleaner. > > [0]: https://github.com/lukas-w/font-logos > Sure >> >> www/manager6/.lint-incremental | 0 >> www/manager6/panel/GuestStatusView.js | 44 +++++++++++++++++++++++++++ >> 2 files changed, 44 insertions(+) >> create mode 100644 www/manager6/.lint-incremental >> >> diff --git a/www/manager6/.lint-incremental b/www/manager6/.lint-incremental >> new file mode 100644 >> index 00000000..e69de29b >> diff --git a/www/manager6/panel/GuestStatusView.js b/www/manager6/panel/GuestStatusView.js >> index 8db1f492..96e9adea 100644 >> --- a/www/manager6/panel/GuestStatusView.js >> +++ b/www/manager6/panel/GuestStatusView.js >> @@ -11,6 +11,30 @@ Ext.define('PVE.panel.GuestStatusView', { >> }; >> }, >> >> + controller: { >> + xclass: 'Ext.app.ViewController', >> + >> + init: function(view) { >> + const nodename = view.pveSelNode.get("node"); >> + const id = view.pveSelNode.get("vmid"); >> + const me = this; >> + Proxmox.Utils.API2Request({ >> + url: `/api2/extjs/nodes/${nodename}/lxc/${id}/config`, >> + waitMsgTarget: view, > > I could swear we got the config already available somewhere in the hierarchy there, > and checking the debug console's network view I saw a config load in the summary > panel, naturally without your patch applied yet ;-), for the pmxNotes panel. > > I really want to avoid loading the same stuff in the same view multiple times. > > As we don't need the config often in the LXC panels (just Summary and Network, > otherwise we use the slightly odd /pending endpoint) I'd not add it in the > PVE.lxc.Config, but rather load it once in the pveGuestSummary > > Then you can pass it along to the notes and status panels for reuse on declaration. > To avoid forced dependency bump and browser cache issues please keep the widget > toolkits notes view's config load as fallback. Correct me if I'm wrong, but we can't pass it to Network (because different Tab), and passing to to pmxNotes would result in a circular dependency. I guess we can store it in some global object? > > >> + method: 'GET', >> + success: function(response) { > > fyi: if you only ever need to access child properties and you can be sure that they > exist (normally fine in the "success" callback) you could use some destructuring > here: > > success: ({ result }) => { ... }, > > style wise you could naturally also do: > > success: ({ result: { data: { ostype, unprivileged } } }) => { ... } > > but it increases assumptions about the return type, as you do not check for > definedness or use nullish coalescing below anyway it would stay at the same > risk level w.r.t exceptions in this case, and as said, should be fine for the > success callback (no hard feelings to either variant on my side) > In that case, I'll use the current format without destructuring, I feel like it's more readable.