It might be due to Chromium, IIRC it has restrictions for notifications created outside of web workers. Someone would need to look into all of this again to confirm.
Yes, I think this is the case. From the KDE settings: "This application does not support configuring notifications on a per-event basis". So even with your notification daemon this would probably have to be configurable from gamja itself.
(I also think that a timeout on the notifications would be the saner default to have, as again, this is what other chat services do. But doesn't make sense to debate this)
I'm not sure. I don't want to miss notifications.
Then please make it configurable. Having to manually dismiss every notification is very annoying if you have a lot coming in (especially since they paint over fullscreen applications but you cannot interact with them there - you have to exit the fullscreen application to dismiss them).
Should already be the case. If not, sounds like a browser or DE issue.
I just checked again with gamja master. This is not the case for me. And I think the KDE/Chromium combination is common enough that it could be worth taking another look at this, if you have the time.
It's a bit hard to tell for me what exactly the bug report is from that chat excerpt... So apologies if this is a duplicate.
But yes, I mean the list of channels you had open last time should persist. I can imagine this is a very, very important feature to have for a large class of users.
Thanks again in advance for considering to implement this.
Environment: Generic "Linux desktop" with KDE and Dbus running, Chromium. Chromium uses the native KDE notifications.
When receiving a message, the notification from Chromium/gamja stays around forever, instead of vanishing after some time as it should. One has to manually click X to remove it.
I think the notification should appear for 5 seconds, this is the timeout web clients of some chat services use.
Another thing which would be important for a good notification experience: clicking on the notification should take you to the gamja tab and open the channel with the message the notification was issued by. Again, this mirrors behaviour other services implement and thus is expected by users.
Just tried master. The error message does not appear anymore, but the behaviour is the same - private message channels disappear after closing.
I'm using gamja in combination with soju (network: rizon), and only regular channels stay after closing it - private message channels aren't present after re-opening gamja.
When receiving a private message while gamja is open, the channel reappears, with history working as expected.
This is the final piece missing to make gamja usable for me (along with the duplicate messages bug).
When opening gamja, I get
FAIL CHATHISTORY UNKNOWN_COMMAND TARGETS Unknown command- I assume this doesn't work yet because soju hasn't implemented
All of them fail with
failed to start TLS listener on "ircs://irc.rizon.net": listen tcp 188.8.131.52:6697: bind: cannot assign requested address
nc -zv irc.rizon.net 6697 irc.rizon.net ([2602:fd9a:a:b::10]:6697) open
znc works just fine with
Server = irc6.rizon.net +6697.
Soju config file:
db sqlite3 /var/lib/soju/main.db log fs /var/lib/soju/logs/ tls /etc/ssl/soju/cert.pem /etc/ssl/soju/key.pem listen ircs://irc.rizon.net
Not sure if this is aerc's or micro's fault, but I just experienced aerc/micro appending a bunch (1200 lines) of "=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=" and "383026496.emlget_string: = micro: /tmp/aerc-compose-383026496.emlget_string: micro: /tmp/aerc-compose-=" to my mail, which was sent to a list. This is probably going to be hard to track down, I can't reproduce it. Let me know if you need other information.