Gajim - 2017-08-24

  1. Asterix GN
  2. bot Yann Leboulanger pushed 1 commit to branch _refs/heads/master_ of _gajim_ <>: *2b065c0e* <> remove unused import / variable
  3. lovetox i think i found the reason
  4. lovetox there is a pylint.rc file in the gajim folder
  5. bot Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim_ <>: *b9363fe9* <> Remove pylint.rc from gajim folder
  6. lovetox hm no does still not work
  7. mimi89999 How can I see if my contact read a message in Gajim?
  8. andrey.g mimi89999‎: I guess it is still impossible: "Support XEP-0333: Chat Markers"
  9. andrey.g And even delivery receipts were disabled: "Dont show warning on missing 0184 receipt" :(
  10. andrey.g Aha, there is "positive_184_ack" in ACE. Let's try...
  11. mimi89999 Isn't it about me sending them?
  12. andrey.g I don't know for sure, but usually XEPs describe the behavior for both directions.
  13. Asterix 184 tell that the contact's client received the message, not sure it has been read / understood
  14. bot Philipp Hörist pushed 2 commits to branch _refs/heads/master_ of _gajim_ <>: *663176cf* <> fix some import warnings and errors pointed out by pylint *94cbccec* <> Merge branch 'imports' into 'master' fix some import warnings and errors pointed out by pylint See merge request !121
  15. andrey.g Asterix‎, yes. For me 184 is much more important than 333.
  16. lovetox andrey.g, 184 still works in gajim better than ever
  17. lovetox but its still not what you want, and it will never be what you want
  18. andrey.g lovetox‎, yeah. BTW, I thought, that 184 has been removed because IIRC warnings were showed by default, but now positive acks are not showed by default.
  19. lovetox what do you mean by default
  20. lovetox this setting was never enabled by default, as its privacy related
  21. lovetox hm no that makes no sense actually
  22. lovetox we should show the positive ack by default
  23. lovetox this setting probably only exists because people wanted a way to turn of the red X all the time
  24. lovetox but now that its gone i see no reason to not show the positive ack by default
  25. lovetox at least until gajim has something like readmarkers
  26. andrey.g I don't see the setting for disabling red X.
  27. lovetox its the same setting
  28. lovetox show positive ack, means show receipts
  29. lovetox actually that only the internal name for it
  30. lovetox the user has the option "Notify by icon when your messages are received"
  31. lovetox which is clear enough
  32. andrey.g > its the same setting I'm not sure. Before I always had them, now not, because positive_184_ack was disabled.
  33. lovetox you dont see red X because its removed from Gajim
  34. lovetox and positive ack = show receipt icons
  35. lovetox which is disabled by default, it was always like that
  36. lovetox but we can make it on by default
  37. andrey.g > i see no reason to not show the positive ack by default Agree and especially, because gajim asks for them unconditionally (e.g. commit "Always send message delivery receipts requests"), so why then ignore them? Thus it would be even better to check this config before querying for them.
  38. lovetox you misinterpreting commits
  39. lovetox Always meant of course only if the user wants
  40. lovetox but before we even then did not always request it
  41. lovetox this was regarding offline contacts
  42. andrey.g lovetox‎, I mean that showing red X was not regulated by positive_184_ack as you said.
  43. lovetox where we didnt request receipts
  44. lovetox i think it was
  45. lovetox positive ack means show receipt icons
  46. lovetox in the past it meant show red x when we dont get one
  47. andrey.g "Always" I mean that not depending, whether the user want them to be displayed. No display - no need to ask for them.
  48. lovetox yes i agree
  49. lovetox the setting is now useless
  50. lovetox but just to be clear, thats not the setting that regulates if we request receipts
  51. lovetox it just if we show them
  52. andrey.g > at least until gajim has something like readmarkers I vote to keep pos. 184 acks even after readmarkers come.
  53. andrey.g Yes.
  54. andrey.g At least now.
  55. lovetox i did not mean to remove them, as the marker xep can not compensate the 184 xep
  56. lovetox but it maybe influence the default on what we show
  57. andrey.g Then good.
  58. lovetox if you can get the information if someone read the message, its not needed to show you that its received
  59. andrey.g Yes, once readmarker is received it could just replace the 184 one.
  60. lovetox but of course these are minor things that can be discussed to find sensible defaults
  61. bot Yann Leboulanger pushed 1 commit to branch _refs/heads/master_ of _gajim_ <>: *e57817ad* <> Nicer code
  62. mimi89999 lovetox: Shouldn't be hard to show that message was read...
  63. lovetox it probably would not, but at the moment instead of adding new features i try to conectrate on refactoring
  64. lovetox as the codebase is really old and needs some updates
  65. mimi89999 lovetox: Do you think I could try to implement it?
  66. mimi89999 lovetox: I think moving the read status might be a bit difficult. Will it be?
  67. mimi89999 I mean in the chat window.
  68. lovetox i would not move anything
  69. lovetox we add a mark in the textview, the name of the mark is the stanza id
  70. lovetox when a receipt comes we grab the mark and insert the symbol
  71. lovetox so if now another read receipt comes, you would grab the mark again
  72. lovetox delete one char to the left
  73. lovetox and insert the new symbol
  74. lovetox better not delete the received mark
  75. lovetox instead add the second symbol besides
  76. lovetox because when the next read receipt comes you have to delete the previous one
  77. lovetox because you dont get for every message a read receipt only for some, we should only display the last
  78. mimi89999 lovetox‎: It was what I mean
  79. mimi89999 lovetox‎: If I send 2 messages and get a read for one and then for the other, we should only display read for the last one... So the previous read would be removed...
  80. mimi89999 I have no clue how to add that...
  81. mimi89999 I know Python...
  82. lovetox mimi89999, in the time i would need to guide you through this i could probably do it myself. i have a branch where i began to implement it, maybe wait a few weeks and i have time to finish it
  83. mimi89999 lovetox‎: Which one?
  84. mimi89999 (branch)
  85. Asterix hmm this is perfectly valid code: but pylint return an error: E: 11, 4: An attribute defined in ttt line 21 hides this method (method-hidden)
  86. Asterix we don't hide the d() method here
  87. Asterix how can I prevent pylint from raising that error without disabling E0202?
  88. bot Yann Leboulanger pushed 1 commit to branch _refs/heads/master_ of _gajim_ <>: *8d4e815f* <> fix some pylint errors
  89. bot Yann Leboulanger pushed 1 commit to branch _refs/heads/master_ of _gajim_ <>: *134f72db* <> Hide some pylint errors