Open Bug 184231 Opened 22 years ago Updated 3 years ago

"view" dropdown should include "Watched"

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

x86
Windows 98
enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: Biesinger, Unassigned)

References

(Depends on 2 open bugs, Blocks 2 open bugs)

Details

It would be nice if the new View dropdown list would contain "Watched Threads",
so that you could easily show only watched threads.
Flags: blocking1.3a?
Flags: blocking1.3a? → blocking1.3a-
I'm not sure all the details have been worked out where Watched will appear...
spec not final yet.  http://www.mozilla.org/mailnews/specs/views/
QA Contact: olgam → laurel
I'm a little confused, as the reference doesn't clarify what _is_ shown in the
Views dropdown.  But my inclination would be that it would show the same options
as View -> Messages rather like Outlook Express, in which case bug 73562 would
be the key.

If selecting which messages to view and which threads to view are going to be
separated, then it would make sense for custom views to be able to set both
simultaneously.  My idea would be that, once message criteria have been
specified, a thread viewing option would be "only", "threads with" or "threads
containing only".
Depends on: 73562
Stewart, comment #2 made no sense to me at all. Could you provide a sketch, like
this (from bug 73562):

| View |
+------------+
| Show/Hide  |
| Sort by    |+-----------------------------+
| Messages  >|| All                         |
| ...        || Unread                      |
              | Threads with unread         |
              | Watched Threads             |<-----This one !!!
              | Watched Threads with Unread |
              +-----------------------------+
Are you talking about my first paragraph or my second?

If the first, then I can't really draw a sketch as the page doesn't show a picture of the 
expanded Views dropdown for me to draw an improvement of.  But it would probably 
look similar to your sketch.

The second paragraph isn't related to bug 73562, but a separate idea that probably 
ought to be brought up as a separate RFE.  Basically:
 
____________________________________________________________________
_____________
|Message View Setup                                                               |
|---------------------------------------------------------------------------------|
| Message view name: [Untitled 1]                                                 |
|                                                                                 |
| When this view is selected, display [ only                   v] messages that:  |
|                                     +-------------------------+                 |
|                                     | only                    |                 |
|                                     | threads containing      |                 |
|                                     | threads containing only |                 |
|                                     +-------------------------+                 |
|                                                                                 |
 
~~etc.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~
So is this bug and 73562 duplicates of each other?  It kind of seems that way.
Not yet.  They'll be the same once bug 189543 is fixed.
I don't think they will be duplicates. The Searchbar "View" will be *added* to
the already existing items under View | Messages. Actually, since the Searchbar
"View" menu is mostly for "custom" views, I suspect that the current "All" and
"Unread" will be handled by the existing "View | Messages" entries, and this bug
will be WONTFIXed (because bug 73562 is older than this one).

Thus the future merged "View | Messages" might look like bug 189543#c17

PS. We might need to add a menuitem to accomodate the mass of submenuitems
(takes cover).

View
 ....
 Sort by
 Messages
 Threads     <-- this one
 ...
I've seen that idea before, but the way I've seen it doesn't seem logical.  Guess one way it 
could be broken up is something like Standard Views, Custom Views, Labels, Options or 
something along those lines.
Blocks: mailviews
Blocks: 214286
Depends on: 218208
I'm not sure what should be done with this bug.  The View menu has been 
restructured as described in comment 7.  However, threaded views are not part of 
the MailViews dropdown; until such point as bug 135326 is addressed, it seems 
unlikely that they will be.

Bug 207862 is an RFE requesting that all threaded views be integrated into the 
MailViews dropdown.  Bug 218208 is an RFE requesting that the Watch/Ignore 
status be available when defining a MailView, but doesn't specifically ask that 
the results be threaded.  It seems to me that this bug is a dupe of one of 
these.
Blocks: newsviews
No longer blocks: mailviews
Product: Browser → Seamonkey
Assignee: sspitzer → mail
This bug applies to Thunderbird as well!

If bugs apply to Thunderbird *and* Seamonkey at the same time, do there have to be separate reports for *each* application? Seems to me, as bug 73562 is for Seamonkey, bug 294901 is for Thunderbird.
Mike in comment #9
> I'm not sure what should be done with this bug.  The View menu has been 
> restructured as described in comment 7.  However, threaded views are not part of 
> the MailViews dropdown; until such point as bug 135326 is addressed, it seems 
> unlikely that they will be.

since bug 135326 was fixed by bug 263180, should something be happening? :)
 
should this or bug 218208 be duped to this or something else? (bloody messy maze of dependencies here)
> should this or bug 218208 be duped to this or something else?

I'd dupe this to bug 207862, just to consolidate; but to me the ideal solution is implementing bug 218208, along with bug 197620 (which encompasses Stewart's comment 4).  But I wouldn't bet that any of this web of enhancing mailviews and/or consolidating View|Threads and View|Messages will ever occur.
This, bug 218208 and bug 207862 are very different proposals.  At the moment this has nothing to do with bug 207862, but will have something to do with it once bug 73562 is fixed.

Even so, if only bug 218208 and bug 197620 (both of which block 207862) are fixed, then it would be straightforward to implement this as a completely separate project from 207862.

Bug 218208 is the most certainly not a dupe of anything, and definitely not a dupe of anything that's been mentioned in this bug's comments.  It's a basic first step towards a handful of enhancements including this one.  Just look at its dependency tree.
Assignee: mail → nobody
QA Contact: laurel → message-display
You need to log in before you can comment on or make changes to this bug.