Modern XMPP project discussion - 2024-04-18

I can't seem to find any XEP for polls in XMPP.

Nor for voting to promote/demote MUC members to/from roles.

> 12:04:21 fugata> jonas’: Why's everyone so bothered by that? Round, square, rounded square...I don't really seem to care 🤔 When I last worked on making GTK fast on my phone, the single biggest performance cliff was caused by having round things.

For instance a texture blit would be one shader instruction, but a texture blit with round corners would be like 150+ instructions.

But this is Googles general design choice

On my phone, writing a theme with mostly no border-radius made most applications go from struggling around 20 fps to being smooth 60 fps.

> Nor for voting to promote/demote MUC members to/from roles. *yes*. i would be very intersted in alternative community governance schemes besides 2 owners like this room

and it includes polls

if anybody is working on one i mean

Link Mauve: Thanks, I didn't know there was a performance hit. Nobody ever mentions it when complaining about round/square/rounded square, so I figured it was purely an aesthetic preference.

> *yes*. i would be very intersted in alternative community governance schemes besides 2 owners like this room Would be nice to have indeed

> Link Mauve: Thanks, I didn't know there was a performance hit. Isn't that stuff hardware accelerated and barely measurable?

It is hardware accelerated and very measurable on slower GPUs.

and square corners look better, too.

:P

jonas’: true, but only when you add drop shadows! /s

contrapunctus [13:35]: > Nor for voting to promote/demote MUC members to/from roles. I did this via a bot in some channels I used to run. Worked well enough, but could be made nicer.

MattJ: Cool! What steps did you take to prevent abuse of the voting process?

It was a long time ago, but IIRC there was a threshold for the amount of time you had to be present for, before you could participate in voting

If there was other stuff I can't remember

There could be so many ways to do this. Unsure how to integrate it in the protocol :/

I do recall that I started porting it to work server-side in the early Prosody days

Basically it would tell everyone they were an admin, so they could use normal MUC syntax

But the actions would only occur if enough people performed them

That's a good start I guess, but yeah, who gets to be admin and why, that would probably require tweaks per room that use this kind of module..

And it should be possible to change whenever $people decide they should :P

> It was a long time ago, but IIRC there was a threshold for the amount of time you had to be present for, before you could participate in voting MattJ: Ah, that sounds like a good way. ↺

BRB, generating some sleeper accounts 😉

hi all we've recently began using Dino for our company's IM, made our own fork, and invested some time into MacOS build which was neglected for a while i would be very interested in any feedback from Mac users, if there are any: https://github.com/mxlgv/dino/blob/master/BUILD_MACOS.md

and my apologies if this is a bit out of the scope of this MUC

ru_maniac, instead of doing notifications using a plugin, wouldn’t it be better to implement it in glib so that GApplication in any program can use native notifications on that OS?

if there's any better way to do so - please let me know, this is my primary goal here, to gather feedback I've only two devs whom have Macs, so I rely specifically on their estimations

ru_maniac, this issue is the only one I can find about notifications on macOS: https://gitlab.gnome.org/GNOME/glib/-/issues/2988

Are you sure they don’t already work?

I'll check with devs on the team, so let me put a pin in that

Also it might be better to build a .app/.dmg file instead of requiring every user to install brew, but I don’t know much about this OS to give any further guidance.

dmg is already in the works, we want to put that into our existing CI

brew is a temporary solution, I hope

Cool!

btw, we already have pkgbuild for arch/manjaro and deb packages for ubuntu 22.04+ and the like will be available starting with the next release, alongside windows version

(windows build is available now as well, it's deb that's hanging behind)

Oh, you don’t plan on merging your changes back upstream?

the reason for the fork is that upstream devs weren't that interested in our changes

after seeing how they've treated our first PRs, we've decided to fork off

I'm not blaming anyone here, don't get me wrong, but they seem not really that interested in accepting PRs

I would be thrilled if upstream project would cherry pick stuff from our fork, but for now it is what it is

Makes sense.