Hello,
On 2005-03-03 11:19:25 +0000 Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: > > On 3 Mar 2005, at 10:02, Frederico Mu�oz wrote: >> However, and while I, as said, agree with the probable issues that can >> result, what I'm doing now, and without any side effect for now, is to call >> the installPackage on a NSThread and then make the installPackage method >> send a notification each time it does something with a file. Then, in the >> main object, I register it for the notification with the updateProgress >> method. Since I'm not directly dealing with variables between them (what I >> need is simply to be notified, and everything else like the filename can go >> into a NSDirectory and passed inside the notification) I think I'm pretty >> safe, at least while this is the only thing I need to do. The >> updateProgress then deals with the progressIndicator. I've tested this >> approach many times and it works perfectly everytime. Since I'm using a >> notification and not calling an object directly maybe this will help to >> keep the side effects down. > > I don't think this is the right way to do it ... Well, back to the drawing board then... > because I don't think > notifications are guaranteed to be delivered in a particular thread. If you > post them for immediate delivery, they are generally delivered to the same > thread that posts them, and if they are posted in a queue, they are generally > delivered in the first thread to execute a run loop ... which may be what is > happening in your current code, and why it's working. I'm using [[NSNotificationCenter defaultCenter] postNotificationName: @"ProgressShouldUpdate" object: file]. > > The correct way (as I understand it) is to perform the slow install operation > in a second thread, > and at intervals when milestones in the install operation are completed, call > -performSelectorOnMainThread:withObject:waitUntilDone: > with the 'waitUntilDone' flag set to NO. > Ok, this was my previous way of doing things, check for the selector and call it in the installer thread. The only difference is that I'm not using milestones, I'm calling it inside a loop that copies files. The problem for me in setting milestones is that in the .pkg installation process 99% of what is done is "copy files listes in this enumerator to this destination". I could trigger it at intervals, say each time 10 files are copied or something, but wouldn't this work the same way as doing it each time a file is copied? > This lets the main thread run normally during the install, and update the > progress bar at intervals when the installer thread tells it to. Using this > method guarantees that the update > of the progress bar is done in the main thread ... which is the only thread > that it's safe to > perform gui updates in. Well, I'm probably missing something but even using notifications from the installer thread the update of the progress bar is only done in the main thread, or at least that's the way it looks to me. The updateProgress method in the maint thread is the one registered to handle the notification, and it is only there that any UI code is in any way touched. The installer thread doesn't even know about the UI instances being used. I will revert to the previous way of doing things then, while beginning to think that writing "When it's Done It's Done" in a NSPanel will probably be the easiest way to deal with this. Best Regards, fsmunoz -- Frederico Mu�oz [EMAIL PROTECTED] _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
