Gajim - 2018-05-08

  1. Citizen Zibb Lol
  2. Citizen Zibb I was a little hasty
  3. bbreezin Not sure if this is expected or not, I'm seeing AttributeError: 'NonBlockingTCP' object has no attribute 'ssl_errors' from connection_accepted() in master
  4. lovetox bbreezin, you have to install nbxmpp from git
  5. lovetox or use a nightly package
  6. bbreezin ahh okay, coded around that issue with try/catch to make it work for now
  7. lovetox pip3 install git+gitcloneurl
  8. lovetox if you dont know that already
  9. bbreezin trying to look into issue #9092, the history mismatch issue. Just looks like the sqlite queries need to be filtering by account_id in the database, but they aren't already
  10. lovetox yes nice issue to start
  11. lovetox should be relativily eas
  12. lovetox easy
  13. lovetox but there is a catch
  14. lovetox the account_id field is only there since gajim_1.0
  15. lovetox so expect that many of these fields come back empty for people that use the same database since 0.16.9
  16. lovetox so the db query must be, accound_id is in (id, empty)
  17. lovetox this is of course not correct sql syntax, just saying
  18. bbreezin gotcha, I should be able to test that case by just removing the account_id field in my database to simulate
  19. lovetox no you misunderstood
  20. lovetox ah no
  21. lovetox if you mean by field, the value in the field its ok
  22. lovetox you dont need to remove the column, it will always be there, because migration adds it the first time someone start gajim 1.0
  23. lovetox it just will be empty
  24. bbreezin I can delete the account_id field in my gajim_1.0 db to simulate an older db, no?
  25. bbreezin oh ok
  26. bbreezin just the values
  27. lovetox and yes thats a good way to test this
  28. bbreezin currently trying to figure out where to get the actual account_id when populating that listview on the history window
  29. lovetox look at the module
  30. lovetox there we do the db querys
  31. lovetox you have to adjust the db query, than it will automatically return a named tuple that includes the new column
  32. lovetox but ideally the db query gives only back what we query
  33. lovetox so no need to sort that out in the listview
  34. bbreezin but I need to compare to the actual account_id of what should be shown in the history window
  35. bbreezin so I need to know the which account_id the user is asking to see the history of
  36. lovetox let me take a look
  37. bbreezin this would be in I believe
  38. lovetox no history_manager ignore for now
  39. lovetox its based on JIDs
  40. lovetox you cant just filter an account, you would need to add a account selector
  41. lovetox start with the
  42. lovetox you can do the whole patch in the in my opinion
  43. lovetox you find the method that the uses to query records
  44. lovetox in the there is a method called, get_account_id()
  45. lovetox use this to get the account_id from an account name
  46. bbreezin got it, just figured out I actually want, now this makes more sense
  47. lovetox get_conversation_for_date
  48. lovetox is the method in you want to modify
  49. lovetox and it already has the account name supplied
  50. bbreezin yep I see it now
  51. lovetox just to make it a bit more work
  52. lovetox there are various other db calls in
  53. lovetox of course all have to take then account_id into considaration
  54. lovetox also if you modify the args of a method call, always grep the whole code base for that methodname, to catch where we use it and modify these to
  55. bbreezin is get_last_conversation_lines() where the last few log lines are loaded into the conversation window into small text?
  56. lovetox yeah i think
  57. bbreezin Yeah it is, adding account_id in that function fixed the messages window
  58. bbreezin like you said, need to think of how to handle it when you click History from the View menu on the main window
  59. lovetox ah
  60. bbreezin looks like it will use account_id = 1 if you have two conversations with the same contact
  61. lovetox becuase we have no account there...
  62. lovetox then make it for now that this window will not filter per account
  63. lovetox this is i guess expected
  64. lovetox the problem is mostly if you select history from within a conversation, that it displays message that have not been in this conversation
  65. lovetox if i select history from view, and type a JID
  66. lovetox it is expected i get everything from this jid
  67. bbreezin Right
  68. bbreezin Right
  69. bbreezin but same window doing both duties
  70. lovetox to be honest this brings us to the next point, why can we even change the jid if we open the window from winthin a conversation
  71. bbreezin Yeah I agree
  72. lovetox its always like that, one leads to anther
  73. lovetox i recommend baby steps and solving one task after another 🙂
  74. lovetox so just fix it that account is taken into consideration when we open from within a conversation
  75. lovetox and the backlog loading for the chatwindow
  76. lovetox afterwards in another MR you can then look into the other things
  77. bbreezin but the History window from the view menu is the same window right?
  78. bbreezin so if it is also using get_conversation_for_date() it'll filter by account when we don't want it to
  79. lovetox bbreezin, but the window is called with other args or not
  80. lovetox the window cant have a value for account, if we call it from the menu
  81. lovetox so if you have no account, you can call another db method, or do another sql query inside the method
  82. lovetox look HistoryWindow is called without account from menu
  83. lovetox so it is None in that case
  84. lovetox so you can know what to do
  85. bbreezin Right
  86. bbreezin Yeah so right now in that case when it is None, it uses info_account, which is the first account
  87. bbreezin so I need to change that behavior
  88. bbreezin Alright, way past my bed time. I will keep thinking on this. Right now when called from the menu with account=None, self.account=info_account, so populating the dates and log data gets done with info_account. We want the dates, and log data to be populated with data from all accounts in that case
  89. bbreezin thanks for the help so far. I will have more questions I'm sure
  90. bot Christoph Erhardt closed an issue in _python-nbxmpp_ < >: #49: < python-nbxmpp fails to parse a JID's domainpart expressed as an IP-literal >
  91. pep. > Maranda> lovetox, it happened to me once as well but I was unable to track it down, Link Mauve told me I was spamming with presences the Tatoeba room. Because it was movim@
  92. Maranda pep. What?
  93. Maranda Oh
  94. bosurus Hi, I have a problem to set GUI to german language. Gajim 1.02 on Windows 7. I have set env var LANG to de_DE (and tried other var like LC_ALL etc) but i does not work
  95. lovetox its broken bosurus, we have already a issue about it
  96. lovetox hope to fix it in the next major gajim version
  97. bosurus Thanks. it tried alos to open an issue, but found next problem: I do not get the confirmation email for registring
  98. lovetox thats bad maybe asterix can look into that
  99. lovetox what is your name on gitlab?
  100. bosurus I tried to register as "stephan"
  101. lovetox i activated your account
  102. bosurus Thanks for your help and the info about language selection; I will wait for the new version
  103. asterix lovetox: I didn't know there was a confirmation email ...
  104. lovetox for users who register with their own email
  105. lovetox i would think so
  106. xram Hum, no mam in this conference?
  107. lovetox yes this room has mam
  108. bot Daniel Aleksandersen created an issue in _gajim_ < >: #9117: < Windows UAC dialogs changes status to Not available >
  109. vanitasvitae lovetox: regarding xep-0373, how did you create pgp keys with the userid ""? My gnugp refuses to do that :/
  110. lovetox what command do you use?
  111. vanitasvitae gpg --edit-key
  112. vanitasvitae And then adduid
  113. vanitasvitae It refuses to accept "xmpp:jid@server.tld" as name, mail addtess and comment
  114. lovetox then you are not creating a key..
  115. lovetox i dont do this so i dont know
  116. lovetox but its probably possible
  117. lovetox gnupg just defaults to a behaviour
  118. lovetox but im sure you can overwrite this
  119. vanitasvitae > then you are not creating a key.. The same dialog comes when creating a key
  120. vanitasvitae It doesnt work at creation time either
  121. vanitasvitae > i dont do this so i dont know > but its probably possible Afaiu it is mandatory in xep-0373, so we should find a solution :D
  122. lovetox its not mandatory to give the user the ability to edit existing keys
  123. lovetox --gen-key allows for providing a dict like input file
  124. lovetox which overwrites gnupg behaviour
  125. lovetox
  126. vanitasvitae Ah I'll look into that
  127. vanitasvitae > its not mandatory to give the user the ability to edit existing keys But it is mandatory, that keys used in the context of 373 do have a uid attribute with xmpp:jid@server
  128. lovetox yes, and thats what i do
  129. lovetox but im not editing existing keys of users for that
  130. lovetox i generate a new key for use with xmpp
  131. lovetox you should really think this through if you planning to let users add their own keys
  132. vanitasvitae Yeah I'll consider that
  133. lovetox stuff like blind trust before verification needs many trust changes to the keyring
  134. lovetox if a user lets you use his main pgp key, he will not give you his password
  135. lovetox meaning you have to use a agent
  136. lovetox meaning he gets prompted everytime a new key is received
  137. lovetox or he has to configure his agent that he is not prompted on EVERY change
  138. vanitasvitae Which uid parameter do you provide? Name, mail or comment?
  139. lovetox which means he gives the application basically access to his whole keyring
  140. vanitasvitae I think the best solution would be to auto generate a key and give the user the ability to sign it with his own key.
  141. lovetox params = { 'Key-Type': 'RSA', 'Key-Length': 2048, 'Name-Real': 'xmpp:%s' % jid, 'Passphrase': passphrase, }
  142. vanitasvitae Okay
  143. vanitasvitae Thank you :)
  144. vanitasvitae Ah, generating the keys unattended worked :)
  145. bbreezin is the list app.contacts.get_accounts() always indexed as (account_id - 1) as in the account_id stored in the log database?
  146. bbreezin I'm asking if I can use the account_id in the database to lookup the account with .get_accounts()[] to get the account nickname
  147. lovetox no breezin
  148. lovetox that gets you a list of all accounts
  149. lovetox but you can delete accounts
  150. lovetox so the index of a account can be 100
  151. lovetox if you deleted 99 accounts before
  152. lovetox account_id is a database thing, you should not introduce it anywhere else than in the
  153. lovetox and there you can convert a account name to a id with the appropriate method
  154. bbreezin Ahh, need to get from account id in the messages to the nickname in the _add_message() function
  155. bbreezin add_message() in the HistoryWindow
  156. lovetox why?
  157. lovetox the nickname of what?
  158. bbreezin The case where I have a conversation with contact C with both my accounts A and B. In the history window from the View menu, we want to show all messages with contact C
  159. bbreezin so I want the prefix to every SENT message (my nicknames) to show the correct account A or B nickname
  160. lovetox this is already done in add_message
  161. lovetox just look how it determines contact_name
  162. bbreezin you're talking about the if self.account:
  163. bbreezin self.account is always defined. Even when launched from the View menu
  164. bbreezin even if self.account was None in that case, it would just use the nickname from the first account in app.contacts.get_accounts()
  165. lovetox ok so you get account_id from the database and want to translate it to a account name
  166. bbreezin Right, each message object passed into add_message() as an account_id field
  167. bbreezin I want to use it, and if the account_id is blank, I will default to using the name of the first account from app.contacts.get_accounts()
  168. bbreezin has an*
  169. lovetox ok let me thing about it whats the best move here
  170. bbreezin No problem. In _load_history(), I had to loop through all accounts in app.contacts.get_accounts() when the window is opened from the View menu for the purpose of running the get_first_date_that_has_logs() and get_last_date_that_has_logs() functions. The first or last messages could be stored in either account that messaged the contact.
  171. bbreezin Does that sound like a valid method to you?
  172. lovetox hm no i dont think i understand this
  173. lovetox if there is no account supplied
  174. lovetox then it should not be in the db query
  175. lovetox so you get the first date that has logs, and dont have to care about the account
  176. lovetox the account has to be supplied to get_last_date_that_has_logs() because of the metacontacts hm
  177. lovetox so we could just pass a list of accounts, and gather all the familiy jids from all accounts
  178. bbreezin but the functions, get_first_date_that_has_logs and get_last_date_that_has_logs require accounts
  179. bbreezin Right, so either iterate through an account list in HistoryWindow, making multiple calls to the logger functions, or pass a list of accounts to the logger function and have it do the checking
  180. lovetox the second one
  181. lovetox the account is only need to gather a list of jids that will be taken into account
  182. lovetox goal would be to do only one db query
  183. lovetox not multiple
  184. lovetox so loop over get_family_jids, acquire all jids
  185. lovetox then do one db query
  186. bbreezin Gotcha, so essentially pass the result of app.contacts.get_accounts() to the call
  187. lovetox i think this would be correct
  188. bbreezin Okay, I'll work on that. Like you said....this small issue has snowballed into a lot more work than it first appeared to be lol
  189. lovetox yeah quite complex now
  190. lovetox though im really overthinking if we need that view -> history window call
  191. lovetox it seem to be redundant if you look at the history manager
  192. lovetox which does the same
  193. bbreezin The history manager doesn't have the calendar selector or anything though
  194. bbreezin I think eventually it might not be a bad idea to have an "account" drop down in the history window to only show messages from the account you select, or the option for all accounts, but all this current work will be the basis for selecting the "show all accounts" option
  195. lovetox i will add a method that gets you the account from the id
  196. lovetox do you know how you rebase your work?
  197. bbreezin Yeah I've added an upstream remote
  198. Maranda rebasing that strange thing
  199. bot Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim_ < >: *2bb5d55c* < > Add conversion from account_id to account jid To use this alias `account_id` with `account` Example: SELECT account_id as account FROM logs
  200. lovetox there you go bbreezin ^
  201. bbreezin Got it, I'll dig into this later. Thanks lovetox
  202. marc I get this error message on Ubuntu: E: Repository ' unstable InRelease' changed its 'Origin' value from '' to 'Gajim'
  203. marc What's wrong?
  204. asterix I indeed changed origin ... nothing wrong
  205. marc asterix, okay, thanks
  206. bot Daniel modified an issue in _gajim_ < >: #9117: < Windows UAC dialogs changes status to Not available >
  207. bot Daniel modified an issue in _gajim_ < >: #9114: < group chat makes gajim segfault in glib >
  208. bot Daniel modified an issue in _gajim_ < >: #9113: < Gajim on OpenBSD gives error when connecting >
  209. bot DorKeinath created an issue in _gajim_ < >: #9118: < gajim-nightly problem with gir1.2-gtk-3.0 or 3.10.8~8+qiana >
  210. bot Philipp Hörist closed an issue in _gajim_ < >: #9118: < gajim-nightly problem with gir1.2-gtk-3.0 or 3.10.8~8+qiana >