How to display the insert index when sorting manually (Tasks applet)

[Aaron J. Seigo]

On Tuesday 17 March 2009, Christian Mollekopf wrote:
> > > > this is inconsistent with how other items in the plasma desktop shell
> > > > work and
> > > > is pretty old school. you'll also run into "doesn't fit" issues in
> > > > edge cases,
> > > > and painting it in the abstract item should be perfectly feasible.
> > >
> > > So should each item display a bar inside the task, or shouldn't there
> > > be any bar and only the text moves a bit away form the edge?
> >
> > the whole frame and text would move, yes.
>
> -wouldn't this affect the column width in all rows?

no, the item's size() would remain the same, it would just use the space 
differently in the paint method.

> -i think it's not very nice if we have two different visual hints per index
> (left item, right edge or right item, left edge)

it would be easy enough to split it between two items, really, so it's always 
the same.

> > * items should be dragged directly and should not be dragged via
> > representations (this is what we currently have, and it is very not
> > plasma). this also completely solves the "nervous" nature of having items
> > added/removed as it is directly responding to your movements.
>
> if you mean by "dragging directly" what is done in the panel, i'm against
> it.

it wouldn't be identical, but it could appear similar enough.

> Inserting a spacer on every insertIndex causes the whole taskbar to
> move if you have multiple rows. i know it works perfectly with one row
> (plasma panel, osx dock), but with multiple rows it sucks in my opinion.

not at all, since the items move out of the way for the space, there is never 
any more space used.

but.. yes.. it should only be done for items dragged out of tasks widget or 
for items dragged from a different tasks widget into that tasks widget.

for dragging *within* the same tasks widget, the object itself should be 
dragged around with none of this placement marker stuff.

if we drag the item around itself, however, this is a non-issue since it's 
just following the item around as the user drags it.

> > 	* when grouping is possible, hovering over the center 1/2 of the task
> > would cause the task group to highlight itself signifying it will be
> > dropped on
>
> this can be done of course. but it also means splitting the logic and not
> keeping it in one place (the taskgroupitems dragMoveEvent). Also if the
> expanded group receives the drop event we have to find the targeted item,
> which we would have otherwise for free (already determined in the last
> dragMoveEvent).

ok, so there are really only two situations:

* expanded group
* collapsed group

in the expanded group situation, there is never a "merge". there is only "move 
here". on move, the parent group of the item it is moved next to is set as the 
moved items' parent. 

btw, this is one situation where an insert point beam just sucks. consider 
this layout of expanded groups:

[   group 1    ] [     group    2   ]

in between group 1 and group 2 there are three possible drop areas:

* between the groups
* end of group 1
* beginning of group 2

with an insert beam, it's a matter of a pixel here or there at best. with a 
drop zone spacer, it is much more obvious whether it's the end of group 1, in 
between the two groups or at the beginning of group 2.

in the "between groups" scenario, items in both groups would get a bit smaler; 
in the end of group 1 scenario only one item in group 1 would get smaller; in 
the beginning of group 2 scenario only one item in group would get smaller. it 
is much more obvious. 

this problem can be seen in many treeview widget implementations, where 
dragging an item to a parent versus a child can be annoyingly difficult 
because there's just a little drag indicator line.

but you know, this is all a completely moot point now that i think about it. 
forget about spacers and beams and all that jazz.

when an acceptable drop is detected, simply create a temporary item that 
represents that item and move it around inside the tasks widget like any other 
item.

for items dragged around in the tasks widget, don't start a drag until they 
are moved outside the tasks widget.

dragging actual objects around is so much less ambiguous than drag and drop 
representations.

the only trick here will be that if an item is dragged outside the tasks 
widget, it will have to reappear in the tasks widget which might look a bit 
odd ... but that's the case no matter what we do here.

> > 	* when grouping is not possible (e.g. not turned on in the config) or
> > when hovered on the 1/4 left/right part of the item, the hovered item
> > will paint a small indicator to the left/right _within_ the item itself
>
> -what if you hit the area between the tasks? of course not the normal case
> but if you drop your item there just nothing happens (=> user thinks
> sorting is buggy and works not reliably)

one of the tasks would claim it. one way to ensure this works reliably is to 
have a "showDragIndicator(Location)" method in AbstractTaskItem and then have 
the group tell the items to show (or not) drag indicators.

of course, with the "literally drag the object" approach, this is a non-issue.

> -what if you drag a task from the rootGroup to the expanded group1?

then group1 handles it, just as rootGroup would. no particular magic.

> as currently implemented the expanded group one will receive the
> dragMoveEvent, will highlight the corresponding index and highlight itself,
> since this will be a combined grouping/sorting action.

yet another reason not to do it with drag objects ...

> Otherwise the hovered Item would have to check if it's group has to be
> highlighted and highlight it if neccessary (which would be the wrong way
> round in my opinion).

no, the group would respond on its own as well. the item would *pass through* 
the event after reacting to it locally.

> > this resolves *all* problems of adding additional items as you drag,
> > removes the whole unplasma style of creating drag objects unnecessarily
> > or with abstract representations ...
> >
> > and again, handling of the representation should be done in the item
> > being hovered, even if the actual drop is handled by the group.
>
> while i understand this general rule i think there are some valid points to
> do it different in this case.

there aren't.

> My logic is more that only the container (expanded group) can receive the
> items and is therefore responsible for the  visual feedback.

what happens in the code and what happens in the interface are two different 
concepts.

as soon as the interface follows the implementation, someone is doing 
something wrong.

in this case, trying to make the visual representation map directly to what's 
happening behind the scenes in the code is a mistake.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090317/c4357999/attachment.sig