pep.I'd recommend trying to backport stuff from the stable/master branch, so you don't have to rewrite everything yourself, but just the graphics toolkit bits
ZashPresumably the same settings would need to be applied to all different nodes to avoid weird interop problems
tomso I've modified axolotl.device list to be open subscriber model, but what are the bundles:somelongnumber?
pep.tom, same permissions
tomare those private conversations? should those be presence only or open as well?
ZashEach device picks a random integer and creates a node for it
ZashIIRC it publishes pre-keys or something there
Zash(I'm not a fan of this design)
tomI'm sorry I'm confused, I thought the devicelist node stored the keys
ZashNo
tomwhat exactly is the difference between devicelist and bundles?
ZashThe device list stores those numbers
tomok so when sending OMEMO messages the backlog (offline encrypted messaging) is still stored in MAM serverside not a special pubsub node
ZashIIRC this is because you can't count on being able to store more than one item per node
tomthe device list contains a list of the bundles and the bundles contain the key right?
ZashBut OMEMO got publish options and subscriber models implemented and deployed, so it could just as well have used a single node with an item per device
tomit SHOULD as in says the in the spec or are you saying the spec should have did that instead but it doesnt?
ZashYou SHOULD assume that I have no idea what I'm talking about.
tomok
ZashNot a client developer.
tomok So I've modified all the axolotl device list and bundle nodes to be open. I'll experiment with this and go over the spec extra fine. If this ends up being correct I'll modify the source
tomto be open by default
ZashDO NOT do that for every PEP node
pep.yeah, just OMEMO
pep.devicelist and bundles
pep.Also as I said above, maybe you should try backporting stuff from master rather than rewriting everything
pep.I might every ask lovetox (current maintainer) and see if it's not worth starting from 1.x and porting it to gtk2 if that's really what you want✎
tomonly did that for the eu.siacs.conversations.axolotl.devicelist and eu.siacs.conversations.axolotl.bundles:$rand nodes
pep.I might even ask lovetox (current maintainer) and see if it's not worth starting from 1.x and porting it to gtk2 if that's really what you want ✏
ZashGood
pep.Also maybe the gajim discussions could go in gajim :)
pep.Ah wait this is jdev@, I though we were in operators@, I have this mental picture of "tom" the ghost of operators@
ZashHow supported is GTK2 these days?
tom>pep.: Also as I said above, maybe you should try backporting stuff from master rather than rewriting everything
I'll take that into consideration but as I understand it the 1.X changes do more than just switch the toolkit but change around the user interface very extensively and include functions lke hamburger menus. These things don't exist in gtk2. Also, the really only things that I need to fix in the 0.16.X client I'm aware of is this OMEMO pubsub thing and changing the Jingle implementation to use a more modern version of libfarstream (or other protocol implementing Jingle) and work with either a modern version of gstreamer or better just use ffmpeg instead
pep.I think there's a lot more things you don't see that have been fixed
pep.Lots of code refactor as well
tomI don't think the main gajim developers are very open to making the 1.X branch support gtk2 or any other toolkit like qt5 either
tomthey seem pretty set on gtk3
ZashSwitching toolkits is no small task
tom>Lots of code refactor as well
Yeah i can see. there's lots of single-character variables in the source code like somebody just copy-pasted from stack overflow
ZashI would be happy if lower level libraries are reusable
ZashLike, protocol stuff
tommy experience with gstreamer has always been painful. Where it's always been better to use ffmpeg if possible and if not install gstreamer-libav plugin that just wraps ffmpeg anyways
tomI've met some camera developers who say they like using gstreamer internally rather than learning ffmpeg because it's more abstracted but I already know ffmpeg and I've had nothing but problems with gstreamer dating back to KDE3 on slackware
tom>How supported is GTK2 these days?
It receives bugfixes on it's own branch and is generally considered 'mature' or 'finished'
tomIt's also first class on Devuan even all the way to sid
pep.Devuan, heh
pep.runs away now
tomstill use exclusivly by Gimp and claws-mail
pep.iirc Gimp was going to jump to gtk4
tomyeah, the problem with that is that gtk3-+ is considered the GNOME toolkit. The development direction is only geared to serve GNOME's needs. The GNOME3 development team have explicitly stated this. While at the same time the gtk2 toolkit is the Gimp toolkit. Was originally designed as a generic graphical toolkit to make gimp with. However it was not explicity for gimp
tomso a lot of other *nix programs use gtk2.
pep.Yeah I've read that whole discussion before and I'm not replaying it
tomk
tombut yeah, I'm not running GNOME so it gtk3 really does not meet my needs so I'm needing to fork
tomI appreciate your pointers pep. and Zash . thank yo
tomu
Zashnp
pep.While Gajim devs might not be interested in supporting gtk2 anymore, being a friendly fork would be nice I think. If it's in your cords, talk to lovetox a bit, even if it's just asking advice on where to look at, what has been changed etc.
pep.You might want to stick to gtk2 but getting bug fixes can be a good thing :)
pep.(Also not annoying other users with bugs we've already seen here and there and that are fixed in master :))
tomok. I'm not sure what you mean by 'friendly fork'
ZashMVC-ish separation of UI code and other application logic is good, so you might be able to ensure/push for that 🙂
pep.Yeah, either try to make the new code easy to adapt to new toolkits, to make it easier for you to have your gtk2 patches on top
pep.It's a bit more maintenance for the gajim devs, but if you're willing to help maybe they would be ok? And you benefit from new features/bugs (fixes) etc.
tommaybe. I don't see me needing to change toolkits in the near future, if I was going to do that I'd probably be going from gtk2 to qt but going from gtk to qt is a much bigger change than going to one gtk version to another. I don't expect to have to save development model as Gajim. I'm more interested in conservative LTS releases and stabilizing those as much as possible than implementing many features very fast. However everything is still very much up in the air right now so I'll definitely think about it. And as I see it currently the Gajim devs have a very different grand vision in mind than I do right now.
tomI also see myself using the XFCE 4.12 theme engine for at least another 6 years and gtk2 is very well supported there
ZashI thought XFCE were going GTK3 too
tomyes, but Debian isn't
tomnor am i
pep.Debian isn't?
pep.So they'll maintain their fork downstream?
tomDebian will maintain the 4.12 release for 6+ years
tomwith security patches and bugfixes only
pep.What kind of Debian releases are you talking about?
pep.LTS ?
tomstable
pep.stable only go 4 years no? + maybe another year for LTS?
ZashNot 3 years? (new release about every 2,
tomI don't know how well versed you are with Devuan/Debian release models but ounce a STABLE RELEASE becomes OLDSTABLE RELEASE it then goes into LTS support by a private company that employs a team of fulltime developers
Zash+1 y support) (gah why is enter there?)
pep.stable (2) -> oldstable (2) -> lts (1)
tomas long as the funding goals are met it's 6 years
pep.ah
pep.I'm not well versed into LTS tbh
pep.Also I'm surprised I haven't yet shouted HERESY all over this room
Zashpep., I've been very tempted to ask whether this fork is Python2 😛
pep.tom, yeah I know about them, just never bothered to read
pep.I shall return to my omemo stuff now.. (another fun thing to play with)
tomWell, I would be tempted to convert Gajim 0.16.X to python3
ZashOh, so the py3 switch was in 1.x then?
Zash(I've not been following Gajim that closely)
tomlet me check
tomyes, It looks like Gajim.py specifies the python interpreter, and the default version in Devuan ASCII is Python 2.7.13 (default, Sep 26 2018, 18:42:22)
[GCC 6.3.0 20170516] on linux2