[feature][tree d&d] needs to respect sorting when doing drop feedback

NEW
Unassigned

Status

()

Core
XUL
P5
major
18 years ago
9 years ago

People

(Reporter: Mike Pinkerton (not reading bugmail), Unassigned)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
subject says it all.

The tree code needs to take into account whether a sort is being imposed, and if
so, only allow a drop into the parent container. On the root of the
tree, just check for the attribute/value:  sortActive="true"
(Reporter)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M14
(Reporter)

Comment 1

18 years ago
cc'ing robert, accepting, m14

Updated

18 years ago
Target Milestone: M14 → M15

Comment 2

18 years ago
drag&drop is once again post-beta according to marketing. moving all d&d bugs to
M15.

Updated

18 years ago
Blocks: 15774
(Reporter)

Updated

18 years ago
Component: XP Toolkit/Widgets → XP Toolkit/Widgets: Trees
Summary: sched: tree d&d needs to respect sorting when doing drop feedback → [feature][tree d&d] needs to respect sorting when doing drop feedback
Whiteboard: 1 day
(Reporter)

Comment 3

18 years ago
flashes a lot, but gets the job done for now.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 4

18 years ago
VERIFIED with 2000032909 builds
Status: RESOLVED → VERIFIED
(Reporter)

Comment 5

18 years ago
reopening, I realized my solution was too simplistic once i turned my brain on.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 6

18 years ago
bumping to m16 since i need to do a little bit more work, still not rocket 
science.
Status: REOPENED → ASSIGNED
Target Milestone: M15 → M16

Comment 7

18 years ago
You know, I was just about to call you, Mike.  :^)  Sometimes, when doing D&D on 
the Mac, Mozilla just silently quits.  Ever see that?
(Reporter)

Comment 8

18 years ago
pushing this over to UE. I need a good spec on what drop feedback should look 
like when a tree is sorted.
Assignee: pinkerton → german
Status: ASSIGNED → NEW

Comment 9

18 years ago
this bug seems belone to pinkerton, not german. re-assign. 
Assignee: german → pinkerton
hahahahaha  Laugh or cry?
(Reporter)

Comment 11

18 years ago
pushing back, read the comment. i need to know what the drop feedback should look 
like!
Assignee: pinkerton → german

Comment 12

18 years ago
OK, so I'll go hammer german instead. Need for PR2?
Severity: normal → major

Comment 13

18 years ago
M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 14

18 years ago
I am a bit worried that drop feedback would be different because of sort only. 
Cause and effect is hard to understand for the casual user
I we do it here's my suggestion A:
- Over close folders the grey background we have now, indicating a drop would 
land inside the folder being moused over
- Over items in opened folders I suggest we also hilite the parent folder of the 
item being moused over in order to indicate that's its going in there instead of 
the root
Alternative B:
- we do the same feedback as when unsorted, namely we draw an insertion line when 
over items and a grey background when over a folder, but we run the sort 
afterwards
temp. changing components to UE feedback to the proper folks to contribute/
comment
Status: NEW → ASSIGNED
Component: XP Toolkit/Widgets: Trees → User Interface: Design Feedback
Whiteboard: 1 day → [not to self: need to add to ui spec]
Target Milestone: M16 → M20

Comment 15

18 years ago
I propose reassigning this bug to ben, the mozilla UI owner, so he can add this
to his 'ongoing discussions bin'.
I am still think solution B mentioned before is the right one.
Assignee: german → ben
Status: ASSIGNED → NEW
Whiteboard: [not to self: need to add to ui spec]

Comment 16

18 years ago
Neither Option A nor Option B would be good for usability. Option A would often 
mean that you couldn't see any drop feedback at all for opened folders (if the 
parent folder wasn't currently visible in the tree). And Option B would mislead 
the user into thinking that your exact drop position was important when it really 
wasn't -- leading to exactly the `Cause and effect is hard to understand for the 
casual user' problem that German was allegedly worried about.

How about this:

* When a list is unsorted (e.g. bookmarks), so exact drop position is important:
  - Tree can be drag-scrolled by holding the dragged item at a point less than 1
    em above or below the tree.
  - If dropping between two items:
    o Drop feedback is a 2px solid line drawn in drag variation color (Mac) or
      selection color (Windows, X) between the two items; starting from the level
      of items inside the relevant folder on the left, and extending to the right
      by the width of the item itself (e.g. the width of the bookmark icon plus
      its title).
    o If dropping between two items where the upper one is at least 1 folder
      nesting level away from the lower one, the drop target is dependent on the
      horizontal position of the cursor. For example, if I have
      v Folder A
        v Folder B
      > Folder C
      and I am dropping between Folder B and Folder C, then the item will be
      dropped inside Folder A (below Folder B) if {the horizontal position of the
      cursor} >= {the left edge of Folder B}, or it will be dropped below Folder
      A (between Folder A and Folder C) if {the horizontal position of the
      cursor} < {the left edge of Folder B}. (This way the innermost expanded
      folder has the largest target, which is good since it's probably where the
      user wanted to drop anyway otherwise they wouldn't have expanded the folder
      in the first place.) The exact drop destination is shown by the position of
      the left edge of the drop marker as described above.
  - If dropping on a folder:
    o Drop feedback is showing that folder in selected style.
    o Hovering over a closed folder for the system delay time (Mac OS) or one
      second (Windows, X), or pressing the Space bar while hovering over the
      folder, flashes the folder between unselected and selected styles twice,
      then expands the folder to allow dropping within that folder (without the
      scroll position of the folder itself changing). If at any subsequent time
      during the drag the item is dragged outside that expanded folder, the
      folder is collapsed again. (This means you have to keep a temporary record
      of which folders are just expanded temporarily as a result of the drag, and
      collapse them when the drag is over.)
* When a list is unsorted, so exact drop position is not important:
  - Tree can not be drag-scrolled.
  - Drop feedback is: a 2px solid border around the inside of the tree as a
    whole, in drag variation color (Mac) or selection color (Windows, X).

Errrrr ... That's probably more than you wanted, Pink?
(Reporter)

Comment 17

18 years ago
even when a list is sorted, i may still wnat to put something w/in a folder
(since we sort w/in folders IIRC and retain the general hierarchy). that isn't
covered by your cases.

mpt, the unsorted portion doesn't belong in this bug, and will probably get lost
when it is closed. If you want the way unsorted tree dnd is done to change, file
a new bug with your suggestions.

Comment 18

18 years ago
> i may still wnat to put something w/in a folder (since we sort w/in folders
> IIRC and retain the general hierarchy). that isn't covered by your cases.

I realized this ten minutes later ...

Hokay. What the Finder does (in a sorted list of files/folders) is assume that 
any drag that's not onto a folder itself is intended to go into the root folder. 
Though folders in Mozilla tree widgets are under more constraints (you can't just 
open them in a new window like you can in the Finder), I think you should do the 
same thing, using the whole-tree drop feedback I described -- except where the 
cursor is actually over a folder, which means that the drag should go into the 
folder itself.

I don't really see any other way of doing it -- you can't drop anywhere into an 
expanded folder list to place an item in that folder, because you have no way of 
showing meaningful feedback for that. You can't highlight the folder itself, 
because it might not be visible; and you can't draw a drop ring around just the 
expanded folder and its children, because for a sufficiently long list of 
children it would look practically indistinguishable from dropping into the root 
folder anyway.

'Course, it's Ben's job to make the final decision. :-)

Updated

17 years ago
QA Contact: claudius → zach

Comment 19

17 years ago
Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...
Tree Bad, Outliner Good. 
Status: NEW → ASSIGNED
Priority: P3 → P5
Target Milestone: --- → Future

Comment 21

16 years ago
.
Assignee: ben → hewitt
Status: ASSIGNED → NEW
Component: User Interface Design → XP Toolkit/Widgets: Trees
QA Contact: zach → shrir

Updated

10 years ago
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: shrir → xptoolkit.widgets
Assignee: hewitt → nobody
You need to log in before you can comment on or make changes to this bug.