Hidable Topbar!

Updates Announcements
#70

Instead of the corescripts telling the API which methods exist, if the API was the one who kept track of them and the corescripts were on the listening end, that problem wouldn’t exist.

Edit: Oh, if Corecii is correct in interpreting what you mean and the methods are already handled by the API, then what he said: the methods should be registered before SetCore yields for the corescripts.

1 Like
#71

Isn’t it possible to register the SetCore method prior to the yield(s) which saves the changes to be executed once the CoreScript is done loading?

1 Like
#72

It probably is. It’s something I’d like to look into if I ever get time, but VR is pretty fast-paced! Maybe @Garnold the Friendly Intern can do it.

To expand on what this would entail very quickly: all of the methods are handled in the core scripts. SetCore is kind of just a way to communicate with them from developer-level scripts. If we were to register them early, we have two real options:

  • Register them with a placeholder, and any call to it will recognize the placeholder and yield your script until the actual definition is written. SetCore isn’t supposed to be a yield function so this isn’t great.
  • Register them before any yields happen, and refactor the core scripts so that this is possible. It technically should be, but there’d be a lot of work in ensuring that all event listeners are also backed up with checks for existing state, since the code that reacts to a SetCore might actually need to happen after a yield.
2 Likes
#73

Can’t we just have those 2 things added?

  • GetCore("IsFeatureAvailable","TopbarFullTransparency")
    Returns whether a feature is (already) available
  • SetCore("OnFeatureAvailable",callback)
    callback = A BindableFunction which you set the OnInvoke for as event handler.
    (Same mechanic as the callback for ShowChatMessage)
    (which is required because functions can’t get passed trough contexts I think)
    (even if it can, it wouldn’t be allowed as that would allow context increasing hacks)
    Connects the callback to an internal event so it gets fired when a feature gets added.
#74

I’m willing to take a look into it.

7 Likes
#75

Sorry for the long wait, but I finally got around to this. As @baa_aaa suggested, I registered a placeholder setcore function for the topbar, which saves what state you set it to. And then once the actual function that sets the topbar enabled/disabled loads, it uses the state that was set in the placeholder function to determine whether or not to disable it.

tl;dr You wont have wrap setcore in a pcall loop anymore.

13 Likes
TopbarEnabled broken
#76

Any chance mouse clicks will work in the topbar area when the topbar it’s disabled?

4 Likes
#77

If you use UserInputService you can get mouse events through the topbar, though game processed event will be true.

uis.InputBegan:connect(function(iobj, gpe)
	if iobj.UserInputType == Enum.UserInputType.MouseButton1 then
		print("click down", gpe)
	end
end)```

If you meant gui buttons though, I don't believe that is planned.
1 Like
#78

Yes, that’s what I meant.

I was hoping that had changed, because for some reason it is/was intentionally blocked. Someone made a PR that fixed this issue and it was declined with the reason being GUIs not working in the space of a disabled topbar was intentional. Having to disable the rest of the ROBLOX CoreGui entirely to disable the topbar prevents anyone from disabling it just 'cause, so it’s a shame that the topbar was made intentionally buggy to be redundant.

1 Like
#79

I really need that extra space for my game. Those 36 pixels are important to me!

1 Like
#80

The extra 36 pixel shift, even when the top bar is disabled, really throws off my proportion-scaling UI. I literally have to edit sizing in play solo, cut it, stop play solo, and paste it in regular edit.

1 Like
#81

On phones (not tablets) I think this is a problem for UI design.

My controls are at the bottom of the screen, therefore I want to put my menu buttons at the top. I can’t do this nicely with the perfect location being occupied by an empty bar.

5 Likes
#82

That’s been my biggest problem with the top bar since day 1.

#83

Same. The topbar is a wonderful idea because games can rest easy knowing the ROBLOX CoreGui will never interfere with their interface, but if the game is never going to have any ROBLOX CoreGui to cause interference in the first place, it’s not needed, and we should be able to use that space without having to worry about intentionally introduced bugs stopping us.

3 Likes
#84

I think I made that PR some time ago.
It actually uses the :SetGuiIntentThing(0,0,0,0) so those 36px become 0px.
(I think I did that, or I just set .Visible to false. but I think I did that ^)

It’s so sad that we get an empty bar there when we want to get rid of the Topbar.
Just enlarging the gap between pc, mobile and console.
(simple GUIs that worked on all, now suddenly have an empty bar on some)

#85

Yeah, I really don’t understand why they would allow us to open up this topbar space but then not actually be able to use it normally. Especially because it still is doable with extremely hacky code, but for whatever reason they just don’t want it to be easy for us… Thinking that people wouldn’t wanna put stuff at the very top of the screen after having freed up that topbar space is crazy.

There needs to be a method that removes the 36px offset and allows regular button clicks in that newly-opened area, or this just isn’t worth the trouble of using very much.

I imagine it being especially annoying to work with when you’re creating a cross-platform game that includes consoles, since all of your GUIs near the top would have to account for both the 36px offset on other platforms and a 0px offset on console.

Is this blockage because of phishing/misleading players or something? People creating look-alike topbars with buttons to steal account information? Because people can already do that using the UIS methods. And people can already phish in a myriad of other ways as well. This can already be used for any ill-intentioned purposes - making it more difficult to use doesn’t stop those people. It only gives us legitimate developers a really hard time using it. I don’t understand what the point is of intentionally making this feature more difficult for us to use.

16 Likes
#86

Pretty please, someone…?

4 Likes
#87

This should now be live.

3 Likes
#88

Thanks!

Fix intentionally introduced bug where mouse events don’t work under disabled topbar next?

4 Likes
#89

Awesome. Can we please have the ability to click on top bar space please?

Please???

4 Likes