120421 - UI issues with Progress for LDAP Replication dialog

Status: RESOLVED FIXED

(MailNews Core :: LDAP Integration, defect, P2)

Description

[scottputterman]

When we replicate an LDAP Directory we need to show a progress dialog or
progress of some sort.  This may need to be two bugs if we need a bug for the
backend for progress.

Comment 1

[Rajiv Dayal]

If possible, the Progress dialog should be a non modal dialog. This will not
block the user in case if a large file is replicated, specially when all the
records need to be downloaded. This will however require to take care of the
case if the user tries to close Mozilla while the replication is still going on.

Comment 2

[(not reading, please use [e-mail] instead)]

just for completeness, was the dialog modal in 4.x?

as we discussed in rajiv's meeting, we need to make the LDAP replication 
service do the same thing that the compose window does on quit:

put up a dialog asking if the user wants to cancel replication and quit, or 
stop the quit and continue replication.  

again, we should check what 4.x did.

Comment 3

[Srilatha Moturi]

The dialog in 4.x is modeless. In 4.x when the user exists, it brings up a
"Netscape Exit Confirmation" dialog which asks if you want to close all windows,
doesn't matter if replication is being done or not. 

Comment 4

[Rajiv Dayal]

I however think we should do what Seth suggested in comment # 2, better than 4x.
We need to figure out how to stop the quit though.

Comment 5

[Srilatha Moturi]

Moving to 1.0 since I will be checking this in when the rest of LDAP replication 
code gets checked in

Comment 6

[(not reading, please use [e-mail] instead)]

taking, I plan on helping with the UI while srilatha focuses on #78585

We'll need this, and other UI, so that we can land #128086

Comment 7

[Michael Buckland]

Discussed in Mail News bug mtg with Engineering QA Mktng PjM.  Decided to ADT3
this bug. 

Comment 8

[(not reading, please use [e-mail] instead)]

Attachment: screen shot

Comment 9

[(not reading, please use [e-mail] instead)]

For robinf / jglick, see the attached screen shot.

Here are the strings, please let me know how you want the dialog to look and 
what you want the strings to be.

replicationStarted=Replication started...
changesStarted=Started finding changes to replicate...
replicationSucceeded=Replication succeeded
replicationFailed=Replication failed
currentCount=Replicated %S entries so far...
replicatingTitle=Replicating %S

<!ENTITY status.label   "Status:">
<!ENTITY progress.label "Progress:">
<!ENTITY replicationCancel.label "Cancel">
<!ENTITY replicationCancel.accesskey "C">

Comment 10

[(not reading, please use [e-mail] instead)]

other comments / issues:

1) note, the progress dialog is not modal.

2) since the progress dialog is not modal, how will we prevent multiple 
replications?

3) what should we do when the user tries to sync when offline?

4) note, [x] will act like cancel.  

5) Should cancel, and [x] ask the user to confirm?

6) what if the user tries to exit while replication is in progress?  (should 
they be asked to confirm, like we do when sending mail, or composing mail?)

Comment 11

[(not reading, please use [e-mail] instead)]

note, the files for this are checked in.

to try it out, you nee the patch in bug #120427.

Comment 12

[Rajiv Dayal]

Since the replication is happening on main thread having more than one
replication at the same time will be an overkill, the reason i suggested the
dialog box to be non modal earlier was since the earlier plans were to replicate
on a separate thread. Maybe we should make the dialog as modal.

Comment 13

[robinf]

currentCount=Replicated %S entries so far...

Is it possible to have this text include the total # of entries? "Replicated %S
of x entries..." where x is the total?

Comment 14

[jglick]

Attachment: Examples

Suggested dialogs.

No min/max controls.
Buttons usually centered for Windows dialogs.
More space between top of dialog and "Status" text.
More space between "Status" and "Progress" text.
If user tries to exit while replication is in progress, confirm with other
dialog.

Comment 15

[jglick]

>2) since the progress dialog is not modal, how will we prevent multiple 
>replications?
Disable button while replication in progress, or show an information dialog: "A 
replication of this directory is already in progress." OK. Title=ProductName.

>3) what should we do when the user tries to sync when offline?
Info dialog: "You must be online to replicate a directory." OK. 
Title=ProductName.

>4) note, [x] will act like cancel.  
Yup.

>5) Should cancel, and [x] ask the user to confirm?
Probably not. No data loss. They can click the button again if they change their 
mind.

>6) what if the user tries to exit while replication is in progress?  (should 
>they be asked to confirm, like we do when sending mail, or composing mail?)
See dialog in attachment above.

Comment 16

[(not reading, please use [e-mail] instead)]

> Since the replication is happening on main thread having more than one
> replication at the same time will be an overkill, the reason i suggested the
> dialog box to be non modal earlier was since the earlier plans were to 
> replicate on a separate thread. Maybe we should make the dialog as modal.

One good reason to keep the replication progress dialog non-modal is it allows 
the user to do other things (like read email, browse the web) while replicating.

I think 4.x has the same behaviour.

Comment 17

[(not reading, please use [e-mail] instead)]

thanks for the screenshots and the UI suggestions.

I'll work on them soon.

as far as I know, we don't know the total # of entries to be replicated.

If we did know, we could do a real progress meter show real progress, instead 
of just the spinning bar.

note, 4.x has the same limitation, and has a similar UI.

given that we don't know the total, what should the text be?

I can find out what the text was in 4.x, if that will help.

Comment 18

[yulian chang]

Ran Rajiv's builds on Win2K and Linux, a progress dialog shows while replicating
a LDAP Server but no confirmation dialog yet asking if the user wants to cancel
replication or continue replication.
 

Comment 19

[Rajiv Dayal]

> Since the replication is happening on main thread having more than one
> replication at the same time will be an overkill, the reason i suggested the
> dialog box to be non modal earlier was since the earlier plans were to 
> replicate on a separate thread. Maybe we should make the dialog as modal.

> One good reason to keep the replication progress dialog non-modal is it allows 
> the user to do other things (like read email, browse the web) while replicating.

I just meant the dialog to be modal only to the Address Book window, otherwise
the user can exit the Directory properties dialog and start replicating another
directory or even a quick search on another directory. Just disabling the
replication button will not do the trick to stop the user from working with
another directory.

Comment 20

[jglick]

>as far as I know, we don't know the total # of entries to be replicated.
>Given that we don't know the total, what should the text be?

"Replicating directory entry: <X>"

Comment 21

[(not reading, please use [e-mail] instead)]

Attachment: patch with strings changes

here are the string changes we'll need.  the code that uses all of these is not
yet in the product, but we need the strings before the l10n freeze.

Comment 22

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 23

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 24

[Mark Banner (:standard8)]

I believe the remaining issues on this bug were fixed by bug 340560 - Integrate the replication progress dialog into the LDAP directory properties window - Therefore I'm marking this as fixed by 340560.