QTableView.verticalHeader().setOffset() doesn't work
Maurizio Berti
maurizio.berti at gmail.com
Sun Mar 20 19:06:01 GMT 2022
Il giorno dom 20 mar 2022 alle ore 17:13 Matej Brezović <
matey.brezovic at gmail.com> ha scritto:
> Here is the MRE. If you replace view.verticalHeader() with
> view.horizontalHeader(), the offset will be visible, but doing it with
> verticalHeader doesn't seem to affect the table view at all.
>
I'm actually surprised that it works for the horizontal header for you, as
it doesn't on my computer. And it shouldn't.
As written in my previous email, any resize event in the view will always
trigger updateGeometries() (
https://doc.qt.io/qt-5/qabstractitemview.html#updateGeometries ), which in
the case of QTableView potentially updates (or resets) the offset. Since
widgets *always* receive at least one resize event the first time they are
shown (especially whenever they are added to layout), your call to
setOffset() becomes pointless.
The only way to achieve so on startup would be to call self.show() before
setting the offset (but calling self.show() in the init is usually
discouraged, while not technically an "error" per se), and/or possibly
using a single shot QTimer (a 0 interval should theoretically be enough,
but it might be necessary to increase it).
In any case, there are two problems:
- the offset would be reset again as soon as the view will be resized (due
any geometry change in any parent widget/layout that could affect it) or
the scroll bars are used;
- most importantly, programmatically setting the offset alone is *wrong*,
as the view uses the offset to compute the visualRect of items, which is
important for the advanced layout and painting required for item views: the
result is that, since you're using negative values, the headers will
actually translate by the given offset, but most items won't be painted at
all, as their geometry will not be considered valid for the "dirty scroll
regions" of their indexes; it might be a theoretical bug, but since header
offsets are *always* positive, I wouldn't consider it as such.
It's not clear what you're trying to achieve, but if your intention is to
add some "padding" on the top and left of the first row and column, I
believe that it would be very difficult to do without breaking the default
behavior.
Maurizio
--
È difficile avere una convinzione precisa quando si parla delle ragioni del
cuore. - "Sostiene Pereira", Antonio Tabucchi
http://www.jidesk.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20220320/27f7ba33/attachment.htm>
More information about the PyQt
mailing list