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

Group
 
 

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

Submitter:  Richard Frith-Macdonald <CaS>
Submitted:  Sun 16 May 2010 09:30:15 AM UTC
   
 
Category:  Gui/AppKit Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 30 Oct 2020 03:48:42 PM UTC, comment #7: 

Per wlux's comment, I am closing this.

Gregory John Casamento <gcasa>
Group administrator
Fri 27 Aug 2010 01:30:48 PM UTC, 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 25 May 2010 12:03:01 PM UTC, 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>
Group Member
Tue 25 May 2010 08:40:07 AM UTC, 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 actually*inside* an item you collapse).

Richard Frith-Macdonald <CaS>
Group Member
Mon 24 May 2010 11:34:24 PM UTC, comment #3: 


Dug through the lists a little, from this thread:
http://lists.gnu.org/archive/html/gnustep-dev/2007-02/msg00003.html

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>
Group Member
Mon 24 May 2010 09:21:46 PM UTC, 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>
Group Member
Mon 24 May 2010 08:25:38 PM UTC, 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>
Group Member
Sun 16 May 2010 09:30:15 AM UTC, 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>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-30 gcasa StatusNone Fixed
        Open/ClosedOpen Closed
    2010-05-24 FredKiefer Item GroupNone Bug

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code