[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-guidelines
Subject:    Re: [kde-guidelines] Grids
From:       Aurélien_Gâteau <agateau () kde ! org>
Date:       2013-09-06 14:13:09
Message-ID: 2112435.EV8VoRZ1um () trinity
[Download RAW message or body]

Le jeudi 29 ao=FBt 2013 14:01:17 Heiko Tietze a =E9crit :
> Am 26.08.2013 16:05:38, schrieb Heiko Tietze:
> > Am Montag, 26. August 2013, 12:59:50 schrieb David Edmundson:
> > > I'm not sure I fully understand the question.
> > > There's a QTableView
> > > http://qt-project.org/doc/qt-5.0/qtwidgets/images/qtableview-resized.=
png
> > =

> > Exactly! Is there a difference from the point of implementation between
> > list view with multiple columns and this table view?
> =

> The guideline for list view states:
> Implementation     =

> * QListView, for single-column lists.    =

> * QTreeView, for multi-column lists. Be sure to set the rootIsDecorated
> property to false if the items in your list do not have children.  But
> QTreeView does not look like lists with multiple columns, IMHO. I'd
> recommend to rethink it in respect to QTableView.

(back from holidays, catching up on email)

Qt terminology is confusing:

QListView can either look like a single column list or an icon view (!)

QTreeView can show trees. These trees can have multiple columns. It is the =

recommended way to create a multi-column view, even if it is flat.
QTreeView can show a header for the different columns.

QTableView is for 2-dimensional data like a spreadsheet. The main differenc=
e =

is a QTableView can have headers for columns (like QTreeView) and rows (unl=
ike =

QTreeView).

> =

> 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 fir=
st
> 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?

All 3 view classes can have inline editing.

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

> 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 pa=
ge
> for complex views without the selection stuff.
> =

> What do you think?

One thing which would be worth mentioning in a HIG about multi-column views=
 is =

the sizing of columns. Unfortunately, Qt does not provide a very good way t=
o =

get this right. You can specify default size and let the user resize manual=
ly =

or use one of the two automatic resize modes (stretch to fill space or resi=
ze =

to content) but in this case the user cannot resize the columns himself.

For this reason I personally try to avoid multi-column views and instead dr=
aw =

the different elements in one column when possible (but it's much more work)

Aur=E9lien
_______________________________________________
kde-guidelines mailing list
kde-guidelines@kde.org
https://mail.kde.org/mailman/listinfo/kde-guidelines
[prev in list] [next in list] [prev in thread] [next in thread]