gnustep-dev
[Top][All Lists]
Advanced

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

Re: [Gnustep-cvs] r27874 - in /libs/gui/trunk: ChangeLog Source/NSCell.m


From: Fred Kiefer
Subject: Re: [Gnustep-cvs] r27874 - in /libs/gui/trunk: ChangeLog Source/NSCell.m
Date: Tue, 17 Feb 2009 10:00:55 +0100
User-agent: Thunderbird 2.0.0.19 (X11/20081227)

Matt Rice wrote:
> On Mon, Feb 16, 2009 at 11:50 PM, Matt Rice <address@hidden> wrote:
>> On Mon, Feb 16, 2009 at 11:43 PM, Fred Kiefer <address@hidden> wrote:
>>> Fred Kiefer wrote:
>>>> I make these changes and you can comment on them.
>>> It turned out that the patch I made had a big problem. :-)
>>>
>>> The new code in itself was correct, but there is a long standing bug in
>>> NSButtonCell #11946 (With a reference to the even older #4635). And as
>>> long as the setXXXTitle: methods on NSButtonCell fall back to
>>> setStringValue: we cannot use setObjectValue: in the method
>>> setStringValue: NSCell.
>>> Looks like we need to fix one bug first before we can work properly on
>>> the other. For now Riccardo has added a work around that will allow
>>> NSCell to operate again. In the long run we should be able to remove
>>> this workaround again.
>>>
>>> Fred
>> Hmm, I believe I had a patch for #11946, the problem was I sent out
>> patches to various maintainers to fix their usage of setStringValue:
>> to setTitle: and succeeded in getting one app fixed (GWorkspace)
>> i'll look around for it.
>>
> 
> attached and updated to head, not sure if it does what you want,
> because it relies on the [super setStringValue:] in -setTitle: and
> reimplements -setStringValue: to manage state.
> 
> note that in gorm i'm seeing "Button" in every scroll view's scroller,
> which leads me to believe there is something somewhere that should be
> using setTitle: in either gorm or gui.. should be easy to track down
> with a breakpoint on NSButtonCell setStringValue: i imagine.
> 
> not really tested very well.

Thank you for the patch! Most of it looks great, what I am a bit worried
about are the changes to call super. When we ever change the super
implementation of setStringValue: to call setObjectValue:, as it should
do per documentation, your implementation will the same problem as the
current one. Looks like we need to copy over part of the implementation
of setStringValue: into the corresponding title methods.

And as you pointed out, we need to make sure callers use the right
interface :-(




reply via email to

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