[Pharo-dev] Don't do this X(

Chris Cunningham 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
showWhile: process.

Progress bars or other non-shared state do seem safer to utilize for core
activities like this.

-cbc


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>
> wrote:
>
> MCWorkingCopyBrowser>>basicSaveVersionIn:
> 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: [[
>  self
>  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...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140403/18a44055/attachment-0002.html>


More information about the Pharo-dev mailing list