62011 - UI: Subscribe Dialog - Statusbar should be at bottom of dialog

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[jglick]

In the Subscribe Dialog, the statusbar should be at the bottom of the dialog,
(like Search dialog) and not above the OK and Cancel buttons.

Comment 1

[jglick]

Add mail3 keyword so considered for 6.5.

Comment 2

[jglick]

Are OK and Cancel even valid here? Does Subscribing/Unsubscribing to a newsgroup 
perform the action immediately, or does the user need to click OK for the action 
to occur? Does Cancel really cancel actions the user has performed?  

Comment 3

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

Yes, ok and cancel are valid.

the changed don't take effect until hit ok.

if you hit cancel, any changes you made will not take effect.  4.x behaved like
this, too.

accepting.  jglick, can you add a link to the spec that shows where the status
bar should be?

Comment 4

[jglick]

No updated spec yet, but I'll attach a picture.

Comment 5

[jglick]

Attachment: Subcribe dialog

Comment 6

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

shouldn't the ok and cancel buttons be centered?

Comment 7

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

attaching patch, ccing the big boys for a code review.

Comment 8

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

Attachment: fix, please review

Comment 9

[jglick]

As for the centering, we seem to be inconsistent on that one. On Windows, the 
Search Mail Dialog, Filters dialogs, Prefs, Account Settings, Mail Password and 
others have the buttons at the bottom right aligned.  But other dialogs such as 
the "Find in this Page" dialog, have them centered.  On Mac we seem to do right 
aligned. I asked Paul Hangas about this and he said Ben G would be the one to 
ask.

Comment 10

[Scott MacGregor]

sr=mscott

Comment 11

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

fixed.

Comment 12

[[e-mail] (gone - use [e-mail] instead)]

VERIFIED on Windows 2000120720, Mac 2000120708, and Linux 2000120721.

Comment 13

[jglick]

Reopening, see attachment below.

Comment 14

[jglick]

Attachment: current subscribe dialog

Comment 15

[jglick]

Statusbar at bottom.
http://www.mozilla.org/mailnews/specs/subscribe/images/Subscribe1a.gif

Comment 16

[andreww]

taking off Seth's plate.

Comment 17

[andreww]

waiting for hewitt's changes to <dialog> - to allow for explicit buttons- so I 
can place the statusbar under it.

Comment 18

[andreww]

Attachment: changes to subscribe.xul

Comment 19

[andreww]

patch ready for review. 

Comment 20

[shliang]

Comment on attachment 60717 [details] [diff] [review]
changes to subscribe.xul

r=shliang

Comment 21

[Joe Hewitt (gone)]

Comment on attachment 60717 [details] [diff] [review]
changes to subscribe.xul

sr=hewitt

Comment 22

[racham]

r=racham.

Comment 23

[andreww]

fixed

Comment 24

[jglick]

:-D

Comment 25

[[e-mail] (gone - use [e-mail] instead)]

I'll spin up a new bug about the lack of vertical bars separating the offline
status indicator from the progress meter, but this bug itself is fixed:

RedHat 7.2 - 2002-01-11-08
Windows 2K - 2002-01-11-03
Mac OS X 10.1.2 - 2002-01-11-08

Verified FIXED.

Comment 26

[[e-mail]]

Should dialogs have a statusbar at all? After all they have default padding
which makes the statusbar look odd compared to windows.

Comment 27

[Blake Ross]

Why was this done?  I remember moving it to under the tree a long time ago. It 
looks considerably better attached to the tree, where it is everywhere else in 
the product.  It looks very awkward to not have the OK and Cancel buttons at 
the very bottom of the dialog. And what about the status applies to the OK and 
Cancel buttons?  The status is specific to the population of the tree.  I'm 
looking at this in Classic and I can't imagine seeing a dialog like this in 
another product, so I'm going to be a big jerk and reopen this for a bit more 
discussion :-)

Comment 28

[andreww]

I could go  either way - this dialog seems like a hybrid anyway..  it's very 
complicated for a modal dialog but do you want the user keeping it up with 
out dismissing it?  

I think this dialog should behave more like the  "search messages"  
dialog - which has no ok/cancel and is non-modal.

Jennifer - what was your original reasoning?

Comment 29

[andreww]

Attachment: view of subscribe in mac classic skin

yeah it does look yukky in mac classic.

Comment 30

[andreww]

Attachment: old subscribe dialog from 4.x w status next to ok cancel

Comment 31

[jglick]

Attachment: 4.x - Status bar at bottom

4.x had it at the bottom. It seemed out of place to me, floating above the
buttons. Blake, I thought its location was an error, I didn't know you did this
on purpose. Any window in the product that has a statusbar, the status is at
the very bottom. But this is a dialog so it makes things less clear. If people
agree it looks worse at the bottom, we can switch it back.

Comment 32

[andreww]

what if we slid the status bar to the left and made room for the ok cancel 
buttons? then the status bar would be closer to it's tree and you'd still 
have the ok cancel buttons in the right place. -- plus remove some of the 
extra cruft from the status bar perhaps.

Comment 33

[timeless]

ok, really outside the box suggestion: could we put the subscribe options into 
the content pane instead of fighting over this awkward dialog?

Advantage H: status bar is where it always is.
I: no modal window

some art to show what i'm thinking:

+----------------------------------------------------------+
|_Mozilla_Messenger____________________________________.O_X|
| File Edit                                                |
>----------------------------------------------------------<
| Back Forward Reload Stop                                 |
>------------------v---------__________--------------------<
|_Folders__________|/Server\|Newsgroups|/Offline\__________|
|-pop.sample.net   ||( )All (*)Search ( )New               |
| o Inbox          ||Newsgroup: [ ne                    ]  |
|-news.aol.com     |>----------------------------v-v-------<
| o aol.im.beta    || Name                      A|o|Count|W|
|>news.mozilla.org<|>----------------------------+-+-------<
| o m.inspector    ||mozilla.derivatives.netscape| | 593 |^|
| o m.mail-news    ||mozilla.mail-news           |.|7108 | |
| o mozilla.reorg  ||mozilla.networking          | |1327 |X|
|------------------||mozilla.networking.qa       | | 479 | |
| Add Server       ||mozilla.newideas            | |6829 |v|
+------------------^--------------------------v------------+
| Status: Loading newsgroup 15/89             |        $ U |
+---------------------------------------------^------------+

Comment 34

[[e-mail]]

> Any window in the product that has a statusbar, the status is at
> the very bottom. But this is a dialog so it makes things less clear. 

Yeah, make your minds up (or get mpt to do it :-)

Personally I prefer the old position of the progressmeter and statusbarpanel,
but since statusbars (will) have resizer grippies they are not suitable for
dialogs, only for windows, although you can just stick the meter and panel into
an hbox.

If you do leave the explicit buttons please put default="true" on the OK button.

Comment 35

[Matthew T (active 1999-2002)]

> Yeah, make your minds up (or get mpt to do it :-)

Waah, why do I always get the sordid problems?

This problem exists for two reasons. Firstly, bug 57266 isn't fixed. The reason 
this is a dialog in the first place is because the back end doesn't allow you 
to make a change in the Subscribe window and have it immediately reflected in 
any open three-pane windows, and vice versa. This is akin to showing a folder 
window in your file manager (e.g. `My Documents') as a dialog, because some 
other window happens to be showing the same folder at the same time and you 
don't want them to get out of sync. That's not insurmountable; it's just a 
silly architecture bug.

Secondly, faced with the constraint that this window had to be a dialog, 
whoever designed it tried to make it look like a non-dialog window anyway. As I 
said in bug 42090 comment 10, such attempts always end in tears -- the dialog 
in 4.x looked yucky, and the current one is even worse. Document windows and 
utility windows may have status bars; dialogs, as I said in bug 95929 comment 
5, never should.

So, the easy fix for this bug is to get rid of the status bar (fixing bug 95928 
and bug 95929 in the process), to make the dialog really look like a dialog. To 
show progress in loading the folder/group list, use text and/or spinning arrows 
(like we use for sidebar panels) above the top right corner of the list, which 
disappear when the list is complete.

Available groups:                    48 % loaded (\)
+-------------------------------+--------+-------+-+
| Group                         | Unread | Total |H|
+-------------------------------+--------+-------+-+
|                               |        |       |A|

While you're at it, please fix the order of buttons on the Mac -- it should be
( Cancel ) ((  OK  )), not (  OK  ) ( Cancel ).

The long term, and much preferable, solution is to fix bug 57266. Then this 
window could be cleaned up along the lines of bug 83763, and it could indeed 
have a status bar, though it would still probably look better without one.

Comment 36

[andreww]

MPT: You're right the ok/cancel buttons are indeed reversed. Which that 
alone is enough in my opinion to reopen this and Ill fix that.

ALL: Before we(I) make 10-20 iterations of this in XUL, please come up 
with a screenshot that has approval from relevant parties.  When the 
iterations dust settles from that I'll implement whatever screenie is 
decided upon.  Thanks!
 
Meanwhile I'll go ahead and fix the reversed ok/cancel buttons in a new 
bug and mention that bug here.

Comment 37

[andreww]

Ok separate bug for ok/cancel issue filed   - patch forthcoming for that 
aspect at least.

http://bugzilla.mozilla.org/show_bug.cgi?id=120799

Comment 38

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

> ALL: Before we(I) make 10-20 iterations of this in XUL, please come up 
> with a screenshot that has approval from relevant parties.  When the 
> iterations dust settles from that I'll implement whatever screenie is 
> decided upon.  Thanks!

Since we're following her spec, wait for jglick to process all the suggestions 
and update the spec before hacking away.

Comment 39

[scottputterman]

I agree with Seth. The current spec has it at the bottom.  It looks like the
arguments for different ways of showing status have been given.  It's up to
Jennifer to decide if she wishes to change it.  If not, then we'll close this
bug after Andrew fixes the OK/Cancel buttons on the Mac (unless someone wants to
file a separate bug on that).

Comment 40

[Lori Kaplan]

approving nomination. Andrew figured out how to put the status bar next to the
buttons. 

Comment 41

[andreww]

Attachment: new appearance with latest patch

Comment 42

[andreww]

Attachment: new patch

the dlgtype buttons in this patch are  hidden  otherwise two sets of ok-cancel
buttons appear because this is a dialog window. If I  remove  them alltogether,
another set of ok  cancel buttons appears due to  the dialog binding.  This
patch allows the status bar and the ok cancel buttons to coexist on the same
horizontal  space and satisfies the need for the status bar to be positioned
close to the tree it  is  associated with, while also allowing the ok cancel
buttons to appear where they need to be as well. this patch also fixes the bug
120799.

Comment 43

[[e-mail]]

Comment on attachment 70242 [details] [diff] [review]
new patch

That --> looks wrong.
The align="right" that was there before looks wrong.
The extra boxes and offline indicator look wrong.

Comment 44

[andreww]

good feedback ! Looks like I should make a simpler progress meter 
without the extra boxes.

Comment 45

[andreww]

Attachment: classic subscribe panel with v2 changes

Comment 46

[andreww]

Attachment: modern subscribe panel with v2 changes

Comment 47

[andreww]

Attachment: new v2 patch

Comment 48

[andreww]

ok - new and improved patch there. Jen - does this look ok?

Comment 49

[andreww]

I'm not expecting to get a r/sr by end  of the day, so I'm moving this to 1.0 
but it'll be hopefully ready for checkin as soon as the tree reopens.

Comment 50

[jglick]

Looks much better. Blake, you ok with this solution?

Comment 51

[[e-mail]]

Comment on attachment 70392 [details] [diff] [review]
new v2 patch

Is there any chance that you can turn off the additional status bar elements in
chrome, rather than hiding them in skin? My idea is as follows: Don't overlay
mailWindowOverlay.xul, it's got tons of irrelevant junk in it which produces at
least two JS errors because you're not really a mail window. Instead, just
include the two relevant <statusbarpanel>s, the progressmeter and the status
text.

Comment 52

[andreww]

ok - I can try that out.  I did try that before with strange results, but ill try it 
w/o the overlay.  

Comment 53

[[e-mail]]

Attachment: subscribe.xul but without mailWindowOverlay.xul to get rid of JS errors

Andrew, I hope this is useful, this subscribe dialog has an explicit status
bar.

Comment 54

[andreww]

Ill take a look at it. I'd need to modify that version to get the ok/cancel
buttons back in the right location.

Comment 55

[andreww]

Attachment: new v3 patch

Ok new patch - removes redundant dlgtype - hidden buttons, moves the buttons to
the platformoverlay where they belong, and simplifies the css.

Comment 56

[Joe Hewitt (gone)]

Comment on attachment 71395 [details] [diff] [review]
new v3 patch 

dialogOverlay.xul is completely deprecated.  If you've already converted to
<dialog>, you shouldn't be overlaying dialogOverlay.xul to begin with.

I see that there is a need to extend <dialog> so that we can do custom button
layouts while maintaining platform-specific button arrangements (mainly for mac
vs. windows).  A thought that comes to mind is a new tag called <dialogbuttons>
which you can place within your dialog to get the platform-specific button set.
 Children of this tag would be inserted wherever the platform xbl thinks it
should go.  Andrew, can you hack up this change into dialog.xml ?

Comment 57

[[e-mail]]

Possible alternative: modify the dialog binding so that <statusbarpanels> are
inserted into an appropriate place: by default before all of the buttons, but on
the mac as children of the <spacer> (after changing it to a <box> of course :-)

Comment 58

[andreww]

Ok - I like the dialogbuttons idea because it's much more likely to get 
used  in other contexts than progress meters. Plus progress meters are 
more like "content" in a dialog, whereas virtually all dialogs have some 
form of ok/cancel buttons. I'll make another patch and post it here soon. 

 

Comment 59

[andreww]

Attachment: changes to subscribe.xul

I'm reverting this dialog to it's previous state with some cleanups in order to
fix the button reordering issue.  Making such a huge change to dialog.xml just
for one dialog seemed like a good idea at the time but after pouring over the
code i'm seeing that it'd be way more complicated than simply avoiding having
to have the progressmeter right next to the ok/cancel buttons.	 

So in the interests of	time and getting lots of bugs fixed for machV instead
of spending alot of time on this one alone, I've opted for a simpler patch
which does just about the same thing without having to patch dialog.xml, and
several other files which might destablize  all dialogs for the sake of this
one.   Here's the patch.   Ironically it's alot like the dialog was originally.

Comment 60

[andreww]

Attachment: screenshot of patch in action

screenie

Comment 61

[Håkan Waara]

Comment on attachment 75259 [details] [diff] [review]
changes to subscribe.xul

Insert a <separator class="thin"/> (i.e. a small vertical space) between the
tree and the OK/Cancel buttons, and r=hwaara.

Comment 62

[[e-mail]]

Attachment: Any chance of some extra cleanup?

This patch is basically a diff of my attachment 70785 [details]
but with an extra <row> as per attachment 75259 [details] [diff] [review]
and an extra <separator class="thin"> as per comment 61.

Comment 63

[andreww]

sure - I added the elements to the final version. 

Comment 64

[David :Bienvenu]

Comment on attachment 75371 [details] [diff] [review]
Any chance of some extra cleanup?

sr=bienvenu

Comment 65

[Asa Dotzler [:asa]]

Comment on attachment 75371 [details] [diff] [review]
Any chance of some extra cleanup?

a=asa (on behalf of drivers) for checkin to the 1.0 trunk and bringing the r=
forward to current patch.

Comment 66

[andreww]

fix checked in.

Comment 67

[[e-mail] (gone - use [e-mail] instead)]

Verified FIXED with:

Mac OS 9.2 / 10.1.3 - 2002-03-22-08 Modern and Classic
Linux Mandrake 8.1 - 2002-03-22-08 Modern and Classic
Windows 2000 - 2002-03-22-03 Modern and Classic.