83151 - Subscribe dialog should not be modal

Status: NEW

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[timeless]

from bug 57266. my new additional comments in **

i can't understand why this window should be modal. fetching the server 
newsgroups list can be very long on 56K modem and you can't [read mail or news 
while it's being downloaded]. It's not trivial. but it's worth it, because 
fetching the groups list can take something like 5-10 minutes on a modem, and 
this is far too long when you just want to subscribe to one group or a few 
groups.

------- Additional Comments From Seth Spitzer 2000-11-03 07:16 -------
[we made] the subscribe dialog modal [for] simplicity.

making it non-modal would require:

1) prevent the user from launching 2 subscribe dialogs
*this is easy to do*
2) handle the case where the user quits mail, or quits the app while the 
dialogs is up.
*this is easy to do*
3) if the user adds a new account while the subscribe dialog is up, and then 
that new server (if subscribable) has to show up in the server list.
*this is worth doing and shouldn't be too hard to do*
4) update the subscribe / unsubscribe status of a newsgroup (or folder) in the 
subscribe dialog if the user auto subscribes, or unsubscribes from it in the 
three pane.
*this shouldn't be hard to do*
etc.

jglick may be able to add other reasons for (and against) making the subscribe 
dialog non-modal.

------- Additional Comments From [e-mail] 2000-11-03 10:24 -------
I think Seth's points are valid. In addition, the information you enter on the 
Subscription dialog directly affects what newsgroups are displayed in the 
Folder Pane. If the subscribe dialog is modeless, then as soon as the user 
subscribes to a new newsgroup, should it appear in the folder pane? Or not 
until the user has clicked "OK"? Generally in modeless dialogs, actions take 
affect right away.

I don't have a problem going with modeless if folks feel strongly about it, but 
I think we need to have good solutions to these issues if we go this route.

mpt, any comments?

------- Additional Comments From Matthew Thomas (mpt) 2000-11-04 07:25 -------
In 4.x for Mac OS, the subscribe dialog doesn't know quite what it is ... and 
violates the Macintosh HIGs all over the place. [Don't Do That]

I would prefer going for a proper non-modal subscribe dialog (i.e. one with a 
close box instead of `Ok' and `Cancel' buttons). A group would appear/disappear 
in open three-pane windows as soon as the relevant checkbox was 
checked/unchecked in the dialog. A group's checkbox would become unchecked if 
the user chose `Unsubscribe' from the group's context menu in the three-pane. 
And the server menu would update if an account was added/deleted elsewhere. 
Yes, it would be annoying to implement, but it would be nicer for the user.

------- Additional Comments From Ben Bucksch 2000-11-23 06:33 -------
In the long term, I'd like to read my mail, while it downloads the newsgroup 
list.

> 3) if the user adds a new account while the subscribe dialog is up, and then
> that new server (if subscribable) has to show up in the server list.

It would be cool to catch that case, but I don't think that this is necessary. 
There's no problem to close and reopen the dialog in that rare case.

------- Additional Comments From Seth Spitzer 2000-12-18 11:03 -------
marking this won't fix. the current mailnews architecture assumes it is modal.  
making it non-modal will open a can of worms we don't plan to address.

------- Additional Comments From Ben Bucksch 2000-12-18 12:39 -------
Seth, is this a "We won't allocate the resources" or "We don't think, this is a 
good idea in general"? The previous discussion suggests the former, but WONTFIX 
is not the correct resolution for that. Some other contributor might want to 
fix this (OK, unlikely, but still...).

------- Additional Comments From Matthew Thomas (mpt) 2000-12-19 04:12 replying 
to Additional Comments From Seth Spitzer 2000-12-18 13:02 -------
> to clarify, I think that making subscrbie a non-modal dialog is a bad idea.

> subscribe is like new folder and rename folder, which are also modal.
*personally i don't believe these need to be modal either -- i'll file another 
bug later, or there's always ILE -- currently dead*

> when subscribing, renaming or creating folders, you should be blocked from 
the mail application.

> when you launch those dialog, you are basically taking a snap shot of the 
current state of the folders, modifying it, and then applying the change. if 
you make it non-modal, you could make changes which invalidate the snap shot.

That's an implementation flaw, it's not something the user should have to care 
about. The subscribe window and the three-pane window should both be making 
(and listening for) changes to an underlying state, rather than taking 
snapshots of each other.

Word, Photoshop, Excel, and other apps let you open more than one window for 
the same document at the same time. Each window is updated as you make changes 
in the other(s). This is the same situation -- two interfaces are provided for 
doing the same thing (subscribing and unsubscribing), and they should not have 
to lock each other out.

> the account manager and prefs dialog should also be modal for the same 
reason. by making it modal, we simplify the design and the architecture. it's 
not a matter of having the time or resources to make this fix, we shouldn't 
make it at all.

Comment 1

[nnooiissee]

i consider the entire news reader to be flawed (i don't like the subscription
model), but this would make it more useable to me, and i want to use it, not
just to nitpick it.

Comment 2

[[e-mail]]

Doesn't unsubscribing from news servers result in "dataloss" i.e. it deletes the
files with all the info about headers and what you've read?

Comment 3

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 4

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 5

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 6

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 7

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 8

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 10

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 11

[Karsten Düsterloh]

Still sucks! :-(