[Top][All Lists]
[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/
- Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m,
Matt Rice <=