Allow mouse events to pass to GUI elements under the disabled topbar

Continuing the discussion from Hidable Topbar!:

The decision to intentionally make the topbar annoying to work with is an insult to the feature. The topbar is an amazing idea, and I am thoroughly disappointed to see it intentionally made annoying, regardless of the reason. The topbar should be something both developers with custom UI and developers using the default ROBLOX UI can look at with satisfaction, and currently that’s only the case with the latter. While I am overcome with joy about being able to disable the topbar, transitioning it from being something that needs to be worked around to an augment which can be switched out when the situation is approprate, intentionally blocking mouse events to buttons under the topbar when it is disabled is absolutely ludicrous.

We can create our own mouse events with UserInputService to enable feedback to reach GUI elements under the topbar. The only thing forcibly intercepting mouse feedback to GUI elements under the disabled topbar accomplishes is making the process of using previously topbar-occupied space more laborious. You already have to disable all other CoreGui elements to be able to disable the topbar – there’s no need to make the process even more lengthy to prevent people from disabling the topbar just `cuz. Please do the feature the justice it deserves and make it a professional-grade tool instead of something that results in having to hackily remake bits and pieces of ROBLOX from scratch.

23 Likes

To tell you the truth and not to offend anyone but I think they just made a simple function to make the topbar go transparent and completely forgot about making it so you can add buttons and stuff were the old topbar used to be.

It was intentional. I think the reason is so that the top bar can not be replicated by developers so that users are always able to trust the CoreUI.

1 Like

What do you mean by “trust the CoreUI” its not like you can click a button on roblox and download a virus on to your computer.

Disable TopBar, place similar object there and use UIS to make pretend backpack button. How does this make me trust it?

I meant that phishing with a custom topbar might be a concern but I don’t think it is the primary reason for this decision. As you have said UIS can be used to create the exact same effect as GuiButtons anyway. I’m sure a lot of different aspects were considered that I haven’t thought of.

ROBLOX make good thing.

Developer make bad thing.

Developer pretend bad thing is ROBLOX thing.

Player think ROBLOX make bad thing.

Sometimes though:
Roblox make bad thing.
Developer is hindered by bad thing
Players hate developer
Developer is a hobo.

Sometimes, rarely intentional.

Point of the matter is that, whatever the reason, it’s not a solid solution because in every case that reason can be bypassed with UIS. The topbar shouldn’t be made annoying to work with because of something so weak.

How has the TopBar hindered you personally?

ಠ_ಠ
Move upper constraint of topbar transparency to 1 (> 60 thank yous on Kunena)
Search results for 'topbar' - Developer Forum | Roblox

We’re able to disable the topbar. It’s obvious enough that there is an overwhelming amount of legitimate desire to disable it or that wouldn’t have happened. It’s already been decided that it needs to be able to be turned off, and we don’t need you coming in here trying to resurrect a discussion of whether a past strife was legitimate or not – do your due diligence and use the search.

1 Like

Can’t make a true Fallout UI because of:
1.) Ugleh black bar (it’s not really that ugly, just kills the fallout feels)
2.) Nomnomnomy hamburger. (But if I removed that then how will my mouselocked players exit the game!?!!??!)

Other then that, it broke my silent admin command GUI for a month because the topbar didn’t offset the ui at the time.

I don’t see the connection between your post and mine.

1 Like

I just want to add my own buttons up there e_e It seem so silly attaching tabs to the bottom of the top bar, especially on a phone when it already covers loads of the screen.

Currently it seems the ability to hide the top bar is intended for cinematic portions of your game. There may not be anything worth phishing on the topbar now, but what if the topbar itself is made more useful in the future? With more social features, and maybe some pertaining to transactions.

What really bothers me, is that there are gameplay-specific features in the core gui and topbar, like the backpack, health, player teams and the “Help” info. If those features aren’t compatible with your game, they becomes useless empty space at the top of your player’s screen.

Custom menu buttons seem like the ideal solution when taking both the menu wheel and topbar into account.

2 Likes

Is it possible we could reconsider this feature request?

With mobile becoming more popular among players developers need all the screen real-estate they can get. I understand the effort to keep core UI trustworthy but I have also seen core UI replicated to look very trustworthy. Personally I think this intentional restriction just a big roadblock that isn’t significant enough to still be in place.

I ended up programming my own GUI system that doesn’t use TextButtons/ImagesButtons so that I can create non-rectangular buttons, get input from behind the top bar, fix inconsistent MouseLeave events, and add custom gesture types for SurfaceGuis or platforms like VR. Implementing this is not for the faint of heart, but it’s one of the best things I ever did for my game. I have ultimate control over gesture input :sunglasses:

My one oversight is gamepad/xbox compatibility, I ended up adding an awkward custom cursor lol.
Gif from June 2016:

Edit: Fixed dead gyazo link

Mouse events now do pass through the disabled top bar. Have you tried this recently? It should work now :slight_smile:

2 Likes

It seems they do not pass through this area (top right corner) despite both top bar and player list being disabled
image

I’ll look into fixing this. Probably some other gui in the way.

4 Likes

in legacy RAD platforms, there were such APIs as StopPropagation(), event.bubbles == true and event.Skip() which addressed the problem with overlapping Guis