Gajim - 2025-04-12

https://xmpp.jix.im/upload/39dcf06f419597d53db777fb5fb1094edaeeb775/8h3I00GqlYal4pVmc473chuBx4FGcz7PzIZv15TJ/3bce6949-9265-4d83-ab71-07ada5eeb875.png

> Someone recently posted a screenshot here and said it is only half-bad 😅 I actually do the same, there are certain issues, but its not bad ↺

I might write some issues later

morsmortium: Gajim is not designed for mobile devices. It's not in scope of development

I thought the scope was xmpp client. Would these issues be closed then?

morsmortium, Gajim is a desktop client

Please answer my question, thats the important part

Yes, issues about mobile compatibility would be closed

Thank you, guess i gotta go find another client

morsmortium, you could try dino on your mobile device, which got an update recently https://dino.im/blog/2025/04/dino-0.5-release/

No, that is gnome, i use plasma desktop

Gajim might/will use Adwaita in the near feature, too. So it wouldn't be such a big difference

Libadwaita is themeable, but the csd is not removable. If that was implemented, i would indeed had to leave too

morsmortium: try Kaidan

> morsmortium: try Kaidan Not multi account and breaks with kde on screen keyboard (maliit) ↺

It doesn't support MUCs but only MIX, and there's a lot of other things, which leave a lot of room for UX improvements ✏

sorry but if you disregard an application because you dont like the window border

then it seems this application cannot really be important for you

Yes, i disregard many applications like that, same as not themeable apps, like webapps. For GTK3 there is gtk3-nocsd, a preloaded library that removes the csd. One thing to note, not visible in the screenshot, this is a maximized window, with titlebar removed, i have set all windows to be maximized, when i use the device in mobile mode. This does not work with csd and wont ever ✏

is there no gui framework for linux mobiles?

Im not sure i understand the question. Linux mobile is the same as linux desktop. Therefore linux mobile frameworks are qt and gtk, mostly

of course you can use that, but if these frameworks make any effort to support the differences in usage, then it will always be a pain

e.g. you need special gtk4-nocsd stuff, why would you need that if the framework had this use case in mind?

Both support touch input, for example. The fact that this (and many other) apps put right click menus in places, is not something gtk can deal with

> e.g. you need special gtk4-nocsd stuff, why would you need that if the framework had this use case in mind? Gtk4 supports not having csd. If you as a developer force the users to have csd, that, again, is not something gtk can deal with ↺

And libadwaita is a gnome platform, so they dont support any other usecase (mac, windows, kde, whatever de), only running on gnome, its made for gnome

so its more than just window borders

what you are saying is, a developer need to develop the application *for* mobile

Yes, same as they have to develop it for desktop. I could develop an app without any hover tooltips bc i have no idea what a cursor is, for example

i mean, when i google how many people cant deal with the CSD, im willing to investigate how we can keep an option for not drawing CSD

because this is something that also people not on mobile seems to affect

Not sure if thats supported by libadwaite

> Adwaita offers application developers many widgets and objects to build GNOME applications scaling from desktop workstations to mobile phones.

thats from their homepage

lib is *for* mobile phones

so if you can make a good case that CSD is problematic on mobile, i dont see why they wouldnt have an option to disable it

The space it takes, plus the window management is not relevant on mobiles, same reason why android doesnt have it

But gnome development doesnt work that way, when researching gtk3-nocsd for gtk4, there was a PR where someone wanted to implement optional csd, he was threatened with a ban from the gnome gitlab

link?

> link? https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6532 ↺

the threat was not for the nature of contribution

There is the qt based Kirigami, and Kaidan uses it. In theory Kaidan is perfect for mobile Linux, but I agree that it currently has issues. ✏

Use Psi+ then )

> the threat was not for the nature of contribution Except the closing was bc of the "nature of contribution" ↺

> Use Psi+ then ) That is what i am experimenting with, currently ↺

> There is the qt based Kirigami, and Kaidan uses it. In theory Kaidan is perfect for mobile Linux, but I agree that it currently has issues. They are so far from mobile, its the single qt app that i ever found broken with on screen keyboard, and i use a big number of them ↺

Did you report the issue?

I just found it today, but for that client to be usable for me, years of development should happen

Also, Kaidan doesn't support Axolotl (OMEMO 0.3), only new OMEMO… ✏

That is a choice. Could be fixed quite easily. Same for mix/muc.

The library they use supports muc

The only real "issue" seems to be no multi-account support.

But they have Automatic Trust Management, which is cool

I wonder if Gajim will ever implement it, as it will allow for painless always-on OMEMO

morsmortium, i just tested, you can draw a window with no decorations at all with GTK

In gtk or in libadwaita?

'always on' OMEMO as in unverified?

Make an adwwindow without it ✏

https://share.hoerist.com/philipp/hqJutELW5yNcSZJg/fa4099df-641c-473a-8698-58f14e5a4198.png

not sure if this is what you want, because seems the wm does not draw its own decorations

so it still is in the csd mode where the application decides what to draw

but as i understood you, on mobile the whole decoration is not wanted

neither from client nor server

For my system its needed, i switch apps back and forth based on whats needed

> 'always on' OMEMO as in unverified? As in "sending plain text isn't allowed"

but sending to an unverified OMEMO contact is?

> but sending to an unverified OMEMO contact is? You don't get what i'm saying

yeah so I'm asking to clarify ✏

I don't talk about "blind trust" here. Just about having no option to send plain text when OMEMO is set to "always-on"

So, if your contact doesn't advertise OMEMO or their only device is marked "untrusted" by you then you can't send messages at all

set to always-on globally? If you turn on OMEMO for a contact, you will encrypt it, no?

ok i see

morsmortium, i just read that if the developer does not set a headbar widget with Gtk.Window.set_titlebar() Gtk will let the server draw if it supports that

it already exist in Gajim, no? In my account, under "confidentiality" I can set the default encryption method to "OMEMO"

so no-csd seems then pretty trivial to support, simply dont set a headerbar

of course the developer would need to account for that

if it works right now for you with Gajim, that is prove of that

as we dont set a headbar

libadwaita does not force you to set a headerbar either

> if it works right now for you with Gajim, that is prove of that Does gajim use adw window? ↺

not right now, we use a normal gtk4 window

but i just tested with Adw

and it does not add a headerbar, you need to actively set that on the window

just with plain GTK4

> not right now, we use a normal gtk4 window Then gajim does not prove that ↺

But this conversation went sideways a bit. I asked about mobile issues, not headerbar issue, and i was told those would be closed. Things like if i asked if things could open right click menu on hold, or if i reported that swipe scrolling doesnt really work in messages, as the focus gets stuck on certain items, or when the window is too narrow, the message part can be scrolled sideways, but the scrollbar is invisible, and if that sideways scrolling could be eliminated somehow

it did not went sideways for me, as you reported a problem with CSD, because we plan to use libadwaita, i was interest, brcause CSD affects more than mobile

the information was correct, we dont develop for touch devices

this is not out of principal, but we believe that as open source project it would stretch resources to thin

By the way, what improvements would libadwaita bring?

with adwaita comes accent color support

https://3o3g.net:5443/upload/677ea0659f17ad7f58c61ece22e438ce1f382b21/mrdIgJq95tV0xAGEz2hvWDCYkgNmH9c9YSs6gMN1/_Z4HK4jGQgyc6qzGf4JhXg.jpg

lissine: they have widgets which are responsive, and they have sensible default styling on them so less css for us

https://3o3g.net:5443/upload/677ea0659f17ad7f58c61ece22e438ce1f382b21/HaXczVWgQHSRWlJb4cTZpubCZlFfYX8yUtpSfwfJ/YbS0LXmSQtu2z6MvpV28Ow.jpg

Also I heard if you use libadwaita system can not override Styles anymore

Which I consider a plus

Hiding the accounts under a button makes it harder to see at a glance which color is associated with what account. Any chance for an option to disable the hiding or doing it automatically only when the sidebar is too full?

> Also I heard if you use libadwaita system can not override Styles anymore False ↺

hau: In what situation is your only option to look up the color on the popup?

We display the account name in all chats for example

> False You can both just write the gtk style in an env variable and it will be picked up or there is an app called gradience, that either can change named colors or straight up load css into any gtk3/4/libadwaita ↺

morsmortium: but that will only happen if a user does it by choice

That's fine.

Now system styles override app css without asking the user

Of course, never had a single distro ever set an env variable lol

But is this happening right now?

> hau: In what situation is your only option to look up the color on the popup? When looking at the list of chats in the sidebar it only displays the color not the name of the account, I also don't see where in the chat the account name is displayed unless it's a muc room where it has your own user at the top with (You). ↺

> But is this happening right now? Yeah, if you set the env variable, it will be picked up, right now. Whether any distro uses this, i have no idea, ive been using artix for 2 years at least, before that manjaro for some years, before that (k)ubuntu for 5 years, i have no idea what the majority of distros do ↺

> Hiding the accounts under a button makes it harder to see at a glance which color is associated with what account. Any chance for an option to disable the hiding or doing it automatically only when the sidebar is too full? 👍 ↺

Is there any way to get a full list of your online contacts still other than the dialogue to start a chat?

can't find one anywhere since a couple updates back

> Is there any way to get a full list of your online contacts still other than the dialogue to start a chat? ❓ ↺

> Is there any way to get a full list of your online contacts still other than the dialogue to start a chat? ❗ ↺

No, that was sadly removed

Many people had the same question already

...seems like a rather fundamental thing to remove

thanks though

> ...seems like a rather fundamental thing to remove 👍 ↺

> When looking at the list of chats in the sidebar it only displays the color not the name of the account, I also don't see where in the chat the account name is displayed unless it's a muc room where it has your own user at the top with (You). and you have the same contacts in multiple accounts? ↺

or how is the account important?

tef, why is the list in start chat not good enough?

It's not persistently visible, which makes it high-friction to see who is online to speak to

Before I could just leave it up and look at the window occasionally; no clicks or modals or anything needed

on what version of Gajim were you before?

I've been updating fairly consistently with Arch's package; I haven't been tracking numerically

I just know it was possible to have a list of online contacts where the "workspace" pane was not too long ago

ok but since a few years, you always had to click the account avatar in the bottom left to make the roster visible

now you can open the start chat dialog with ctrl + n

and something like that is far, far easier to deal with than a modal that discourages me to look before trying to figure out if I want to start a conversation

I'm also not super sure why it should be a modal at all...

you also have a chat list now, it holds as much contacts as you want

you can pin them, sort them in specific order as you like also

It seems like the most fundamental component of any one-on-one chat to me, to be able to track who is there to speak to with no additional friction -- why not just show it all the time?

because it makes the chat area smaller

it would not make much sense, to have a list of contacts, beside a list of conversations also

its essentially both a rows of contacts

usually you have your most important contacts, pinned in the chat list, so there is no friction

if you want to look up contacts that you dont chat often to, pressing one shortcut is not much friction for me

I believe it absolutely would, the account and its connections are the fundamental thing in *any* chat program with a friend/roster system, prior to everything else. But if you are diametrically opposed to it, another thing: The contact entries shown in the start chat list are absolutely massive, they take up way more vertical space in the start chat view than in the workspace

Could there be a flag to make them same height so more are shown?

there's no information in most of that space, it's just an avatar and a name, seemingly not even the server they registered with...

you mean their address?

Yes, showing the full address would be far better

Names are often short and may not always be unique. But more importantly the space could be used for something (like, say, more of the contacts in one scroll)...

the space is used, usually for status messages

If they were the same size as conversations in the workspace vertically I think it would also massively reduce the burden of having to hit start chat all the time

it seems your contacts dont have them set

well, a tiny segment of it certainly is, if the window is spawned at equal width to the initial one...

https://share.hoerist.com/philipp/DFsXvK6fqI6bAV9l/ca4871c5-602b-4844-9820-2a7e34ffa3cf.png

im not against showing the full address, it seems important

Yeah, so what if the empty space and font sizes were matched to the workspace view?

i just wonder where, and if this not goes against the same wish to have less height per contact

I think that would make it far, far less painful (or at least allowing to set that...)

The font sizes are different between start/join chat and "my workspace"

as is the width of a line of text

yeah slightly

we made it more compact, but i agree we could make it a bit more compact

the full address could be beside the contact name maybe

i would highly appreciate both that and the full address if the horizontal space will be there

i agree, i added a feature request, https://dev.gajim.org/gajim/gajim/-/issues/12261

im positive we can fit this in there

thank you!

I can register and try to add FRs for anything like this myself...

if its about features or changes how things should be done, its appreciated if you first discuss it here. Nothing wrong with opening a issue on the tracker, but often the topics have been discussed already a lot, or there are specific reasons why something cannot happen, and that spares us to close the issues

OK

Another thing I wonder, which I think I asked about before (just for discussion's sake since the reception was not good at the time): I once talked about the need to coordinate deleting fingerprints on both to solve OMEMO issues... my high-level understanding of what is going on is that deleting the fingerprints causes republishing to occur. I think that it is unintuitive to have to solve this by nuking a lot of fingerprints like this (unsure if it's necessary either, isn't it just that they need to go to one device?)

Is there any way we could get something to manually publish keys or detect it needs to be done when the other side can't decrypt?

When did that happen to you the last time?

Let me try to dig up the last one. My intuition says a few weeks

We fixed bugs, that made sessions that were not used for a longer time (think a few weeks) unstable and fail

ahh huh

i actually didnt have any reports for months, about issues where encryption fails with only specific devices

I see 30th march was my last but I may have been behind on updates at that point. If it fails again, I guess I should just report here?

in any way, its sadly not a thing where we can point to a single root cause, and fix that, there are multiple things that can go wrong, and we need to investigate it specifically if you have a problem somewhere ✏

just ping me the next time something like that happens, before you do anything to fix it

Ok

Thanks

and yes i agree, telling users to delete fingerprints, is a workaround that stuff is working again

its not a solution

yeah it just doesn't match how the functionality used to do it is presented IMO. totally fine doing it manually or the software handling it if it does

oh I missed "how is the account important": it is important because my contact list for one is far bigger than another and people are more often online, so all of those other contacts get entirely engulfed by the first account's contacts in "start/join chat"

that was a question for the user "hau"

where do you miss account information?

you have a filter button in start chat, and can filter it down to a specific account, if you have that situation that you need to see only contacts for one account

> Is there any way to get a full list of your online contacts still other than the dialogue to start a chat? This has always been a great core thing to have.

> you have a filter button in start chat, and can filter it down to a specific account, if you have that situation that you need to see only contacts for one account Talking about the account filter list, could the horizontal size of the list be increased or the account color be added. In my case, moving the ellipsis tn the center should also work, but that might not be true for others. ↺

yes, the dropdown is the new GTK Dropdown, what we didnt yet figure out is how to make the drowdown larger than the field where the value is stored

the only thing right now we can do is make the whole thing larger

which may be ok in this case anyway because its a popover itself

lovetox pushed 3 commits to branch gajim/master imprv: StartChat: Make contact list more compact - https://dev.gajim.org/gajim/gajim/-/commit/874605240ae9c1f7e3ca23e63ec84f1c839ae468 imprv: StartChat: Show contact addresses - https://dev.gajim.org/gajim/gajim/-/commit/8857720416eb445da6e9b493c36242d7b6ae0e70 imprv: ChatFilters: Increase width of dropdowns - https://dev.gajim.org/gajim/gajim/-/commit/3690a0358ce697368da1c3ee0dd931d9dfd209ca

hannibal, i made it a bit wider, we could add account colors also, but i wonder would your problem not be solved by simply naming your accounts a bit different?

> or how is the account important? So I can see when someone new messages me, which account they are messaging easily. ↺

It also makes it easy to see at a glance if there is a connection issue with one of them

> would your problem not be solved by simply naming your accounts a bit different? That should work. Haven't thought about it.

>> or how is the account important? > So I can see when someone new messages me, which account they are messaging easily. The account is shown at the top of each chat _and_ in the list.

The account of the person messaging me, not which account they are messaging

Unless I'm missing it

That's the person's address. That's shown in chat details for example

The issue is that I can't see which account they are messaging easily since the accounts on the bottom left are now collapsed

Which was an easy reference to the colors

I'm talking about which account of _mine_ they are messaging, not who is messaging me

Yes, that's shown at the top of each chat, including color

you dont see the name of the account in the chat list thats right

but if you click the chat, i mean we assume you want to read the message or not?

the chat opens, and you see the full name of the account in the banner

thats not enough? You need to know the account name, before you open the chat?

i mean before you saw a mapping of account color -> to avatar

one other option i can offer you is, in the account settings, you can assign each account a default workspace

you can choose a avatar for each workspace

I think there's a mistake in mds stanzas sent by Gajim. In MUCs, the `by` attribute is supposed to be the address of the room, right? https://xmpp.org/extensions/xep-0359.html#stanza-id Gajim is instead using the jid of my account in the `by` attribute

meaning all chats from one account will go into a specific workspace always, making it very easy to separate accounts completely

You can easily see that using the PEP Configuration window

lissine, thanks will check that

lissine, no looks right to me

https://xmpp.org/extensions/xep-0490.html#sect-idm46077023511904

you are talking about the mds assist

> the chat opens, and you see the full name of the account in the banner I see what you mean now, I missed that ↺

the server needs to take the item-id fro the "to" attribute of the message

yes

What about seeing accounts with connection issues? Is there another solution for seeing that easily?

To clarify, I'm talking about the `stanza-id` element within the mds stanza ✏

read the spec above, we add the stanza-id so we need to put our jid in the by attribute

hau, if thats a problem you experience often, some solutions come to mind, like showing in the status color some kind of connection-problem icon

which tells you at least, some of your accounts have a problem

i assume its not everyday that your accounts have connection problems, so if that rare case happens some icon that shows you one look, something is wrong, then you can click and check the account

lovetox, I was talking about the `by` element, not the `to` element. If I'm understanding correctly, the `by` element must be equal to the room jid for MUCs: > the creating XMPP entity generates and sets the value of the 'id' attribute, and puts its own XMPP address as value of the 'by' attribute. The value of the 'id' attribute must be unique and stable, i.e. it MUST NOT change later for some reason within the scope of the 'by' value. https://xmpp.org/extensions/xep-0359.html#stanza-id

why is that relevant lissine, ?

this says nothing about forwarding stanza-ids

Monal ignores mds updates if the `by` element does not match the room jid

i can clarify this later with the standards body

Monal? you are talking about a mds assist

this is for the server, not for monal

https://github.com/monal-im/Monal/blob/develop/Monal/Classes/xmpp.m#L5433

mds assist is information for the server

server strips it even from the stanza if it supports it

the XEP says nothing about other clients parsing this

why would it? we send a chat marker, with the same information

I don't understand the relation with server assist. Normal mds also uses stanza-ids https://xmpp.org/extensions/xep-0490.html#example-1

oooh, now i think i understand

let me have a look

mhm, ok i will ask what is right in this situation

> hau, if thats a problem you experience often, some solutions come to mind, like showing in the status color some kind of connection-problem icon that would work yeah 👍 ↺

hau, also check out the default worksapce assign feature in account settings, i think it maybe could be helpful for you

i added a issue for your feature request https://dev.gajim.org/gajim/gajim/-/issues/12262

> hau, also check out the default worksapce assign feature in account settings, i think it maybe could be helpful for you That's useful yeah thanks, is there a way to auto assign by type as well? (message/muc/muc private msg) ↺

lovetox pushed 1 commits to branch python-nbxmpp/master fix: MDS: Make by attribute configurable - https://dev.gajim.org/gajim/python-nbxmpp/-/commit/2d246b0b67c891026ff42730f0be63d86977246a

lovetox pushed 1 commits to branch gajim/master fix: MDS: Set by attribute correctly - https://dev.gajim.org/gajim/gajim/-/commit/2ee672cde9214a2daf573243dc4d54d749cea068

hau, no, not yet

lissine, thanks for reporting, should be fixed in the next release

Thanks!

I tested with the latest Gajim and python-nbxmpp commits, and now mds works with Monal. Thanks!