KListView, Dolphin and usability

[Peter Penz]

Hi Rafael,

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

Thanks for the offer, any help is very welcome!

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

I think it only makes sense when always a visual feedback is given. Only by this the user knows during dragging a file, whether the drop-target is a viewport or a directory. The KDE3 version of Dolphin does this kind of feedback already, although the visual feedback implementation is quite poor (it's only represented as a "lighter icon"). I'm sure with Qt4 we have a lot more possabilities now to give a nice visual feedback.


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

You are right: for sure we also can discuss those future topics now :-) It also might help us for giving us the right design decisions for the more basic issues we have now.

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

I honestly was not aware that many users requested this until David mentioned this in an e-mail today. Although I personally don't work this way, I think it's a valid usecase, which may not be ignored.

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

Sounds nice! Sure there are many implementation details to think about (where and how is this information stored...), but generally I like the idea.

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

Do you mean by "joining" your new kind of selection?

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

As said I like the idea of categories. I think it might be not trivial to do this and we have to think about many details (what is a "rule" etc, how can the user define own rules, ...), but we should keep this in mind.

I'm not sure about the effort to write a rough prototype, but such a prototype might help us to get an impression about the direction we might go.

Thanks for all your ideas and suggestions, I hope we can bring them to life :-)

Peter
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<