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

[Christian Mollekopf]

On Tuesday 17 March 2009 21:05:20 Aaron J. Seigo wrote:
> 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.

well i implemented this once (with removing the item and inserting the drop 
target spacer, so exactly as it's done in the panel) and decided that it's way 
to nervous. As i sad before for a single row taskbar this works like a charm, 
but if you have multiple rows the tasks start to jump from the end of one row 
to the beginning of the next row so pretty much the whole taskbar is moving if 
you're dragging a task from the last .

This could be overcome by using a little timeout before moving the item but 
then you need a drag with a snapshot of the item again.

Also it doesn't work well together with grouping as descibed in my first mail 
(when dragging the task from left to right).

Therefore i still think the displaying a bar is the better solution.


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

agreed

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

okay, this must sound ridicolous but i didn't know that i could just leave 
them ignored and the next widget would get it =/.
Anyway in this case the abstractTaskItem can catch all grouping events, and 
the underlying expanded group can handle only the sorting.
>
> > > 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.
well thats also not wat i was trying to do... if you move the item directly 
it's also handled by the group, so why should it be handled different just 
because the  drop indicator is different.

I won't have time this week to do much but hopefully on the weekend.

Somehow we're not really getting any further. It be nice if someone else could 
add his opinion.

Thanks for your response though aaron, it is very appreciated =)