Subject: [sup-devel] [PATCH] idle and unidle updates

From: Eric Sherman <[email-masked]>
Date: Wed, 13 Jan 2010 08:56:44 -0500

After talking it over with Rich Lane who suggested I check for idleness 
near the unblocking_getch loop, it made sense to separate it out into its 
own patch.

The :idle and :unidle updates are relayed only once, when transitioning 
from one state to the other.

* Is setting 'main' as the relay sender a problem?
* Is there anything more meaningful to send as the payload than the time of 
the last keystroke?

---
 bin/sup    |   16 ++++++++++++++++
 lib/sup.rb |    3 ++-
 2 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/bin/sup b/bin/sup
index 19b2a87..f4261f4 100755
--- a/bin/sup
+++ b/bin/sup
@@ -260,6 +260,9 @@ begin
     SearchResultsMode.spawn_from_query $opts[:search]
   end
 
+  no_keystrokes_since = Time.now
+  idle = false
+
   until Redwood::exceptions.nonempty? || $die
     c = begin
       Ncurses.nonblocking_getch
@@ -274,9 +277,22 @@ begin
         debug "redrawing screen on sigwinch"
         BufferManager.completely_redraw_screen
       end
+
+      if !idle and Time.now.to_i - no_keystrokes_since.to_i >= ($config[:idle_threshold] || 60)
+        UpdateManager.relay self, :idle, Time.at(no_keystrokes_since)
+        idle = true
+      end
+
       next
     end
 
+    if idle
+      UpdateManager.relay self, :unidle, Time.at(no_keystrokes_since)
+      idle = false
+    end
+
+    no_keystrokes_since = Time.now
+
     if c == 410
       ## this is ncurses's way of telling us it's detected a refresh.
       ## since we have our own sigwinch handler, we don't do anything.
diff --git a/lib/sup.rb b/lib/sup.rb
index b83bbe7..e228772 100644
--- a/lib/sup.rb
+++ b/lib/sup.rb
@@ -230,7 +230,8 @@ else
     :discard_snippets_from_encrypted_messages => false,
     :default_attachment_save_dir => "",
     :sent_source => "sup://sent",
-    :poll_interval => 300
+    :poll_interval => 300,
+    :idle_threshold => 60
   }
   begin
     FileUtils.mkdir_p Redwood::BASE_DIR
-- 
1.6.6
_______________________________________________
Sup-devel mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-devel

---

From: Eric Sherman <[email-masked]>
Date: Thu, 14 Jan 2010 09:31:22 -0500

Excerpts from William Morgan's message of Thu Jan 14 09:22:45 -0500 2010:
> Are you going to send a second patch that makes use of these events to
> do the accumulation?

Yes.  I wanted to wait till this was accepted though since I wasn't sure 
about submitting a patch that depends on another patch.
_______________________________________________
Sup-devel mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-devel

---

From: William Morgan <[email-masked]>
Date: Thu, 14 Jan 2010 09:22:45 -0500

> near the unblocking_getch loop, it made sense to separate it out into its 

Yes, I like this even better, with the same caveat as before about the
config option.

> * Is setting 'main' as the relay sender a problem?

I don't think so.

> * Is there anything more meaningful to send as the payload than the time of 

Probably not. Not a big deal either way.

Are you going to send a second patch that makes use of these events to
do the accumulation?
-- 
William <[email-masked]>
_______________________________________________
Sup-devel mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-devel