YesNoOk
avatar

NewEventNotify / popup solution (Read 25239 times)

Started by Nightwish, April 20, 2005, 08:13:45

0 Members and 1 Guest are viewing this.
#1
NewEventNotify / popup solution |
April 20, 2005, 08:13:45
I have now, hopefully once and forever, found a solution for the popup/event notify problem.

I integrated parts of the NewEventNotify code and rewrote it so that it can work almost flawlessly now. Popups now always show when they should and clicking on a popup will perform the proper action (open the message window, accept the file transfer or just dismiss the popup).

Also, the code allows status mode selection so that you can select in which status modes event popups should show up.

I realize that this is not the most perfect solution, however, it works and offers almost all options you can also get in NewEventNotify (customizing popups, mouse button actions and so on). Also, popup merging works (multiple popups from the same contact are "merged".

Also, this saves some resources :) The code adds about 15k to tabSRMM (much less than a complete NeN plugin) and saves a few additional hooks.

For those who still prefer using NewEventNotify - it is possible to completely disable the internal event popups.

I tried to motify NeN to make it fully work with tabSRMM, but these modifications would probably make it incompatible with other message dialog plugins - which I don't want.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#2
Re: NewEventNotify / popup solution |
April 20, 2005, 08:21:35
Good work (as always)!

What about popups for, for example, incoming filetransfers? Does TabSRMM handle them now? :-S
Or should I keep NEN and just disable notify for messages?
#3
Re: NewEventNotify / popup solution |
April 20, 2005, 08:56:47
What about popups for, for example, incoming filetransfers? Does TabSRMM handle them now? :-S
Filetransfers are considered as events so I don't know why it wouldn't handle them...

@Nightwish: so I understand it's based on NEN-ng by Prezes, right...?
#4
Re: NewEventNotify / popup solution |
April 20, 2005, 09:00:47
Good work (as always)!

What about popups for, for example, incoming filetransfers? Does TabSRMM handle them now? :-S
Or should I keep NEN and just disable notify for messages?

It handles all events, yes. Internally, there is no difference between a file and message event - all events which are added to the database can be handled by the message window plugin (even, if no message window is open for that contact).
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#5
Re: NewEventNotify / popup solution |
April 20, 2005, 09:03:36
Superfly. Can't wait for this to be released.

TabSRMM should be able to intercept filetransfer events because the original NEN could and did, so...

NG-NEN has been really buggy for me. At least the 0.1.7.3 version.
#6
Re: NewEventNotify / popup solution |
April 20, 2005, 09:21:45
Good work (as always)!

What about popups for, for example, incoming filetransfers? Does TabSRMM handle them now? :-S
Or should I keep NEN and just disable notify for messages?

It handles all events, yes. Internally, there is no difference between a file and message event - all events which are added to the database can be handled by the message window plugin (even, if no message window is open for that contact).

Okey, great! pluginlist just getting smaller and smaller... :)
#7
Re: NewEventNotify / popup solution |
April 20, 2005, 09:28:04
Superfly. Can't wait for this to be released.

TabSRMM should be able to intercept filetransfer events because the original NEN could and did, so...

What do you mean with "intercept"?

What it currently does is showing a file event popup and when you click this popup it opens the file receive dialog.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#8
Re: NewEventNotify / popup solution |
April 20, 2005, 09:31:49
Yeah... I didn't mean anything else than it being able to show the event popup.
#9
Re: NewEventNotify / popup solution |
April 20, 2005, 09:33:47
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#10
Re: NewEventNotify / popup solution |
April 20, 2005, 09:35:30
What about popups for, for example, incoming filetransfers? Does TabSRMM handle them now? :-S
Filetransfers are considered as events so I don't know why it wouldn't handle them...

@Nightwish: so I understand it's based on NEN-ng by Prezes, right...?

Yes, it's based on one of the -ng versions (mainly, because of popup merging, which I found a very important thing, as it can avoid "popup madness" on the screen :) ).

I found that the -ng versions worked best with tabSRMM (better than all others), but some things are simply not possible with an external event notify plugin, because it does not have access to all the internal data and functions of the message window plugin - and that's quite a lot in tabSRMM). Modifying NewEventNotify up to the point where it can work the same way as an integrated popup solution would make it incompatible with most other message dialogs (and that does not make much sense).

Also, when using multithreaded popups, things get a bit messy internally - NewEventNotify has to use a call service workaround (which is pretty clever, but not without problems) in order to get around multithreading issues within miranda. If the popups are created from within the message window plugin, things are way easier.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#11
Re: NewEventNotify / popup solution |
April 20, 2005, 09:36:21
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#12
What about OSD?! |
April 21, 2005, 00:31:27
Alex, all you said in this thread sounds logical and most welcome, but there's one little aspect you didn't touch:
in your old mod of NEN, you added an option to use the OSD plugin instead of the Popup plugin and also not to show popups for the RSS contacts. This is why I loved and used that mod, and still do. Tell me, would this integration have the same ability? I'd hate to install a new tabSRMM build and see popups all over the place, instead of the clean, "pinned" OSD.
I'm sorry, I know I'm a pain; sometimes I just can't stand myself, too. :-[
#13
Re: What about OSD?! |
April 21, 2005, 00:56:28
Alex, all you said in this thread sounds logical and most welcome, but there's one little aspect you didn't touch:
in your old mod of NEN, you added an option to use the OSD plugin instead of the Popup plugin and also not to show popups for the RSS contacts. This is why I loved and used that mod, and still do. Tell me, would this integration have the same ability? I'd hate to install a new tabSRMM build and see popups all over the place, instead of the clean, "pinned" OSD.
I'm sorry, I know I'm a pain; sometimes I just can't stand myself, too. :-[

Disable popups for RSS contacts will be possible.

As for OSD:

I found that the OSD plugin was pretty buggy overall. It frequently crashed Miranda, especially when using fast user switching on XP or when logging off while miranda kept running. Unfortunately, there was no source code for this plugin and it seems that it is no longer maintained by its author.

I know that there is a new OSD (wbosd), but this cannot be used as it does not provide a service for showing osd notifications (that wbOSD is meant as a standalone plugin).

[edit] And it is possible to completely disable the internal event notifications in tabSRMM. So, if you don't want to see popups, you don't have to (it's even disabled by default).
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
Last Edit: April 21, 2005, 05:25:24 by Nightwish
#14
Re: NewEventNotify / popup solution |
April 21, 2005, 03:43:12
And while I'am at that whole eventnotify stuff, I may add an (optional, of course) tray icon and baloon tooltips for those who dislike popups (or want more stability). These notifications would then be unicode safe also (something I really miss in the popups plugin) :)
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#15
Re: NewEventNotify / popup solution |
April 21, 2005, 21:37:11
That would rock, but MIM already has a tray icon...
#16
Re: NewEventNotify / popup solution |
April 21, 2005, 21:50:16
That would rock, but MIM already has a tray icon...

That doesn't matter. tabSRMM will have its own (although completely optional) with advanced features like:

* Minimize to tray (so that message windows won't clutter the taskbar)
* tray Icon menu to access a list of tabs with unread events (updated when new events arrive)
* tray menu which remembers the x most recently tabs in use.
* maybe some kind of "favorite contacts" to quickly open a message window for them.

Since the contact list fully controls Mirandas tray icon, it is not possible to implement all this without creating another one.

A lot of this stuff is already working and is pretty cool. The balloon tooltips are basically my own thing (I don't like tons of popups on my screen :) ). Popups still work of course, including popup merging similar to NewEventNotify-ng but with a different approach. However, due to a bug in Popup.dll, merging popups leaks enormous amounts of memory (it seems that popup does not free the old text/content of a popup window when it is replaced with new text).That must be a bug in the MS_POPUP_CHANGETEXT service.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#17
Re: NewEventNotify / popup solution |
April 21, 2005, 22:55:37
1.0 was so close just a week ago ;)
worth it though :)
#18
Re: NewEventNotify / popup solution |
April 21, 2005, 23:09:41
1.0 was so close just a week ago ;)
worth it though :)

A 1.0 with many problems, non- or only partially working neweventnotify (at least, for quite a few people) wasn't the greatest idea, imho. That tray stuff is all related to the event notify integration.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#19
Re: NewEventNotify / popup solution |
April 21, 2005, 23:32:45
That doesn't matter. tabSRMM will have its own (although completely optional) with advanced features like:

* Minimize to tray (so that message windows won't clutter the taskbar)
* tray Icon menu to access a list of tabs with unread events (updated when new events arrive)
* tray menu which remembers the x most recently tabs in use.
* maybe some kind of "favorite contacts" to quickly open a message window for them.
Heh... cool... that'll rock... :D
#20
Re: NewEventNotify / popup solution |
April 22, 2005, 06:38:58
Ok, the tray icon stuff is working (not fully, but the concept is complete).

It works as following:

When tabSRMMs own tray icon is active, it will flash when unread messages are there (and it will prevent Mirandas tray icon from flashing). Left clicking on the icon will bring up a menu with the following content:

  • sessions which have unread events (menu entry shows protocol, nickname, status and number of unread messages)
  • list of containers which have been minimized to the tray, separated by a menu separator.

This menu will also list messages if no window has been created for that contact (yet - e.g. if you don't use autocreation options). If you click it, the window will be created.

By using that menu, you can quickly bring a window on screen. Also, you can doubleclick the icon when it flashes, and then it will:

  • restore the window with the most recent message in it.
  • If no unread messages are waiting, double-clicking will restore the first container which has been minimized to the tray. If there is no unread message and no minimized container it will do nothing :)

Minimizing to tray is optional, so you can have the tray icon + menus, but still everything on the taskbar.

The right - click menu contains some useful global options, like:

  • disable/enable popups or tray notifications.
  • disable/enable auto-creation of tabs and containers.
  • disable all message window sounds
  • Hide all containers (put them in tray)
  • Restore all hidden containers
  • "Be super quiet" that option toggles everything, so if you enable it, tabSRMM will instantly stop all activity which may be considering "disturbing" :) - No popups, no autocreation, no sounds etc..

The right-click menu also contains submenus for:

  • x most recently sessions - list will be saved when you close MiM
  • favorites (you can put contacts on this list, using the contacts menu in the message window (add/remove to favorites). This list will also be saved when you exit MiM.

Balloon tooltips:

I also added discreet notifications via tray tooltips (balloon - style). They need tray support enabled, but are optional, so you can still use popups together with tray support if you want. Tray tooltips are unicode safe (can display a up to 255 chars long preview of the message) and there is always only one tooltip visible.

To be continued... :)

P.S. Tray Icon is the same as the static container icon already available in the icon packs. Since most icon packs include an icon which looks somewhat like a "message" symbol, it should be ok for this job :)
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
Last Edit: April 22, 2005, 06:47:19 by Nightwish
#21
Re: NewEventNotify / popup solution |
April 22, 2005, 08:19:42
option "No popups for RSS" doesn't work  :-\
#22
Re: NewEventNotify / popup solution |
April 22, 2005, 08:23:46
option "No popups for RSS" doesn't work  :-\

It's not even implemented. Please don't report bugs, if you got the code from CVS. CVS code is often just incomplete and may contain lots of unfinished (and seriously broken, in some cases) stuff.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#23
Re: NewEventNotify / popup solution |
April 22, 2005, 11:02:23
Lots of new things for the next release, yummy.
#24
Re: NewEventNotify / popup solution |
April 22, 2005, 11:44:39
Hope it will be more stable that the already existing plugin. Cause they driving me crazy, non stop crashing  :frown:
__


#25
Re: NewEventNotify / popup solution |
April 22, 2005, 18:38:01
Wooow, so many new features :D
I'm really looking forward to the new version.
*hopes this will be added as well :D* - I'm still waiting :(
__
;D Sorry for my English ;D