From b9eb6e084b67973eb132a0b94e31730fafc0a8c5 Mon Sep 17 00:00:00 2001 From: kostix Date: Wed, 8 Apr 2009 00:19:48 +0000 Subject: Update TODO list git-svn-id: http://svn.xmpp.ru/repos/tkabber-3rd-party/trunk/plugins/urgent@210 cc602e41-bd33-0410-9637-a208f32f1443 --- TODO | 33 ++++++++++++++++++++++++++++----- 1 file changed, 28 insertions(+), 5 deletions(-) diff --git a/TODO b/TODO index c124073..b08d186 100644 --- a/TODO +++ b/TODO @@ -1,6 +1,29 @@ -Looks like under certain circumstances got_focus_hook - can be fired earlier than open_chat_post_hook, - and its handler fails because it looks at the per-chat - state open_chat_post_hook handler initializes. - A workaround is needed. +* Reaction on "personal" messages should take into account + groupchat "highlights" as well as private chat messages. + This possibly could be accomplished by hooking not + the drawing of messages by some event which is generated + when a chat tab/window title is updated. + +* Sometimes, it looks like the urgency flag is not dropped + when a (toplevel) chat window seemingly gets focus. + The reason *might* be a race condition between two + parallel copies of `urgent`, of which one tries to + clear the urgency flag, and another one tries to set it. + + The only sensible way to prevent such race conditions + seems to be turning `urgent` into a Tcl extension. + + Another way could be to not just [exec ... &] the `urgent` + binary, but read its stdout asynchronously while queueing + urgency flag manipulation requests. + This seems compilcated though. + + Yet another possible solution is to make `urgent` read + the flag manipulation commands on its stdin continuously. + Then we could permanently spawn just one copy of `urgent` + at startup and feed it with commands. + Serialization of commands would happen automatically + while maintaining good speed of processing. + +* Think about turning `urgent` into a Tcl package. -- cgit v1.2.3