[Top][All Lists]
[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 :-(