Gajim - 2024-10-22

Why it's mostly broken in a lot of places

is it possible for gajim to change spellchecker's language based on MUC's language?

If you mean automatically, no

Recently upgraded to gajim 1.8.4 and it's nice. Of course there's newer but if this version stays reliable and the backports don't mess things up too much, it's not a problem.

it's not possible now, or it's not implementable?

emru: it's not possible at the moment

thanks!

but can be implemented

> Why it's mostly broken in a lot of places To sort out any potential packaging problems, e.g. missing packages, outdated versions, strange behaviour under one of the ≈255 different window managers in Debian etc. *before* there is an offifical GTK4 based release. ↺

debacle: sounds reasonable

> debacle: sounds reasonable Yes, I did the same when Gajim moved from GTK2 to GTK3 and also when Dino moved from GTK3 to GTK4. ↺

lovetox, technically there is nothing preventing it from switching automatically, it just isn’t implemented right?

Im not convinced Users would want that

And it's very complex to implement

Because you need to track a app default, a MUC default and a user override and a way for the user to remove the user override

Yeah.

I’ve also built the gtk4 branch here, I’ll use it for a while and report/fix issues. :)

Please don't it's work in progress

We release a nightly if we want people to test it

Ah ok, I won’t then.

Link Mauve: of course help is welcome! But right now it's not ready for testing

I’m in the process of migrating another Python program to gtk4, so I can wait until you want external contributions. :)

lovetox, cal0pteryx: can i ask you for fork access on my gitlab account, freshly created "cve-1312"?

It's not mentioned here https://dev.gajim.org/gajim/gajim/-/issues/12008 but StyleContext has been declared deprecated since 4.10: I guess we port away from it and I shouldn't use it anymore, right?

https://docs.gtk.org/gtk4/class.StyleContext.html

cve-1312: please register again

Our spam protection did delete your account

meson: use add_css_class

In the .ui file you can use <style><class name="foobar"/></style> and then you can use .foobar in the CSS.

Thanks, I've added in the code and now do the following (bit simplified pseudo code): ``` self.set_state_flags(Gtk.StateFlags.CHECKED, True) ctx.set_source_rgba(self.get_color())) ctx.fill() self.set_state_flags(Gtk.StateFlags.NORMAL, True) # reset the colors ``` This works fine, but if I leave the state as `checked` and interact with the widget, I get a memory corruption (segmentation fault), yay

Link Mauve, interest in debugging the issue? Then I give you steps to reproduce ;) unfortunately I don't have libgtk4 with debug symbols here for a useful backtrace. ✏

Why not? Does your distribution not provide it?

I’m already debugging clipboard in that other project atm.

Oh, I do have it indeed, I wondered why gdb hasn't suggested the right package nor debuginfod hasn't downloaded it automatically

if you are interested: https://paste.opensuse.org/pastes/68e26617f3da and https://paste.opensuse.org/pastes/708d06ee3840 ✏

alright, my solution makes it crash anyway, just a bit later, when resetting the state flag back to normal :-(

I guess https://docs.gtk.org/gtk4/method.Widget.get_color.html > This function should only be used in snapshot implementations could be a reason.

meson, really don’t get stuck with cairo, if you have something which works even with wrong colours that’s ok for a first version, you’ll convert it to proper widgets soon enough anyway.

> Our spam protection did delete your account Oh, right, that's done ↺

Link Mauve: ...going for snapshots now.

Yay!

cve-1312, you have now the rights

Great, thanks :)

> Our spam protection did delete your account Is this something public? I run a GitLab instance too and would love spam account protection!

https://dev.gajim.org/lovetox/spam-fighting-tools

it runs once a day, and checks via http api if any new user has contributions, issues, merge requests, comments

if not the user is deleted

we found that for some reason spam accounts do not start spamming after registration

they register hundreds of accounts, and then do nothing, or wait multiple days to produce spam

we still get 2 or 3 a month that start spamming issues immediatelly after registration, but if they create a issue its trivial to delete all contributions

its 3 clicks in the gitlab interface

it would be so nice if gitlab offered a simple, approve new registrations feature

because you can spot spam account profiles from a mile

ah and beware, the app scans all accounts which are marked "external", and if it sees contributions it removes the external flag

this way you dont scan all users again and again

on first run on a big user base, its better you do some dry run and comment out the delete commands

to see if it has false positives

when you made the first run, then its very unproblematic, because it only touches accounts < 24 hours old, those accounts cannot have made any serious contribution that is by accident deleted

> ah and beware, the app scans all accounts which are marked "external", and if it sees contributions it removes the external flag but this means you need to set in gitlab that all new registrations are flagged as "external" ↺

Nice! Thanks!

i reiterate the warning, this is a internal lib written for our gitlab, it sends delete commands to your gitlab, you should do some dry run and read the codebase, before you execute this on your users

:-) I'll be sure to do the dryruns.

Not sure if we'll use it for production at all, but I think we do need to investigate it.

Would like to update the build on Fedora, however protobuf dependency may delay this as would need Bazel build to be packaged, or some other build system used for python bindings to protobuf. Could another library be optionally used? Some old benchmarks at https://github.com/thekvs/cpp-serializers

not sure why you ask this here, we dont maintain the fedora package

Benson: I've tried to contact Michael Kuhn, the new package maintainer, by mail, but got no response

Maybe you have more luck

It would help many distros that do not carry Bazel but would want to carry a new version of Gajim.

Happy to send a merge request if it is something that would be considered.

merge request for what?

Alternative option for serialization library.

you want to replace protobuf?

i think you got the wrong idea what we do with protobuf

we dont need just serialization, we need other applications to be able to deserialize

we transmit data to other applications with that

we can not simply switch to some other serialization library, because the serialization format needs to be exactly the same

There is a C implementation https://github.com/protobuf-c/protobuf-c

what are you proposing? that we write our own bindings to the google protobuf library and not using the bindings google offers?

> it would be so nice if gitlab offered a simple, approve new registrations feature They don't? Riseup does it on 0xacab.org, maybe they made some kind of patch for that... but I never touched to a gitlab install personally ↺

ha, yeah i found the option now

maybe they added it somewhere in the last years

> what are you proposing? that we write our own bindings to the google protobuf library and not using the bindings google offers? It seems it is only used in omeno-dr https://dev.gajim.org/gajim/omemo-dr/-/blob/master/pyproject.toml?ref_type=heads#L24 could call a c library from Python. At this point exploring options. Can do implementation for options that would be considered.

Wouldn't it be better to "fix" the protobuf build to work without bazel

Benson, of course and then we maintain bindings for a ever changing google library, because someone at fedora does not want that dependency

Its good that there is a solution for the fedora users, its called flathub

Would want an alternative to what Google offers. There are pure python implementations of protobufs https://github.com/protocolbuffers/protobuf/blob/main/docs/third_party.md but this would likely not be performant.

> Wouldn't it be better to "fix" the protobuf build to work without bazel Suggested this upstream. Waiting for responce.