Hi Scott, Thanks for reaching out!
Flaky positions at application startup sounds like a Linux windowmanager, applying decorations which asynchronously change the (size and) position of the widget. Windows and macOS are not affected, because of their synchronous nature. The fact that the expected position flips between the spin box and it's internal line edit, seems rather random. The "fix all that were forgotten" function is a band aid. It sounds scary to me, to put band aid over band aid, by e.g. excluding "qt_*" object names or processing events on Linux a resize / move event is consumed. My personal recommendation is to set the correct tab order where it belongs, or construct the widgets in the right sequence, even if that's a bit more work in the first place. It's super satisfying to fix an issue by eliminating the root cause 🙂 Cheers Axel ________________________________ From: Interest <[email protected]> on behalf of Scott Bloom <[email protected]> Sent: Tuesday, 24 February 2026 18:13 To: [email protected] <[email protected]> Subject: [Interest] QAbstrctSpinBox position issues Using Qt 6.8, I have a dialog that “others” (read customer spec) has been changing a ton. Ive missed a couple of “set the tab order correctly” when the layout was changed. So I wrote a simple function to automate the tab order Essentially, it finds all the children of the widget, sorts by y position then x position, then sets the tab order appropriately. Ive hit a snag, that makes no sense. For QAbstractSpinBox derived classes (QDateEdit in particular, but it appears to be for all spin box classes) there are two positions. First is the pos reported QAbstractSpinBox::pos, and then there is a hidden internal QLineEdit called “qt_spin_box_lineedit” which has a totally different position reported. The issue is sometimes the Spin Box’s position is correct, other times the line edit’s is. I realize this is an internal widget, so there is likely zero public documentation. But looking through the code, I can not find any rhyme or reason why the locations are so different. The work around, is beyond a hack. I wound up forcing the widget to require each input to have a buddy label. This allows me to determine the Y location (note the X is fine) by 1. Checking if it has a buddy label, if so use its Y 2. Checking if the widget has an internal widget, if so use its Y 3. Finally use the actual Y position of the widget Any thoughts on this? I realize I’m missing a sample, I can create one and will if I wind up filing a bug on this, for now Im just wondering if anyone has seen this before and has any thoughts. Scott Confidential
_______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
