115348 - Generalize System Tray Icon Support

Status: VERIFIED DUPLICATE of bug 325353

(Core Graveyard :: QuickLaunch (AKA turbo mode), enhancement)

Description

[Joseph Elwell]

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.

Comment 1

[Alex Bishop]

Any chance of making that URL publicly accessible?

Comment 2

[Joseph Elwell]

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

Comment 3

[Ian Pottinger]

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???

Comment 4

[Brian 'netdragon' Bober]

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?

Comment 5

[scottputterman]

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 [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 6

[Joseph Elwell]

Attachment: work has begun, but is not complete.

Comment 7

[Joseph Elwell]

Attachment: preliminary stages.

Comment 8

[Ian Pottinger]

adding self to cc list

Comment 9

[Garth Wallace]

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.

Comment 10

[David Tenser [:djst]]

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.

Comment 11

[Ian Pottinger]

> 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.  :-)

Comment 12

[Brian 'netdragon' Bober]

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

Comment 13

[Wim Borghs]

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.

Comment 14

[Wim Borghs]

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?

Comment 15

[David Tenser [:djst]]

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

Comment 16

[Peter Lairo]

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  |
+-------------------+

Comment 17

[Søren Thing Pedersen]

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.

Comment 18

[Richard Klein]

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.

Comment 19

[Søren Thing Pedersen]

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

Comment 20

[Brian 'netdragon' Bober]

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 21

[Jonathan Leighton]

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

Comment 22

[Brian 'netdragon' Bober]

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?

Comment 23

[Jonathan Leighton]

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?

Comment 24

[Brian 'netdragon' Bober]

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>

Comment 25

[Jonathan Leighton]

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.

Comment 26

[Brian 'netdragon' Bober]

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.

Comment 27

[Jonathan Leighton]

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.

Comment 28

[Brian 'netdragon' Bober]

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.

Comment 29

[Jonathan Leighton]

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).

Comment 30

[Brian 'netdragon' Bober]

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.

Comment 31

[Brian 'netdragon' Bober]

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.

Comment 32

[Michael Favia]

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.

Comment 33

[Jonathan Leighton]

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.

Comment 34

[Jonathan Leighton]

Attachment: Incomplete system tray bug summary

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.

Comment 35

[Brian 'netdragon' Bober]

> 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.

Comment 36

[Rick]

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.

Comment 37

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

move everything to bug 325353 that has now a patch ?

Comment 38

[Robert Accettura [:raccettura]]

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