[Pharo-dev] Don't do this X(
cunningham.cb at gmail.com
Thu Apr 3 15:48:12 EDT 2014
Could it be that one of the processes called from this code is specifically
setting the cursor back to normal? That would defeat the whole Cursor wait
Progress bars or other non-shared state do seem safer to utilize for core
activities like this.
On Thu, Apr 3, 2014 at 12:18 PM, Sebastian Sastre <
sebastian at flowingconcept.com> wrote:
> On Apr 2, 2014, at 12:10 PM, Goubier Thierry <thierry.goubier at cea.fr>
> basicSaveVersionIn: aRepository
> | newVersion waitForVersion |
> waitForVersion := Semaphore new.
> UIManager default defer: [
> newVersion := workingCopy newVersionIn: aRepository.
> waitForVersion signal ].
> Processor activeProcess == UIManager default uiProcess
> ifFalse: [ waitForVersion wait ].
> newVersion ifNil: [ ^ self ].
> Cursor wait showWhile: [[
> storeVersion: newVersion in: aRepository;
> storeDependencies: newVersion in: aRepository.]
> ensure: [ (MCVersionInspector new version: newVersion) show ]]
> It seems asynchronous, but I'm unsure of what it is doing. Progress bar is
> only displayed when doing newVersionIn:, but this is sent to the UIManager.
> And this is done in a fork (see saveVersion), so it's probably allways
> possible to interrupt the thing half-way (or save).
> Anybody to explain what is the objective when writing code like that?
> Good question Thierry.
> I'm sure the cursor was normal during this episode. Suggesting that either
> it wasn't storing the version or it was but not displaying the wait cursor
> as the code suggests.
> Functionally, what sounds to me it should be doing, is overwriting the
> files which is reasonable to take a little. It takes reasonable time,
> that's not the problem. Lack of feedback is the problem.
> So one solution would be to provide a progress bar for that file writing
> process or whatever is doing.
> Having one progress bar for the whole process would be the best solution.
> Plan B would be having 2 progress bars, ending when it really finishes.
> BTW, note that *not* giving control to the user while is saving would
> also prevent this kind of accidents.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev