[Development] QAIV new virtual methods (was: Feature freeze next Tuesday)

Иван Комиссаров abbapoh at gmail.com
Wed Sep 2 13:30:33 CEST 2020


Sorry for bringing this too late, I am busy with the Qbs development these days=)
So, my idea is to move some private slots from QAbstractItemViewPrivate to QAbstractItemView.
For the reference - there's a bunch of slots that are connected to model's signals but are hidden from user. Here's (more-or-less) the full list of such slots https://github.com/qt/qtbase/blob/dev/src/widgets/itemviews/qabstractitemview.cpp#L711
When extending existing views or implementing your own view (been there, done that), user will have to connect to those signals anyway thus duplicating the logic in QAbstractItemView::setModel.
Note that we already have some of this slots in public, e.g. dataChanged, rowsInserted, rowsAboutToBeRemoved. But we do not have slots symmetrical to them, e.g. _q_headerDataChanged, _q_rowsRemoved, etc. So for me it's the question of symmetry.
Obviously, we cannot add  new virtual functions during the qt5/qt6 lifetime, but it's a good time to do now=)
Besides the code duplication in setModel, sometimes it is desired to have more control of the order in which slots (user and qt's) are called. When overriding virtual function, this is easy - just do your actions before or after the call to the base class function. When having multiple connects, this is tricky and relies on the order in which slots are called (AFAIK, there was no guarantee for that, dunno about now). 
To illustrate - rowsRemoved changes the currentIndex. When the index is changed, I want to do some actions, except for the case when it is triggered from rowsRemoved. The naive approach would be to raise a flag before calling the base rowsRemoved method and unset if after. Well, this is not that easy when _q_rowsRemoved is hidden. Luckily, I found a better way for my use-case without raising flags. A workaround is not always possible - e.g. there's no public access to the hovered index (d->hover) which makes it impossible to draw the hovered index correctly in a custom view. But this is a bit offtopic=)
So, what are your concerns about adding symmetrical counterparts to the existing virtual slots and extending those to support all signals from the model?
It’s not like those slots will change Or be removed anytime soon, they were there as far as I remember.

Ivan

> 2 сент. 2020 г., в 10:45, Volker Hilsheimer <volker.hilsheimer at qt.io> написал(а):
> 
> Well, making a whole set of private methods available to application or widget developers that we then have to support with all sorts of use cases is not just a matter of moving some code around, and not just a question on whether it breaks ABI or not.
> 
> This needs to be thought through carefully, with the widget maintainers, with documentation, with examples and new test cases. That it’s “inconvenient” that you cannot call some code is not a very strong argument by itself.
> 
> I don’t see that we have time for that, to be honest.
> 
> Volker
> 
> 
>> On 2 Sep 2020, at 10:38, Lars Knoll <lars.knoll at qt.io> wrote:
>> 
>> Pure ABI changes are no problem until 6.0 is released. 
>> 
>> Source incompatible changes are something we should restrict to where required now, and you’ll need to be prepared to follow up with commits in other modules.
>> 
>> Cheers,
>> Lars
>> 
>>>> On 2 Sep 2020, at 10:29, Иван Комиссаров <abbapoh at gmail.com> wrote:
>>> 
>>> Is it still ok to break abi after the feature freeze? I’d like to move some private methods to the protected interface of the QAbstractItemView and make those virtual (basically, most Private slots). I found it quite inconvenient that I cannot call some code before/after the reaction to the signal from the model.
>>> Dunno if I will find time to do that, but I wonder if this is still possible. Should be a pretty simple refactor.
>>> 
>>> Иван Комиссаров
>>> 
>>>> 26 авг. 2020 г., в 08:47, Lars Knoll <lars.knoll at qt.io> написал(а):
>>>> 
>>>> Hi all,
>>>> 
>>>> This is just a gentle reminder that feature freeze for Qt 6 is approaching very quickly now. We’ve had a round of checks inside the Qt Company regarding how ready the teams are. All in all it looks relatively good, so we’ll keep the feature freeze at the 1st of September.
>>>> 
>>>> There are three areas that have asked for an exception to the freeze to finish things that are still pending:
>>>> 
>>>> * In QtCore, the Q*Iterables in qmetatype/qvariant 
>>>> * Across Gui/Declarative/QuickControls the input system
>>>> * The new desktop styling for Qt Quick Controls
>>>> * The new property system (see separate mail; most likely it won’t need an extension to the freeze date)
>>>> 
>>>> Those areas can finish the required changes to those subsystems beyond the feature freeze.
>>>> 
>>>> I would hope that there are no other exceptions required. If something is not done, but can easily be pushed to 6.1, you know what to do. If anybody knows about something else that can’t be pushed please talk to me, so we can figure out what to do about it.
>>>> 
>>>> Cheers,
>>>> Lars
>>>> 
>>>> _______________________________________________
>>>> Development mailing list
>>>> Development at qt-project.org
>>>> https://lists.qt-project.org/listinfo/development
>> 
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> https://lists.qt-project.org/listinfo/development
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200902/dd23a5e5/attachment.html>


More information about the Development mailing list