Refactor the whole event handling system

[shtrom-gajim@…]

Notifications about new messages should also popup when a new message is received in an already openned but not selected message window (probably minimized or on another desk).

[nk]

no it's not good. then all we get is popup notication that mean nothing. popup notification should popup only when needed.

svn has Urgency Hint, that means the minimized window in taskbar will flash until you click it, also bg windows have * and [] in title and also flash.

window in another desk (you mean virtual desktop?), if put in another vd, then that means the user in the current desktop does not like to be bugged about a window in another vd, unless he has sticky on.

so I close as worksforme

[shtrom-gajim@…]

The chat windows being on another virtual desk doesn't mean I pay no interest in the conversation, but what's the point waiting for an answer without doing anything else ? I just switch to another and try and be productive, but I'd like to know when the contact has answered (and maybe what ?).

Maybe popup notifications should be more configurable the way sound events (which I find to be totally useless :p) are ?

Care to reopen this one ?

[nk]

sound events are very common to everyday users, where as half (or even more) the users of Gajim never use VD. there are two tickets about Gajim and stuff to do with VDs, #835 and #472.

Maybe you can express 'how it should work' there. I see a potential in what you say: "I wanna be productive but I want the guy to reply", but I also see another user saying: "If I have it in another VD it means I do not want to be bugged at this VD"

leave out the fact that I think Gajim does the latter, (but if you u bugreported I think it does not?)

[shtrom-gajim@…]

The problem here is not really with VD handling. But maybe I wasn't clear enough. I will try and rephrase it. First it's not a bug, it's a request for an enhancement: I'd like to be able to set up the notifications (the tiny boxes flashing in the bottom-left of my screen) so that I get one:

1. When a new message starts a conversation (Gajim already does that perfectly)
2. When a new message is received in an already openned, but currently unfocused chat window (unfocused maybe because on another VD but also maybe under another window on the same desk, this is not a VD-related request) (this is the behavior I'd like to have, or at least an option to activate it)

I spoke about the sounds because they are an audible notification and are currently handled exactly the way I would like these visible notifications to be. Let me try and make this clearer. Let's take the current's (0.8.2) preference window, events tab.

There is a list of possible event and an associated sound.

I'd like to have the same functionnality for notifications:

• Currently, the only possible thing as seen in 1. above is "Notify me about it" when new message is received. This is exactly equivalent to (taking the sound list example) show a notification when "first_message_received".
• What I'd like to be implemented (2.) is to have this notification also when "next_message_received" which is not possible at the time

Maybe this sound list can be modified in this way (more of an example to try and show what I'd like than an actual thought that things should be don like this), becoming a "what-to-do-on-event list"

Event	Play sound	Sound file	Show notification
first_message_received	y/n	"path"	y/n
next_message_received	y/n	"path"	y/n
contact_disconnected	y/n	"path"	y/n

And so on.

I'm sorry to argue so hard on this already closed RFE, but it's the feature I'm missing the most since migrating from Gaim with gaim-notifications.

Hope I've made my request clearer this time.

[nk]

yes now I understand and I like your proposal (the table)!

[shtrom-gajim@…]

Hooray !

I owe you a beer ;)

[asterix]

this idea is very nice, but will be in next release: not enough time to do that for the moment I'll add mockup here soon

[nk]

we also need buddy pounce feature. c #664

[Geobert]

Can we hope buddy pounce for 0.10?

[nk]

c #1106 for sound and Jim++ 98% commitable patch

[nk]

for status msg desc and how psi does the whole frame to control those notifications about any event c #1416

[Jim++]

First, I think we can't find a simple AND advanced way to control notifications.

So, I suggest to keep the event tab nearly like it is and to add a button "Advanced notification control" in preferences that open a new window. In this window we have a table quite like shtrom said, but with a dynamic line number :

Event	condition on contact	condition on our status	Show notification	Use urgency hit	Auto open message	Play sound	Sound file
All/single event	All/List	All/List	[ ]	[ ]	[ ]	[ ]	file/None

Important : [ ] can be yes, no, or unspecified, so you change the thing(s) you want for the condition you specified. In the three first columns, "All" mean unspecified.

• The two conditions (columns 2 and 3) can't be both empty. When the two are empty, it must be possible to setup this in actual Events tab of preferences. Exceptions for use urgency hit (ACE option) and one line :

Event	condition on contact	condition on our status	Show notification	Use urgency hit	Auto open message	Play sound	Sound file
All	All	status_lists	[N]	[ ]	[N]	[N]

Which means, "do not notify me when" status_list. I hope we can control this option in both simple (actual) and advanced mode. Because we need a simple way to do that (checkbox, combobox, whatever) but if we don't print it in advanced mode the the logic of this mode is a little broken.

• Then we have buttons :

[Add / Delete] For this part, see how we add filter in kmail may help us. Link : lwn.net/images/ns/mua/kontact/filters.png

• When a new event is raised, notifications control is done by an unique fonction that takes (our) status and jid (of contact) as parameters. And probably event too.

Do you think it's to complicated (for users) ?

PS : This ticket will kill us all I think :D

[asterix]

I suppose the notification control will use the first line that correspond to the event. so we also need 2 other buttons: up and down to move a line up or down.

#1405 is not tacken into account with this design. For that we need another column: show in roster.

We also need another column for systray.

Another thing is that not all events need all these columns, but we can insensitive them. For exemple, contact signed in event don't need use urgency hint.

and latest comment, how to handle both simple and advanced mode? By defaul advanced mode contains no line and notification control first if a line correspond to the event in advanced lines and if no line, look what to do in simple mode ?

[asterix]

mockup

[asterix]

whay about sth like the attached mockup ?

[shtrom-gajim@…]

asterix said: "Another thing is that not all events need all these columns, but we can insensitive them. For exemple, contact signed in event don't need use urgency hint."

I agree that cases like your example might be useless. However, why add specific code to disable the possibility to do this anyway ? Letting the user decide whether he wants his roster to have the urgency hint set would be, IMHO, better than adding code preventing him from doing so and which may frustrate said user (for example while eagerly waiting for his girlfriend to come online (: ).

[nk]

user have ACE to disable urgency and imo we cannot afford to lose more than a week in this ticket as for the vast majority of users having this ticket done or not it's the same thing, and if we lose more time to refactor the way stuff work and all that, we just end up with .10 which has nothing new for the aunt lillie to upgrade. and yes non blocking sockets is big thing on the core, but user wants something he sees in UI and that is "neat", "cool" and all that. and this ticket eventhough UI is not one of those. (well luckily Travis hacked SingleMessagesWindow? but still we need one more big thing)

[Jim++]

"and latest comment, how to handle both simple and advanced mode? By default advanced mode contains no line and notification control first if a line correspond to the event in advanced lines and if no line, look what to do in simple mode ? "

Yes, I wasn't thinking it like this, but this must be the better way to do this.

About your mockup, I think it's great. :) I suppose column names are "auto popup window", "show in roster", etc... Like others software do (kmail notifications), we can use a small icons for column names so the width of the table is not enormous. We probably need a way to tell that specifing jid is optional.

Other notes : We need up/down as you said I suppose. "all" must be in your event combobox. And I don't think any event can be raised when we are offline so we don't need a checkbox for it :p

[Jim++]

We also need a column "name" to easily remember what the line does.

[Jim++]

Maybe we could add a condition "have an open chat with that contact" (See #1682 ) if it's not too complex (for the user also).

[nk]

I think this ticket is the last we should do.

we should say No to some tickets that have been marked as dup of this, we should try to implement the others without bloating the code and the UI and then close this ticket as WONTFIX.

Gajim is an IM client and comparing that to Mail Filtering of Mail Clients is bad nor comparing to the UI of Psi.

The fact that this ticket wants to do it all, means too much wasted time from devs and community as well as bloated code in the "core" of gajim. Last but not least, this is a feature that will scare the everyday chatter and even geeks who find everything cool and neat in reality prefer doing stuff easier and cleaner.

Actually the fact that this is advanced, means we better do other tickets that might be used by 40-70% or more of our users instead of a super hidden window such as this. If this ticket was 1 hour hack, I would not mind that much. But it's not, so I think we better use our time on other tickets and some of the tickets that have been marked as dup of this as I said above.

It is my opinion that Gajim has to fight on UI to become simpler and exposing code logic in UI for sure doesn't do that. Again I better have 5 tickets of our 182 tickets fixed than this.

When I joined Gajim tried to meet demands of all users but was targeting to everyday user. now that we have as somehow easy to use UI we should keep this as gold so we have to deny some more geeky features as dev hours are limited.

those were my 3 euros

[asterix]

it's funny *you* say that. you're working on a ticket for which I disagree, that is closed, and that is for 0.11 instead of working on the tickets you have for 0.10 !

and it won't bloat the code but this will clean the code ! events are very badly handled in the code. This won't bloat the UI as this will only add a button.

[nk]

what ticket is that? if you mean pounce it always was .10 and don't worry I'll deliver my .10 tickets

[jim++]

Idea about how to store it in config :

"special_notifications"
-name
--"conditions"
---cond_name0
----cond_data0
---cond_name1
----cond_data1
--"actions"
---action_name0
----action_data0
---action_name1
----action_data1

(Everything is string)

--"actions" and --"conditions" aren't needed technically but it's more clear.

Sample :

"special_notifications"
-Important people
--"conditions"
---jid
----god@jabber.heaven.org
---event
----first_message, contact_connected
--"actions"
---popup
----yes

[asterix]

ok why not, so it will be in config file this way:

special_notifications.Important people.conditions.jid = god@… special_notifications.Important people.conditions.events = first_message contact_connected special_notifications.Important people.conditions.actions.popup = True ...

it's currently not possible with the current common/config.py cause we can only have 3 level of options. But we can improve it to support that

[nk]

user wants sth he can use and feel shocked about it

[jim++]

Note to self : See #1263

[jim++]

I don't understand why filetransfert-request, -error and -fisnished should

be handled by advanced notifications settings.

Be notified with a popup when receiving a FT from someone, but with others one, only show it in systray ? Do not popup FT requests when 'Do not Disturb' ? I'm not sure this is usefull... Who will use that for these events ?

Specially for -error and -finished, I'm sure we don't need to be able to use advanced settings for their notifications, because we know they will happend so they don't really disturb (else use general settings about that).

[patrys@…]

I'd rather have a grid of some varius sensible options (new conversation,

new message in conversation, file transfer requested, etc.) on one axis and possible notification methods on the other (rather than having to use 666 select boxes and 20 checkboxes to add one goddamn popup window and then make sure the order is right and no other rule gets in the way).

[roidelapluie]

there might be some constants in «launch command»

e.g.

%j will be JabberId? of contact %s will be status %n will be nickname

etc.. It would be very very funny and interresting

[asterix]

beginning of implementation in [209b46d91e70dbe212dd921e5571f3a9bbed394f]

[patrys@…]

Asterix:

You should rather implement a generic event dispatcher that handles objects derived from some GajimEvent? base class and allow hooks to be programmatically attached to certain events. Then your notification code can be moved to an external file and make everything more readable. You wouldn't also have to pass unused fields to methods as different classes could have totally different fields. Furthermore, if external modules were able to add their own hooks, Gajim would be able to handle plugins.

A simple example:

• Gajim starts
• Notification module hooks this.onStatusChange to "user.status"
• User X connects
• Gajim calls event.dispatch(UserStatusChangeEvent?(jid, newstatus, oldstatus))
• Dispatcher looks through the given object and checks the eventType field derived from the base class and gets "user.status"
• Dispatcher checks the list for methods bound to this event
• Dispatcher calls each method, starting with notification::onStatusChange("user.status", eventObject)
• Notification module gets the event type and the object that it's able to typecast into something sensible for that event type
• Notification module return False, as it does not want to abort event handling
• Dispatcher catches that False and decides to call the next hook from the queue and continues doing so until either a hook returns True or all hooks get called

[patrys@…]

A better version:

• Gajim starts
• Notification module hooks this.onStatusChange to "user.status"
• User X connects
• Gajim calls event.dispatch(UserStatusChangeEvent?(jid, newstatus,

oldstatus))

• Dispatcher looks through the given object and checks the eventType

field derived from the base class and gets "user.status"

• Dispatcher checks the list for methods bound to this event
• Dispatcher calls each method, starting with

notification::onStatusChange(eventObject)

• Notification module gets the event object and handles the event
• Notification module return False, as it does not want to abort event

handling

• Dispatcher catches that False and decides to call the next hook from

the queue and continues doing so until either a hook returns True or all hooks get called

One of the modules could be a DBUS module that just passes the event over a DBUS broadcast using org.gajim as the service for example.

[asterix]

see also #2113

[dkirov]

the window needs to be refigned to meet HIG

• The height is longer than my visual area (GNOME with two panels

1024x768 resolution)

• Advanced expander is always expanded, should be the opposite

• window is full of controls, user will get bored comment:28 . This

should be split in two windows - the as in account modification. Moreover, human logic of setting a new condition is wizard alike.

• changing window sizes on control events is agains HIG. generally we

should not show/hide widgets, but make them sensitive/insensitive

• checkbuttons should not work as radiobuttons. There are alternative

ways to achieve the same

• checking one checkbutton makes the other one(s) insensitive
• use combobox with additional value for None (which is equivalent to

unchecking all checkboxes)

• centered titles are against HIG ('Conditions' and 'Actions')

• controls are not aligned. See

[ http://img123.imageshack.us/img123/1184/105710851080108410821072advancednotificationscontrolul0.png scrnshot]

[nk]

just hide the button from prefs to push .11?

[anonymous]

It would also be nice if you could automessage people based on these

events, or other actions, such as remove from roster or invite to chat, etc

[mogorman@…]

something like this  http://astjab.org/picture.png

sorry i am not a glade expert, but being able to do any action based on a status event would be nice, like being able to go away if your ex- girlfriend signed on , or relay presence between two friends. For example a simple introduction, if bob signs on message sue and say hey bob is on. etc would be very cool.

mog

[sb]

(In [ba57658db688350ebd772563c734c74f46283bcf]) change/correct some strings, see #1005 (please say if don't agree)

[Tomas Racek]

It would be nice to have another condition - contact is typing.

[steve-e]

Work on this hasn't been started yet. We won't be able to finish this in time for 0.12. Sad but true.

[Jim++]

Not planning to work on this anymore, sorry.

[steve-e]

See #2791.

[http://olivier.mehani.name/]

From #5314: It would be good if, in addition to preference `notify_on_new_message', there were the possibility to be notified of messages in already open conversation windows which are not visible (hidden by other windows, iconified, in another workspace or viewport) or --maybe much easier-- unfocused.