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

[Christian Mollekopf]

> > > 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?
-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)
>
> > The bar is displayed by adding a QGraphicsWidget directly to the scene()
> > instead of inserting it into the layout. This has the advantage that it
> > doesn't make the whole operation "nervous" since nothing moves.
>
> right, though that's the same thing with the method i described above.
>
> > have a look at http://tinypic.com/view.php?pic=2mm7oti&s=5 if you wan't
> > to see how it looks atm.
> >
> > I know the cursors is a bit tiny, but this can be improved.
>
> yes, it took me quite a bit to actually see it at all. it's probably more
> apparent when actually using it as it will appear and disappear.
>
> anyways .. what i really don't like about this is that it takes our common
> visual for "this is a drop location" (the rounded grey translucent rect)
> and changes its meaning in this one case to "this is what is being
> dragged".
>
> changing the meaning of a visual hint is not good.

agreed (i thought more of a spacer so the meaning wasn't changed in my pov but 
thats probably more a developer pov). But still i think a spacer would look 
better than no spacer (but yes i simply copied the one from the panel ;) .

>
> *thinks*
>
> what might be cool, actually, is to only turn it into a QDrag when it
> leaves the taskbar and when it is in the tasks widget just move the item
> around directly much as we do in the panel.
>
> though in the case of the tasks widget, there's also the possibility to
> group things, so it can't just move around to the left/right of items
> exclusively.
>
> ok, starting from scratch here and making it "plasma"
>
> * 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.
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.

It's indeed the fancy way to display where the task goes but it's not good for 
usability. I thinks also displaying a bar might be not as nice as the spacer, 
but it looks clean and professional (and still not boring =).

>
> * within the tasks widget, items should be dragged about directly, when it
> leaves the tasks widget a snapshot of the item should be made and that
> should be set as the drag icon (just as we currently do with extender
> items)
agreed... the current drag with an icon as representation sucks obviously
>
> * to accommodate both grouping and rearranging, two different visual cues
> would be provided:
>
> 	* 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).

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

-what if you drag a task from the rootGroup to the expanded group1?
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.

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

My logic is more that only the container (expanded group) can receive the 
items and is therefore responsible for the  visual feedback. (it's clear 
developer logics don't matter and plasma itself should be consistent)

Anyway, i think i will post a reviewRequest soon, so you know about what code 
i'm actually speaking =)