You are not logged in.

#351 2013-05-27 16:56:18

r4
Member
Registered: 2009-10-20
Posts: 19

Re: dunst - a dmenu-ish notification daemon

Glad to hear I'm not the only one noticing this.

Offline

#352 2013-05-28 14:57:13

raining
Member
Registered: 2012-04-27
Posts: 21

Re: dunst - a dmenu-ish notification daemon

progandy wrote:
ninian wrote:
r4 wrote:

For some reason dunst doesn't seem to respect my timeouts consistently.

Hmm... I'm using 10 second timeouts for urgency low and normal and I could swear sometimes the message persists for about 3 x longer.
Haven't pinned it down consistently though.

I have seen it too. messages stay too long, until a new one pops up or sometimes forever. If I use the history function, the window doesn't update properly either. I cannot find the reason, though.

I am facing the same inconsistency as well. Sometime everthing piles up untill i click on it to make it disappear.

btw. Thanks You, knopwob for making such an awesome program.

Offline

#353 2013-06-04 20:11:00

onebitaway
Member
Registered: 2013-02-11
Posts: 1

Re: dunst - a dmenu-ish notification daemon

Observing strange behavior with timeouts here.
Most of the time notifications stay until manually closed, although sometimes they expire as expected.
Using notify-send and tested dunstify from the git repository.

notify-send -t 5 title message
dunstify -t 5 title message

both with the same result.

Offline

#354 2013-06-10 16:36:17

progandy
Member
Registered: 2012-05-17
Posts: 5,180

Re: dunst - a dmenu-ish notification daemon

I may have a fix ready. https://github.com/progandy/dunst/


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#355 2013-06-10 18:18:48

firecat53
Member
From: Lake Stevens, WA, USA
Registered: 2007-05-14
Posts: 1,542
Website

Re: dunst - a dmenu-ish notification daemon

Hey, I don't know if this is a dunst quirk, or something with the lightweight screen lockers, but if a notification is received with either i3lock or sflock (only 2 I've used) engaged, then you can see a unreadable wavy/discolored area on top of the lock screen where the notifications would normally sit. I think I would expect to see nothing at all. If you need more info, let me know.

Thanks!
Scott

Offline

#356 2013-07-07 18:32:10

zeltak
Member
From: New England
Registered: 2010-08-07
Posts: 168

Re: dunst - a dmenu-ish notification daemon

Hi all

i decided finally after a few months of dust to further config dunst but running into an issue with the specific color optione per app

i have something like this:

[sxhkd]
    appname = sxhkd
    timeout = 0
    background = "#000000"
    foreground = "#dddddd"

i know its wrong in syntax since its not really working, how does one specift per app colors, is it based on wm_class, instance etc?

thx alot

Z

Offline

#357 2013-07-08 11:51:34

knopwob
Member
From: Hannover, Germany
Registered: 2010-01-30
Posts: 239
Website

Re: dunst - a dmenu-ish notification daemon

zeltak wrote:

Hi all

i decided finally after a few months of dust to further config dunst but running into an issue with the specific color optione per app

i have something like this:

[sxhkd]
    appname = sxhkd
    timeout = 0
    background = "#000000"
    foreground = "#dddddd"

i know its wrong in syntax since its not really working, how does one specift per app colors, is it based on wm_class, instance etc?

thx alot

Z

You can run dunst -verbose in a terminal to see what the  programs are sending as their appname.

Offline

#358 2013-07-08 21:20:05

zeltak
Member
From: New England
Registered: 2010-08-07
Posts: 168

Re: dunst - a dmenu-ish notification daemon

Hya

thx for the answer!

the problem i guess is that all apps give the same appname, IE

appname: 'notify-send'
    summary: 'interrobang'
    body: ''
    icon: ''
    urgency: 1
    formatted: 'interrobang'
    fg: #FDBE6A
    bg: #000000
    id: 76
    script: (null)


can i use the summary to create the per app colors, am i missing something, arent all app names going to be notify-send?

thx again

Z

Last edited by zeltak (2013-07-08 21:20:53)

Offline

#359 2013-07-08 22:37:58

progandy
Member
Registered: 2012-05-17
Posts: 5,180

Re: dunst - a dmenu-ish notification daemon

can i use the summary to create the per app colors, am i missing something, arent all app names going to be notify-send?

The appname should be uniqe to the application creating the notification. That's why it is called appname. notify-send lets you define the appname manually since it is designed to be used in different scripts.
As for the rule matching I quote the example dunstrc

# Messages can be matched by 'appname', 'summary', 'body' or 'icon'
# and you can override the 'timeout', 'urgency', 'foreground', 'background'
# and 'format'.
# Shell-like globbing will get expanded.

Last edited by progandy (2013-07-08 22:43:18)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#360 2013-07-11 23:26:54

madalu
Member
Registered: 2009-05-05
Posts: 217

Re: dunst - a dmenu-ish notification daemon

Great tool! Might I request a configuration option to turn off the context menu and url detection? The URL regexp detection picks up mailto addresses, but does so inconsistently. For instance "some.address@gmail.com" becomes "gmail.com" in the context menu. Since my primary use for notify-send is to broadcast new emails, I would prefer not to see the "(U)" at the start of every notification.

Last edited by madalu (2013-07-11 23:28:37)

Offline

#361 2013-08-09 12:50:30

manuelschneid3r
Member
From: Germany
Registered: 2013-04-14
Posts: 152

Re: dunst - a dmenu-ish notification daemon

Pretty cool. thanks! But make an option making dunst capable of overwriting notifications, that are sent from the same app. I would need it for a "Volume Notification" in case of change.

Regards


Please feel free to correct my english.

Offline

#362 2013-08-09 15:11:03

progandy
Member
Registered: 2012-05-17
Posts: 5,180

Re: dunst - a dmenu-ish notification daemon

manuelschneid3r wrote:

Pretty cool. thanks! But make an option making dunst capable of overwriting notifications, that are sent from the same app. I would need it for a "Volume Notification" in case of change.

Regards

dunst supports the complete notification protocol (except some graphical extensions like images)
You can replace a notification if you use the same id, only notify-send does not support it. You'll need to download the dunst source and compile "dunstify" which supports this. On the first call store the notification id in a temp file. on succesive calls reuse it. There is an example called replace in https://github.com/knopwob/dunst/blob/m … st/test.sh


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#363 2013-09-20 22:50:30

awh
Member
Registered: 2012-08-18
Posts: 4

Re: dunst - a dmenu-ish notification daemon

firecat53 wrote:

Hey, I don't know if this is a dunst quirk, or something with the lightweight screen lockers, but if a notification is received with either i3lock or sflock (only 2 I've used) engaged, then you can see a unreadable wavy/discolored area on top of the lock screen where the notifications would normally sit. I think I would expect to see nothing at all. If you need more info, let me know.

Thanks!
Scott

Came to this thread to report the same thing.
I assume you SIGUSR1'd dunst before locking your screen like me?
I got a strace (-fv) of dunst when this happens: http://paste.ubuntu.com/6134805/
For me the wavy area is just a big black box.


Alex | GPG: 40A40800
GPG FP: F892 4C01 38F1 F9AC 19CD  2185 6D04 3557 40A4 0800

Offline

#364 2013-12-30 05:54:40

3xOSC
Member
Registered: 2013-03-18
Posts: 107

Re: dunst - a dmenu-ish notification daemon

my dunstrc that's living in my ~/.config/dunst/ folder simply isn't being read (checked with strace) but the changes aren't applying, does anyone know why?

EDIT:  solved, turns out i needed to restart my computer.   weird o_O

Last edited by 3xOSC (2013-12-30 06:04:17)

Offline

#365 2014-01-12 15:35:53

milomouse
Member
Registered: 2009-03-24
Posts: 940
Website

Re: dunst - a dmenu-ish notification daemon

May have missed it, but is there a way to stack messages horizontally instead of vertically?

What I mean is... if you get a message notification, it's displayed where you specified it to in the dunst config, but if you receive another message before the previous one times out then it is stacked below the previous one, and these continue to stack vertically (downwards) with each new message in this fashion.   I was wondering if you could stack them beside (left/right) each other in a line of sorts.. instead of a column below/above each other.

If this functionality exists I apologize as I must have missed it.  If not, then what do you think about it?

Offline

#366 2014-01-12 15:37:45

milomouse
Member
Registered: 2009-03-24
Posts: 940
Website

Re: dunst - a dmenu-ish notification daemon

3xOSC wrote:

my dunstrc that's living in my ~/.config/dunst/ folder simply isn't being read (checked with strace) but the changes aren't applying, does anyone know why?

EDIT:  solved, turns out i needed to restart my computer.   weird o_O

If dunst was already running before you made changes in the config, I think you need to kill it before your new config changes are recognized, I believe?

Offline

#367 2014-04-20 18:38:28

faiden
Member
Registered: 2014-03-08
Posts: 22

Re: dunst - a dmenu-ish notification daemon

If you're piping the logs from journald into dunst via a script and if you have some ignore entries in dunstrc then dunst will be stuck in an endless loop telling you what notification it has skipped.

Is there an option to turn off logging what dunst is skipping? If not, could an option for this be added?

Offline

#368 2014-06-26 10:27:30

hobarrera
Member
From: The Netherlands
Registered: 2011-04-12
Posts: 355
Website

Re: dunst - a dmenu-ish notification daemon

I've a very odd issue with dunst.
I've two computers, a laptop and a desktop, both with i3 and identical configurations, and all the latest packages from the official repos.

On my laptop, alt+space dismisses the notifications, on the desktop, it does not (nothing happens). stdour/stderr show nothing, and I've no idea what to try. What can be causing this issue? What should I look at? My configuration is available here

Offline

#369 2014-07-16 20:03:07

hobarrera
Member
From: The Netherlands
Registered: 2011-04-12
Posts: 355
Website

Re: dunst - a dmenu-ish notification daemon

Is there any chance of getting rounded borders? Or would that be a paint to implement?
I'd also sort-of like double frame: Grey notification bg, a white frame, and a black 1px frame outside that. Is that possible, or am I getting too picky?

Thanks!

Offline

#370 2014-09-11 16:17:58

dejy
Member
Registered: 2014-03-18
Posts: 67

Re: dunst - a dmenu-ish notification daemon

Is there a way to make Notifications go to the same box (Override the previous notify box), as opposed to spawning it's own new Notify event?

For example running a bash-script for notifying on Caps-lock state the following problem occurs (if one changes Capslock several times before the time out intervals)

#*press capslock 
    < Capslock ON>
#*press capslock 
   < Capslock ON>
   < Capslock OFF>
#*press capslock 
   <(1) Capslock ON>
    < Capslock OFF>
#*press capslock 
  <(1) Capslock ON>
 <(1) Capslock OFF>

So generally it will like this: 
<(1) Capslock ON>
<(1) Capslock OFF>

Which is not priority sorted and completely ambiguous. (And there are a number of notification events for which this would not make sense).
One alternative is to use a Python script and Notification.close(), but it also seems awkward to run a .py script and import subprocess / evdev libraries just for two lines of bash script.

Anyways if there is a way to notify-send into a single-box, or other effective work arounds, that would be great to know.

Last edited by dejy (2014-09-11 17:37:51)

Offline

#371 2014-09-11 16:41:11

hobarrera
Member
From: The Netherlands
Registered: 2011-04-12
Posts: 355
Website

Re: dunst - a dmenu-ish notification daemon

dejy wrote:

Is there a way to make Notifications go to the same box (Override the previous notify box), as opposed to spawning it's own new Notify event?

For example running a bash-script for notifying on Caps-lock state the following problem occurs (if one changes Capslock several times before the time out intervals)

#*press capslock 
    < Capslock ON>
#*press capslock 
    < Capslock OFF>
#*press capslock 
 <(1) Capslock ON>
#*press capslock 
 <(1) Capslock OFF>

So generally it will like this: 
<(1) Capslock ON>
<(1) Capslock OFF>

Which is not priority sorted and completely ambiguous. (And there are a number of notification events for which this would not make sense).
One alternative is to use a Python script and Notification.close(), but it also seems awkward to run a .py script and import subprocess / evdev libraries just for two lines of bash script.

Anyways if there is a way to notify-send into a single-box, or other effective work arounds, that would be great to know.

Rather than a mere script, I'd have a tiny daemon that updates the same notification, and signal that daemon.

Offline

#372 2014-09-11 17:17:00

dejy
Member
Registered: 2014-03-18
Posts: 67

Re: dunst - a dmenu-ish notification daemon

hobarrera wrote:
dejy wrote:

Is there a way to make Notifications go to the same box (Override the previous notify box), as opposed to spawning it's own new Notify event?

For example running a bash-script for notifying on Caps-lock state the following problem occurs (if one changes Capslock several times before the time out intervals)

#*press capslock 
    < Capslock ON>
#*press capslock 
    < Capslock OFF>
#*press capslock 
 <(1) Capslock ON>
#*press capslock 
 <(1) Capslock OFF>

So generally it will like this: 
<(1) Capslock ON>
<(1) Capslock OFF>

Which is not priority sorted and completely ambiguous. (And there are a number of notification events for which this would not make sense).
One alternative is to use a Python script and Notification.close(), but it also seems awkward to run a .py script and import subprocess / evdev libraries just for two lines of bash script.

Anyways if there is a way to notify-send into a single-box, or other effective work arounds, that would be great to know.

Rather than a mere script, I'd have a tiny daemon that updates the same notification, and signal that daemon.

So what you mean (correct me if i'm wrong) is something like having a little python daemon receiving socketIO events on keypress - and updating the notifications from there?

And I take it that's a no, on updating a new message to the same notification window (maybe forking dunst, to enable something like this would be preferable?)

Offline

#373 2014-09-11 17:37:07

progandy
Member
Registered: 2012-05-17
Posts: 5,180

Re: dunst - a dmenu-ish notification daemon

If you use dunstify instead of notify-send, you can store and set the notification id in order to replace a message. dunstify is part of the dunst sources, but not included in the arch package.

wget https://raw.githubusercontent.com/knopwob/dunst/master/Makefile
wget https://raw.githubusercontent.com/knopwob/dunst/master/dunstify.c
touch config.mk
make dunstify

dunstify -p ... >nid
dunstify -r $(<nid) ...

Last edited by progandy (2014-09-11 17:40:17)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#374 2014-09-11 17:45:33

dejy
Member
Registered: 2014-03-18
Posts: 67

Re: dunst - a dmenu-ish notification daemon

progandy wrote:

If you use dunstify instead of notify-send, you can store and set the notification id in order to replace a message. dunstify is part of the dunst sources, but not included in the arch package.

wget https://raw.githubusercontent.com/knopwob/dunst/master/Makefile
wget https://raw.githubusercontent.com/knopwob/dunst/master/dunstify.c
touch config.mk
make dunstify

dunstify -p ... >nid
dunstify -r $(<nid) ...

+1, exactly what I needed.

Offline

#375 2015-05-18 08:29:03

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,354

Re: dunst - a dmenu-ish notification daemon

knopwob wrote:
progandy wrote:
knopwob wrote:

exactly. an A would indicate an Action btw. and the url detection gets a lot of false positives. But I prefer this to wrongly not detected urls. patches that improve url detection are welcome. see menu.c

I added a commit to my fork, feel free to cherry-pick this and any other commit I made
https://github.com/progandy/dunst/commi … 78ee1a0288

I've picked most of your commits (not yet pushed to my github) except for the two icon related commits. I've not yet decided wether I want to merge those, since I'm thinking about adding real icon support. Anyway thank you for your efforts.

Any update on the icon support?

Edit: ignore me please, trigger-happy posting.

Last edited by ngoonee (2015-05-18 09:22:49)


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

Board footer

Powered by FluxBB