QRadioButton in Pyside6 won´t change size when expanding window

Question

When using setSizePolicy(QSizePolicy.Expanding, QSizePolicy.Expanding) in Pyside6, QPushButtons react when expanding the window and become bigger, but QRadioButtons remain the same.

I can´t post images because Stakoverflow says "You need at least 10 reputation to post an image" and I have 9 reputation :(, I´ll edit when I reach 10.

Small window:

Large window:

Here the code, in case you want to give it a try:


from PySide6.QtWidgets import (
    QLabel,
    QPushButton,
    QSizePolicy,
    QHBoxLayout,
    QVBoxLayout,
    QWidget,
    QRadioButton,
    QSpacerItem
)
import sys
from PySide6.QtWidgets import QApplication


class ExampleWidget(QWidget):
    def __init__(self):
        super().__init__()
        self.button1 = QPushButton("Example1")
        self.button2 = QPushButton("Example2")
        self.button3 = QPushButton("Example3")
        self.button4 = QPushButton("Example4")

        self.button1.setSizePolicy(
            QSizePolicy.Expanding, QSizePolicy.Expanding)
        self.button2.setSizePolicy(
            QSizePolicy.Expanding, QSizePolicy.Expanding)
        self.button3.setSizePolicy(
            QSizePolicy.Expanding, QSizePolicy.Expanding)
        self.button4.setSizePolicy(
            QSizePolicy.Expanding, QSizePolicy.Expanding)

        widget_layout_buttons = QVBoxLayout()
        widget_layout_buttons.addWidget(self.button1)
        widget_layout_buttons.addWidget(self.button2)
        widget_layout_buttons.addWidget(self.button3)
        widget_layout_buttons.addWidget(self.button4)

        widget_layout_options = QVBoxLayout()

        self.selection_label = QLabel("Choose one:")
        self.selection_label.setSizePolicy(
            QSizePolicy.Expanding, QSizePolicy.Expanding)

        self.option1 = QRadioButton("Option 1")
        self.option2 = QRadioButton(
            "Option 2")
        self.option3 = QRadioButton("Option 3")
        self.option4 = QRadioButton("Option 4")

        self.option1.setSizePolicy(
            QSizePolicy.Expanding, QSizePolicy.Expanding)
        self.option2.setSizePolicy(
            QSizePolicy.Expanding, QSizePolicy.Expanding)
        self.option3.setSizePolicy(
            QSizePolicy.Expanding, QSizePolicy.Expanding)
        self.option4.setSizePolicy(
            QSizePolicy.Expanding, QSizePolicy.Expanding)

        widget_layout_options.addWidget(self.selection_label)
        widget_layout_options.addWidget(self.option1)
        widget_layout_options.addWidget(self.option2)
        widget_layout_options.addWidget(self.option3)
        widget_layout_options.addWidget(self.option4)

        merged_options_buttons = QHBoxLayout()
        merged_options_buttons.addLayout(widget_layout_buttons)

        spacer = QSpacerItem(20, 40, QSizePolicy.Expanding,
                             QSizePolicy.Expanding)
        merged_options_buttons.addItem(spacer)

        merged_options_buttons.addLayout(widget_layout_options)

        self.setLayout(merged_options_buttons)


app = QApplication(sys.argv)
window = ExampleWidget()
window.show()
app.exec()

Even if you can't show images in the post, you can still add the urls for them. What do you mean by "QRadioButtons remain the same"? Radio buttons don't have a border, their text is always close to their indicator, and they normally follow the text layout direction of your system (if you're using a RTL language, they will be aligned on the right). — musicamante, Jul 29 '23 at 23:36
@musicamante I´ve attached a link to the images, I think it´s easier to understand my issue with them. The clicking area won´t make bigger, but they do so in QPushButtons — setibs, Jul 30 '23 at 00:05
By default, radio buttons and checkboxes are only affected by mouse events within the geometry of their indicator (the "circle" or the "box", respectively) and their text. Note that the post for which I marked yours as a duplicate does what you probably expected, but I *strongly* discourage to do that. There's an important reason for which the geometry explained above is different on those widgets: in a button, the area available for mouse interaction is *clearly* visible, because buttons have a natural border that is required to show what type of element they are (see "Skeuomorphism") and -> — musicamante, Jul 30 '23 at 00:18
-> allow the user to intuitively understand how to interact with them. If you make the "clickable" area of a radio/checkbox much larger than its *visual hint*, the user will have inconsistent, unwanted (and possibly dangerous) behavior. Using the solution linked above with an UI as large as your second image will be problematic, as the user may trigger a radio when inadvertently clicking on a **clearly blank area** of the window (for instance, to activate the window), and since that area is that big, they may even not realize that the button has actually been clicked. It is also terribly -> — musicamante, Jul 30 '23 at 00:22
-> counter intuitive and inconsistent, and your example coincidentally shows that: clicking near the right edge of the window, but still within the "geometry" of the button, will trigger the button, but clicking in the middle of the window will not, due to the spacer you added: why can I click on the blank area on the right, but not on its left? And what about clicking in the middle between any of those radios? Having sizes that big, it's almost impossible to the user to be sure if they are clicking on the one above or that on the bottom. If what you want to achieve is an *exclusivity* -> — musicamante, Jul 30 '23 at 00:26
-> behavior, similar to that of radios, and have a visual geometry that is that big, then just use QPushButtons, make them *checkable*, and add them to a [QButtonGroup](//doc.qt.io/qt-6/qbuttongroup.html). In that way, the user will **always** know the area in which they can interact with their mouse, and the visual hint (pressed/unpressed) of the button will still be clear enough to understand the button state. To clarify the *grouping* of those buttons and allow better identification, use a further container widget (like a QFrame or a QGroupBox) so that the grouping will be easier to see. — musicamante, Jul 30 '23 at 00:27
@musicamante What about making at least text bigger when expanding? Maybe I could leave text part blank and add a Qlabel next to it and apply the setSizePolicy to it? — setibs, Jul 30 '23 at 00:32
Changing the text size in an UI when it is resized is always discouraged. Note that this is much different than the responsiveness of modern websites, which are normally shown at a specified size (usually, the maximized window, or in full screen for mobile devices) and almost always provide scrollable areas for the *whole* content. Desktop applications normally follow a different design pattern that inherently considers frequent resizing of windows and consistent element positioning. Due to their nature, desktop frameworks do the opposite: they don't rearrange elements based on the size -> — musicamante, Jul 30 '23 at 00:39
-> of the window (which is also often computed using the font metrics), but eventually change the size of the window itself based on the requirements of its elements. For this very reason, making widgets use different font sizes depending on the window size is almost always a problem, and it can also cause infinite recursion. Now, the real question here is about UX design: why do you want those elements *that* big? Making *some* elements bigger *can* be useful to highlight their importance, but making *all* elements that big has little benefit. If you're looking for something more modern, -> — musicamante, Jul 30 '23 at 00:45
-> "web-like UI", then maybe you shouldn't be using QtWidgets at all, and you may consider using the QML framework instead. Note that while QML provides similar controls (specifically, [RadioButton](//doc.qt.io/qt-6/qml-qtquick-controls-radiobutton.html), the UX requirements will still remain. 1. the user **must** know the area in which the interaction will happen (instead of making a bigger area, you should consider making the area *more visible*); 2. "big areas" are usually a benefit only for large devices that use "large" controls (screen/finger ratio), otherwise they are just annoying; -> — musicamante, Jul 30 '23 at 00:52
-> 3. the element hierarchy is important; as said above, elements should be bigger than others based on their importance; and while it makes sense to have a few "big" controls, the ratio between the size and its content is also important: huge buttons with relatively small text make little sense; considering the above aspects about desktop design, you should just prevent resizing of the window, or add spacers (or set the main layout alignment) so that contents are properly center-aligned, no matter the size of the window. — musicamante, Jul 30 '23 at 01:01
@musicamante Thank you very much, I´ll give QML a try, and consider to implement element hierarchy — setibs, Jul 30 '23 at 16:31

QRadioButton in Pyside6 won´t change size when expanding window

0 Answers0