Okay I have to apologize that I am having difficulty in understanding what your problem is. In your second example you are using a SizePolicy and it works as it should, while in your first example you put a button within a Grid Layout so the default size policy of that Grid Layout is governing how the button within it it will resize to some degree. Now to determine the default size policy of a layout you can reference the sizePolicy( ) function. For which it states the following:
The size policy holds the default layout behavior of the widget. If there is a QLayout that manages this widget's children, the size policy specified by that layout is used. If there is no such QLayout, the result of this function is used. The default policy is Preferred/Preferred, which means that the widget can be freely resized, but prefers to be the size sizeHint() returns. Button-like widgets set the size policy to specify that they may stretch horizontally, but are fixed vertically. The same applies to line edit controls (such as QLineEdit, QSpinBox or an editable QComboBox) and other horizontally orientated widgets (such as QProgressBar). QToolButton's are normally square, so they allow growth in both directions. Widgets that support different directions (such as QSlider, QScrollBar or QHeader) specify stretching in the respective direction only. Widgets that can provide scroll bars (usually subclasses of QScrollArea) tend to specify that they can use additional space, and that they can make do with less than sizeHint().
So if you read that carefully you can see that the SizePolicy is never without a value and that the value may change based on the particular widget it is being applied to -- without any manual SizePolicy being set -- further even if you set a specific policy I have encountered features that state -- unless you specifically turn this off it will dictate part of the SizePolicy -- granted those are not the exact words but that was the gist of what it was saying.
In short -- yes there are aspects in play almost all the time based off the widgets and layouts you are using. The key -- if you wish to dig that deep -- is to fully understand each of the pieces you are using and what the default rules are to how they interact with one another. Either that or you can just get a solid general idea of how they interact and then deal with any oddities that pop up when you are implementing something new. Make adjustments for the oddity, make note of that oddity and then move on.
The former has the benefit of giving you solid idea of what to expect but is going to take quite a bit of time. The latter has the benefit that you get up and running much faster but it means you do not necessarily know exactly how something is going to respond beyond what you have already experienced with it. However the latter is also more practical in that you are moving forward while you are learning rather than sitting stagnant until you have learned. Neither is wrong, it just depends on the situation you are in.
The size policy holds the default layout behavior of the widget. If there is a QLayout that manages this widget's children, the size policy specified by that layout is used. If there is no such QLayout, the result of this function is used. The default policy is Preferred/Preferred, which means that the widget can be freely resized, but prefers to be the size sizeHint() returns. Button-like widgets set the size policy to specify that they may stretch horizontally, but are fixed vertically. The same applies to line edit controls (such as QLineEdit, QSpinBox or an editable QComboBox) and other horizontally orientated widgets (such as QProgressBar). QToolButton's are normally square, so they allow growth in both directions. Widgets that support different directions (such as QSlider, QScrollBar or QHeader) specify stretching in the respective direction only. Widgets that can provide scroll bars (usually subclasses of QScrollArea) tend to specify that they can use additional space, and that they can make do with less than sizeHint().
So if you read that carefully you can see that the SizePolicy is never without a value and that the value may change based on the particular widget it is being applied to -- without any manual SizePolicy being set -- further even if you set a specific policy I have encountered features that state -- unless you specifically turn this off it will dictate part of the SizePolicy -- granted those are not the exact words but that was the gist of what it was saying.
In short -- yes there are aspects in play almost all the time based off the widgets and layouts you are using. The key -- if you wish to dig that deep -- is to fully understand each of the pieces you are using and what the default rules are to how they interact with one another. Either that or you can just get a solid general idea of how they interact and then deal with any oddities that pop up when you are implementing something new. Make adjustments for the oddity, make note of that oddity and then move on.
The former has the benefit of giving you solid idea of what to expect but is going to take quite a bit of time. The latter has the benefit that you get up and running much faster but it means you do not necessarily know exactly how something is going to respond beyond what you have already experienced with it. However the latter is also more practical in that you are moving forward while you are learning rather than sitting stagnant until you have learned. Neither is wrong, it just depends on the situation you are in.