[Interest] QAbstrctSpinBox position issues

[Scott Bloom]

Thanks for the reply.

This doesn’t appear to be a window manager issue at all. The reason I say this, first its on windows, however second the numbers are consistently wrong in the same way.

While I agree, when it’s a designer based widget, fixing it correctly in the ui file is utopic 😊 it doesn’t help the case when it’s a code based widget or hybrid case.

Meaning, when I explicitly instantiate the input widgets not using C++.  It becomes especially difficult if dealing with a multi-language system where some of the languages supported are Right to Left, forcing you to lay things out differently.

I cant remove the qt_* widgets because at least with QDateEdit it has the correct position sometimes.

The code I have works really well, Ive been happy with the results.  I have found a couple caveats, such as it has to be called during the initial showEvent (so all positions are correct), but otherwise its easy to use and simple

Take a look at https://github.com/towel42-com/T42-Utils/blob/trunk/AutoTabStop.cpp

Scott


From: Interest <interest-bounces at qt-project.org> On Behalf Of Axel Spoerl via Interest
Sent: Tuesday, February 24, 2026 09:58
To: interest at qt-project.org
Subject: Re: [Interest] QAbstrctSpinBox position issues

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 <interest-bounces at qt-project.org<mailto:interest-bounces at qt-project.org>> on behalf of Scott Bloom <scott at towel42.com<mailto:scott at towel42.com>>
Sent: Tuesday, 24 February 2026 18:13
To: interest at qt-project.org<mailto:interest at qt-project.org> <interest at qt-project.org<mailto:interest at qt-project.org>>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20260224/cfb8417a/attachment-0001.htm>