bugGNUstep - Bugs: bug #29892, Outline view selected item...


You are not allowed to post comments on this tracker with your current authentification level.

bug #29892: Outline view selected item highlighting not preserved when collapsing/expanding

Submitted by:  Richard Frith-Macdonald <CaS>
Submitted on:  Sun May 16 09:30:15 2010  
Category: Gui/AppKitSeverity: 3 - Normal
Item Group: BugStatus: None
Privacy: PublicAssigned to: None
Open/Closed: Open

(Jump to the original submission Jump to the original submission)

Fri Aug 27 13:30:48 2010, comment #6:

I have just committed a fix for this bug. I tried to match Cocoa's behavior as closely as possible. In particular, the changes attempt to ensure that the outline view is in a consistent state whenever a notification is posted, i.e., an object that receives one of the notifications can ask the outline view for the number of rows and selected row (indexes) and the returned values will match the actual state.

Thus, even though I really see no point in doing that from a user's POV, it would be possible for the delegate to implement the current behavior, i.e., preserve the selected row indexes when an item is collapsed or expanded – just save the current indexes when receiving the will collapse (expand) notification and restore when receiving the did collapse (expand) notification.

Wolfgang Lux <wlux>
Tue May 25 12:03:01 2010, comment #5:

except NSTableView and NSOutlineView don't track selected objects,
if it did, I would expect there to be a -selectObject: method,
and a -selectedObject: method at least

the truth is that it tracks row indexes, and its much easier to add this behaviour to your NSOutlineView delegate, than it is to stop it from happening should this not be the behaviour one wants.

but honestly in my opinion NSOutlineView in this case breaks the cardinal sin of OpenStep, that things shouldn't expand and contract, except based on direct mouse movement, such as moving a scroll bar,

it makes perfect sense that if you do the above, you need to break the other cardinal sin of OpenStep, and move the place where the user put the cursor/selection around when you do so.
so go for it

matt rice <ratmice>
Project Member
Tue May 25 08:40:07 2010, comment #4:

This: 'the selected row shouldn't jump around to the new row index where the selected object now is' appears to be a mistake to me for two reasons.
1. If you actually try using an outline view in an application where the selected item is important, you will find that maintaining the selected row means that collapsing/expanding an item effectively selects a random item (whatever happens to be moved to the selected row) ... making it impossible to navigate the outlineview without losing your selected item.
2. It's not OSX compatible ... OSX maintains the selected item through expand/collapse (except where the selected item is actuallyinside an item you collapse).

Richard Frith-Macdonald <CaS>
Project Member
Mon May 24 23:34:24 2010, comment #3:

Dug through the lists a little, from this thread:

so it appears that this removal was intentional, and I disagreed that this bug is a bug,

"This stuff doesn't seem to make sense to me, if the selected objects changes row indexes
the selected row shouldn't jump around to the new row index where the selected object
now is...

attached is a patch which gets rid of _selectedItems,
and implements a private method to maintain the selected row index
not the selected objects."

so if you want to re-add this you will need to fix the bugs associated with it, IIRC these bugs take the form of,

'the selected row index changed, but the delegate was not informed of any change'

matt rice <ratmice>
Project Member
Mon May 24 21:21:46 2010, comment #2:

iirc the intent was removing duplicate code and letting it fall back to the super's implementation, when I was doing the whole rewrite of the NSTableView selection tracking, so I didn't have to make bugfixes in subclasses, Its very well possible I missed a difference between the 2, such as the bug described here.

so it is possible that you may be able to re-add the code, but also possible that it requires the same changes to mirror those which were made to NSTableView

anyhow, the way I remember it is that the code was the same between NSTableView and NSOutlineView except for one detail, which is the way in which NSTableView and NSOutlineView figure out the number of rows, and so I added a private method to NSTableView which it calls on self, and NSOutlineView then overrides it

matt rice <ratmice>
Project Member
Mon May 24 20:25:38 2010, comment #1:

I think this used to work (more or less), but it looks like Matt Rice removed this code in revision 24478. we could just re-add this code or try to find out, why he changed it. The problem is this was three years ago, he might not even remember changing it :-)

Fred Kiefer <FredKiefer>
Project Member
Sun May 16 09:30:15 2010, original submission:

When an item in an outline view is collapsed or expanded, and the selected item is further down in the view than the item being collapsed/expanded, the selected/highlighted row is currently not updated to take the collapse/expand into account.

The selection should be adjusted so that the same item is selected after the expand/collapse, not the same row (unless the selected item was within the collapsed item, in which case there should be no item selected).

Richard Frith-Macdonald <CaS>
Project Member


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by wlux (Posted a comment)
  • -unavailable- added by ratmice (Posted a comment)
  • -unavailable- added by FredKiefer (Posted a comment)
  • -unavailable- added by CaS (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon May 24 20:25:38 2010FredKieferItem GroupNone=>Bug

    Back to the top

    Powered by Savane 3.1-cleanup