pauljonas’: I've heard that you wrote xep 0392 and implemented it in poezio, isn't it?
jonas’paul, both correct!
paulI have a color issue, following the xep I have different color from poezio, and reading the poezio code I see that when computing the hue_angle the sha output is / 65535 instead of 65536 in the xep
jonas’that is a typo in the poezio source then
jonas’the XEP has the correct value
paulok thanks :)
jonas’(logic behind it: as the result is supposed to be an angle, 0 == 360. Hence, we don’t want to be able to generate *both* 0 and 360. Hence, we must divide by 2^16 instead of 2^16-1 in order to get the full possible range of distinct values out of the 16 bits of hash)
jonas’paul, thanks for the hint, I shall patch it
paulmake sense, you are welcome for the hint
lovetoxa few days ago i asked if there is a client that stores notifications in a way they survive a restart
lovetoxdoes someone know such a client? is there any one that thinks this is important for a client?
lovetoxor can we live with seeing 0 notifications after restart
KevPsi will store unread message counts, if that's what you mean.
lovetoxyes its a subset of what i mean, but yes thats probably the most important notification
lovetoxi wonder what i should store, simply a dict like thing like "contact: 10 notifications"
lovetoxor does the user need to know exactly which 10 messages are unread
lovetoxi could probably store the stanza or message id
KevPsi stored the messages.
lovetoxbut then it gets much for mucs ect, if i have to store 350 unread messages with message id etc in a public muc
KevOf course, I've not looked at the Psi code for coming up to a decade and a half, so I may be a *smidge* out of date.
lovetoxyeah maybe i take a look myself
Sam WhitedGajim shows me a little unread marker when I start it if that's what you mean? Or do you want it to pop up notifications again for each message?
jonas’actually this sounds like "inbox"
lovetoxyes Sam Whited , i mean exactly that, right now Gajim saves one db row for every unread message but only 1:1
lovetoxand yes jonas’ its probably that if we talk about syncing this state across clients
lovetoxbut i rather try to think how i can solve this locally
lovetoxi just wonder if and how this saving of unread messages scales in public mucs
Zashlovetox, one row per message? as opposed to one row per chat, with a pointer to the latest message?
StefanSome clients have notification setups. None, mentioned, always.
In big public mucs I have just mentioned. I would recommend to do this based on the notification setup.
Sam WhitedWhat Zash said. Although I still don't get what you're asking or what you're trying to do I think.
lovetoxSam Whited, you have 1134 messages unread in jdev, your computer does a restart
lovetoxwhat do you expect to see when you start it again
jonas’lovetox, I think I don’t expect a notification for those, but the unread counter in the UI should be correct.
Sam Whitedlovetox: the chat marked however you mark unread (maybe it's bold, maybe it has a little icon, an unread number, whatever) and when I open it there's a line dividing the read from the unread and it's at the top of the unread list.
jonas’but I *do* expect a notification for messages which arrived between the last focus to gajim and the restart, I think.
Stefan1134 unread messages + new as counter. I think conversations does.
Sam WhitedI wouldn't expect any notifications after restart (assuming you mean some sort of pop up) personally.
lovetoxok so i need to save the counter, and the last message-id, and if you open the chat again, i scroll to that message-id and thats it
jonas’Sam Whited, torn on that one, I think no notifications is OK
lovetoxsorry with notification i mean a bubble with the counter
lovetoxnot a desktop notification
jonas’yeah, those need to be correct
Sam Whitedoh gotcha, yah, I'd show an icon or a counter or something
lovetoxok and when you focus the chat, and i scroll to that message, should the counter go to 0?
jonas’I personally think there’s no good solution to that. All solutions are terrible / wrong.
jonas’I personally think there’s no good solution to *that* specifically. All solutions are terrible / wrong.
lovetoxi mean i can color all messages in a way so you know they are unread
lovetoxbut when i the point where i mark them read
Sam WhitedOn a desktop client at least I'd expect it to go to zero once I've scrolled to the bottom. That's what Slack does and it seems to work pretty well.
jonas’but IME the solutions which allow me to mark as read as easily and painlessly as possible are the least worst
Sam WhitedOr once I click the "Clear notification" or "Jump to recent messages" or whatever if either of those are a feature you hvae
lovetoxim in the process of rewriting the whole thing, so thats why i ask
lovetoxreaching bottom is good i guess
lovetoxbut with that solution i dont need to save all message-ids, only the first unread
lovetoxand the total count
Sam WhitedIt also depends if you have threads, I think. Those may change things.
lovetoxno i dont have threads
lovetoxand i will not
lovetoxpersonally i hat them
Sam WhitedCool, no need to handle those differently then
Sam WhitedYah I haven't seen a threading implementation I like. I want them, I like the general idea, I just don't like any of the implementations I've tried. Slack is the least-bad I think, but it's the only one I've used in a long time so I may just be used to the pain.
jonas’Sam Whited, out of curiousity, did you try zulip?
jonas’(a recent one, they had a major release in 2020)
jonas’we had a zulip trial run at $dayjob, and I was pleasantly surprised. threads feel really natural and workable there.
KevSlack's looks ok on the surface, but then you realise that threads are invisible as soon as you don't choose 'share in main channel' or whatever it's called, and you don't see replies, and blah. I agree it's probably the least-bad, mind.
Sam Whitedjonas’: I think so, but I literally don't remember it. That sounds really familiar though. Definitely didn't try it in 2020, so maybe I'll play with it again
KevMy favourite threading implementations are the ones that just allow replies to messages, rather than 'threads'.
Sam WhitedKev: I really like that they're invisible actually and that I can get to them from the initial message and from the "Threads" view, I just wish they had a subject to make them more obvious and you could see a list of threads by channel
KevDifferent use case, I guess.
Sam WhitedI like it because I end up discussing a feature I'm working on in our team channel, and some front end people end up discussing some front end stuff I don't care about, and neither of us have to get every channel notification, it's just kind of hidden away for people who want that conversation to look at