Closed
Bug 18729
(MailNotification)
Opened 25 years ago
Closed 22 years ago
[FEATURE] Windows integration for new mail notification
Categories
(SeaMonkey :: MailNews: Message Display, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
Future
People
(Reporter: phil, Assigned: mscott)
References
(Blocks 1 open bug)
Details
(Keywords: helpwanted, Whiteboard: [br])
Attachments
(4 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
image/jpeg
|
Details | |
(deleted),
text/plain
|
Details |
This is a feature tracking bug for showing mail notification in the Windows
system tray, next to the clock, as we did in 4.x. Dunno if we'll get to this,
but we should certainly document our decision.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M20
Comment 1•25 years ago
|
||
Marking M20. Personally I think this would be cool. But I don't know if we
will have the support.
Comment 2•25 years ago
|
||
reassigning to gayatrib
Comment 3•25 years ago
|
||
adding helpwanted keyword and marking future.
Keywords: helpwanted
Target Milestone: M16 → Future
Updated•24 years ago
|
Comment 8•24 years ago
|
||
marking nsbeta1+
Comment 10•24 years ago
|
||
If this requires Mozilla to always be running, bug 50424 should be fixed before
the patch for this bug goes in. Currently, you can't double-click a desktop
shortcut to mozilla.exe (with no command-line parameters) to open a new browser
window if any Mozilla app is already running.
Comment 11•24 years ago
|
||
i don't think this depends on bug 50424. All we need is a toolbar icon that
periodically checks for mail and when doubleclicked loads mozilla WITH the -mail
parameter. Since we are launching WITH a parameter (-mail), the other bug
doesn't affect this feature. Even if it does, the confusion over the other bug
should not prevent from starting work on this useful feature.
BTW, nsnotify for NC4.x does NOT work with imap servers. This should not be the
case with the Mozilla notifier.
adding seth and hurricane to the list since they'll know when the code is all done.
Comment 14•24 years ago
|
||
updating summary. this is NSNotify. there are bugs for GNOME / KDE
integration, too. (they are assigned to me.) when we do NSNotify for 6.x,
we'll need to do it in a XP way.
Summary: [FEATURE] Windows integration for new mail notification → [FEATURE] Windows integration for new mail notification (4.x NSNotify)
Comment 15•24 years ago
|
||
actually this bug wasn't meant to be nsnotify. This bug was meant to be for
putting something in the Windows tray when biff goes off from within the
application. NSNotify was a separate app that did the same thing. Getting it
to work from within the app is a good first step.
Comment 16•24 years ago
|
||
fixing summary. thanks for the info putterman.
#11056 is the NSNotify bug.
Summary: [FEATURE] Windows integration for new mail notification (4.x NSNotify) → [FEATURE] Windows integration for new mail notification
Comment 17•24 years ago
|
||
*** Bug 64609 has been marked as a duplicate of this bug. ***
Comment 18•24 years ago
|
||
Before someone pointed out that bug 64609 was a dupe of this, I attached a
couple of sample files that show how to add an icon to the tray. This was in
case someone doesn't know how to do it, and didn't feel like digging through the
old NSNotify code. The tray icon shouldn't be too difficult to add to, say,
nsWindow.
Comment 19•24 years ago
|
||
*** Bug 64609 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
Mail notification... Very important. I'm suprised this wasn't in the mail prog
from the beginning. NS 4.x had it. Outlook/Outlook Express has it... Most
decent mail progs do. I was so confused when I discovered that I wasn't getting
a wav file when my mail arrived.
Comment 22•24 years ago
|
||
Bhuvan and I talked yesterday about where to put the platform-dependent code to
handle this. My proposal is to add the following methods to nsIAppShellService
(see
http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/public/nsIAppShellService.idl):
void setTrayIcon( in string id, in string iconURL, in wstring toolTipText );
void removeTrayIcon( in string id );
"id" is an arbitrary, unique identifier for the "tray icon" (note that this term
is kind of Windows-centric; a platform-independent term would be better).
"iconURL" is an pseudo "chrome URL" that identifies (in a platform-independent
way) the native icon resource to use. The format and mapping to a platform
resource is the same as for window icons (see bug 57576). For example, this
might be, for a mail alert icon, something like:
resource:///chrome/icons/mail/mailAlert
"toolTipText" is, well, the tool tip text. Probably should be called something
more generic like "helpText" because the tool tip is just the Windows
implementation. This might be ignored on other platforms.
You can call setTrayIcon again to change the icon or help text. Use removeIcon
to remove it.
These methods would cause the icon to be added/removed. The only other piece is
the code that notifies you when the user interacts with that tray icon. I think
we only need to handle double-clicking (dealing with drop-down menus in an xp
way is a pain) and a whole new interface for doing the notification isn't necessary.
When the user double-clicks the icon (or whatever the equivalent is on other
platforms), we will fire off an nsIObserverService notification. The topic will
be the "id."
I think the same 2 methods will be added to nsINativeAppSupport so that we can
easily provide platform-specific implementation. The methods will need to be in
nsIAppShellService, also, because naINativeAppSupport isn't scriptable (because
it has to come to life before xpcom to handle the splash screen).
Comment 24•24 years ago
|
||
Law, that sounds good. It should handle the basic needs for the notification.
If we want to add the right-click menu, we could do it on a platform-specific
basis.
Comment 25•24 years ago
|
||
marking nsbeta1- and moving to future milestone.
Comment 26•24 years ago
|
||
*** Bug 79090 has been marked as a duplicate of this bug. ***
Comment 27•24 years ago
|
||
outlook has it, yes but only when outlook is started and using a whole slot of
the taskbar, then it starts up a trayicon when mail arrives...
mozilla should be able to stay in the trayicon like the old netscape mail
notifier and tell the user when a new mail arrives by flashing or an animated
icon!
but it should be mozilla down there and not any small prog like netscape mail
notifier - a user could be able to start a navigater window through double
clicking or something, that would be nice
Comment 28•24 years ago
|
||
Law, I love your of adding to the nsIAppShellService & nsINativeAppSupport
interface. Makes it easy to add tray icons.
Dean Dessman has provide almost all the Win32 code in bug 64609. Looks like all
that needs to be done is wrap that code into the Win32 implementation, hook up
the IDL's and add the nsIObserver.
Is anyone already working on this? It's marked Future and helpwanted. I don't
want to waste my time looking further if there is already a conservative effort
to do something similar in another bug. It seem to be blocking a lot of other
bugs like biff notification, preloader, and AIM could use it just to mention a
few.
Comment 29•24 years ago
|
||
Comment 30•24 years ago
|
||
Okay, this patch lays the groundwork intefaces that need to be implemented.
Please let me know what you think. I think it'll work nicely XP in the
future without having us to implement on every platform right now.
TODO:
1) Incorporate the patch from bug 64609 for calling the Windows API
2) Rip off the code in nsWindow::SetIcon for getting a chrome:// or res:// icon
to create an HICON. Is there another way to do this?
3) Add MSG_SYSTRAY to WndProc. What Hwnd should I use?
4) Then we will probably need to convert the event to a "netscape" type GUI
mouse input event.
5) Grab the nsIOberverService to send out the event notification to all
registered listeners.
** 6) Implement on Mac, Linux, and other platforms.
cc:ing Joe and Syd on this as they may want something like this for AIM. I know
there's a Bugscape bug similar to this but doing it XP is better anyway.
Clearing milestone to trigger re-evaluation for post beta1.
Target Milestone: Future → ---
Comment 31•24 years ago
|
||
Comment 32•24 years ago
|
||
Patch #2 actually has some code in it. Not quite sure if it works correct, but
it compiles. I'm jumping through some hoops to get the hWnd of the hidden window
so hopefuly I didn't make too many mistakes. It addresses my issues #1-3. Thanks
Dean for some of your code.
Left to do:
1) Add code to widget's windows/nsWindow.cpp to handle my new callback message
(WM_SYSTRAY_MSG).
2) Convert that to a mouse click input event
3) Handle Observer callbck. This may be a little tricky if it's in nsWindow
4) Need to figure out how to develop a testcase to try this out!!!
5) Cleanup. Possibly add prefs.
Alas, I must tend to my mozilla0.9.1 bugs.....
Comment 33•24 years ago
|
||
The code you've attached looks OK, for the most part (I didn't look it over too
closely, though).
As it happens, the fix for bug 53952 adds a new "hidden window" of sorts, and I
was thinking that it would be a better place to put the handling of the systray
messages (its window procedure is right in nsNativeAppSupportWin.cpp). I think
that might make the code cleaner.
I've also (as part of work on bug 75599) replaced nsINativeAppSupport.h with a
.idl file (which your patch conflicts with).
I also agree that we should try to reuse the same "icon url"-to-filename mapping
code as is currently in nsWindow::SetIcon. Maybe add some generic "convert"
method to nsINativeAppSupport that takes a pseudo-icon url as input and returns
the appropriate native file path.
I've got the same mozilla0.9.1 bug list problem, so I don't have time to work on
this right now. It might be better to tackle this after some of the code for
bugs 75599 and 53952 lands.
Comment 34•24 years ago
|
||
Oh wow...yes..I wanted to use the hidden window for getting the sys tray
callback but I didn't relaze it was in the same file. Is it the "splash screen"
that's the hidden window? I need to figure out how to get the hWnd of the hidden
window in nsNativeAppSupportWin.cpp.
Comment 35•24 years ago
|
||
No, this new window isn't the same as the splash screen...best is to have a look
at the patch attached to bug 53952, I think.
I thought the "hidden window" went away (except on Mac). Or is it just not a
xul window now, or something?
Comment 36•24 years ago
|
||
Ahh...yes..I see what you mean. Marking dependancy (please change if you feel
otherwise). That would be GREAT! Much better to leave all this implementation in
one file anyway. This may make it for mozilla 1.0.
Depends on: 53952
Keywords: mozilla1.0
Comment 37•24 years ago
|
||
peter: this may be of service:
http://lxr/commercial/source/AIMGlue/src/nsCUIHelper.cpp#413
Comment 38•24 years ago
|
||
Hidden window mentioned, must cc: danm!
/be
Comment 39•24 years ago
|
||
Aaaaaaaaaaaa! Curse me for not destroying nsCUIHelper yet. It shouldn't be used
as a guideline for new code. HiddenWindow has been nearly completely expunged
from the Mozilla codebase, though the out-of-date Netscape branch still revels in
it. We're trying very hard to completely remove it (except on the Mac, where it's
insurmountably useful) because (a) it's a performance hit and (b) people keep
using it for stuff.
Please don't use or rely on HiddenWindow for anything. We've been making progress
toward its removal. New uses will only make my dream of wrapping my hands around
its scrawny evil neck and throttling that much harder to fulfill.
Comment 40•24 years ago
|
||
actually, I think that a os-dependant notification system needs to be in a
seperate interface, apart from nsINativeAppSupport.. nsINativeAppSupport is
already starting to handle a bunch of mismatched components as it is.
Let's basically implement a single interface which has three implementations,
each of which does it's own handling of creating the native taskbar icons, etc.
I'll call it nsISystemNotification for argument's sake.
In the case of windows, where the taskbar icons need a native HWND to hang off
of, let the Win32 nsSystemNotification implementation have it's own private
(hidden) window to hang it's icons off of. Linux and Mac might not require such
a hidden window to do notifications..
Comment 41•24 years ago
|
||
That sounds like a good idea to me.
Comment 42•24 years ago
|
||
Here is a little thing that is often forgotten but can be useful (when explorer
crashes):
Taskbar Creation Notification
Microsoft® Internet Explorer 4.0 will notify applications that the taskbar has
been created. When the taskbar is created, it will register a message with the
"TaskbarCreated" string and then broadcast this message to all top-level
windows. When your taskbar application receives this message, it should assume
that any taskbar icons it added have been removed and add them again. The
following example shows a very simplified method for handling this case.
LRESULT CALLBACK WndProc(HWND hWnd, UINT uMessage, WPARAM wParam, LPARAM lParam)
{
static UINT s_uTaskbarRestart;
switch(uMessage)
{
case WM_CREATE:
s_uTaskbarRestart = RegisterWindowMessage(TEXT("TaskbarCreated"));
break;
default:
if(uMessage == s_uTaskbarRestart)
AddTaskbarIcons();
break;
}
return DefWindowProc(hWnd, uMessage, wParam, lParam);
}
Comment 43•23 years ago
|
||
*** Bug 87937 has been marked as a duplicate of this bug. ***
Comment 44•23 years ago
|
||
*** Bug 87124 has been marked as a duplicate of this bug. ***
Comment 45•23 years ago
|
||
*** Bug 89823 has been marked as a duplicate of this bug. ***
Comment 47•23 years ago
|
||
i wanna tell that you already did a notify icon for the mozilla turbo start now,
so the argmuent (rather old on this page) that notify icons are bad because they
are only for windows doesn't work anymore.
just get a second trayicon up when a email arrives, the trayicon could be
animated and playing a sound once (the user should be able to choose wich one to
play) and could even put a baloon up (yellow field like the tooltip but it is
larger and will be used in windowsxp much by microsoft)
how about that?
Comment 48•23 years ago
|
||
Instead of having two icons (turbo & mail notify) for one program (Mozilla), it
would be better to integrate the functionality into one tray-icon.
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).
I have filed bug 90466 to track this "merger" (please vote and CC yourself if
interested).
Comment 49•23 years ago
|
||
that's a really good idea. voted for it and cc'ed myself ;)
Comment 50•23 years ago
|
||
*** Bug 93424 has been marked as a duplicate of this bug. ***
Comment 51•23 years ago
|
||
mscott (mail pseudo-manager now iirc), is this work going to be targetted at
some point? It continues to be one of the top feedback requests for mail, from
6.0, 6.1pr1 and 6.1.
Whiteboard: [nsbeta1+ 2/21] → [nsbeta1+ 2/21][br]
Comment 52•23 years ago
|
||
*** Bug 98869 has been marked as a duplicate of this bug. ***
Comment 53•23 years ago
|
||
Nahor: after reading your comment several months ago, I filed bug 100846 for
turbo to use the TaskbarCreated notification, not remembering where I had heard
about it or what it was called. Now I know :)
Comment 54•23 years ago
|
||
reassigning to sspitzer
Assignee: racham → sspitzer
Keywords: nsbeta1-
Whiteboard: [nsbeta1+ 2/21][br] → [br]
Target Milestone: --- → mozilla0.9.7
Comment 55•23 years ago
|
||
*** Bug 105402 has been marked as a duplicate of this bug. ***
Comment 56•23 years ago
|
||
*** Bug 104295 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Comment 57•23 years ago
|
||
*** Bug 83652 has been marked as a duplicate of this bug. ***
Comment 58•23 years ago
|
||
What is still necessary in order to finish this?
Comment 59•23 years ago
|
||
1. Show envelope on Windows task bar when mail is waiting.
2. Fix bug 84705.
3. Perhaps add a couple words to the preference dialog to say "Play default
Windows mail sound when new mail arrives."
Comment 60•23 years ago
|
||
Shouldn't this be made dependant on bug 84705 then?
Comment 61•23 years ago
|
||
That isn't enough information.
Who is currently working on this (if anyone)?
Is the patch obsolete - how much of what is left to do do we have?
1. Show envelope on Windows task bar when mail is waiting.
Have you made the icon? Have you made the code to show the icon? Which parts of
this aren't complete?
2. Fix bug 84705.
3. Perhaps add a couple words to the preference dialog to say "Play default..."
Does the sound already play? Is the UI all you need?
You talked a lot about the notification icon for the turbo feature. How does
that play into this?
I'm not going to even think about working on this bug until I get some real
information about what needs to be done. I already have 4 bugs I'm working on.
If I got the information I needed, then I feel I could do parts 1 and 3 rather
quickly.
Comment 62•23 years ago
|
||
Sorry - forgot to mention - On part 3, I wouldn't do the UI, but if you need the
default mail message played, then I could do that.
Comment 63•23 years ago
|
||
It looks like mscott will get to this as part of a replacement to nsnotify.
I'll reassign when I know more.
Comment 64•23 years ago
|
||
The code for showing an icon is written cause the Turbo-icon is the same
thing... We though about the turbo icon chaning when new mail arrives to some
kind of animated thing so that the user can see that there happened something...
I think mozilla doesn't play a sound when mail arrives, the ui has to be made
for soundselection and the coding to make mozilla play a sound...
Currently if you double-click the turbo icon a new browser window opens... This
behavior has to be changed in case there has a mail arrived... Then it should
open the inbox... The icon should go back to normal if you read the mail.. but
this depends on bug 84705 ...
Comment 65•23 years ago
|
||
1. Show envelope on Windows task bar when mail is waiting.
Have you made the icon? Have you made the code to show the icon? Which parts of
this aren't complete?
Who? Me? I am just an incompetent user/tester. Steal the icon from Netscape 4.
2. Fix bug 84705. I suspect this bug will mess up toolbar icon behavior also.
Does the sound already play? Is the UI all you need?
YES, the default Windows sound already plays. That was fixed a long time ago -
See comment 39 of Bug 64475.
Comment 66•23 years ago
|
||
There are two ways this can be worked.
1. Have the Netscape 6 Icon in the tray change to a mail flag when mail has
arrived.
2. A second Icon appears saying mail has arrived and when its clicked on it
brings you right into the mail.
I have another suggestion too for when mail arrives besides just playing a
sound. For those of you who use Norton Antivirus 2002 you will know what im
talking about. When new virus deffitions are downloaded a little box pops up
right above the tray saying 'virus deffintions updated' then it goes away 2
seconds later. Would it be hard to incorporate something like this after we
solve the original problem?
Comment 67•23 years ago
|
||
Many comments presuppose use of turbo mode. I think many people do not use it,
so simply changing the icon in the tray from Moz/NS6 to show mail will not work.
If icon is added for non-turbo people, and then it disappears once mail is read, OK.
Scott's latter paragraph seems to be a separate RFE that I don't think should
become part of this bug. I hate those little popups, anyway. I like sound.
Comment 68•23 years ago
|
||
There's a standard cross-platform notification system built into widget
(nsIWidget::GetAttention). No need to worry about specifics like icons. Just use
the toolkit (and modify it if it isn't everything you need, of course).
Comment 69•23 years ago
|
||
i would vote for the dialog ...
but it has to be to the upper right on the screen and without a windowborder...
it should slide in with a nice icon saying You have [number] new mail message(s)
and when you click on it it should open the messenger... And it should disappear
automatically after a time setable in the preferences...
that would be kind of cool...
why not making a option for sound yes / no | dialog yes / no and trayicon yes / no
that would be the best solution i think
Comment 70•23 years ago
|
||
Harald,
100% agree, this would be a really nice set of features.
Personally, I don't like any dialog boxes - but it could
also be possible to display the number of new mails in
the tray icon. E.g. if you copy a file with the Windows
Commander (a file manager for windows) and minimize it
to the systray, it still shows the percent-progress in
the tray icon - and you can read this quite well.
And if somebody really has more than 100 new mails at a
time an the space becomes to tight - well, display
something else. :)
Axel (...just adding a comment)
Comment 71•23 years ago
|
||
Ok don't want to add more spam. But wanted some clarification. By dialog are we
talking about something like yahoo messenger does. When someone comes online or
sends you a message when you don't have a window open for them, it floats a
small "tooltip" above the tray icon and contains text telling you what is going
on. I'll see if I can post a screenshot. This would be very nice.
Comment 72•23 years ago
|
||
when i talk about a dialog... i think of it like microsoft messenger.. when
someone is getting online or sending you a message a window slides in from into
the right lower edge of your screen with a nice background and an icon saying
"blah is telling you something"...
i'd like that very much... like described above... of course everyone would like
it in a different way so this has to be very flexible in the preferences..
Comment 73•23 years ago
|
||
Exactly like the messager. It isn't really a dialog, just a tool-tip maybe 1x2
in the corner of the screen then it fades away on its own. Doesn't really get
in the way at all.
Comment 74•23 years ago
|
||
I logged bug 115348 to track generalizing the System Tray Support so that mail
can access it.
Depends on: 115348
Comment 75•23 years ago
|
||
I personally would like just a sound, and an icon. When you move your mouse over
the icon, a tooltip would come up showing you how many new mails you have. I
think the icon should be a mailbox with a flag up :-)
Three suggestions:
1) Yahoo tooltip type thing
2) Sound
3) Icon
Why not do all 3 and make each one a preference?
Comment 76•23 years ago
|
||
Just so programmers can see it, this is what yahoo shows when someone comes
offline or sends you a message when no windows exist. looks like this but says
the message and truncates it if its too long. Censored name from screenshot to
protect the innocent :)
Comment 77•23 years ago
|
||
reassigning to mscott. This will go in as part of nsnotify.
Assignee: sspitzer → mscott
Comment 78•23 years ago
|
||
*** Bug 117985 has been marked as a duplicate of this bug. ***
Comment 79•23 years ago
|
||
This attachment provides a proposed interface with a full set of methods to
manipulate "system notification widgets" (i.e., "systray icons" on Windows).
This interface does the job for the Navigator QuickLaunch systray icon needs.
Need verification that this will work for mailnews, etc. (and need to implement
it, of course :-).
Comment 80•23 years ago
|
||
my suggestions:
- add local addObserver/removeObserver and do event notifications that way..
possibly even use another well-known interface like nsIEvent? That way the
entire system doesn't have to be notified about events which have only one or
two consumers
- keep context menus (or any other UI) out of this interface - maybe put in a
seperate nsISystemNotificationMenu interface, or at the very minimum allow
context menus to be defined in XUL and implemented as xul popups. UI should
always be manipulated with DOM interfaces.
- make the icon IDs urls to icons or some sort of CSS class...
I'm almost wondering if you might want to load a small XUL document which
represents any content that might be related to this icon.. this would also give
you a JS context to work in.
cc'ing hyatt for ideas.
Comment 81•23 years ago
|
||
Thanks for the feedback, Alec. My replies on each point are below...
re: local nsIObserver vs. nsIObserverService
Having a per-"widget" or per-menuitem observer is nicer. Would it be good
enough to add an "in nsIObserver" argument to createWidget? That would support
one observer per widget (and no way to change the observer) but that's probably OK.
re: keeping UI out of the interface
I'm not sure I see the benefit of separating out the menu item stuff. I don't
think any clients are ever going to set up systray icons (or equivalent) without
specifying what happens when the user interacts with them. So every client is
going to have to deal with the nsISystemNotificationMenu interface anyway. A
new interface to bundle up a few simple attributes seems like over-COMifcation,
perhaps.
Defining the context menus in XUL is problematic. We don't "own" the systray
icon on windows and I'm not sure it's possible to do that. Thus, we can't see
the low-level mouse/menu events that trigger display of the context menu. We
*could* extract the necessary information from the xul document to construct the
native context menu, but that just makes things more difficult for the clients,
I suspect, with no increased cabability.
re: Icon ids == urls
Yes, that's what I meant. If you look at the "icon ID strings" that
nsWidget::SetIcon supports, they are resource URLs that are mapped to
platform-specific files using some per-platform convention.
Window icons are "skinnable" via css but I'm not sure how to accomplish that in
this case (in the case of window icons, the <window> object's style attributes
control the icon).
Comment 82•23 years ago
|
||
> Defining the context menus in XUL is problematic. We don't "own" the systray
> icon on windows and I'm not sure it's possible to do that. Thus, we can't see
> the low-level mouse/menu events that trigger display of the context menu.
I don't get what you mean here, Bill. All we need to do in Windows is capture
the mouse click on the tray icon, which is simple to do. After that we can do
anything we want to, such as displaying a XUL window / menu.
Comment 83•23 years ago
|
||
yes, what dean said. The reason is this: First you'll add these menu-item APIs.
then people will ask for icons in their menus. Then people will ask for
checkboxes.. then people will want to disable them, or make some of them bold.
then someone will want to put a logo on top of their menu, then someone will
want a dialog to pop up instead of a menu. then someone will want /right/
clicking to pop up a menu, but /left/ clicking to open a window. The list goes
on and on. We can't keep adding APIs, it's just not a scalable solution, not to
mention you'll keep adding proprietary APIs instead of standard DOM APIs which
people know and love.
(I see literally ALL of the above in the taskbar icons on MY desktop...)
One thought is to have one main, hidden "window" that loads a xul document, and
have taskbar consumers overlay their own ui into that document.. that might save
the overhead of having a seperate window per icon.
Comment 84•23 years ago
|
||
Anything is possible, I suppose. Using xul popups seem hard because they have
to have a parent <window> and we don't have one here. I was envisioning putting
the <window> in the system tray and getting the popup that way. That's the
thing that's (probably) impossible.
I did find an article where somebody had wired up a 16x16 window and some code
to bit-blt the window to an HICON and then send that icon to the system tray
every second. So he used that to allow you to put anything you wanted in the
system tray. Quite clever, but overkill if you just want a simple menu. And
that just managed the visible window content, no event handling.
I suppose we could have some sort of hidden window that owned the menu and route
the notifications from the systray icon to that window (which would then show
the popup). The hidden xul window we do have has been the source of unending
aggravation (ask danm) and it is *really* hidden (no popup menus except native
Mac ones). I'm not anxious to sign up to support another one of those.
Bottom line is: I don't have time to implement a xul-based menu system for this
in the time frame we need it.
How about a compromise: If there are no menu items defined for one of these
"widgets", then mouse events (the limited ones Windows sends us; on Win32) can
be passed to the observer. That way, an ambituous observer of this interface
could implement their menu the way you suggest. That's what we'll tell the
people who start asking for animated menu icons, etc.
And clients who just want a simple menu can easily get one.
Comment 85•23 years ago
|
||
mscott, this is the bug I was referring to.
law, I didn't mean putting a XUl window into a 16x16 area, I meant a hidden
window which was the master taskbar window
Comment 86•23 years ago
|
||
Being a former Communicator user, I miss this feature horribly. I hope this
makes 1.0, for 4.x parity at least. Adding myself CC: and voting for this bug.
Comment 87•23 years ago
|
||
Bill: sounds like a good idea. There is no need for the kind of complexity
required for OS-specific widgets on a windows-only feature. Besides, that color
menu would clash with all the other menus in the systray.
Comment 88•23 years ago
|
||
Bug 119344, if fixed for all Windows versions, would be the last item for me to
"vote" this bug (18279) fixed. Bug 84705 currently worksforme with build
2002012304. The new mail sound has worked correctly for a very long time. Task
bar notification, any at all, is really enough. I don't see any need to get fancier.
Comment 89•23 years ago
|
||
Well the icons there, but shouldn't clicking on it open mail? It doesn't.
Comment 90•23 years ago
|
||
I don't see any icon in the taskbar, using the lastest build (2002012803)? I use
NT. I only see the little green arrow on the mail icon on the status bar. Do I
have to tweak prefs.js to see the taskbar icon?
Comment 91•23 years ago
|
||
It doesn't seem useful to implement this in XUL when it's not a crossplatform
feature and there aren't a lot of resources to spend on this.
Comment 92•23 years ago
|
||
Bug 119344, though closed, says that tray icon is still not there on Win95, 98,
and ME. I am using build 2002020803 with WIn98, and the icon is NOT there.
Comment 93•23 years ago
|
||
moving this bug out since this isn't what Scott's been using to track his
integration work. Currently we have a tooltip and an icon.
Comment 94•23 years ago
|
||
> Currently we have a tooltip and an icon.
...which don't work in win9x (or do they by now?)
Isn't this one of the most requested feature? It seems "nsbeta1-" is asking for
disapointment from users.
Comment 95•23 years ago
|
||
Peter, please understand that Mozilla is overloaded with features at this moment
(don't forget to count download manager in them). Surely there are important
features being "futured" but what seems to be critical at this moment is to
freeze the api's and fix some nasty bugs for the upcoming Mozilla 1. and MachV
releases. Asking for features doesn't help the project (my opinion only and I
don't think it's apropriate to discuss it here).
Assignee | ||
Comment 96•23 years ago
|
||
I just wanted to jump in with some clarification here. This bug is still open
because it has had some great discussion for a cross platform way to maniuplate
icons in the system tray.
I actually had an other bug open which I used to implement new mail
notifications in the system tray. Mail already had a windows only file
containing windows specific biff integration hooks so it was trivial to add a
call to ShellNotify to add the icon to this file without requiring the over head
of a cross platform implementation. Unfortunately Bug #122626 is still out there
(and that is nsbeta1+) which causes this icon to not show up on win98. I haven't
figured out what's causing that yet.
That being said, it's still beneficial to continue the discussion which is why
this bug is still open. However, it's not beneficial to continue the discussion
before mozilla 1.0.
So this bug: nsbeta1- and not required for 1.0.
biff icon not showing up for win98: 122626 and that's nsbeta1+.
Hope that helps.
Comment 97•23 years ago
|
||
Windows integration for new mail notification doesn´t work with Mozilla 0.9.9
with Windows 98 SE.
Comment 98•23 years ago
|
||
if mozilla is _just_ running in the systray without having any messenger or
navigator window open it doesn't check for new mail... is filed in another bug # ?
Comment 99•23 years ago
|
||
sorry for the spam but: wouldn't it be better to have one icon showing both the
running turbo mode and the new mail arrival?
probably that would also be a workaround for bug #122626 ... i would think of a
normal icon when everythings normal and no mail is there and a little message
sign over the icon if mail arrived...
QA Contact: sheelar → stephend
Comment 100•23 years ago
|
||
adding self to cc list
Comment 101•23 years ago
|
||
Sorry if this is wrong. I'm a newbie really.
I'd just like to note that to have a "system try" on Linux Mozilla needs to
create a mini-xul window. This miniwindow is marked specially so that Gnome and
KDE put it in the "system tray". If something similar could be done on Windows,
a lot of code would be able to be shared.
If Windows supports static icons only, then there could be an offscreen xul
window (!) copied to an icon. This copy would happen only when there is a change
in that window.
Comment 102•23 years ago
|
||
New mail notification icon never goes away till you completly close browser.
Should this be a seperate bug?
Comment 103•23 years ago
|
||
johnlar: Mail notification doesn't go away because, essentially, once you open
MailNews, it never closes until you completely exit Mozilla. So, if you have
MailNews configured to check for new mail every "x minutes", it will continue to
check for new mail even if MailNews is "closed".
And, yes, that should be a new bug (I figured that it would be filed already,
but I can't find it). If you happen to file that as a new bug, please also add
me to the CC list.
Comment 104•23 years ago
|
||
There doesn't appear to be any biff type functionality on platforms other than
win32, for Mozilla. For example, on Mac OS X, I'm running Mozilla and when new
mail arrives (and I'm not in Mozilla to see the mail/news button update), no
external notification tells me that new mail has arrived.
Most every mail application I've come across since I've been working with OS X
has some sort of biff notification in its Dock icon. I think Mozilla should as
well. Obviously this bug is about integrating NS4's biff functionality into
win32/Moz, what I would like to know is if a bug has already been filed to bring
similar functionality to Moz or if this needs to be done?!?
Brice - a very quick search of bugzilla using 'biff dock' turned up bug 86553.
Comment 106•22 years ago
|
||
When a customers telephone call dos not go through to one of my colleagues, the
switchbord people sends an e-mail, and asks him to call the customer.
It is important for our company's survival, that my colleague sees the e-mails.
A tiny icon in the sys-tray is not enough.
Outlook places a message-box in the middle of the screen that ensures it.
Moz mail can raise a message-box from the sys-tray, that is good enough, if the
prefs is changed, so it is open for a hours and not a few seconds, though it
ought to have a pref, where it stays open until it is click'ed on.
We have to define the pref so my colleagues see the notifier after a
offee-break, but then the message-bog stay's up all the pref-time and can not be
click'ed away, when he sees it immediately.
It is a minor problem, that moz mail has to be open - Outlook has to too.
mvh...
Morten Christensen
Comment 107•22 years ago
|
||
*** Bug 158852 has been marked as a duplicate of this bug. ***
Comment 108•22 years ago
|
||
Very good done guys... The mail notification system in build 20020830 is
perfect. Good work. Now there's only one more problem... Mozilla has to check
for mail also if the messenger isn't opened. It doesn't do that currently. Also
it would be great if mozilla checked for mail while in turbo mode and opened in
the system tray only...
How about that?
Comment 109•22 years ago
|
||
I hope this is the proper forum for this comment ... the lack of an e-mail
notification feature in Mozilla is a serious oversight. I've been using Netscape
for years in our school system, but with all the press play about Mozilla I
thought I'd use it instead, primarily for its LACK of that horrible AIM
component, and for its ability to block popup ads. I was astounded to see that
it did NOT have the e-mail notification support which was found in Communicator
4.7x. I can tell you developers, this is a "can't use it then" issue. Our
school's teachers and staff would completely balk at a browser whose e-mail
subsystem lacks a notifier. Of course, this means a notifier which resides in
the SysTray and tells them they have mail, even though the browser is not
running. Mozilla currently will notofy you of e-mail once it's started, but
that's redundant. People need to know there is mail waiting, so they have a
reason to start the browser. They want to be able to tell, at at glance, that
they should start their browser. They shouldn't have to start the browser and
find, oh well, no e-mail right now. I'll look again later. Start-stop-start-stop
the browser? That's not gonna happen. So often, it's the small things which
matter a great deal, and the "no NSNotify" of Mozilla is a poison pill. When
this is available, let me know and I'll put Mozilla on all our desktops ...
until then, no way. I'd be drawn and quartered by the staff.
Comment 110•22 years ago
|
||
Does mail notification still work if Mozilla is in quicklaunch mode? If this
were the case, you'd just have to start mailnews once to get the checker code
started, then the process would still be there due to quicklaunch. If this is
not the case, maybe this would be a good idea.
Does Outlook have a mail notification checker?
Comment 111•22 years ago
|
||
isn't this completed?
in windows xp, i get new mail notifications...
(note - i am running LiteStep {so non-std system tray}
and the popup is in the bottom right while my systray is right middle
...not that that matters, it still comes up in the bottom right)
why is bug 115348 dependant?
it was added in comment 74 ... shouldn't that be blocked by this?
recommending a close of this bug
(assuming this fix also works on win2k and win98).
adding self to cc list.
Comment 112•22 years ago
|
||
This was mail notification when Mozilla wasn't running. I doubt you get
notification if Mozilla is not running.
Comment 113•22 years ago
|
||
are you referring to bug 11056?
what you described does NOT match the summary,
however it DOES match bug 11056's summary.
...or are you implying that when mozilla's quicklaunch agent is open,
mail should be checked. again, the summary would need updating.
you are correct about no notifications while mozilla is closed (obviously).
i think we're falling too far into the monolithic mozilla approach;
if i'm not running mozilla mail, i don't want email notifications.
this seems FAR better served in a third-party application (bug 11056),
which could be linked to by mozilla/moz-quicklaunch as an option.
(just my $0.02)
Comment 114•22 years ago
|
||
You know what... I really don't know what this bug covers. Sometimes they
are talking about a nsnotify style program, other times not. I agree bug 11056
is what I am looking for specfically though.
Comment 115•22 years ago
|
||
WTF Are Netscape/AOL on glue "nsbeta1-"
"nsbeta1- This keyword will be added to bugs which the Netscape evaluation
team has rejected for the next Netscape release."
Comment 116•22 years ago
|
||
"nsbeta1-" means "we don't have anyone available to work on this right now; more
important things need to get done". If you don't like that, feel free to give
Netscape money to hire more people.
In any case, that does not affect non-Netscape developers' ability to fix the
bug. Notice that "helpwanted" keyword?
Comment 117•22 years ago
|
||
Sorry I mis-understood
Comment 118•22 years ago
|
||
*** Bug 190835 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Keywords: mozilla1.0
Comment 119•22 years ago
|
||
the most straightforward solution seems a resurection of NSNOTIFY.exe
It's perfectly mozilla compatible as is (needs IMAP support though). I run it
in my startup folder and have changed the client to Mozilla mail.
Mozilla definitely needs an email notification that has a very small resident
memory footprint that can run without the browser running.
Here are some dream features:
auto-cancel timed email check if processor/memory usage peaks:
NSNOTIFY can cause buffer errors during CD burns and can interfer with
processor-intense software when it checks for new mail. If it could detect
memory and processor peaks and delay it's scheduled check accordingly-- well
that would be awesome.
sound rotator - getting new email is exciting... hearing the same new
email sound each time is rather dull... if a library of sound clips could be
loaded and played randomly upon new mail preferences -- well that too would be
awesome. There are tons of tweaks on this concept -- perhaps the notification
software could have an option to assign sounds based on the number of new
messages (i.e. "you've got 2 new mail messages")
Comment 120•22 years ago
|
||
Call me insane, but isn't the whole idea about this thing that it is supposed to
be _extremely_ lightweight/stable? Features doesn't lend itself to being
lightweight/stable.
I think we should get it to work in the most basic way before we start adding
things like ability to brew your expresso while you are waiting for your mail.
Comment 121•22 years ago
|
||
If anything in terms of timing, we might want to not make a sound more than,
say, every 5 minutes.
Comment 122•22 years ago
|
||
Please take standalone notification discussions to bug 11056. For exciting new
features of notification (like rotating sounds... hm), create new bugs. Thanks.
There are certainly bugs with mail notification (see for instance bug 116181)
but this is DONE. Right? Nobody has offered a reason why not since comment 111.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 123•22 years ago
|
||
Wouldn't this dupe Bug 11056 and not be FIXED?
Comment 124•22 years ago
|
||
Please move your VOTES to bug 11056 - Implement new mail check standalone app
(nsnotify)
This bug has been in for a long time now, and works on all Win9.X and Win2K/XP
variants.
Verified FIXED, using Seamonkey build 2004-07-28-08 on Windows XP and Win2K (but
while working at Netscape, this was tested on Windows ME and Windows 98, too).
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•