Closed Bug 90466 Opened 23 years ago Closed 23 years ago

[RFE] integrate turbo-mode and mail notify into one tray-icon

Categories

(SeaMonkey :: General, enhancement)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 98
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 97326

People

(Reporter: Peter, Assigned: mpt)

References

Details

(Keywords: helpwanted)

Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2+) Gecko/20010710 [RFE] integrate turbo-mode and mail notify into one tray-icon Since there are numerous requests for both features, it would be silly to have two tray-icons (turbo & mail notify) for one program (Mozilla). It shouldn't be too difficult to have a meaningful logic so these two can coexist in one tray-icon (e.g., context menu: (A) disable turbo mode, (B) disable mail notify, (C) disable turbo mode & mail notify. If a window is open and user selects (A) or (C), the window stays open but without turbo mode).
Depends on: MailNotification, 75599, 81149, 89532
Keywords: helpwanted, mail3, mozilla0.9.3, ui
No longer depends on: 81149
I'd prefer to have separate icons. I don't like having a lot of clutter in my task tray, so I'd rather have a simple mail icon that appears only when I have new mail waiting (as in NN4).
I understand your desire for less clutter. However, the advantage of having the tray-icon always visible is that a CTRL+left-click could trigger a check for new mail; a double-click could launch Mozilla. I suggest a preference to have either behaviour. Keep in mind that if you have turbo mode and turn off the icon, you can no longer turn off turbo mode from here.
yeah, I think noone would turn off turbo mode I once wrote it to netscape when I didn't know much from mozilla *hehe* and that was about 2 years ago and now the feature is in! I like it very much that mozilla is now starting faster then iexplore and if you have turbo mode on you have 1 trayicon there. Now if the tray icons for turbo mode and for mail notification are seperated you would have 2 if you have a mail. And there is the point. It would be better to have 1 integrated trayicon for both turbo mode and mail notification. I think this way there is less clutter then making them seperate!
another thing: if the turbo mode is on mozilla resides in memory without a browser window open. it could then also check for mail itself (for example all 5 mins) and get animated if there is a new mail or something. This way you could leave mozilla closed if you aren't browsing but would also know when you have new mail! And I know many people who would like to find such a feature in Outlook but it hasn't. It also fills a complete TaskBar slot to be able to check for mail periodically. This would really be a neat improvement.
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
I like this idea, though of course the mail notification should work without turbo mode enabled. We really need to have two mutually exclusive system tray icons - one for normal turbo mode and one for when there is new mail. Obviously, the icons should be similar enough so that users can tell that they are from the same application. Also, if it ever becomes possible for the turbo mode system tray icon to be hidden (seems unlikely right now), then the new-mail-waiting icon should still appear when appropriate.
with one integrated tray icon replacing both features there would be no matter if turbo is enabled or disabled! one trayicon should always be there! at least for the mailing things and it could also serve to disable the turbo mode! 2 different trayicons aren't required and are too much i think...
personally i prefer having the behaviors of nsnotify.exe and nc4messenger. in brief for those who aren't familiar w/ them nsnotify was a mail checker application which would spin around while it was checking mail, it would give a red x over a mail image if it couldn't log on and it would wave a flag if you had new mail. double clicking and ctrl-double clicking can be mapped to the following actions: run netscape messenger. check for new mail now. show options. new message. running messenger can either open inbox or message center (* i think mozilla doesn't have message center). right clicking the icon allows: check now. run mail. new message. options, disable checking, exit. nc4messenger would stick an icon in your tray _only_ when you have mail. clicking it brings up mail and I think it will check mail again. both of these approaches work (and both allow for a sound to be played). they are even compatible w/ the recommendations of using the tray as a notification area. I think mpt mentioned that we could use a balloon notification too, which would allow us to indicate how much mail is waiting (how many are really new) and perhaps its size/estimated time to download. Given the recommendations provided by others for the current tray element I don't believe we can provide both their menu and the one from nsnotify (well.. we could have two different menus appear depending on which button you click w/, but i don't think you can trigger both clicks using the keyboard on w2k [w/o enabling mousekeys which should never be a requirement]). reporter indicated w98, this bug applies to windows in general but doesn't apply to other platforms as the turbo mode described here is windows only and all of this code is platform specific [os=>w98]
Assignee: asa → mpt
Component: Browser-General → User Interface Design
OS: All → Windows 98
QA Contact: doronr → zach
The nice thing about the old NN4 mail notification was that it put an icon in the task tray only when there was new mail. Since I'm in the habit of reading mail pretty quickly when it comes in, I almost never had an icon there. I'm not entirely opposed to the idea of merging the two, but the "new mail" and "no new mail" icons needs to be easy distinguishable at a glance, and the icon needs to go away completely if turbo mode is disabled and there's no new mail.
the icon could behave like nsnotify IF tubro mode isn't running. but IF turbo mode is running we would have one icon to exit the turbo mode, plus one icon showing you have new mail, and that's what we could merge couldn't we?
The benefit of having the icon there all the time is that the user has a visual confirmation that there is *something* there at all that is doing something. You know there is a program running, because you can see it. It is nice to be able to glance down there and see "ah, no new mail", instead of thinking "is that mail checking thing running or not?". The user can also CTRL+double-click to force a mail check if he wants to know if there is any mail *now* (especially useful if the mail check interval is long - e.g., 1 hr). Since I am sure this is an issue where people feel strongly both ways, I suggest that the icon have an option to be "always visible" or "only visible when new mail arrives". So the icon could look like this when right-clicked on: +------------------------+ | *Check for Mail* | <-- bold = double click behaviour | Open Messenger | | ---------------------- | | [x] Mail Notify | | [x] Tubo Mode | | ---------------------- | | Options... | | ---------------------- | | Close and Exit Mozilla | <-- brings up warning/info dialogue +------------------------+ +- Options--------------------------------------------+ | | | Check for mail every [ ] minutes | | [ ]If no internet connection [autoconnect |v] | | ----------------------------------------------------+ | Double click does this: [open Messenger |v] | | CTRL + Double click does this: [check for mail |v] | | ALT + Double click does this: [write a mail |v] || ----------------------------------------------------+| Tray icon is visible: | | <+> Always (default) | | < > If turbo mode is on or when new mail has arrived| | < > Only when new mail has arrived | +-----------------------------------------------------+ The main menu should be short and easy to understand.
yeah, that's exactly what I thought of!
Why always talking about having one behavior or the other implemented? What about having an option to choose to display an icon even if there is no mail?
That option is covered by my diagram above ("Tray icon is visible: Always"). It's just that my graph got a little messed up. Here's the cleaned-up version: +- Options--------------------------------------------+ | | | Check for mail every [ ] minutes | | [ ]If no internet connection [autoconnect |v] | | ----------------------------------------------------+ | Double click does this: [open Messenger |v] | | CTRL + Double click does this: [check for mail |v] | | ALT + Double click does this: [write a mail |v] | |-----------------------------------------------------+ | Tray icon is visible: | <-- here | <+> Always (default) | | < > If turbo mode is on or when new mail has arrived| | < > Only when new mail has arrived | +-----------------------------------------------------+
(x) Always annoy tray ( ) Only annoy tray when [ ] turboing |^| [x] new mail arrives |o| [x] calendar event happens | | [ ] IRC privmsg happens | | [ ] AIM message happens |v| [ ] Each annoyance should have a seperate icon All verbage must be changed.
No longer depends on: 75599
Blocks: 75599
As of Nightly 2001072003, the 'Launch Mail/News' icon in the bottom left hand corner now has a down arrow when new mail arrives (without having Mail/News active). If this code is written, could it not be integrated into the code that sits in the background that drives -turbo to fire the new mail notification icon in the SysTray? As for the total number of Icons, I would prefer to only have one icon to display both -turbo and new mail notification. I do however fell we need an additional option for -turbo allowing users to elect whether Mail/News should run in the background - If you don't use mail/news, there ain't any point in it checking for new mail. I reckon this would be a standard prefs option under a -trubo heading (or QuickLaunch as it is now called) ie: +- Quick Launch -------------------------------------------+ | | | [ ] Enable QuickLaunch (Restart stuff...) | | [ ] Check for new mail in background [Select Mailboxes] | <-This is a button +----------------------------------------------------------+ 'Select Mailboxes' button would allow the user to select the mailboxes they want to be checked automatically.
since buttons aren't windowsstyle in context menus (right-click menus) i would suggest to make the menu like this [X] Use turbo mode [X] Check for mail > MailOptions > ----------- > and so on ;)
I was thinking of having these options in the prefs dialog under the root of the Advanced tab. I feel that several of these options are becoming blurred - should they be in the prefs dialog or the context menu from the system tray?? needs glarification holmes...
I would also vote for making the prefs available in the prefs dialog only. But the user should still be able to get to the prefs from the trayicon like this: Check for new mail now ---------------------- [X] Periodically check for new mail (Time changeable in prefs dialog) [X] Turbo mode enabled ---------------------- View Options (leads to pref dialog) View Mail Options (leads to mail prefs dialog) View Tray Options (leads to tray prefs dialog) ---------------------- Exit Mozilla (killing all processes) Also currently we set the mail account settings at another place than the normal preferences. Wouldn't it be better to merge them all into "Preferences"?
I'll add another request related to this stuff : as the turbo mode is by default disabled, "normal" ppl will prolly NEVER know it exists, because it's burried in the prefs screen. Why not propose an activation (among other possible options) to the end user during the installation ?
There is a check box to enable turbo mode during install. It defaults to unchecked and is easy to miss if you're not paying attention, but it's there.
In addition to your comments about indication of turbo mode and new email notification, I'd like to propose one other distinction be made: that one be able to choose whether email is checked at all in turbo mode. The traditional point/view (M$ presumably) of preloading core components is to make loading the app faster, not to have it *running* in the background. I want it for the speed increase, but want mail to be left on the server so I can pop it off from elsewhere should I need to. To me the idea of turbo mode still checking mail is more like "run in hidden mode on boot"... I'm using Mozilla in permanent-ip environments - this could/would be MORE annoying for those with dialup accounts - yes?
*** Bug 95637 has been marked as a duplicate of this bug. ***
RE: Stuart (21-08-2001): Isn't there a way to just *see* if new mail is on the server, without retrieving it? I'm pretty sure the "nsNotify.exe" in Netscape 4.x did it that way. [OT] mpt, this seems to be a very popular feature. Are there any plans to implement it in the near future (<1.0)?[/OT]
Keywords: mozilla0.9.3 → mozilla0.9.4
Yes, Peter. I'm going to implement this just as soon as I earn enough to buy a PC and a copy of Visual Studio, and then teach myself how to program in C++, and then become familiar with the Mozilla code. All that should take only five or six years, so there will be plenty of time to implement this RFE before 1.0 is released. It's a shame, really. This RFE, as originally filed, was pretty simple and made a fair amount of sense. But then the bug report was rapidly filled with crap by people who appear to be under the mistaken impression that Bugzilla's main role is a discussion forum (it's not), that ordinary computer users are interested in minute configurability of left- and right-clicking on system tray icons (they're not), and that a hundred different enhancements are routinely magically implemented as part of a single bug (they're not). So if I reassigned this bug to a programmer, they'd start whimpering and chewing their fingernails trying to work out what it was they were supposed to be implementing. So rather than mark this bug INVALID, which is what it really is by now, I'll mark it as duplicate of a fresh bug I've filed on the same topic. If you decide to involve yourself in the new bug, please remember: * there is no need to add a commnt when CCing yourself to a bug (I know no-one did that in this bug, but it's always worth mentioning); * don't add mail1~mail6 keywords unless you are a member of Netscape's mail triage team and know why they're used (ahem Peter); * don't add comments unless you're contributing new information on how to code the RFE (ahem Harald); * discussions about anything other than the exact bug should be carried out in the newsgroups, not in the bug. Further RFEs, such as prefs for determining how the system tray icons respond to particular mouse buttons, should be filed as new bugs so they can be wontfixed individually. *** This bug has been marked as a duplicate of 97326 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: mail3, ui
Resolution: --- → DUPLICATE
I just want to state that I think it was a mistake to close this bug. It contained many useful and thoughful suggestions from interested persons. [OT] mpt, I never said *you* should implement this bug. I asked *when* it would be implemented (by whomever). - Discussion of UI and feature issues *is* valid in bugzilla. - The ordinary computer user relies on *intuitive and useful UI features*. - There are *not* a hundred enhancement requests here, merely an *evolving* set of specs that all relate to this bug directly. Not all of them have to be implemented here. You could have recommended that people make *dependant bugs* for specific requests or asked them to go to a newsgroup. I think mpt is trying to cover up for the fact that he hasn't been following (controlling) this bug since its inceptiion. - How can one be expected to know the meaning of the keywords "mail1-6" if the definition isn't clear? You can't have a definition that says one thing and then complain when people use it as such. Change the definition. The discussion and input on the menu structure and behavour is important and does not deserve the threat of "wontfix". You should refer the interested parties to an alternative venue (newsgroup?). That's just common courtesy for the effort & thought everyone put in to this. [/OT] PS. Anyone interested in these features should CC and vote for bug 97326. PPS. But don't dare say anything there, because you have nothing important to say. PROOF: not a single comment was copy/pasted to the new bug.
Definition of mail3 as seen od 8/28/2001 (today): > Most important features. These will be features and or feature extensions. Examples are Usability > bugs, UE Spec non-compliance bugs, threading, searching, import tools, filters, biff, > improvements to the 3 pane window or compose window. (for use in bug triaging) I copy it here as these definitions have a strange property of mysterious change just after a discussion like this.
> I just want to state that I think it was a mistake to close this bug. Don't worry, we're used to you thinking that. > It contained many useful and thoughful suggestions from interested persons. Unfortunately, all of those suggestions were distinct from and not mutually exclusive with the original RFE. That's why it was closed. > PS. Anyone interested in these features should CC and vote for bug 97326. Anyone interested in these features should file separate depending bugs for them, and supply patches if you can. A fix for bug 97326 won't implement any of them, and votes for bugs aren't worth the paper they're not written on. > PPS. But don't dare say anything there, because you have nothing important to > say. PROOF: not a single comment was copy/pasted to the new bug. OBVIOUS EXPLANATION: Not a single one of those comments would help in resolving the original bug. > ... these definitions have a strange property of mysterious change just after > a discussion like this. Yes, it's a conspiracy. You can find the details at this URL: <http://bugzilla.mozilla.org/buglist.cgi?resolution=--- &product=mozilla.org&component=Bugzilla%3A+Keyword+%26+Component+Changes>. See it quick, before the site gets shut down.
<QA_ignore> Well I do not see there the change I meant (adding "Netscape releases" to nsCat Food definition). See original definition on bug 71908, compare it to the one we have now and tell me which bug it the change was documented in. The change happened few days after the 7/04/2001. </QA_ignore>
No longer blocks: 75599
Blocks: 75599
Component: User Interface Design → Browser-General
No longer blocks: 75599
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.