Make GraphEdit toolbar more customizable

[YuriSizov]

Depends on #81551 (drafting for now).
This should address the issues mentioned in godotengine/godot-proposals#7061, possibly enough to close the proposal.

I'm introducing a set of exposed properties to hide parts of the menu bar, and the menu bar itself. Previously existing properties to hide the arrange button and to show the zoom label are grouped together with the new properties in the inspector. The property to hide the arrange button has been renamed, because its appearance in the inspector can be very misleading:

Now the property is called hide_arrange_button, and its methods are set_hide_arrange_button and is_hiding_arrange_button. Similar naming scheme was used for the new properties. The property to show the zoom label remains unchanged.

This can be discussed further because the problem of negative and positive names is a pretty annoying one. But for now this is my proposal.

godot.windows.editor.dev.x86_64_2023-09-12_20-03-27.mp4

---

Additionally I addressed a usability issue with the toolbar that I had noticed long ago. Since the toolbar didn't have a background and could easily appear on top of various text and icons, it could be hard to read and use under certain circumstances:

So I added a semi-transparent background (both in the default theme and in the editor):

PS. There are some changes in unrelated files because I've cleaned up includes in graph_edit.h.

[lostdisplay]

Great stuff! Is it possible to give the user the option to hide the scrollbars too?

[YuriSizov]

@lostdisplay Sure, but it would be a considerable usability downgrade to do so if panning and zooming is still allowed. What would be the use case?

[lostdisplay]

@YuriSizov I can think of a use case, and that's for my personal project 😅, an app for taking notes with an infinite whiteboard. The scroll bars would just be a hindrance. Right now I'm connecting the visibility_changed signal of the internal scrollbars to a function that hides them again, which is hacky at best.

But to be honest, this has a very limited use case. I've seen some people using GraphEdits for skill trees though?

[YuriSizov]

I've seen some people using GraphEdits for skill trees though?

I haven't, and I'm not sure GraphEdit is that suitable for more simplistic game UIs. But I guess I've seen games where such UIs are done without any scroll indicators. I think it's a material for a different PR, but yeah, it should be doable, since it's GraphEdit that hides and shows them.

[YuriSizov]

Rebased on master and also added compatibility methods. Properties cannot be added for compatibility at the moment. Something to look into in the future. GDExtensions don't have them, but C# might need us to do this gracefully. Can also be useful if we want to expose compatibility code to GDScript.

[raulsntos]

C# might need us to do this gracefully.

That's right, we would have to add the old properties to the Compat.cs file if we want to avoid breaking compat.

That said, since GraphEdit is marked experimental, and we are already breaking compat in the GraphNode API, is there any point to providing these compat methods/properties?

[YuriSizov]

That said, since GraphEdit is marked experimental, and we are already breaking compat in the GraphNode API, is there any point to providing these compat methods/properties?

Outside of the automated system that we have, no, I don't think so. But for GDExt we want to keep binary compatibility as intact as possible, so methods at least are worth adding when we remove or rename them.

[raulsntos]

I don't disagree with that. My point was that if we are already breaking binary compatibility in the GraphNode API, adding these compat methods won't help those users, right? They would still be affected by the break.

[YuriSizov]

My point was that if we are already breaking binary compatibility in the GraphNode API, adding these compat methods won't help those users, right? They would still be affected by the break.

Most of it was renames, so a compatibility method that routes to the new method should be sufficient for GDExtension users who may be using them. That said, I'm not particularly sure where the line would be in this specific case.

[Geometror]

Overall solid work, the visual usability improvement looks nice!
I was actually just planning to implement this after I took another look at my GraphEdit refactoring todo list. Luckily I noticed your PR before that :)

[YuriSizov]

Changed all toolbar properties to be show_* (with show_zoom_label being the only one off by default, which is its current state).

With the flat button changes the toolbar currently looks like this

Light mode definitely needs more work overall, but it should still benefit from these changes

[elmanjar13]

Thats' good!!!!

[akien-mga]

Thanks!