Here is a link on the package in AUR:
https://aur.archlinux.org/packages/sind-git/
and the discussion link
https://bbs.archlinux.org/viewtopic.php?id=160366
jasonwryan wrote:Anyone else seeing dropbox crash with statnot?
process 7632: Array or variant type requires that type string be written, but end_dict_entry was written. The overall signature expected here was 'susssasa{ss}' and we are on byte 10 of that signature. D-Bus not built with -rdynamic so unable to print a backtrace
I'm getting the same problem, though not sure what a solution is.
I've filed a bug report with dropbox. In their words, " Dropbox engineers are aware of the problem and are working on a solution. We do not directly support Arch-Linux, but we'll try to fix it!" That was a day after I posted in this thread...
]]>Anyone else seeing dropbox crash with statnot?
process 7632: Array or variant type requires that type string be written, but end_dict_entry was written. The overall signature expected here was 'susssasa{ss}' and we are on byte 10 of that signature. D-Bus not built with -rdynamic so unable to print a backtrace
I'm getting the same problem, though not sure what a solution is.
]]>process 7632: Array or variant type requires that type string be written, but end_dict_entry was written.
The overall signature expected here was 'susssasa{ss}' and we are on byte 10 of that signature.
D-Bus not built with -rdynamic so unable to print a backtrace
# edit: nvm: missed it in the conf file...
]]>However i want to share my setup with 2 windows managers and 1 config file:
This is my statnot.conf
DEFAULT_NOTIFY_TIMEOUT = 5000 # milliseconds
MAX_NOTIFY_TIMEOUT = 7000 # milliseconds
NOTIFICATION_MAX_LENGTH = 100 # number of characters
STATUS_UPDATE_INTERVAL = 3.0 # seconds
# export WMNAME in ~/.xinitrc before the windows manager start
import os
STATUS_COMMAND = ['/bin/bash', '%(HOME)s/scripts/%(WMNAME)s/statnot-statusline.sh' % {'HOME': os.getenv('HOME'), 'WMNAME': os.getenv('WMNAME')}]
USE_STATUSTEXT=True
QUEUE_NOTIFICATIONS=True
WMNAME needs to be exported in .xinitrc. My scripts are placed in $HOME/scripts/$WMNAME/statnot-statusline.sh
--------------------------
My statnot scripts are used in conjunction with dzen2. This is one of my statnot-statusline.sh script that plays well with dzen2 using a named pipe:
# Create the named pipe
[ ! -p /tmp/statnot ] && mkfifo /tmp/statnot
if [ $# -eq 0 ]; then
# Get date
date=$(echo "^fg(grey)"$(date '+%A %d %B %Y') ; echo "^fg(cyan)"$(date '+%H:%M'))
# Echo results
echo $date >> /tmp/statnot
else
# Echo notification
echo "NOTIFICATION: $1" >> /tmp/statnot;
fi
Obviusly, dzen2 must be started somewhere like this:
tail -n1 -f /tmp/statnot | dzen2
Anyway, the default way you use statnot has functionality which is duplicated in wmii, so I thought I might share my setup.
I launch statnot as:
statnot ~/.config/statnot/config.py &
~/.config/statnot/config.py contains:
def update_text(text):
import os
file = open("%s/.config/statnot/notification" % os.getenv("HOME"),"w")
file.write(text)
file.close()
~/.statusline.sh contains:
if [ $# -ge 1 ]; then
echo "NOTIFICATION: $1 | ";
fi
And somewhere in my wmiirc is:
status() {
echo -n $(cat ~/.config/statnot/notification) 'Wireless' $(iwconfig wlan0 | sed 's/ /\n/g' | grep Quality) '|' $(date)
}
So any notifications found by statnot are put at the start of the wmii status line.
Amazing script, saved me reinventing the wheel (again)
]]>Scott
]]>To disable queueing, i.e. showing the most recent notification, configure as such:
QUEUE_NOTIFICATIONS=False
The project moved from my domain to github, so the few added lines of documentation is at http://github.com/halhen/statnot.
Let me know if I screwed up somewhere.
]]>Scott
]]>It would be ideal for the most recent notification to supersede the existing one.
That this is not the case, is by design. Notifications can come from many places at the same time and build a queue, where each one should show for a certain amount of time if it asks to. I can't think of a way to handle both queue-able notifications and lower priority ones at the same time without adding unproportional complexity. I could add a configuration option to ignore queueing and always show only the most recent one, for the amount of time it asks to be shown.
Example:
* 12:00:00 You receive a chat message that should show for 60 seconds.
* 12:00:15 You receive another message, which replaces the old and shows for 60 seconds
* 12:01:15 The regular status line shows
Example 2:
* 12:00:00 You receive a chat message that should show for 60 seconds
* 12:00:02 A volume update comes along with -t 0, and replaces the chat message
* 12:00:04 The regular status line shows
Would that be useful to you?
]]>Sara wrote:So in short, if you do
notify-send -t 0
you'll get the desired effect. Happily, not hackish at all .
I just tried this and found that the notifications NEVER timed out and stayed up on the screen forever until closed
Really? And the regular updates are working when you dont try the -t 0 stuff?
Try
# notify-send -t 5000 "five seconds"; notify-send -t 0 "should not see"; notify-send -t 0 "for a tick";'
You should see the "five seconds" for five seconds, next "for a tick" for two seconds, and then back to your normal statusbar.
I'm happy to take a look at your ~/.statusline.sh if you think another set of eyes can help.
]]>I'm still playing with my weechat notifications -- I have them stay in the status bar for longer: about a minute, so this trick of setting -t0 doesn't work. It would be ideal for the most recent notification to supersede the existing one.
Scott
]]>So in short, if you do
notify-send -t 0
you'll get the desired effect. Happily, not hackish at all .
I just tried this and found that the notifications NEVER timed out and stayed up on the screen forever until closed
]]>Cool thanks for the update! Using it here and it works great. I think this is more of a libnotify question that I asked in a different thread, but maybe you know...is there a way to override an older notification of the same urgency with a newer notification. For example, when changing volume and displaying it with notify-send into the dwm status bar with statnot, each push of the vol up/down button sends the notification, which stays for it's alloted 3 seconds before displaying the next volume level. So if I hit vol-down like 6 times in a row, I get, well, 6 3 second notifications. Any way to hack that to only see the last one? Hope I'm making sense!
Thanks!
Scott
Actually, he's posted a solution for this at his website. Here's the pertinent stuff:
notify-send can also be used for other, more direct messages. For exampe, I call a script called dwm-volume when my volume media buttons on the keyboard are pressed. This script adjusts the volume and sends a notification containing e.g. vol [52%] [on].
#!/bin/sh if [ $# -eq 1 ]; then amixer -q set Master $1 fi notify-send -t 0 "`amixer get Master | awk 'NR==5 {print "vol " $4, $6}'`"
As you can see, I use the option -t 0 to notify-send, i.e. I request that the notification should show for zero milliseconds. For statnot, this means that the message should show for a regular status tick, by default two seconds, but if other notifications arrive, like a second press on the volume button, it goes away. This setup allows my audio volume to show only when I change it, while it updates instantly when I press the media buttons.
So in short, if you do
notify-send -t 0
you'll get the desired effect. Happily, not hackish at all .
]]>