fix(ui): keep messages visible after scrolling in non-chat windows #123

Manually merged
jabber.developer merged 5 commits from fix/scroll-non-chat-windows into master 2026-05-16 15:48:09 +00:00
5 changed files with 43 additions and 9 deletions
Showing only changes of commit 0f24910685 - Show all commits

View File

@@ -61,6 +61,22 @@ integrity_issue_free(integrity_issue_t* issue)
}
}
gboolean
log_database_can_recover_messages(void)
{
if (!active_db_backend) {
return FALSE;
}
auto_gchar gchar* pref_dblog = prefs_get_string(PREF_DBLOG);
if (g_strcmp0(pref_dblog, "off") == 0) {
return FALSE;
}
if (g_strcmp0(pref_dblog, "redact") == 0) {
return FALSE;
}
return TRUE;
}
gboolean
log_database_init(ProfAccount* account)
{

View File

@@ -109,6 +109,9 @@ ProfMessage* log_database_get_limits_info(const gchar* const contact_barejid, gb
void log_database_close(void);
GSList* log_database_verify_integrity(const gchar* const contact_barejid);
// FALSE if no backend, or PREF_DBLOG is "off" / "redact".
gboolean log_database_can_recover_messages(void);
// Cross-backend export/import (requires HAVE_SQLITE)
#ifdef HAVE_SQLITE
int log_database_export_to_flatfile(const gchar* const contact_jid);

View File

@@ -813,7 +813,9 @@ win_page_down(ProfWin* window, int scroll_size)
auto_gchar gchar* start = g_date_time_format_iso8601(last_entry->time);
auto_gchar gchar* end_date = g_date_time_format_iso8601(now);
db_history_result_t db_response = chatwin_db_history((ProfChatWin*)window, start, end_date, FALSE);
if (db_response == DB_RESPONSE_EMPTY)
// Treat transient DB error (e.g. no active backend) the same
// as EMPTY: no rows can be fetched, so stop indicating [SCROLLED].
if (db_response == DB_RESPONSE_EMPTY || db_response == DB_RESPONSE_ERROR)
jabber.developer marked this conversation as resolved Outdated

If DB returns error, it might be a temporary problem, but it can get user stuck in the middle of the conversation if we change scroll_state. I do not think that DB_RESPONSE_ERROR is a valid reason to switch state.

If DB returns error, it might be a temporary problem, but it can get user stuck in the middle of the conversation if we change `scroll_state`. I do not think that DB_RESPONSE_ERROR is a valid reason to switch state.
*scroll_state = WIN_SCROLL_REACHED_BOTTOM;
// similar to page_up (see explanation there)
@@ -1809,13 +1811,14 @@ static void
_win_printf(ProfWin* window, const char* show_char, int pad_indent, GDateTime* timestamp, int flags, theme_item_t theme_item, const char* const display_from, const char* const from_jid, const char* const message_id, const char* const message, ...)
{
/* While the user is scrolled, bump the unread indicator. Only WIN_CHAT
* skips the buffer/render entirely — it can recover the message via
* chatwin_db_history on scroll-down. Other window types have no DB
* fallback, so the message must still be appended to the buffer and pad. */
/* While the user is scrolled, bump the unread indicator. WIN_CHAT
* skips the buffer/render only when the DB will preserve the message
* verbatim — chatwin_db_history on scroll-down will replay it. When
* the DB is off/redact/dead we cannot recover, so fall through and
* append to the buffer just like non-chat windows. */
jabber.developer marked this conversation as resolved Outdated

it describes the behavior, which can be read from the code itself. It would only make sense to either add a concise explanation on WHY we do it, or to keep this stuff inside of the commit.

it describes the behavior, which can be read from the code itself. It would only make sense to either add a concise explanation on WHY we do it, or to keep this stuff inside of the commit.
if (window->layout->paged && wins_is_current(window)) {
window->layout->unread_msg++;
if (window->type == WIN_CHAT) {
if (window->type == WIN_CHAT && log_database_can_recover_messages()) {
return;
}
}