[00:42] Unit193: I don't think so [00:42] Then might actually be able to move xfce4-indicator-plugin to desktop. [02:49] maybe someone here knows... how can i restart the gvfs daemon in xubuntu session with debugging options? [08:13] Unit193: could you put that into a bugreport incl a description as to how to reproduce? thanks! (having said that it's probably a pango issue, notifyd does nothing special wrt character encoding) [10:02] ochosi: So far I think I only have "Sit in #freenode long enough to get spam" :P [10:34] Unit193: with what client..? [10:45] notify-osd [10:45] Eg, `notify-send` [18:42] bluesabre: ygm === vinzv_away is now known as vinzv [21:13] notify-osd is not xfce4-notifyd. and notify-send is ok, but how can i reproduce that? what message would i have to send via notify-send? [21:38] notify stack appears to be unicode safe [21:38] its probably the irc client? [21:51] that's why i asked about the irc client... [21:51] Unit193: in case you missed it, that was for you ^ :) [21:51] ochosi: Irssi, as always. [21:51] and do you have a string with which i could try to reproduce? [21:54] i presume the locale is en_US? [21:55] Well that's fun: (xfce4-notifyd-config:9552): Gtk-WARNING **: Failed to set text 'notify-send - Tue 21 Nov 2017 04:54:39 PM EST [21:55] â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„â–„' from markup due to error parsing markup: Error on line 2: Entity name 'acirc' is not known [21:56] and what do you put into notify-send exactly? [21:56] plus, what verson of notifyd is that? [21:56] (as you can see, i could use a bugreport) [21:56] notify-send 'â' 'â' [21:57] prints nothing for the message [21:57] only title [21:58] and i get that same warning in journalctl [21:58] It's a message containing '▄▄▄▄▄▄▄▄▄▄▄▄▄', 0.4.0, and notify-send seems to be fine. I just noticed it since the older one seems to handle it better. [22:02] Unit193: what happens if i highlight you and say Â? [22:02] ali1234: Same deal, it doesn't do UTF8 well. [22:02] i dont think it is utf-8 as such [22:02] it seems like there are two bugs here [22:03] Difference between the old and new one is that the old one drops the message and the new one prints a bunch of fun. [22:03] weird, notify-send 'â' 'â' works fine for me [22:03] but the unicode stuff is not resolved, it's printed as is [22:03] first, your irc client is converting unicode code points into html entities, second something in the notify stack is not handling all html entities [22:03] but not swallowed [22:03] only pango is handled [22:03] not "all html" [22:03] notify-send Â Â works for me [22:04] but the html entity does not [22:04] also, the example from Unit193 also works for me (git master) [22:05] replacing codepoints by the html entity is a common strategy when trying to encode unicode [22:05] it isn't really a bug as such - but in this case it is because the receiver doesn't support html... [22:06] yeah, i don't know of a good way to handle html with glib [22:08] notify-send 'summary' 'Â' <- this works [22:08] and that's the same char [22:08] I can fix that part, but I suppose the puking all over the screen is technically more what it's supposed to do. [22:08] pretty much [22:09] Just not very user friendly. [22:09] saw someone post one the other day that ended up drawing over the next several lines of irc [22:09] unicode is weird [22:10] notify-send "Subject" "\o/" is fun too. :P [22:10] ochosi: Right, so technically not wrong, but just not ideal really. [22:11] i wouldn't mind improving on this, i just have no idea how [22:11] i did look into these issues already at some point before 0.4.0 [22:11] and things were even improved [22:12] btw you guys might like this if you run compiles in the bg all the time: http://paste.ubuntu.com/26015297/ [22:12] but yeah, the status quo is what it is [22:12] alias make='notify-when-done make' [22:12] get a notification when it finishes, with the runtime and return code [22:13] sounds nice [22:13] will have to try that [22:13] crap, screenshooter fails to upload [22:14] Unit193: so this is also what you get..? https://imgur.com/a/mlUbj [22:16] ochosi: "nothing"? I get more than nothing. [22:16] ehm, what do you mean "nothing"? [22:17] the ▄ characters look ok in my notification bubble [22:17] the ▄ have nothing to do with it [22:17] that was one example from above [22:17] the problem is caused specifically when Â is sent as a html entity by name [22:20] ochosi: There didn't appear to be an image in that link, at least for me. [22:20] press reload [22:20] rly? [22:20] imgur looks ok for me [22:20] it didnt load for me either, at first [22:20] i would post a screenshot of it, but... [22:20] ;) [22:20] ...Alright, did that a few times and didn't, now it did. Thanks? [22:21] ochosi: I mean, either way I suppose thanks since I fixed it now, buuut. :3 [22:21] so two ways to fix this bug: [22:22] one, make irssi emit numerically escaped code points instead of the html named entities [22:23] two, make notify daemon accept html entities [22:23] three, make irssi output real utf-8, and make notify daemon ignore escaped entities entirely [22:24] option three sucks a little, because pango markup support is already there and in theory some html entities *should* be handled according to the notification spec [22:24] I wonder why the old one didn't print garbage. :3 [22:24] they probably changed pango *shrug* [22:24] it just swallowed certain things [22:25] no, i changed some stuff [22:25] hmm okay if handling them is part of the spec [22:25] I used option three, pretty much. [22:25] then irssi is at fault [22:25] Well, stopped html encoding it and ran a sub on '\' [22:26] pidgin does a good job rendering unicode :) [22:26] at least i thought i did, need to find the commit... [22:26] also i never saw it send a messed up notification either [22:26] Irssi displays them fine, it's rnotify.pl that's at fault. [22:26] oh, your plugin? [22:27] I stole it from somewhere of course, but yeah. It expects one to handle html encoded. [22:27] i would say, if you are able, encode everything as utf-8 and don't mess with it further [22:28] Yeah I disabled the html encoding (and added 's/\\/\\\\/g' to the script.) [22:28] what for with the regex? [22:28] auto escape slashes? [22:28] hmm [22:28] i wonder if that is part of the spec too [22:29] and what the person who wrote it was thinking [22:30] https://git.xfce.org/apps/xfce4-notifyd/commit/?id=8265b411339a390768f2c94f2bc2e0f9983da04b [22:30] there you go, that's the relevant change ^ [22:31] hmm [22:31] well the spec is the spec [22:31] are you sure it says to not handle named entities though? [22:32] let me guess, it isn't actually specific? [22:32] iirc it isn't [22:32] https://developer.gnome.org/notification-spec/#markup [22:33] i think what's above is pretty much what we currently support [22:33] also https://wiki.ubuntu.com/NotifyOSD#Body_text [22:33] neither seems to mention entities tho [22:34] they don't actually specify the text encoding at all [22:34] if you want to see how far we currently follow the spec: https://docs.xfce.org/apps/notifyd/spec [22:34] i think everyone just uses pango [22:34] yep [22:34] not sure if notify-osd isn't a little dead with unity being dead [22:35] and nobody can implement a replacement even if they wanted to, because the spec is insufficient to do so [22:37] \o/ [22:38] https://wiki.ubuntu.com/NotificationDevelopmentGuidelines#If_a_notification_uses_a_hyperlink_or_text_formatting.2C_but_it.2BIBk-s_showing_up_as_plain_text [22:38] (and the following sections) [22:38] that's what you were looking for i think [22:38] nah, hyperlinks are unrelated [22:38] this is about text encoding ;0 [22:39] the next section however... [22:39] yes, i said: and the following sections ;) [22:39] yeah, sorry :) [22:39] i like the "[This example code will be provided soon.]" :D [22:39] so it should not try to interpret them [22:40] or it should interpret them all, depending on what it advertises [22:41] ugh they could have choses less confusing examples there [22:42] hmmmmmm [22:45] i think what this is saying is that & should be transformed to & by the program sending the message - ie any entities should be escaped, which means the notifyd will never have to interpret them [22:45] so what it does when it gets one is still undefined, but it should never get one [22:46] btw, i may have a more intruiging problem to debug for oyu [22:46] if you're at all interested [22:47] oh? [22:47] so i've been working on the xfce4-panel port for a while [22:47] and it's mostly stable now and i think we've reached feature-parity [22:47] (i don't ever get crashes etc) [22:47] but there is some odd behavior with respect to autohiding and intelli-hiding the panel [22:48] somehow the signals have doubled since gtk2, even though (or because?) the code is still the same [22:48] hmm double signals [22:48] and that makes the panel sometimes "flicker" (i.e. pop up and down quickly) [22:48] what signal specifically? where does it come from? [22:49] i don't know how any of that stuff works [22:49] is this a multimonitor setup? [22:49] so the way this works is there are two panel windows. one is an "autohide window" that is just 3px tall (for being able to reveal the panel again), the other is the actual panel window [22:49] one is always offscreen (at -9999/-9999) [22:51] and then with gtk_window_move the two windows change places and with a gtk_widget_queue_resize these updates should be triggered [22:51] why is it off screen rather than just being hidden? [22:51] the size_allocate signal is triggered (maybe too often?) and then the windows are really moved around [22:51] phu, no idea, i didn't question those decisions yet [22:52] i wanted to avoid having to rewrite that part tbh [22:53] i also have a branch that prints quite a lot of debug info so you can more easily follow what's going on [22:53] i can push that to a user repo if you'd be willing to take a look [22:54] (my eyes are just weary from looking, a fresh pair of them maybe see what's wrong more quickly) [22:54] window->autohide_state == AUTOHIDE_HIDDEN [22:54] what does this actually mean? [22:54] and POPUP too [22:55] that's handled in panel_window_size_allocate [22:55] yes i know [22:55] but what does it mean? [22:55] if it is true, what is that telling me about the window? [22:56] it means that the current state is that the autohide-window is shown and the panel window is hidden [22:56] the else hides the autohide-window [22:56] okay and what about POPUP? [22:57] i think POPUP is set while the panel is still hidden but it may be in the process of being shown [22:58] so the POPUP (unhide) is queued [22:58] but the panel is still hidden [22:58] because it [22:58] 's scheduled via the g_timeout_add_full [22:58] via panel_window_autohide_queue [22:58] hmm, so that means "if the panel is shown or about to be shown" [22:59] "if the panel is hidden or about to be shown but not yet shown" [22:59] but it says autohide_state == HIDDEN [22:59] yes, that means the panel is hidden [22:59] the autohide-window is shown [23:00] ah yes, window-> vs window->autohide_window [23:00] yup [23:00] that's what i tried to explain earlier with moving the autohide window offscreen [23:00] so the first block is hiding the panel and showing the autohide [23:00] and the second bit is hiding the autohide and shoing the panel [23:00] yup, the else is for showing the panel [23:01] which way does the flicker happen? [23:01] one reason why i stumbled across the signal issue was that i wanted to try to implement a "slide out" animation for the panel [23:01] so it's clearer visually "where it goes" [23:02] https://bugzilla.xfce.org/show_bug.cgi?id=13640 [23:02] bugzilla.xfce.org bug 13640 in General "Intelligent hiding: panel jumps out and in again (regression from 4.12.1)" [Normal,New] [23:02] the first comment has an instruction to reproduce [23:03] the later comment from Andre is not a regression [23:03] i can't install gtk3 stuff at the moment [23:03] you can try using the xfce-test docker container [23:03] does this happen at the top or the bottom panel? sides? [23:03] it compiles the panel within the container and you get access to it via xephyr [23:03] i only tested the top panel [23:04] i tried that once and i just got a black screen but i can try it again if you link me the instructions again :) [23:04] maybe that makes a difference, i never thought of testing other panel locations [23:04] https://github.com/schuellerf/xfce-test [23:04] the usage etc is in the readme.md [23:07] docker: Error response from daemon: invalid header field value "oci runtime error: container_linux.go:247: starting container process caused \"process_linux.go:334: running prestart hook 0 caused \\\"fork/exec /usr/bin/dockerd (deleted): no such file or directory\\\"\"\n". [23:08] yeah i really don't want to dig into that :/ [23:08] did you pull from docker.io or build it locally? [23:08] the latter should always work [23:08] i followed the instructions in the readme [23:09] is the docker daemon running though? [23:09] i have absolutely no idea [23:10] :> === vinzv is now known as vinzv_away [23:42] okay it's working :) [23:44] i can't reproduce