[Qt-interest] QAIM::headerData() is not tied to QModelIndex?

[Stephen Kelly]

Andre Somers wrote:

>   Op 16-8-2010 13:01, Andreas Pakulat schreef:
>> On 16.08.10 08:17:09, Kishore wrote:
>>> On Monday 16 Aug 2010 12:39:52 am Andreas Pakulat wrote:
>>>> On 15.08.10 18:01:20, Kishore wrote:
>>>>> Why does the headerData() take section parameter and not a
>>>>> QModelIndex?
>>>>>
>>>>> I know this is not how QAbstractItemModel is commonly used but QAIM is
>>>>> designed in such a way that every modelindex can again have children
>>>>> and so on... ie. there can be a table within a table. So essentially,
>>>>> in a tree like structure, a child can have more columns than a parent
>>>>> and with a really different set of headerData as well. A more relevant
>>>>> API would be something like:
>>>>>
>>>>> QAIM::headerData ( const QModelIndex&index, Qt::Orientation
>>>>> orientation, int role = Qt::DisplayRole ) const
>>>>>
>>>>> just the way it is currently with columnCount().
>>>> This doesn't really make sense display-wise. The header is global so
>>>> you cannot have different strings
>>> display-wise, it does not make sense for columnCount either. Still it
>>> exists.
>> No it completely does, different subtree's may have different number of
>> columns. The header in the view is an optional component, so it might not
>> be shown in such a case where each index has a different number of
>> columns. And having one subtree with less columns than another can also
>> improve performance as the view doesn't have to fetch data for cells that
>> don't exist in the model anyway.
> Still, I think the reasoning of Kishore's question is, by extension of
> what you write above, valid. If you only show a subtree, then you could
> display a header that is valid for that subtree, could you not? 

You could put a proxy between the model and each view to implement the 
headerData method to return the correct data. Such a proxy could also be 
used to filter out columns so that you could show a different number of 
columns in each view. If the header data changes for different sub trees you 
can do that too.

KDE PIM apps have the same requirement, showing a tree of folders on the 
left with folder names, item count and data size, and a list on the right 
showing for example the subject, to, from, and date of an email. At the time 
I implemented it though I used a terrible hack of dividing up the available 
custom data roles to make it possible to specify different numbers of 
columns and different header data.

http://api.kde.org/4.x-api/kdepimlibs-
apidocs/akonadi/html/classAkonadi_1_1EntityTreeModel.html#a78fb18875ea3f23e4765ce67f6546bcd

Today I would use a proxy instead and fully separate the structure modelled 
from the data modelled, implement data() trivially in the 'base' model and 
use a separate (or multiple separate) proxies to provide data for different 
roles. 

> It would
> make sense to have the views query for the headers as valid for a
> certain QModelIndex if you have set that index as the root index for
> that view. You just can not, in a standard view, display different
> headers for different levels. That would look confusing, I think. If you
> want something like that, you should just use QicsTable or a widget like
> that. I think the current QAbstractItemModel could even be extended to
> provide that functionality with full backwards compatibility. Simpy make
> the default implemenation call the old function, and change the views to
> query the new method.

The new method would have to be virtual so I don't see how it could be BC?

All the best,

Steve.

> 
>>
>>> As such, IMHO hierarchy in anything other than the first column does not
>>> make much sense display-wise.
>> Yes, thats right, subtree's in Qt MVC only make sense in the first
>> column. See also the modeltest in the Labs repo which explicitly tests
>> for this.
> Actually, you can think of data structures where subtrees do make sense
> in every column. The QAbstractItemModel caters for that that scenario
> just fine*. Qt just does not offer any views to display such data.
> Think of it as a table where you might be able to zoom in on every cell
> in that table, and on that zoom level, every cell can display a new
> table. Would not even be that hard to wire into QTableView, by simply
> setting the root index to a cell if you double click on that cell and
> that cell has child rows and columns...
> 
> André
> * It is just not used in Qt, but it does make for part of the complexity
> of working with QAbstractItemModel...