From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id C89411FF13B for ; Wed, 06 May 2026 11:55:24 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A72531BCFD; Wed, 6 May 2026 11:55:24 +0200 (CEST) Message-ID: <824a0c3b-3784-4d6b-bb89-a64332106cb8@proxmox.com> Date: Wed, 6 May 2026 11:55:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [RFC yew-comp/yew-widget-toolkit/yew-widget-toolkit-assets 0/3] minor ui/ux tweaks for pwt and yew-comp To: Shannon Sterz , yew-devel@lists.proxmox.com References: <20260504143911.288747-1-s.sterz@proxmox.com> <3f821349-1126-43e9-9a3c-0eecb8e02ffb@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1778061209904 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.050 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [align.rs,syslog.rs,dropdown.rs] Message-ID-Hash: KKLWKKISXLKKT5P6Y4524FZTWK5Z6WMP X-Message-ID-Hash: KKLWKKISXLKKT5P6Y4524FZTWK5Z6WMP X-MailFrom: d.csapak@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Yew framework devel list at Proxmox List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 5/6/26 11:41 AM, Shannon Sterz wrote: > On Wed May 6, 2026 at 9:53 AM CEST, Dominik Csapak wrote: >> >> >> On 5/4/26 4:38 PM, Shannon Sterz wrote: >>> this series includes two minor tweaks that should improve the usability and >>> user experience of some yew components. >>> >>> dropdowns should now render their pickers below or above the component >>> depending on the size of the picker and available screen space. a dropup mode >>> improves usability for filter fields when the picker is rendered above the >>> dropdown. >>> >>> the log view in the syslog and task log components was slightly tweaked to avoid >>> interference between scrollbars and drag handles. >> >> this looks fine to me >> >>> >>> mainly sending this as rfc for now to get feedback on how the dropdown/dropup >>> is handled here. >>> >> >> i thought a bit about this, and since the picker in the dropdown is >> relatively generic, i think it's dangerous to simply reverse >> the flex direction. >> >> we have no idea what the user of a dropdown renders, and if it's >> e.g. simply sorted list of flex items, that order would be reversed >> when it would be displayed above? >> >> imho what we could do is to expose the position (if possible) to the >> DropdownController, and the picker renderer can react to that change >> (by e.g. putting the filter on the bottom manually) >> >> wdyt? > > yep sounds good. i'd keep using a reverse column instead of changing the > markup itself tho. for two reasons: > > - it makes more semantic sense to me for the filter input field to still > be the first one in the picker (this also mean the tab order is > "correct"). > - scrolling behavior is better, browsers will scroll the picker to its > bottom by default. > > we could correct these manually too ofc, but i don't really see the > upside here. i will drop the first patch of this series and implement > this behavior in the `GridPicker` component, though. > yes, how the picker decides what to render first is not really important, so if we can reverse the flex order there it's fine i'd only want to avoid that we reverse the flex order when we don't have any information or control over what is actually rendered >>> pwt-assets: >>> >>> Shannon Sterz (1): >>> dropdown: add class for dropup mode >>> >>> scss/_dropdown.scss | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> >>> pwt: >>> >>> Shannon Sterz (1): >>> dropdown/align: make the picker render above or below a dropdown >>> >>> src/dom/align.rs | 6 +++- >>> src/widget/dropdown.rs | 62 +++++++++++++++++++++++++++++++++++------- >>> 2 files changed, 57 insertions(+), 11 deletions(-) >>> >>> >>> yew-comp: >>> >>> Shannon Sterz (1): >>> task_viewer/syslog: make padding margin to improve ux >>> >>> src/syslog.rs | 2 +- >>> src/task_viewer.rs | 2 +- >>> 2 files changed, 2 insertions(+), 2 deletions(-) >>> >>> >>> Summary over all repositories: >>> 5 files changed, 63 insertions(+), 13 deletions(-) >>> >