feature: prioritize active dropdown boxes if they are in the same Z-Index #49

New Issue

2023-03-25T09:06:04+08:00

luiz00martins commented

2023-03-25 09:06:04 +08:00

(Migrated from github.com)

Problem

Currently, if you have multiple dropdowns in a frame, they are prioritized in the order they were added (last in the top).

This means that if you are adding a bunch of dropdowns in a column (perhaps using a for loop), the dropdown box of the ones above will be overshadowed by the label of the ones below.

Minimal Working Example

-- Basalt configurated installer
local filePath = "/basalt.lua" --here you can change the file path default: basalt
if not(fs.exists(filePath))then
	shell.run("pastebin run ESs1mg7P packed true "..filePath:gsub(".lua", "")) -- this is an alternative to the wget command
end
local basalt = require(filePath:gsub(".lua", ""))

local main = basalt.createFrame("mainFrame")

for i = 1, 3 do
	local fg_color, bg_color
	if i % 2 == 0 then
		fg_color = colors.black
		bg_color = colors.white
	else
		fg_color = colors.white
		bg_color = colors.black
	end

	main:addDropdown('dropdown_'..i)
		:setPosition(20, 6 + (2*i))
		:setSize(10, 1)
		:addItem('Option 1')
		:addItem('Option 2')
		:addItem('Option 3')
		:addItem('Option 4')
		:addItem('Option 5')
		:setForeground(fg_color)
		:setBackground(bg_color)
		:selectItem(1)
end

basalt.autoUpdate()

https://user-images.githubusercontent.com/43142209/227669717-fc23b552-ae45-4d98-8b0a-8e42034d91be.mp4

Desired Solution

For me, a reasonable solution would be to prioritize rendering the dropdown box over the dropdown label whenever they are in the same index.

Alternative Solutions

From basalt's part:

Reverse the priority order (i.e. make later added items less prioritized).
- I wouldn't like this solution, as I would expect items added later to be rendered above items added beforehand, including dropdowns.
Prioritize rendering active dropdowns.
- I wouldn't like this solution, as I wouldn't expect a dropdown to be "brought to the front" just because it was clicked. For example, in the setup below, the dropdown stays behind after being clicked. That's the behaviour I would expect, and the dropdown getting "popped" up would be weird in that scenario.

https://user-images.githubusercontent.com/43142209/227669644-4c612f34-b3b1-4a53-99d6-c884d3547e3a.mp4

From my part:

Reversing the for loop. (i.e. for i = 3, 1, -1 do)
Manually setting the index. (i.e. :setZIndex(3 - i))
Both of these workarounds resolve the issue.

https://user-images.githubusercontent.com/43142209/227668535-5e518eb1-c6ca-4df7-9d9f-5cf6132fb1e2.mp4

Additional context

Although the workarounds (from my part) are quite simple, I think it's reasonable for a developer using the API to assume the dropdowns boxes (on the same level) would be prioritized over labels.

As an example, in the Windows API for GUI, it's true (and expected) that if you add a couple of dropdowns in a column one after another, when you click on the first dropdown, its box won't be overshadowed by the dropdowns below it. I think it's reasonable to assume the same behaviour in basalt.

Edit: I now realize this is probably a bug report, not a feature request... oh well ¯\_(ツ)_/¯

### Problem Currently, if you have multiple dropdowns in a frame, they are prioritized in the order they were added (last in the top). This means that if you are adding a bunch of dropdowns in a column (perhaps using a `for` loop), the dropdown box of the ones above will be overshadowed by the label of the ones below. ### Minimal Working Example ```lua -- Basalt configurated installer local filePath = "/basalt.lua" --here you can change the file path default: basalt if not(fs.exists(filePath))then shell.run("pastebin run ESs1mg7P packed true "..filePath:gsub(".lua", "")) -- this is an alternative to the wget command end local basalt = require(filePath:gsub(".lua", "")) local main = basalt.createFrame("mainFrame") for i = 1, 3 do local fg_color, bg_color if i % 2 == 0 then fg_color = colors.black bg_color = colors.white else fg_color = colors.white bg_color = colors.black end main:addDropdown('dropdown_'..i) :setPosition(20, 6 + (2*i)) :setSize(10, 1) :addItem('Option 1') :addItem('Option 2') :addItem('Option 3') :addItem('Option 4') :addItem('Option 5') :setForeground(fg_color) :setBackground(bg_color) :selectItem(1) end basalt.autoUpdate() ``` https://user-images.githubusercontent.com/43142209/227669717-fc23b552-ae45-4d98-8b0a-8e42034d91be.mp4 ### Desired Solution For me, a reasonable solution would be to prioritize rendering the dropdown box over the dropdown label whenever they are in the same index. ### Alternative Solutions #### From basalt's part: - Reverse the priority order (i.e. make later added items less prioritized). - I wouldn't like this solution, as I _would_ expect items added later to be rendered above items added beforehand, including dropdowns. - Prioritize rendering active dropdowns. - I wouldn't like this solution, as I wouldn't expect a dropdown to be "brought to the front" just because it was clicked. For example, in the setup below, the dropdown stays behind after being clicked. That's the behaviour I would expect, and the dropdown getting "popped" up would be weird in that scenario. https://user-images.githubusercontent.com/43142209/227669644-4c612f34-b3b1-4a53-99d6-c884d3547e3a.mp4 #### From my part: - Reversing the `for` loop. (i.e. `for i = 3, 1, -1 do`) - Manually setting the index. (i.e. `:setZIndex(3 - i)`) Both of these workarounds resolve the issue. https://user-images.githubusercontent.com/43142209/227668535-5e518eb1-c6ca-4df7-9d9f-5cf6132fb1e2.mp4 ### Additional context Although the workarounds (from my part) are quite simple, I think it's reasonable for a developer using the API to assume the dropdowns boxes (on the same level) would be prioritized over labels. As an example, in the Windows API for GUI, it's true (and expected) that if you add a couple of dropdowns in a column one after another, when you click on the first dropdown, its box won't be overshadowed by the dropdowns below it. I think it's reasonable to assume the same behaviour in basalt. --- _Edit: I now realize this is probably a bug report, not a feature request... oh well ¯\\\_(ツ)\_/¯_

NoryiE commented

2023-03-25 19:26:23 +08:00

(Migrated from github.com)

Hello, thank you - this is a very good idea and i will try to implement it! But i will need a couple of days, especially because currently is a interesting beta to test! :P

👍 1 🚀 1

Damianu commented

2023-05-08 04:58:39 +08:00

(Migrated from github.com)

It's working now.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GitHub/Basalt#49