I want to generalize the System Tray Icon Support in Mozilla so that other applications, such as mail can easily implement system tray icons and notifications via the system tray.

Any chance of making that URL publicly accessible?

Not in it's current form. I'll spend some time sanitizing it later this week. ;)

http://bugzilla.mozilla.org/show_bug.cgi?id=11056#c23 begins the discussion of integrating Mozilla calendar alarms with nsnotify. Is this something that should be discussed here???

I am fixing bug 100846. Please don't cause a regression after its fixed. Also, I noticed that the systray icon doesn't appear until after you go into prefs. Is there any way to make it appear whenever Mozilla is running?

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

adding self to cc list

re: the URL attached to this bug. Does "rocknroll.netscape.com" exist, and is it accessible to people outside of the Netscape LAN? I'm getting "not found" errors when I try to look at it.

Would this enable, say, the Calendar to display notifications of alarms? Or the mail client to notify when new mail are available on the server? If so, I will vote for this.

> Would this enable, say, the Calendar to display notifications of alarms? > Or the mail client to notify when new mail are available on the server? We, at bug 115348, don't make solutions to the display notifications bugs you hate; We make the solutions to the display notifications bugs you hate better. :-)

<spam>Ian: If there were a "Best of Bugzilla Awards Ceremony", I think that comment would be the winner</spam>

Shouldn't [Product: Browser], [Component: Quicklaunch], Platform and OS be set more general? If I understand correctly all Mozilla products/components should be able to use this solution to use the system tray and run background processes independently from the big Mozilla. (Mail and Calendar notifications) Mozilla components for any OS should be able to tell this solution what they need in the system tray and running in background in the same way. The target milestone needs to be adjusted too.

I imagine this bug 115348 as providing an OS-independent groundwork layer for all things scheduled, be it at regular intervals or at user-logon or a specified moment, maybe even at system-startup... Scenario: When a user logs on the OS loads Mozilla SysTray. There may be plugins for this SysTray that will: - for some OS preload some core Mozilla modules if the user wishes this (quick launch). - provide easy access to the Mozilla components in the taskbar (Navigator, Mail & Newsgroups, Composer, Address Book, Calendar). - check for new mails and notify them. - notify Calendar alarms. - notify for updates on watched sites. - logon the user to Jabber IM. (imagining a resurrection of Jabberzilla) ... Is this how other people see it as well?

Moved the milestone, please change again if it's not correct.

Here is a comment from bug 11056 which may be useful here: > The other reason Quicklaunch and NSNotify shouldn't be tied is that even on > Windows, people (like me) may want to use NSNotify and not Quicklaunch. There are already too many icons in the system tray! The best solution is to have *both* QuickLaunch and nsNotify share just *one* icon. This is NOT to say that QL & nsN need to be the same "process", it could mean that two processes share the same icon (possible?). Obviously, it must be possible to activate/deactivate either independently of the other. The icon graphic could reflect this: State Icon symbol ------------------------------------------------ only nsnotify only nsNotify symbol visible <-- large symbol for clarity only QuickLaunch only QuickLauch symbol visible <-- large symbol for clarity both both symbols visible in icon <-- smaller symbols to fit neither no icon visible If unread mails are present, then a big numer is superimposed on icon (symbols remain as in table above). Right-clicking on icon yields a context menu with useful options (depending on state above?): +-------------------+ | *Read Mail* | <-- if no new mails there, go to inbox with new mail? +-------------------+ | x QuickLaunch | | x nsNotify | +-------------------+ | nsNotify Options | +-------------------+

How about a modular "Mozilla Agent" where the user can quickly enable/disable TSR features such as "Notify when new mails", "Quicklaunch Mozilla", "Calender alarms" and of course "Start agent on system startup". The features for the agent could be extended when other TSR-features are developed in trunk or as extensions.

I think comment #17 is right on track. I would go even one step further. I think that this should be at the GRE level so that any gecko based application can register with the agent.

Especially now the new development plan for Mozilla is public, a GRE-level Mozilla-agent module seems like a logical step.

The movement to GRE in the Roadmap (http://www.mozilla.org/roadmap/) means that this should be available for all GRE-based applications, right?

Comment #18 is a great idea (which comes from comment #17). I think more system tray support is essential, as one of the main problems that new users have when migrating to Firefox and Thunderbird is start up time. With a "Gecko/Mozilla Agent" they wouldn't even notice that the applications are starting up and they would always be available quickly after that. Currently I simulate this using a third party program called Trayconizer, but I can't get it to minimize at start up so the programs always maximise and it isn't an ideal solution. What would make this even better is if all Gecko programs have a list of actions that the Gecko/Mozilla Agent can perform from the system tray. Like this: Firefox ======= - Start program silently at start up - Open program (maximized/minimized) Thunderbird =========== - Start program silently at start up - Open program (maximized/minimized) - Check e-mails - If there are new emails have an option like "4 new messages" rather than the letter icon that goes in the system tray

I don't think this bug is the proper bug for discussion of that. There already is a turbo mode, and this is for making system tray support something that is shared within the GRE or toolkit as opposed to separate for each application. Shouldn't this also be something that is applied to Linux, too?

There is a turbo mode for the Mozilla Application Suite, yes, but there is a no turbo mode for Firefox or for Thunderbird. If system tray support were built into the GRE then turbo modes would not have to be developed for each separate application. As you say though, perhaps a new bug should be created? With regard to Linux, I have no idea having never used Linux in my life. Is there an equivalent to the system tray?

jelwell: The link ( http://rocknroll.netscape.com/users/jelwell/publish/machv/SystemTray.html ) is invalid. Can someone update it? Jonathon: KDE and Gnome have notification areas (system trays) on the right side of the launcher panel. Gnome also has guidelines: http://mail.gnome.org/archives/usability/2003-March/msg00039.html This says that it might be useful to abstract some of the tray support to be cross platform, for instance the way that the mail application might send a message to the tray icon to change its appearance, or show an icon when mail arrives. I.E. although the back-end code would remain different, the API would remain the same. I think its also a good idea to keep nsnotify in a separate process so it is not taken down when Mozilla crashes. <offtopic>Another notification method I've seen recently is a little window popping up on the right side of the screen then disappearing. MSN Messenger on Windows uses this method.</offtopic>

Firstly, just a small, pedantic thing, but please please please observe the correct spelling of my name, it's quite frustrating the number of people that misspell it ;) Well, as KDE and GNOME do have system trays then I think there is no reason why there shouldn't be tray support for them too. With regard to nsnotify, I was proposing that a "Gecko Agent" would replace it, and the turbo mode of Mozilla. I was thinking that the Gecko Agent would be a standalone application (although shipped *with* Gecko products) that would be able to interact with the various Gecko applications on a computer and run the various system tray tasks that they instruct. In this way, if Mozilla crashes, it wouldn't affect the Gecko Agent (being independent of Mozilla), which would still be able to tell you if you have new mail in Thunderbird. I don't think your off topic comment *was* off topic actually. As far as I am aware, the MSN Messenger notifications are triggered from MSN Messenger residing in the system tray. I'm pretty sure that "Mail and Newsgroups" in Mozilla also does this.

The standalone notification application was the intention of Mach V and earlier work done a couple years ago. The work never got done, though, and a lot of the bug reports are forgotten and abandoned. For instance: Bug 127122 was about Quicklaunch being in a separate process "The quicklaunch and notification icon should be in a seperate process so that when Mozilla crashes, it remains. There could be an application created called quicklaunch.exe in the bootstrap directory that does this, or possibly a DLL somehow loaded under a sepearte process." Bug 11056 was about having the mail notification standalone. On and on... What we need is someone to really dig through, find all the bugs, and list them and summarize what was discussed in each bug so that discussions aren't repeated (or even worse, ignored or contradicted) that were already discussed in other bugs. This is such an old thing, that I doubt many strong hackers remember much of the discussions about this. Its almost a clean slate, but some research is needed into the past discussions.

Well... if you want I'd be perfectly happy to do that. It might take me a while depending on how much work there is to be done, but I'd be glad to be doing my bit for the Mozilla project. I'd also be pretty pleased that something was happening, as I'm quite keen for better system tray support. I don't really know what to say other than that. I'm what some might call an "advanced" computer user, but I have no experience with C++ or any other "real" programming languages. In my own time I'm a web developer, so I have experience of programming (and web) concepts, but if you're looking for or needing something more than that then I'm probably not the right guy.

I don't think its really necessary to know too much about C++ to simply summarize the old discussions on this issue. You can attach a page with the summary. Its not necessary that you do much besides strike up a web page with a list of bugs about system tray support like: Bug # - summary Bug # - summary And then a summary of discussions throughout all the bugs, suggestions of developers, and requests by users, and arguments for and against suggestions and requests. Nothing too detailed, perhaps simply an outline, because you can say which bugs these things are mentioned in and by whom, and in what comments. Technical details (threads, interfaces, etc) you can simply give links to bug comments where they are discussed, and give key phrases mentioned in each link.

OK, that sounds fine. I should be able to do that tomorrow I think (I'm over in the UK, so right now is a bit late).

Jonathan: There is no need to rush it. I'd start tomorrow, but its going to take a while to find bugs, then look through them and see what's what and who says what and organize the thoughts into concise summaries. Don't overcommit yourself. Take it from me :-) This bug has been open since 2001, and the quest for shared system tray support sorta died a couple years ago. Its better to take your time because there is no rush. I'd spend the time tomorrow just searching through and finding bugs that talk about this sorta thing or have comments discussing it. You might also want to search the netscape.public.mozilla.* archives on Google. Basically, what we need is a summary of what things went on, what the ideas were from developers, why did the work stop, what was accomplished before it stopped, and what changes people have mentioned affect the older work on it.

I suggest when you find bugs, list their bug # and name. Then you can put up a page with this list that makes it easier for you to look through the bugs and keep track. You can start filling in under each of the bugs what bugs they depend on and block, the topics discussed and comment #s involved for each topic (I wouldn't add links for these as it'll be too much work). Then later you can summarize everything at the bottom. I'd pay more attention to what the main developers (guys who appear to know what they are talking about). Any technical details you don't understand and that really get in your way, you can email me about and I'll most likely be able to help you understand them.

Some very interesting comments in here (#17 caught my eye in particular, and i like the idea of turbo loading but not on startup but instead on first launch depending on the necessary availability of application cores for systray functionality) and i would like to know if Jonathan was still persuing his summary to get the ball rolling again on this issue. There seem to be quite a backlog of issues that this type of work would resolve and im willing to commit an afternoon to doing the research if he is no longer interested/has time. Jonathan, please advise if you are still around.

Hi Michael, I was debating with myself earlier today whether to make a "I'm still here and working" post here, but I didn't get round to it. Brian was incredibly wise when he mentioned about not overcommitting myself, I didn't actually manage to *start* it until a week after I made the last post, for which I apologise. However, I *have* now started working on the summary list. I can put up a "Work in Progress" page if you would like to see what it looks like currently, but basically I am going through and as briefly (and concisely) as possible making summary point about what is said in a bug. Currently I am only on bugs filed under the QuickLaunch component (of which there are 45), but I intend to cover ones where QuickLaunch plays a big part in comments, and also Brian suggested looking at netscape.public.mozilla.*, too. It might be a while yet, but I am focusing my free time on getting it done, so it should happen reasonably soon (just not as soon as I initially anticipated ;). Let me know if you would like to see a work in progress.

I attach an incomplete version of the system tray bug summary I was working on. Unfortunately I won't be able to work on it for a little while, so I thought it best to post up here what I've done, and let somebody finish it if they'd like. If not, I will finish it when I can. I've gone through and summerised every single UNCONFIRMED, NEW, ASSIGNED, and REOPENED bug filed directly under the QuickLaunch component, and I was starting to go through bugs not filed under the QuickLaunch component, but which mentioned "QuickLaunch" or "turbo" in the comments. I was initially just finding the ones that are relevant, and was then intending to come back later to summerise them. You will see that I have left "templates" for the NEW bugs where the bug number can just be pasted in (along with the bug summary from bugzilla). So, if anyone wants to finish it, that's fine. If not, I'll do it when I can, but I can't promise anything.

> so I thought it best to post up here what I've done excellent. That is what people should do more often when they know they won't be able to work on something for a while so that someone could pick it up. Thanks for doing a partial summary and I'm sure it'll be helpful to people trying to sift through the bugs.

Not sure if this is the correct place, but related to "quick launch" and the system tray calander. An enhancement or option of a notification I would like to see would be automatic email notification. The reason for this is that an automatic email could be generated and sent to a cell phone as a text message for example. Someone "out of the office" would still recieve notification as long as the application is active. I'm sure there are security concerns here, but hopefully they could be worked out.

move everything to bug 325353 that has now a patch ?

I'm going to agree, considering no objections in almost a year. I don't see any relevant diff between the bugs.