[bug #26949] NSTableView missing 'display' after cell selection

[Matt McCutchen-8]

URL:
  <http://savannah.gnu.org/bugs/?26949>

                 Summary: NSTableView missing 'display' after cell selection
                 Project: GNUstep
            Submitted by: tschmielau
            Submitted on: Fri 03 Jul 2009 03:54:19 PM GMT
                Category: Gui/AppKit
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

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.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Fri 03 Jul 2009 03:54:19 PM GMT  Name: NSTableView.m.patch  Size: 281B
 By: tschmielau
patch to fix the problem
<http://savannah.gnu.org/bugs/download.php?file_id=18365>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?26949>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Matt McCutchen-8]

Update of bug #26949 (project gnustep):

                  Status:                    None => Confirmed              
             Assigned to:                    None => FredKiefer            

    _______________________________________________________

Follow-up 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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?26949>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Matt McCutchen-8]

Follow-up Comment #2, bug #26949 (project gnustep):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?26949>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Matt McCutchen-8]

Follow-up Comment #3, bug #26949 (project gnustep):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?26949>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Matt McCutchen-8]

Update of bug #26949 (project gnustep):

                  Status:               Confirmed => Ready For Test        
             Open/Closed:                    Open => In Test                

    _______________________________________________________

Follow-up 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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?26949>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Matt McCutchen-8]

Follow-up Comment #5, bug #26949 (project gnustep):

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!

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?26949>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Matt McCutchen-8]

Update of bug #26949 (project gnustep):

                  Status:          Ready For Test => Fixed                  
             Open/Closed:                 In Test => Closed                

    _______________________________________________________

Follow-up Comment #6:

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?26949>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep