so, thinking of how to address the recent issue where a user closed the conversation window in pidgin 2 which caused pidgin to part all of theirs channels from their bouncer…
We could add a property to a conversation to signify that closing the conversation will leave it. This could be a protocol/connection property instead I guess. But if we set this for IRC, we could then prompt the user saying “you’re about to leave these channels…” instead of just doing it.
Now obviously we don’t want to do this for stuff like slack, discord, telegram, etc where you have to explicitly leave as that’d get really annoying. So we definitely need a way to determine whether or not to do it.
We also probably don’t want to do this when leaving a single channel as again, that’d get really annoying quickly.
So does any one have any thoughts? Any thoughts on the property name? Best I have right now is something like part-on-close.
I was thinking ephemeral, but like the channel doesn’t go away when you leave which is why I stopped considering it.
With something like slack or telegram, you have to explicitly leave a conversation which is more or less what we’re doing now with the conversation manager, but we’ll have the same problem when we allow multiple windows, which is part of why I’m looking at this now.
The main intent is to give the user to not leave these conversations accidentally, but we use a tag or a badge on the conversation to distinguish it.
And actually badges on channels could be interesting from a plugin point of view, not sure what chat networks implement that though. But something like a NSFW or actually a Private badge would make a lot of sense.
Is there anything to be said for allowing the user to customize the behavior on close per-protocol? Then, when the user sets l sets up the account they could be warned in advance to select the setting that’s right for them?
There may be something I’m not understanding here, though.
That could be possible, but it’d be unlikely that it’d end up consistent. Also this is trying to manage user expectations despite the way conversations are implemented in protocols.
That said, a global option to “prompt on mass conversation leaving” is something we should implement.
Regarding the property name: depart-on-close or leave-on-close would be more clear to me as a non-native speaker. I would imagine this can be an enum like never, always, and ask. It would be filled by the protocol plug-in with a default that is sensible for that particular protocol. I assume the property is on the conversation (some protocols may have chats of either kind). In case folks want more intricate control, that could be done with a stand-alone plug-in which sets the property after the conversation created event (similar to the auto-accept plug-in).
We could also have a call back akin to conversation_close and let the protocol plug-in do the asking, but a property on the conversation feels more consistent.
The enum is an interesting idea, I was thinking the asking would just be a user interface thing, but this could be used set to ask on a channel that’s invite only for example which could avoid some issues.
Yes, it’d be a read/write property on the conversations enabling individual control and being able to be changed whenever.
Having the protocol ask would require the requests API and that’s something i’m trying to make sure is used very sparingly as it leads to pop up hell.