Are you suggesting more of them should be "deactivated" by default to decrease... uhhh... overhead? Or increase efficiency? I haven't seen anyone look into the actual costs of these built-in signals.

@Erich_L said: Are you suggesting more of them should be "deactivated" by default to decrease... uhhh... overhead? Or increase efficiency? I haven't seen anyone look into the actual costs of these built-in signals.

To stop crazy behavior. It is your choice to have a signal or not. It is absurd that I have how to actively disable hover on button.

To the people happy for GODOT programmers to mess with your game control, you should happy with whatever game breaking bugs they produce.

Hover on button signal is activated by default

Why is this a problem for you?

Which class emits the signal? I couldn't find it.

Button- can't tell which level of GODOT OO is actually doing it.. It has a handler that distorts my output image, First I had to work out WTH was going on. Which posters in multiple forums couldn't figure out. Then ask how to disabled- it can't be disabled. It can't be disabled only overridden. I wasted an hour on this nonsense. I haven't even tested the solution because I am working the real part of my program.

You should be programming your own games not have GODOT program your game (only assist). Don't you go with all the default values- don't you trust the GODOT programmers to do everything for you.

Oh I get it, you wanted to be able to click the button but you don't want to know if the mouse is hovering over it? I would say it doesn't seem like a big deal.

It switched from my preset stylebox to some default stylebox_hovered just as it was created while my mouse happened to be over it. I didn't what was happening. It is like a Sprite after creation suddenly changing its color and shape. I made a proposal to GODOT github wouldn't do anything,l

It switched from my preset black writing on white to white writing on black with the same text and button size.

You can define your own signals and use them exclusively. You don't have to use the built-in signals, but they do make your life easier for stuff like GUI interaction and collision detection. For example, for hover animation, you could read the global mouse position and compare it to the bounds of the button. This would work, but again you are making your life harder for no reason as the Godot signals work fine. I'm not sure I understand what the problem is.

I could be wrong, and if I am please disregard this entirely, but I think the terms a getting a tad mixed up here.

It switched from my preset stylebox to some default stylebox_hovered just as it was created while my mouse happened to be over it. I didn't what was happening. It is like a Sprite after creation suddenly changing its color and shape. I made a proposal to GODOT github wouldn't do anything,l

This is not a signal issue, but instead just built-in functionality with Godot's button class. Instead, this seems to be a styling issue and that, if I understand correctly, is the crux of the problem. This is just normal code reactions that are baked into the C++ code, no signaling beyond that of just normal programming. I think under the hood there is some data being called and passed around, but I believe it happens through the _unhandled_input function (or rather, the equivalent in C++). I believe a more descriptive term for this would be "processing", "data-passing", or "functionality" rather than "signals" simply due to the fact Godot has it's own signal term that means something completely different.

Godot has its own signals used for callbacks for when a button is pressed, hovered, etc, that allow you to execute code when these events occur. Signals can be in UI, Physics, 2D, 3D, and more, it really is just callbacks intended to allow specific chunks of code run when something has happened and you want to respond to it. These Godot signals are emitted whenever a proper event has triggered them (generally determined in C++ code) and you can make your own custom signals in GDScript as well. Again though, that is not a visual thing, it is essentially just callbacks. Signals can cause visual changes if the function they are connected to does a visual change, but on it's own they do not do anything visual. I do not think there is any signal that is emitted that causes a visual change from the emission of the signal itself.

As for the issue with the styleboxes, that is because Godot's built-in classes try to be helpful and provide a bunch of template and starter functionality. It can be a tad time consuming at times when you want the over and press styleboxes to be the same, but it's just a matter of copy-pasting the stylebox from Normal to Hover (and potentially Pressed) in the inspector stylebox overrides. It's also possible to set them all through code, which if you have lots of buttons can be a time saver. Generally though, I do not find it too troublesome and once you know what you need to set to get the visuals you want in the scenarios you want, it's pretty quick and easy to make buttons behave how you need them.

@cloa513 said: Hoover on button signal is activated by default which is bit of big brother decision- I don't what other ones are activated by default. https://strawpoll.vote/polls/hu17wgz6/vote?s=0

so are you saying the signal is called whether you use the signal in a script or not?

If so I believe this is because the button node has a default ability to change color if you hover over it which you can alter in the inspector, so they probably need that signal for that function.

I do agree it should be able to be disabled.

Edit: No longer positive about the default color change, I may have gotten confused between godots button and unity's button, cause I cant find the option in godot. sorry. =)

Edit 2: this comment is completely useless. the signal is not called unless you call it. =)

Yes, I don't believe this problem has anything to do with signals. Signals are callbacks (basically function calls), that inform your code when something happens. If you don't handle the signal (by defining a function and connecting it) then nothing happens. So this is not related to signals.

It sounds like the issue here is with the default styles of buttons. Buttons have styles for various states, like pressed and hover, etc. When you create a new button, it comes with default styles so you can see something and quickly prototype and use the button without extensive editing, and this is the right thing to do. When you do need to add your own art, you would style the button (for example, by creating a StyleBox on the Hover state).

If you need many of the same (or similar) buttons, you can create a single Button and save that as a scene, and then create instances of the button scene and just change their text or their color, or whatever you want to customize. You can also define global themes with the theme editor, and have all buttons and other UI elements use your theme. This is not hard to do, but does require effort (but you will need to do this no matter what, since there is no way for the engine to know what kind of art style you want in your game).

@cloa513 said: You should be programming your own games not have GODOT program your game (only assist).

I wouldn't mind Godot programmers programming my game :)

You're making an issue where there is none. No signal is enabled by default. You can clearly see this in the Node tab that's right beside the Inspector tab. All possible signals for selected node are listed there, with all active connections. Nothing is connected by default. Signals are even grouped by upstream classes in node's inheritance chain. All for your convenience, courtesy of Godot programmers :)

This is just how Button node behaves. It has graphical representation for standard button states. Which is what you want from a button 99% of the cases. This has nothing to do with signals or event handling. That's how Button node is programmed at the low level.

You can assign same stylebox to all button states. Just create a stylebox for one state and drag it to all other states so they all use the same instance. It's literally 15 seconds of work.

Alternatively, you can set "flat" flag for the button and it won't be displaying any graphics, set button's text to empty and draw a custom label and a sprite over it. Or manage the visual state any other way you like.

There's also TextureButton node you can use instead. Just assign "normal" state image to it, and this will be the only thing displayed, regardless of the button state.

While I'm not sure what the problem is I want to say my 2cents about polls :)

Its useful result if the poll was done by currently godot users? its a 2d designer who decide against a 3d ones? its a solo indie game or a boy who use godot once a mont to learn something or to have 10 min of fun? Its a indie game who decide what is the best way for godot? Or the poll have to be addressed an hypothetical user of the future? We can trust that the current user base is what we want to be in the future?

My point is: "Is not so simple to make a poll for Godot" :)

There's plenty of choice in godot, if you don't want to use the default Button you also have the choice of either using the TextureButton or even using a TextureRect node to create your own completely custom button.

@Megalomaniak said: There's plenty of choice in godot, if you don't want to use the default Button you also have the choice of either using the TextureButton or even using a TextureRect node to create your own completely custom button.

The choice should be explicit at least. You want to have it a certain way- not GODOT Engine does it for you because the programmers think they know what every single game designer wants to do. I have been privately emailing one who closed my no default signals (or what ever you want to call when a button sends a message to some default function handler) a programmer who closed my proposal in a very short time. He really think that he knows best about how you want to use buttons. I have feeling he thinks buttons should only be used to control the game and that every one expects to have a mouse hoover button effect and a mouse focus button. You should have some pull with the GODOT team- please tell that game designers want to the game however they want it. Minimum default settings as little as possible happens without set up in the inspector or script creation.

@cybereality said: Yes, I don't believe this problem has anything to do with signals. Signals are callbacks (basically function calls), that inform your code when something happens. If you don't handle the signal (by defining a function and connecting it) then nothing happens. So this is not related to signals.

It sounds like the issue here is with the default styles of buttons. Buttons have styles for various states, like pressed and hover, etc. When you create a new button, it comes with default styles so you can see something and quickly prototype and use the button without extensive editing, and this is the right thing to do. When you do need to add your own art, you would style the button (for example, by creating a StyleBox on the Hover state).

If you need many of the same (or similar) buttons, you can create a single Button and save that as a scene, and then create instances of the button scene and just change their text or their color, or whatever you want to customize. You can also define global themes with the theme editor, and have all buttons and other UI elements use your theme. This is not hard to do, but does require effort (but you will need to do this no matter what, since there is no way for the engine to know what kind of art style you want in your game).

I am doing it all by code because I was having so many troubles with creation of instances by code.

Lots of people created buttons (especially Buttons) by code because buttons looks simple and straightforward- no image need to add and mouse handling included . Just search for Button.new()

@cloa513 said: The choice should be explicit at least. You want to have it a certain way- not GODOT Engine does it for you because the programmers think they know what every single game designer wants to do.

Yes, and you definitely have that choice. By using themes and theming the button. It is very simple to do in the Inspector and you can customize all the colors, or the shape, different states, textures, etc. It's all included in Godot and it works fine. You also don't even need to use the Button class at all. You could just create Sprites and do all the code yourself (but this would be silly and pointless, but you have that choice). You can also choose to use another engine, since you seem so frustrated with Godot. Or write your own game engine from scratch, since you seem to have a lot of ideas of how a game engine should work. Lots of choices.