KListView, Dolphin and usability

Wed Feb 14 13:20:34 GMT 2007

>
> I think my original mail was a little bit unclear in this case; sorry for
> this. With "issues for selections and drag&drop" I meant especially the
> handling of the current QTreeView when using the "Details View" in Dolphin.
>
> Please let me explain: currently it is not possible to drop an item into a
> "Details View" (implemented as QTreeView), if a vertical scrollbar is shown.
> This is because there is no "viewport" area visible anymore. In the KDE3
> versions of Dolphin and Konqueror both applications have adjusted the
> "Details View" in a way that only the icon + name are a valid selection
> area, whereas the rest of the line acts as viewport. This behavior of the
> "Details View" is also used in the Windows Explorer and I think is quite
> common.

I'm not able to drag&drop items in the icon view neither. I can't even have
items freely-movable. I try to set the property setMovement(Qt::Free); and
it doesn't work. Please check out this.

Dolphin team, if you need any help with improving those kind of problems I'm
open to help you. Right now I haven't time for it... but I will for end of
february.

But for this behavior it is very important to give the user a visual hover
> feedback what is the target of his drop operation (viewport or
> file/directory).

You only want to give on-hover visual feedback when a drag&drop operation
has started, or always ?

Now from an implementation point of view it is not clear for me whether this
> can be achieved by the KFileItemDelegate implementation or whether there is
> a need for having a KTreeView. I trust here on Fredriks point of view very
> much as I think he has already a clear vision how to solve those kind of
> issues.

I think it will be probably necessary to add some features to
KFileItemDelegate to let join items.

So my concern is just if we concentrate now on categories by implementing a
> custom KListView, that we might lose the focus to have unified behavior for
> "Icons View" (implemented by QListView/KListView) and "Details View"
> (implemented by QTreeView).

Why ? if all applications use KListView instead of QListView, there's no
unified behaviour losing.

So if possible I think we should concentrate on those things first (even if
> they are easy to implement like hover) to get an indication in which
> direction we might go when implementing categories later.

I look a bit more on the future, and I really think things that are more
necessary right now go first, as you said, but that doesn't imply we are not
able to talk about the future. I am not going to write a line about this
right now, but I just want to have my mind clear about in which points you
agree with me, and in which you don't, so no unnecessary extra work is done.

Since this goes to kfm-devel I will explain the new features some users
requested David Faure. Here we go:

They wanted Konqueror/Dolphin to be able to move icons wherever they want,
for example, for logical ordering. Konqueror did give this functionality
since early KDE's versions. Now, I propose some cool features [FOR THE
FUTURE]:

1) Keep "Sorting" menu as is, with radio boxes. Adding a new "radio box"
called "Manually ordering" for example. When a sort is performed for name or
size, icons are just in a grid, and they cannot be moved in any way, only
for dragging&drop into anothers (copying, moving files...). If the user
selects "Manually ordering" we could have a file that stores the logical
positions of files, and show them that way. That allows user to sort always
and having they "fixed" in that order, or go back to the "logical order" the
user wanted.

2) Letting items being joined. If we have a fixed sorting (name, size...)
then items are joined if one next-to-another (vertically, horizontally,
diagonally) is selected. If we have a "manual order", then items are joined
if they are as close as a given radius. That would need some extra
functionality for KFileItemDelegate, for painting correctly.

3) Categories. If we have a fixed sorting (name, size...) then items can be
shown in categories. Probably this would need a new class that filters to
which category an item with a given property belongs. This means (passing
QSortFilterProxyModel::sortRole() to that class) that if we have the icon
view sorted by sizes, this new class could have "rules": if item is "<=1MB"
then it is "Small", if it is ">1MB and <=10MB" then it is "Medium" and if it
is ">10MB" then it is "Big". As items on the list are sorted that way, we
could ask one by one in a foreach loop, asking this class, and this class
would be returning "Small", "Small", "Medium", "Big". So we would have 2
small items, one medium and one big. When the view detects a different
string is returned then it goes for a new category.

If what we have on categorizing is the "logical order" by user, we could let
him/her add "custom categories". For example: imagine on "Documents" folder
he/she has uploaded some of them, or processed some, or whatever. He/She
could ask for adding a "Category" that is shown like a label with a special
look, and he/she could have some items below (with that logical order). Then
he/she could add another category, and have there some other items. It's
another way of having all in a-fast-look instead of folders if they are only
a few documents. This custom categories could be saved in the same file as
the icon positioning. So we really know the position of every "manually
positioned" element.

Bye,
Rafael Fernández López.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20070214/334eaab8/attachment.htm>