Gajim - 2024-06-15

PCRE message history search when? :)

what is cert_store for and should these files be migrated?

https://dev.gajim.org/gajim/gajim/-/blob/master/flatpak/README.md#migrate-your-data says to `Copy ~/.local/share/gajim -> ~/.var/app/org.gajim.Gajim/data/gajim`

so this means overwrite the logs.db that already exists for the flatpak install, then when started gajim flatpak converts it to the new db?

Trusted certificates

im using the flakpak version and dark mode does not work for me. the only place the theme changes is the subject dialogue box inside the chat, rest of the UI stays in light mode. ✏

talked too soon, i remembered this flatpak guide exists for theming: https://docs.flatpak.org/en/latest/desktop-integration.html#theming

I kind of like the idea of gajim being packaged with some built in theme options

I've incorporate `PreferenceBoxes` into my plugin, interestingly for `SettingsKind.POPOVER` the text in the UI does not change when selecting an item, only when re-opening the plugin settings dialog. It works though for `.COMBO` or `.SWITCH`. Maybe you have an idea why? See for example https://dev.gajim.org/mesonium/gajim-plugins/-/blob/stt_voice_messages/stt_voice_messages/gtk/config_dialog.py?ref_type=heads#L217

The plugin config is changed, it's purely a visual thing.

(I can live with combo boxes anyway)

hm seems this does not work good with callbacks

the popover bound to a gajim setting, and only will change the text once the setting is changed

as you dont modify any gajim setting it never changes

you can overwrite the _on_menu_row_activated() method of the popoversetting

and call _on_setting_changed() directly from there

hm but then you have to create your own setting subclass

...

hm i think this needs to be fixed in Gajim, i have to think about how

Are there plans to support flipped pages for MAM in gajim? I have looked at implementing it myself a bit but got stuck on not entirely understanding how the archive is implemented on the Gajim side (got it to work in nbxmpp though).

whats your end goal?

Sync the history in a way where the newest messages are synced first. My current issue is that I need to wait quite a long time for a full sync to show messages I care about

hm you actually dont need more then simply adding the parameter in the mam request

not sure there is something to do in Gajim

of course this will break sometimes, because you change the order, that means if 2 messages are received with the same timestamp they will be shown in the wrong order

but if you are on ejabberd, which has microsecond timestamps this should be no problem

the issue is that gajim syncs 70 messages, stores them, syncs another 70 messages (set as the default limit in nbxmpp), so that requires some changes on the gajim side

we store messages when they come in

the page size is irrelevant

just flipping is not enough

you would need to do a request backwards

or rather start requesting the last page first

flipping is just a very minor optimization, to get the messages *within* one page in different order

> or rather start requesting the last page first yea, that's where I ran into problems and that's why I came here to ask about that ↺

yes we dont do backwards queries, and this will break in various places

but requesting the last page first

is still only a task in nbxmpp

you need to read the RSM XEP to get an idea how that works

what comes to mind is, you need to disable _set_message_archive_info() that it records the current mam id

because this method currently expects that they arrive in chronological order

and then of course the major problem you have when the mam request fails in the middle

then you suddenly have a hole in your history, but where does this hole begin and where does it end

we currently have no place to store such information, and if you have one history hole, you can have multiple, and then you need to discover on start that you have a hole and query only that hole

and thats all under the assumption servers will never send 2 messages with the same timestamp

so you have a attribute on which you can order messages when loading them from the database

but this is not the case for prosody, a server that is probably used by most users in xmpp

you can dive into that rabbithole, but i would say simply waiting a bit on start for the sync to finish, is a relative small price to pay ✏

Okay, I see what the issue with that is, thanks for the information