gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m


From: Matt Rice
Subject: Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
Date: Sat, 31 Dec 2005 06:14:05 -0800 (PST)


--- Fred Kiefer <address@hidden> wrote:

> Enrico Sersale wrote:
> > On 2005-05-28 06:34:22 +0300 Matt Rice
> <address@hidden> wrote:
> > 
> >> --- Enrico Sersale <address@hidden> wrote:
> >>
> >>> On 2005-05-26 16:38:12 +0300 Fred Kiefer
> >>> <address@hidden> wrote:
> >>>
> >>>> CVSROOT:    /cvsroot/gnustep
> >>>> Module name:    gnustep
> >>>> Branch:    
> >>>> Changes by:    Fred Kiefer
> >>>
> >>> <address@hidden>    05/05/26
> 13:38:11
> >>>
> >>>>> Modified files:
> >>>>
> >>>>     core/gui       : ChangeLog    
> core/gui/Source:
> >>>
> >>> NSTableView.m
> >>>
> >>>> Log message:
> >>>>     Improved mouseDown call handling for table
> view.
> >>>>
> >>>>> CVSWeb URLs:
> >>>>
> >>>>
> >>> I think that it would be a good habit to try to
> run
> >>> one or two of the (few) GNUstep applications
> before
> >>> committing changes that can break things...
> >>>
> >>
> >> just to elaborate.. this breaks (at least)
> >> gworkspace's
> >> view->list segfaults when selecting a row.
> > 
> > 
> > Just to be more precise :) ... I'm not referring
> to this; I've fixed it 
> > implementing -copyWithZone: in my cell class when
> I've seen that 
> > gworkspace segfaults trying to release an ivar of
> this class.
> > The real problem is that it is not possible
> anymore to start a drag from 
> > a cell (this is visible in GNUMail, too). Making 
> > -startTrackingAt:inView: to return NO in the cell
> class fixes this 
> > problem too, but I think that there is something
> wrong in -mouseDown: 
> > because, before theese changes, both the apps
> worked well.
> > 
> 
> Enrico,
> It is not always bad to break things. If in this
> case my change showed 
> some memory problem in GWorkspace and GNUMail this
> is a good thing. 
> Provided we are able to fix it before the next
> offical release of 
> course. So there was at least one benefit from
> applying the patch. :-)
> 
> We should work together to track down the actual
> problems and fix them. 
> GNUstep is stil full of hacks to get partial
> functionality working. We 
> need to try to get it correct completely.
> 
> >> anyhow the culprit being cell copy, which was
> added
> >> because NSComboBoxCell caches the cellFrame so it
> can
> >> pop up the window through a NSButtonCell's
> action...
> >>
> >> though it was causing multiple drawWithFrame:
> calls
> >> for the combobox cells with its setNeedsDisplay:
> then
> >> popping up in the wrong place...
> >>
> >> anyhow this seems to work in both cases..
> >>
> 
> Matt,
> You are surely correct about the fix for
> NSComboBoxCell, it should only 
> mark its onlĀ“e frame for a redraw. I am not totally
> convinced about the 
> copy of the active cell in NSTableView. Copying the
> cell also gets done 
> when editing is started for a cell. So cells that
> don't handle it 
> correctly will also pose problems when edited.
> 
> I will test this myself and propably apply it as
> well, to get GWorkspace 
> and GNUMail working again. But my feeling is still
> that there is another 
> problem hidden here, which we need to resolve.
> 
> 

considering that GWorkspace was fixed wrt the cell
copy, not copying the cell introduced a nasty bug, and
GNUMail had a different issue altogether
i recommited this cell copy, and cleared up the
comment. 

to reproduce:
edit a cell,
select the same cell in a different row,
selected cells object value becomes previously edited
cells object value

which has to do with selecting the new cell causing
validation to occur on the edited cell.


        
                
__________________________________ 
Yahoo! for Good - Make a difference this year. 
http://brand.yahoo.com/cybergivingweek2005/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]