bugGNUstep - Bugs: bug #26949, NSTableView missing 'display'...

 
 

bug #26949: NSTableView missing 'display' after cell selection

Submitted by:  Tim Schmielau <tschmielau>
Submitted on:  Fri 03 Jul 2009 03:54:19 PM UTC  
 
Category:  Gui/AppKit Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  Fred Kiefer <FredKiefer>
Open/Closed:  Closed

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Tue 07 Jul 2009 07:52:00 AM UTC, comment #6: 

Thank you once more for pointing at the problem. Sometimes bug reports are even more helpful than patches :-)

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Mon 06 Jul 2009 02:59:40 PM UTC, comment #5: 

Perfect. Current svn as of rev #28383 indeed seems to have this completely fixed, even if the focus jumps out of the table view.

I think this bug can be closed. Thanks a lot for fixing this!

Tim Schmielau <tschmielau>
Mon 06 Jul 2009 02:25:31 PM UTC, comment #4: 

I think I found the real reason for this problem.

When the text object was getting marked as needing redisplay the invalidated rectangle didn't change (it already was the full view). This resulted in the window that the text object had just moved to not being marked for needing redisplay of its views.
I added a work around for this problem. Perhaps we need more code in other places as well to handle the cases where a view changes its window or its frame.

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Mon 06 Jul 2009 01:17:40 PM UTC, comment #3: 

While testing your changes for bug 26950 (Tab sometimes jumps to wrong cell), I figured that my 'fix' indeed isn't sufficient and we need to figure out what's broken with autoupdate:

If you use the tab key to jump out of the table view, it isn't even sufficient to redraw the whole table view, as the new control that needs to be redrawn as having the focus is outside of it. Luckily, your changes for 26950 now seem to prevent this jumping out, so for now we at least have a working solution.

Tim Schmielau <tschmielau>
Sun 05 Jul 2009 10:01:42 AM UTC, comment #2: 

Thanks, Fred, for looking into this.

I should have added that this is the first time I look into the GNUstep code base, and thus the patch not necessarily is the right fix.

However, just adding setNeedsDisplay: is not enough to fix the problem. Obviously, it has already been (correctly) called, as otherwise a call to displayIfNeeded would not fix the problem.

I don't know enough in general about where the calls to displayIfNeeded should be placed.

Tim Schmielau <tschmielau>
Sun 05 Jul 2009 09:28:47 AM UTC, comment #1: 

Thank you for this bug report. I was able to reproduce this behaviour in Gorm.

I think there really is an issue here, but we need to think about it a bit more. Your suggested solution to add a call to  displayIfNeeded is not what we should do here. Any direct call to display is something that should be avoided as much as possible in all the gui classes. display causes an imediate redraw of the full gui object and this might be rather heavy. What we prefer to do is call setNeedsDisplay: or even better setNeedsDisplayInRect:. But in this specific case it is not the table view that needs to display itself. What needs to get redrawn is the text editor that is used to display (and edit) the selected cell. Your call causes that to display as it is a sub view of the table view. But normally the code that sets up the editor should already mark it as needing a redisplay. So there must be something in that process which messes up. Most of the code is in NSCell _setupTextWithFrame:inView:editor:delegate:range: if you want to have a look.

As a cheap solution, we could just display the text object at the place, where you added the display of the table view, but even that would be wrong. If the whole mechanism of autodisplay is broken, we have to fix that and not just work around it.

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Fri 03 Jul 2009 03:54:19 PM UTC, original submission:  

NSTableView misses a 'display' when a new cell is selected, which is highly confusing for the user who thinks he cannot edit the table data.

The attached patch fixes the problem.

Steps to reproduce:
Open anything that uses a NSTableView, e.g. create a window with a NSTableView inside and go to interface testing mode.
Double click on any cell.
Double click on another cell. It does not get selected as it should.
Now type something. The cell does get edited, even though the selection was not highlighted.

Tim Schmielau <tschmielau>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #18365:  NSTableView.m.patch added by tschmielau (281B - application/octet-stream - patch to fix the problem)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by tschmielau (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-07-07 FredKiefer StatusReady For Test => Fixed
        Open/ClosedIn Test => Closed
    2009-07-06 FredKiefer StatusConfirmed => Ready For Test
        Open/ClosedOpen => In Test
    2009-07-05 FredKiefer StatusNone => Confirmed
        Assigned toNone => FredKiefer
    2009-07-03 tschmielau Attached File- => Added NSTableView.m.patch, #18365

    Back to the top


    Powered by Savane 3.7