<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title></title><style type="text/css">.felamimail-body-blockquote {margin: 5px 10px 0 3px;padding-left: 10px;border-left: 2px solid #000088;} </style></head><body>Am 26.08.2013 16:05:38, schrieb Heiko Tietze:<br><blockquote class="felamimail-body-blockquote">Am Montag, 26. August 2013, 12:59:50 schrieb David Edmundson:<br>> I'm not sure I fully understand the question.<br>> There's a QTableView<br>> http://qt-project.org/doc/qt-5.0/qtwidgets/images/qtableview-resized.png<br>Exactly! Is there a difference from the point of implementation between list <br>view with multiple columns and this table view?<br></blockquote><p><br></p><p>The guideline for list view states:</p><p><br></p><p>Implementation <br></p><p>* QListView, for single-column lists. <br></p><p>* QTreeView, for multi-column lists. Be sure to set the rootIsDecorated property to false if the items in your list do not have children. </p><p><br></p><p>But QTreeView does not look like lists with multiple columns, IMHO. I'd recommend to rethink it in respect to QTableView.<br></p><p><br></p><p>At the moment I'm unsure whether we should 'allow' lists with multiple columns or rather separate simple lists from grids (aka tables). On a first glance I'd say lists do not have inline editing but tables does. Or do I expect editing on single clicks for tables and after double click with lists? What else: Usually, tables have a distinct bevel and a fixed first column (both are non-functional and not a guideline), tables can be extended in both directions... That's not productive, both controls may appear similar to users.<br></p><p><br></p><p>I vote for simple, single column 'lists' and extended, multi column 'tables'. Two, user-centric pages in the HIG, implemented by either QListView or QTableView. And perhaps we should duplicate the list view page for complex views without the selection stuff. <br></p><p><br></p><p>What do you think?<br></p></body></html>