-
Notifications
You must be signed in to change notification settings - Fork 219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add MarkActiveChatRead ui setting #461
Conversation
Would be nice to have a description of the intended use case in the commit message. |
This seems like it mimics the behavior of the "set marker line" options (on switch chat, on lose focus), but for marking a buffer as read instead. I'm also curious about use case - say, quickly checking a buffer to see new messages but leaving it marked unread as a reminder for later? Something else..? |
I'm sorry, I will explain: I use the Qt Quassel client on mulitple computers with a core on my server. Now suppose I left the client open with my favorite channel on one computer. Then on the second computer that channel will always be marked read, even though the first computer is idle. This leads me think there are never new messages in it, which I found incredibly annoying. My first thought was that I would use some sort of cross-platform desktop idle detection API, however Qt does not have anything like this, there are other things such as: https://github.com/paulcbetts/node-system-idle-time Or for a specific platform, such as X11: https://gist.github.com/jamesadney/1879754 (if there is nothing for C++ it could probably be fairly easily ported.) But this solves the problem in a different way, without adding dependencies or native code. If you would prefer a solution using idle time in addition to, or instead of, this setting, I could work on that. |
I see. With this setting switched off, you'd have to deselect and reselect a buffer you're currently looking at, to get it marked as read, though, IIRC. Replacing this bool with a check to determine whether the client is in the foreground / has focus / isn't in a locked desktop session (or a combination of these) would probably be the better approach here. That may even match user expectations enough that it wouldn't need to be configurable. |
Aha! We've actually discussed this long ago over on Freenode/#quassel, and wanted to add support for KDE's KIdleTime is a Tier 1 KDE framework, so no additional dependencies, and it supports FreeBSD, Linux (also in the Debian/Ubuntu repos), MacOSX, and Windows. Including it in Windows would involve modifying the Craft blueprints; TheOneRing might be able to help. (This was originally delayed for some Windows packaging improvements, which have landed by now.) Aside: Ideally, in addition to not marking buffers as read after a configurable idle delay, the "present or idle" information should be communicated back to the Quassel core, so "away on detach" can finally be joined by "away on idle", a feature that's been in the database and protocol but not (yet) implemented. This can be saved for a follow-up; though, the "don't mark as read when idle" is purely client-side. |
I agree that having idle time as trigger for away state makes sense. For the buffer read toggle I'd prefer something tied to the window or desktop session state, as described above. |
This seems like a better strategy, I'll try to implement something and update this PR. |
8f557d4
to
a27d078
Compare
I've experimented with the It is starting to look like we are going to need to implement some kind of idle detection after all, but if you have other ideas I will test them out. |
If no one has any objections, my plan is to make a small C library based on node-system-idle-time, or find one if it exists, since it will be very small it could be bundled for the time being to not deal with dependency issues. |
If we're making use of an external library anyways, we're already using one KFramework library from KDE, the Sonnet spell-checking library, so it might be worthwhile seeing how hard it is to add others. Theoretically, KIdleTime support should be self.runtimeDependencies["kde/frameworks/tier1/kidletime"] = None I haven't actually tested this; it's possible the project needs to be added to KDE Craft's packaging list or something. Debian/Ubuntu already have it ( I'm not opposed to making a C library around This is merely an opinion as a non-maintainer. Feel free to try other methods, or wait for feedback from the project leads. |
Will this framework, if included, work correctly under non-KDE? E.g., windows, gnome/wayland, gnome/x11, macos. If you say wayland is not supported, we could just disable it there, but if the other platforms work that will be ok for the time being I think. We could also have a small |
Looking at the dependencies for
And there's a
The Wayland idle protocol proposal appears to still be stuck in discussion.. I'm not quite sure. But Xorg/Windows/macOS should be fine as is. Former
Apologies for long delay… |
Thank you for the detailed information. I suggest the way we proceed is we enable this framework, regardless of the The only platform actually in use this would not support then, is gnome/wayland. For gnome/wayland I could perhaps figure out a way to get this information via dbus or some other mechanism not requiring building with gnome libraries. |
Incidentally I found a solution for the Gnome/Wayland platform: https://unix.stackexchange.com/questions/396911/how-can-i-tell-if-a-user-is-idle-in-wayland |
a27d078
to
915e904
Compare
This will be used to implement auto-away when idle. See: https://api.kde.org/frameworks/kidletime/html/ Signed-off-by: Rafael Kitover <rkitover@gmail.com>
915e904
to
e210370
Compare
@AlD @digitalcircuit @justjanne @Sput42 Sorry that I haven't gotten back to this for so long, but I was just looking at it again today. So, this is going to be much harder than I initially thought. At first I thought it would be just a few lines of code, but now it looks like it will require much more extensive changes. And my initial attempts were completely wrong. I replaced them with a commit that adds the KIdleTime framework to cmake. So my plan now is to make an auto-away feature based on user idle time. This will take care of the issue with the buffer being marked read, and also better communicate the user state to other users. Notes:
So what do you guys think? |
I decided to leave IRC permanently so I am not going to implement this. |
Add the ui setting MarkActiveChatRead to the chat view settings page,
and check this setting before calling Client::markBufferAsRead() in
MainWin::currentBufferChanged() and MainWin::event().
Defaults to true, which is the current behavior.