I really like this asset, I use on my personal projects and it’s pretty well made.
The only thing that I found kind of sad is that the syntax for Signals and things like that, could’ve been in PascalCase, just like Roblox events, so everyone’s code has similar syntax everywhere, and so that this, is consistent with Roblox naming and everything.
That is personal preference of course, and it’s not like this will change, not on this version, there’s no reason to, and would be worse, but if there was ever a v3 in the future, I feel like that could be something that could change if the team agrees on it.
For Instance, look at the difference here:
local function ToggleMenu()
--\\ Pretend this handles menus with TweenService
end
--// camelCase:
Icon.new()
:setCaption("Settings")
:setLabel(123)
:setOrder(2)
.toggled:Connect(ToggleMenu)
--// PascalCase:
Icon.new()
:SetCaption("Settings")
:SetLabel(123)
:SetOrder(2)
.Toggled:Connect(ToggleMenu)
Other than that, I think something that could help me move away from :bindToggleItem to .toggled and mess with menus with TweenService, would be that .toggled is fired with (isToggled, icon) instead of (isToggled) only. That’s a change that wouldn’t break any code I believe. Correct me if I’m wrong though.
So you can have one function to handle all menus using less memory. I would love that!
Having a consistent formatting makes working with other open source modules/dependencies easier for everyone involved, hence most use camelCase. One notable project which doesn’t is AeroGameFramework, although this has created extra work for Sleitnick as it’s required him to convert modules like Evaera’s Promisie and various Nevemore modules (all camelCase) into PascalCase.
You’re welcome to create a fork which converts them into PascalCase although this won’t be something we maintain.
The toggled event only passes through a single argument, could you clarify what you mean by this?
By this I mean, that you would pass through self.isSelected, self instead of just self.isSelected.
That would mean I wouldn’t have to create a bunch of “intermediate” functions.
--\\ Here, .toggled fires with (isToggled)
local function SmoothToggleMenu(isToggled, icon)
--\\ Pretend this uses TweenService to close and open menus.
end
local icon = Icon.new()
:setCaption("Settings")
:setLabel(123)
:setOrder(1)
icon.toggled:Connect(function(isToggled)
SmoothToggleMenu(isToggled, icon)
--\\ Need to construct and connect a new function for every icon.
end)
And instead, I can just do this:
--\\ Here, .toggled fires with (isToggled, icon)
local function SmoothToggleMenu(isToggled, icon)
--\\ Pretend this uses TweenService to close and open menus.
end
Icon.new()
:setCaption("Settings")
:setLabel(123)
:setOrder(1)
.toggled:Connect(SmoothToggleMenu)
--\\ No need for constructing a new small function for every icon.
I suppose the memory use for just creating a function which calls another function with some extra arguments isn’t that big, but it’s also a question of syntax, I don’t need to set the icon to a variable, to THEN connect it.
That would make that way better organized and easier to handle.
local function SmoothToggleMenu(icon, isToggled)
--\\ Pretend this uses TweenService to close and open menus.
end
Icon.new()
:setCaption("Settings")
:setLabel(123)
:setOrder(1)
:bindEvent("toggled", SmoothToggleMenu)
It looks like you’re referencing UI objects which get destroyed because your GUIs have ResetOnSpawn set to false.
Two solutions:
1.Set ‘ResetOnSpawn’ to false for the GUIs you use with your icons
2. Move the localscript within the GUI and paste the following at the bottom:
local icons = IconController.getIcons()
for _, icon in pairs(icons) do
IconController.clearIconOnSpawn(icon)
end
Topbar suffers a spammy-overextension in the example place. Appears to be a confoundance between the tween and overflow behavior.
I assume this is to say mouse detection is directly dictated by actual UI dimensions?
For instance, if you put your mouse right below a button that raises on mouseover, it would spam up and down, like a certain rust website I visited.
I thus make a feature request for underlying static boxes; have the flashy transition be only aesthetic in feed. (perhaps an argument, as I do understand a menu opening in size may want said growth of mouse interest while growing for cases like nested ribbon option lists)
Hi
I have an icon with a dropdown list. I noticed the state of icons in the dropdown gets removed when a new icon (outside the list) is clicked.
In other words: the icon under the dropdown that was selected is suddenly deselected.
That doesn’t work however, since I want to have that enabled for other icons…
To explain my use-case better:
I want to make an icon that displays what song is currently playing, and have a button to mute the music:
When clicked, the “Mute music” icon must remain enabled. It should only disable when clicked again. I don’t want this icon to be influenced by other icons, while still having only one “open” at a time.
Also one bug I noticed with resizeInfo's tween (on label add/remove) is that the tween jumps back and forth when using it on an icon that has :setRight().
This doesn’t seem to be a bug. Whenever you disable and re-enabled the script, it will run like it hasn’t started and will recreate the icons. If disabling and re-enabling the script is necessary, you can use IconController.getIcon(IconName) and see if the icon exists before creating a new one.
Expanding upon what Haydz6 said, this isn’t a bug, icons are only designed to be constructed once per client. We do however provide support for icons which reset on spawn, you can find the solution here:
