Add ability to disable inactive color changing
name: Feature request about: Suggest an idea for this project title: Add ability to disable inactive color changing labels: enhancement assignees:
Is your feature request related to a problem? Please describe. Etherpad makes author colors lighter when they go inactive. This feature is of dubious utility since a user might have chosen a light color, so there's no way to know a priori whether the user is active or inactive. Moreover, it effectively doubles the number of colors in use, making it harder to avoid someone else's color; and if you switch machines and want to match your now-inactive color, you have to guess at something close and then you have effectively used a third color when that browser goes inactive. Rinse and repeat, eventually ending in Zeno's white in the limit.
Describe the solution you'd like Allow inactive color changing to be disabled, either by server config or on a per-pad basis. Or just take that "feature" out entirely.
Describe alternatives you've considered See the description above.
Additional context N/A
Plugin? No. This is related to core etherpad functionality.
Hello @ether/etherpad-maintainers,
I've been analyzing this feature request to add the ability to disable inactive color changing and I believe it's a valuable improvement for user experience and color consistency.
I would like to formally express my interest in implementing this feature. I have a clear plan for a minimal, non-breaking solution:
My Proposed Solution:
-
Add a Server-Wide Configuration Option: Introduce a new setting in settings.json.docker, for example "disableInactiveColorChanging": false. This is the most straightforward approach and maintains full backward compatibility.
-
Modify the Color Logic: The implementation would involve locating the server-side function (likely in AuthorManager.js) that handles author colors and wrapping the existing "lightening" logic for inactive users in a conditional check for this new setting. This centralizes the change and ensures the frontend automatically reflects the correct color without requiring client-side modifications.
-
Ensure Robustness: I will thoroughly test both states of the setting:
-> When true: Verify that author colors remain constant, regardless of activity status.
-> When false (default): Confirm the current behavior is preserved, ensuring no regression for existing installations.
I have a local development environment ready and have already started exploring the relevant code paths. I am confident I can deliver a clean, well-tested pull request for this.
If this approach sounds good, could you please assign this issue to me? I am ready to start working on it immediately.
Thank you for your time and consideration.
Hey @ether/etherpad-maintainers
Just following up on my earlier message about the feature to disable inactive color changing. I’d love to work on this if the approach looks good — could you please confirm or assign it to me when you get a chance?