tmolitorarune: I fixed the emoji sorting :) I'm creating a ticket for code inclusion right now...
tmolitorasterix: please see this ticket for proper emoticons sorting: https://trac.gajim.org/ticket/8204
tmolitorasterix: I attached a patch to the ticket....
botRSS: Feeds for Gajim
• Ticket #8204 (emoticons in dropdown menu not sorted properly) created
Bug description
Gajim can not sort emoticons provided by the emoticons plugin.
The missing ability for emoticon pack designers to specify the sorting of their emoticons in the emoticons dropdown menu is ab bit anoying.
Given large emoticon sets containing all u[…]
https://trac.gajim.org/ticket/8204
• gajim_emojis_sorting.patch attached to Ticket #8204[]
botRSS: Feeds for Gajim Plugins
• Changeset [708:2dc8e77a80e5]: Added new (better) sorting to the twemoji resized package
Added new (better) sorting to the twemoji resized package
https://trac-plugins.gajim.org/changeset/2dc8e77a80e5cb87ee80ca4830ed9f23dc93d60a
arunetmolitor: great
aruneI discovered that the emoji pack didn't work reliable in windows anyway though
botRSS: Feeds for Gajim
• Changeset [15891:47d1d194e2d1]: [tmolitor] add a way to sort emoticons in emoticon menu. Fixes #8204
[tmolitor] add a way to sort emoticons in emoticon menu. Fixes #8204
https://trac.gajim.org/changeset/47d1d194e2d18c9c041a29ea45ad63b86c20d537
• Ticket #8204 (emoticons in dropdown menu not sorted properly) closed
fixed:
In 15891:47d1d194e2d1:
[tmolitor] add a way to sort emoticons in emoticon menu. Fixes #8204
https://trac.gajim.org/ticket/8204#comment:1
kalkinHow do i remove state msgs in normal conversations (not muc). i have searched preferences and advanced preferences
tmolitorarune: why that? I used png files instead of svgs....
arunekalkin: I can check when at my computer, remind me if I forget
arunetmolitor: they did work a while but then not anymore really strange
aruneMaybe Unicode issue in windows gajim
kalkinarune: Thanks in advance!
tmolitorarune: well...maybe you can try again and collect some more information via gajim -l DEBUG or something like that...
kalkinI understand that for some people seeing if the user is on/away/of is important, this kind of people also want to see the state msgs in conversations and gc. Wouldn't it be good idea to have a switch, which disables the whole state stuff like conversations does?
kalkinAt the moment i have to hide state msgs for each muc by hand, this is cumbersome.
Asterixkalkin: state message is "is composing" or "is away" ?
Asterixprints_status_in_chats if it's the second
kalkinthe second
Asterixkalkin: print_status_in_muc for muc
kalkinAsterix thanks
danielCan somebody either tell me or point me to an example on how a plugin can add a menu item to the account context menu? The one that shows if I right click on the account and that has status, personal events, add Contact and so on in it?
Asterixdaniel: currently not possible, but I can add a gui extension point there
danielor maybe action / advanced / for account xxx ? is that possible right now?
danieli just need a menu entry under something account related instead of contact / chat window related
Asterixno it's not either
danielif not it would be great if you could provide that extension point
Asterixyes that's a good thing to do
kalkindaniel: but an extension point doesn't solve the issue now
kalkindaniel: You could just hook in to the Gear Menu like OTR does
danielAsterix, and since you are here right now could you merge this: https://github.com/kalkin/gajim-omemo/blob/master/gajim_fix_pep_messages.patch
danielkalkin, i like solutions not workarounds
kalkindaniel: well thank you picked a wrong job :D
kalkins/thank/then/g
Asterixwhat does it do exactly?
Asterixwhat the link between omemo and pep?
danielAsterix, omemo uses pep (it stores something thats called prekeys in pep). gajim without that patch just eats every unknown pep message
danielunknown meaning not in a list of known namespaces
danielwith this patch all unknown pep messages will just be treated as raw-messages and pushed up the chain
danielpushed up the chain => allow for further processing. by the plugin for example
Asterixdaniel: wouldn't it be nicer to add an AbstractPEP object in the SUPPORTED_PERSONAL_USER_EVENTS variable?
danieleither way i don't think the plugin does any harm as it just pushes messages that were not treated by the pep code on
danielit was kinda confusing to listen to raw_messages and just not receive some
danielespecially since messages that _are_ in the namespace do appear in the raw message event
Asterixexcet this returns breaks a loop
Asterixand the raise is not called (not sure it is really needed though ...)
Asterixand your "return" will block event. A "return True" is neede to not stop it
Asterixand your "return" will block event. A "return True" is needed to not stop it
danielpep events only have one item. so the loop breaking doesn't do any harm
danielbut yeah i guess i could still fix that
Asterixdaniel: I think that's cleaner to have a new class to handle each PEP namespace
danielAsterix, ok i will make the plugin add its namespace to the pep thingy. however i really think the behaviour of messages just not showing up in an event called raw_message_received is very very confusing
danielat least it confused us
Asterixthat's the same for all other messages type. for example RosterItemExchange messages are handled in the RosterItemExchangeEvent, and thus are not forwarded as a raw-message
kalkinAsterix: IMHO if you call something raw-message, people expect to have access to all raw messages (whatever the definition of message is in this context)
AsterixI understand your point ...
kalkinnot saying that you want to use raw-message in this case, but you see where am i going...
Asterixthat's a bit of overhead to continue forwarding this message as a raw-message while it is better handled and parsed in a RosterItemExchangeEvent ...
danielEspecially since other pep messages tune and what not DO show up in raw message
Asterixthey are converted to PEPReceivedEvent later in the process ...
Asterixhmmm yes ... I See that we don't block calling message callback when we get a pep message. I think we should