[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: KListView, Dolphin and usability
From: "=?UTF-8?Q?Rafael_Fern=C3=A1ndez_L=C3=B3pez?=" <ereslibre () gmail ! com>
Date: 2007-02-14 9:51:27
Message-ID: 93f85fee0702140151u2943365t4d5230b08b0b416d () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
[Attachment #4 (text/plain)]
Hi again,
Peter, hovering is "easy" indeed I think. I don't know anything about
previews... maybe I should take a look. What are the issues with selections
and drag&drop ?
I've taken a look at Nautilus, since some users suggested that Konqueror
should be able to put icons wherever the user wants and save their
positions. I thought it was a bad idea in general, but know that I see
Nautilus' implementation is not so bad after all. The idea is not to move
the "order by size, name..." from radio buttons to "menu do-it-right-now
actions" and when the user drags an item hide everything (categorization
labels and so on discussed on my last email). The thing is that we could add
a new "radio box" to that submenu that is "Order manually". There a
different joining could be possible. So, we could have:
1) As before, "Order by Name, Size, Timestamp last modification..."... and
in this view mode all items have same size and *CAN'T* be moved wherever.
They are just sorted the way the user selected, and the way the radio box is
checked. Automatic categorizing enabled, and labels shown. Items joins if
one was selected next-to-another selected (vertically, horizontally and/or
diagonally).
2) Add a new option to the sort submenu: "Manual order" or "Order manually",
where no categorizing exists (where we could think about let user add
"manual labels"), so what's more than manually ordering them, he/she can
categorize them. This would require a different joining method: if 2 items
are not next-to another, but they have a intersection rect, so one is on top
of another, their borders just join. The another possibility, for having
this kind of items joining is having a "virtual fence", that is bigger than
the actual painting rect. If two items rect have a non-null intersection by
their virtual fences, then they two are joined. This probably may require a
new class, KItemDelegate.
Bye and thanks,
Rafael Fernández López.
[Attachment #5 (text/html)]
Hi again,<br><br>Peter, hovering is "easy" indeed I think. I don't know \
anything about previews... maybe I should take a look. What are the issues with \
selections and drag&drop ?<br><br>I've taken a look at Nautilus, since some \
users suggested that Konqueror should be able to put icons wherever the user wants \
and save their positions. I thought it was a bad idea in general, but know that I see \
Nautilus' implementation is not so bad after all. The idea is not to move the \
"order by size, name..." from radio buttons to "menu do-it-right-now \
actions" and when the user drags an item hide everything (categorization labels \
and so on discussed on my last email). The thing is that we could add a new \
"radio box" to that submenu that is "Order manually". There a \
different joining could be possible. So, we could have: <br><br>1) As before, \
"Order by Name, Size, Timestamp last modification..."... and in this view \
mode all items have same size and *CAN'T* be moved wherever. They are just sorted \
the way the user selected, and the way the radio box is checked. Automatic \
categorizing enabled, and labels shown. Items joins if one was selected \
next-to-another selected (vertically, horizontally and/or diagonally). <br><br>2) Add \
a new option to the sort submenu: "Manual order" or "Order \
manually", where no categorizing exists (where we could think about let user add \
"manual labels"), so what's more than manually ordering them, he/she \
can categorize them. This would require a different joining method: if 2 items are \
not next-to another, but they have a intersection rect, so one is on top of another, \
their borders just join. The another possibility, for having this kind of items \
joining is having a "virtual fence", that is bigger than the actual \
painting rect. If two items rect have a non-null intersection by their virtual \
fences, then they two are joined. This probably may require a new class, \
KItemDelegate. <br><br>Bye and thanks,<br>Rafael Fernández López.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic