Re: [Bibdesk-develop] let's have a next release (maybe last before 1.0) - any volunteers?

[Michael M. <mic...@ma...>]

In CVS now: I added the additional notification thing to fix this 
performance issue. Seems like it's gone now. let me know if I missed 
anything. (BTW, this patch should also preemptively fix any problems 
with adding long lists of pubs.)

Now I'm working on adding re-sorting after edits.

I reconfigured the project a little more:
the documentation target is now a shell script target.
there is now a "BuildMeFirst" target that builds the OmniFrameworks and 
btparse, so we can do that once and never again.

I also started trying to add Unit test support back in in a way that 
would be all-in-one

By the way, I didn't do the bugfix that way just to be contrary, I just 
wasn't as comfortable with cancelPreviousPerformRequestsWithTarget... 
I'm glad I know about it now though. Sorry if it sounded bad.

-mike

On Feb 27, 2004, at 2:09 PM, Michael McCracken wrote:

> Yeah, the code in handleBibItemAddDelNotification was preliminary at 
> best...
>
> Matt's suggestion works, but I'm partial to a more direct solution 
> that borrows from network programming - letting the handler know 
> directly if it should expect some more actions before doing a local 
> state update. I'll go write that now and we'll see how it goes.
>
> -mike
>
> On Feb 27, 2004, at 12:13 PM, Matthew Cook wrote:
>
>>> Looks like this gets really slow because updateUI gets called after 
>>> each item is deleted in
>>> - (void)handleBibItemAddDelNotification:(NSNotification 
>>> *)notification
>>>
>>> commenting out the updateUI lets me delete all the pubs really fast, 
>>> but the display is screwed up when I undo the delete; the data gets 
>>> undeleted, but the display has be refreshed manually using the 
>>> search field or something.
>>
>>
>> One trick that often solves problems like these is instead of calling
>>    [foo doSomethingSlow:bar];
>> too many times, instead you can call
>>    [NSObject cancelPreviousPerformRequestsWithTarget:foo];
>>    [foo performSelector:@selector(doSomethingSlow:) withObject:bar 
>> afterDelay:0.0];
>> as often as you want.
>>
>> This is perfect for things like a UI update, where many things can 
>> trigger it, but you only need to do it once no matter how many times 
>> it was triggered, and doing it can wait until the current thread pops 
>> back up to the main event loop.
>>
>> In the old days you could do this more simply with
>>    [foo perform:@selector(doSomethingSlow:) with:bar afterDelay:0 
>> cancelPrevious:YES];
>> but I'm not seeing this in the documentation now.
>>
>> I haven't looked into the situation you are describing, so I can't 
>> guarantee this is an appropriate thing in this circumstance.
>>
>> -Matthew Cook
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>> Build and deploy apps & Web services for Linux with
>> a free DVD software kit from IBM. Click Now!
>> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>> _______________________________________________
>> Bibdesk-develop mailing list
>> Bib...@li...
>> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
>>