GNOME Bugzilla – Bug 610549
notification-daemon / message tray should handle "\n" in the body text specially
Last modified: 2010-02-22 22:37:29 UTC
Some notifications may use "\n" to have a multiline body. Marina told me in IRC that this is currently broken, given that my notifications weren't expandable even though they were cut off. Possible fix would be to mark a notification as expandable if "\n" is in the message body. and hmm.... doing notify-send title "$(echo -e "bodytext\nmoretext\nthirdtime")" seems to strip the first \n but not the ones after.
Created attachment 154291 [details] [review] Make multi-paragraph notifications expandable The first newline of the body being converted to whitespace is by design - not sure what's the reasoning behind replacing only the first one, but I assume someone spend more time on the subject than I did. So this patch just checks for remaining newlines in the body when determing whether a notification can pop out ...
Comment on attachment 154291 [details] [review] Make multi-paragraph notifications expandable > The first newline of the body being converted to whitespace is by design - not > sure what's the reasoning behind replacing only the first one, but I assume > someone spend more time on the subject than I did. nope, it's a bug.
Created attachment 154296 [details] [review] [Notification] Replace all newlines in body with spaces (In reply to comment #2) > nope, it's a bug. OK, nevermind.
Attachment 154296 [details] pushed as ec725cc - [Notification] Replace all newlines in body with spaces
.... I can't have multiline bodies now? What's the point of expandable notifications if I can't send a multiline notification? Marina told me that there is word wrapping in place, but I can't add line breaks at my own leisure to help break the flow of different information in the same notiifcation? For example, in a simple test of my notification daemon, it fails to render correctly, while working perfectly fine in notify-osd, giving the result of something like this: Playing: 4. Somewhere Only We Know Artist: Keane Album: Hopes and Fears Genre: Soft Rock Year: 2002 which is completely unreadable. Can an alternate fix/design be proposed that's a little less intrusive? Thanks.
(In reply to comment #5) > I can't have multiline bodies now? Yes you can - the removal of newlines only applies to the unexpanded notification. > For example, in a simple test of my notification daemon, it fails to render > correctly, while working perfectly fine in notify-osd, giving the result of > something like this: > > Playing: 4. Somewhere Only > We Know Artist: Keane Album: > Hopes and Fears Genre: Soft > Rock Year: 2002 > > which is completely unreadable. I agree - problem is that I can't reproduce that at all (I inserted line breaks as I see fit): $ notify-send "Playing: 4. Somewhere Only We Know" "$(echo -e 'Artist: Keane\nAlbum: Hopes and Fears\nGenre: Soft Rock\nYear: 2002')" results in a truncated one-line body - when expanded, the line breaks are exactly where I'd suspect them to be. Can you attach the output of $ dbus-monitor interface=org.freedesktop.Notifications for your notification?
I think JP was just confused about the effect of your patch. However, there is still the problem that notify-send foo "$(echo -e '1\n2\n3')" ought to result in a notification that expands on mouseover (so you can see it with the correct formatting), but it does not.
Created attachment 154444 [details] [review] Always make notifications with '\n' in bannerText expandable (In reply to comment #7) > However, there is still the problem that notify-send foo "$(echo -e '1\n2\n3')" > ought to result in a notification that expands on mouseover (so you can see it > with the correct formatting), but it does not. Ah, I wasn't aware of that - here we go!
Attachment 154444 [details] pushed as f9c5202 - Always make notifications with '\n' in bannerText expandable