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

[Andre Somers]

  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? 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.

>
>> 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...