A little MC patch

It's always annoying for me, having UI irresponsible during opening
HTTP repository.
Consider this little patch, which is opening repository in a forked
process, and shows a morph when it's done.
I don't know, maybe changing the cursor to hourglass during opening
would be even more convenient, so user will not panic, that by
clicking on 'open' nothing is happens.
In anyway, even in given variant, it feels much better for me than
having a locked UI and waiting for unknown term, when it will complete
operation.

--
Best regards,
Igor Stasenko AKA sig.

Sorry, for flooding ;)
In ideal, it should behave like following:
when you clicking 'open', a cursor changes to hourglass (but only when
you hovering over MC main window), and also all actions are disabled
until operation complete.

But that may require some extra patching.

--
Best regards,
Igor Stasenko AKA sig.

Hi Igor,

could you please fill a bug report on mantis? This is the preferred
way of improving things. You should also consider sending a mail to
Keith Hodges who did a lot of work on Monticello.

On Feb 13, 2008 11:56 PM, Igor Stasenko <[hidden email]> wrote:


--
Damien Cassou

Done,
http://bugs.squeak.org/view.php?id=6926

I thought a bit about better behavior another day,
and i think, the best should be to show repository browser tool and
start downloading in background.
A repository window, while downloading should reflect somehow, that
it's currently busy and upon finish, it should update contents with
results available.
Same when clicking on separate package in list:
- it should lock all operations (so i still can move/resize window but
can't invoke any operations) and show that there is operation pending,
and again, upon completion show update contents of window.
As variant, it can allow multiple background operations:
- often i miss and clicking package with wrong version, resulting in
waiting multiple seconds until it will let me click on another
package.
With background downloading this limitation can be removed - by simply
terminate the background process and start over the new one (of course
i only suggesting, i'm not sure if it's safe enough to do in that
way).

On 14/02/2008, Damien Cassou <[hidden email]> wrote:

--
Best regards,
Igor Stasenko AKA sig.

Do you block people changing methods in their image with a separate
browser?  It is my understanding that this was the purpose for letting
the GUI just block: to make sure no one could edit methods while in an
odd state.

On Thu, Feb 14, 2008 at 8:29 AM, Igor Stasenko <[hidden email]> wrote:

On 15/02/2008, Jason Johnson <[hidden email]> wrote:
> Do you block people changing methods in their image with a separate
> browser?  It is my understanding that this was the purpose for letting
> the GUI just block: to make sure no one could edit methods while in an
> odd state.
>
No, all these no-locks only in places where no code modification
performed, and therefore no need to lock UI.

--
Best regards,
Igor Stasenko AKA sig.

Sorry, I didn't parse that (too many "no"'s I think :).  The GUI
doesn't actually lock does it?  It shows a status bar while it's
working doesn't it?  But if the MC system works by (a) looking at the
current state of the system and then (b) applying what is missing to
bring the system up to date then it is important that no modifications
to any methods are allowed until the whole operation is complete.

On Feb 16, 2008 2:33 PM, Igor Stasenko <[hidden email]> wrote:

On 16/02/2008, Jason Johnson <[hidden email]> wrote:
> Sorry, I didn't parse that (too many "no"'s I think :).  The GUI
> doesn't actually lock does it?  It shows a status bar while it's
> working doesn't it?  But if the MC system works by (a) looking at the
> current state of the system and then (b) applying what is missing to
> bring the system up to date then it is important that no modifications
> to any methods are allowed until the whole operation is complete.
>

- when you opening remote repository, no need to lock UI, right?
- when you downloading package to package cache, again, no locking is necessary

only when you updating the code from package, it may require locking
UI (which is questionable).

It's really hard to say where regular code ends, and code which
modifies classes/methods starting, it's smalltalk at the end.

Also, in real, a UI is not locked while updating image with package,
to be precise, UI is locked because this process performed in UI
process. Nothing prevents you (and MC) from calling different UI
methods while performing update, actually showing a progress bar
during update illustrating that the UI is involved during update.

Also, don't forget, that at any time, higher priority process can
interrupt MC at any time and nothing prevents it to update display or
modify system (classes/methods).

So, locking UI when MC loading package really buys nothing. What its
does is actually making users pissed.
It's not buys any safety, the only way how to ensure it, is to run
updates exclusively, making sure that no other process can interrupt
update until it's fully finishes
(which in own turn brings us to the issue with suspend/resume to be
able do this, read http://bugs.squeak.org/view.php?id=6822 for
details).

I'm already proposed earlier, to add option to MC, to be able to load
package silently, without involving any UI. Simply to make MC be less
dependent from the big amount of code located in image (Morphic)
during update.

--
Best regards,
Igor Stasenko AKA sig.