Mudlet freezes while loading a profile, providing no user feedback or progress

Bug #1254364 reported by Vadim Peretokin
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mudlet
Opinion
Medium
Stephen Lyons

Bug Description

Mudlet can freeze while loading a real-world profile, providing no user feedback or progress - which is quite bad because the user is stuck wondering if it's working at all or not.

GNOME HIG (https://developer.gnome.org/hig-book/3.0/hig-book.html#controls-progress-bars), Apple HIG (https://developer.apple.com/library/mac/documentation/userexperience/conceptual/applehiguidelines/Controls/Controls.html) Windows HIG (http://msdn.microsoft.com/en-us/library/windows/desktop/bb760816(v=vs.85).aspx) all recommend showing some kind of a progress bar when the task is taking more than a few seconds in general.

Attached a video where Mudlet freezes and provides no experience to the user while the profile is loading - first freeze is from 0:13 to 0:24 (11 seconds!), second is from 1:07 to 1:17 (10 seconds!).

Revision history for this message
Vadim Peretokin (vperetokin) wrote :
Revision history for this message
Stephen Lyons (slysven) wrote : Re: [Bug 1254364] [NEW] Mudlet freezes while loading a profile, providing no user feedback or progress

I agree. For example, that sample map with problems takes a LONG time
to load and if I didn't have the QT Creator IDE application output
displaying stuff I'd be wondering what was happening just during the map
restoration part involving that map (and even then the 40K room
wilderness area produces no debug output for many seconds partway though
Mudlet digesting it). Either we should produce a (one, or two level
(level 1 = stage, level 2 = progress in THAT stage)) dialogue - modal
for that host/profile - or we could use the (currently unused ?) status
area area at the bottom edge of the main window...

On 24/11/13 01:01, Vadim Peretokin wrote:
> Public bug reported:
>
> Mudlet can freeze while loading a real-world profile, providing no user
> feedback or progress - which is quite bad because the user is stuck
> wondering if it's working at all or not.
>
> GNOME HIG (https://developer.gnome.org/hig-book/3.0/hig-book.html
> #controls-progress-bars), Apple HIG
> (https://developer.apple.com/library/mac/documentation/userexperience/conceptual/applehiguidelines/Controls/Controls.html)
> Windows HIG (http://msdn.microsoft.com/en-
> us/library/windows/desktop/bb760816(v=vs.85).aspx) all recommend showing
> some kind of a progress bar when the task is taking more than a few
> seconds in general.
>
> Attached a video where Mudlet freezes and provides no experience to the
> user while the profile is loading - first freeze is from 0:13 to 0:24
> (11 seconds!), second is from 1:07 to 1:17 (10 seconds!).
>
> ** Affects: mudlet
> Importance: Undecided
> Status: New
>
> ** Attachment added: "Screen Capture Tool_2013-11-24 00.56.50.mov"
> https://bugs.launchpad.net/bugs/1254364/+attachment/3915681/+files/Screen%20Capture%20Tool_2013-11-24%2000.56.50.mov
>

Stephen Lyons (slysven)
Changed in mudlet:
status: New → Confirmed
importance: Undecided → Medium
Stephen Lyons (slysven)
Changed in mudlet:
assignee: nobody → Stephen Lyons (slysven)
Revision history for this message
Stephen Lyons (slysven) wrote :

As we have added messages to the screen at the beginning and end of map file loading and have made progress with the "Unpacking module/package" widget that pops up whilst modules/packages are being installed into a profile I believe this is less of an issue now.

I do have a suspicion that the message at the start of map loading may not be put up at the time it is generated but not until the end so that all the map loading messages are not displayed until it has completed. If I can confirm this then I think another tweak will be needed {adding qApp->processEvent() calls after some of the Host::postMessage(...) one} but I will need to check for this first.

Whilst this bug does have some linkage to https://bugs.launchpad.net/bugs/1413069 that is specific to module/package installation which was only part of this issue so I think it is not correct to mark this as a duplicate of the latter and so am un-tagging it as one.

Revision history for this message
Vadim Peretokin (vperetokin) wrote :

Migrating issues to Github, please follow the new discussion here: https://github.com/Mudlet/Mudlet/issues/487

This issue needs to be closed and there is no appropriate status, so will set it to "Opinion" just for migration purposes.

Changed in mudlet:
status: Confirmed → Opinion
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.