Gajim - 2019-06-10


  1. lovetox no erik, what we have is a event system, where everyone can issue events, and everyone can subscribe to it
  2. lovetox but events are not bound to objects
  3. lovetox also there are 2 different situations you have to think about
  4. lovetox one is where Gajim internal one object issues a event and another object subscribes to the events of that specific object, for that you can use GObjects event system https://python-gtk-3-tutorial.readthedocs.io/en/latest/objects.html
  5. lovetox Every Gtk Widget is a GObject
  6. lovetox and then there are events that plugins in Gajim want to catch
  7. lovetox its not a good idea for plugins to find some internal Gajim objects to subscribe to it
  8. lovetox its better they subscribe to a global signal like message-reveived or something
  9. lovetox and for that you can use the event system which Gajim already has
  10. erik Ok. Thanks! Now I know what to search for!
  11. lovetox see message_textview.py
  12. lovetox for an example how to inherit from a Gtk Widget and extend signals with our own
  13. lovetox erik, i just read your wiki page, good job of writing this down
  14. lovetox some notes that may make this easier
  15. lovetox I dont think its needed that you spend time to make the new listbox and old textview exchangeable
  16. lovetox thats noble, but also will cost much time i think
  17. lovetox hm but its in the end maybe easier and can be done in much smaller steps
  18. lovetox ...
  19. erik My idea was to make the steps as small as possible. It allows me and others to work together quickly and reduces the effects on the rest of the code base, apart from some clean-up
  20. lovetox The HtmlTextview does right now extend the normal Gtk Textview just with html parser caps
  21. lovetox we will need that also for the listbox design
  22. lovetox would it not better to only move stuff into the htmltextview, that should also be there once the listbox design is finished?
  23. lovetox like does the htmltextview need some api to do buffer operations on it
  24. lovetox like get_end_mark etc
  25. lovetox because in the listbox design we will never operate on the htmltextview buffer?
  26. lovetox at least nothing comes to mind why this would be needed
  27. lovetox in the listbox design, we just pass a html text to the htmltextview and it draws it, we will probably never have to manipulate that buffer later on
  28. erik Agreed, that's likely.
  29. lovetox im not sure on this
  30. lovetox what i really want to say is, if we move stuff into the htmltextview
  31. lovetox its better we really need it to be there also with the listbox design
  32. lovetox hm
  33. erik Agreed. I need to think how to deal with the other methods then
  34. erik However, it could be that in the first iteration it needs all that
  35. lovetox i just thinking loud, im actually not sure what the textview has to do in the listbox design
  36. erik Because we have no specialised row classes tyet
  37. lovetox it displays initially the text yes
  38. lovetox but what if we have a correction
  39. lovetox do we correct the text of that textview? or is the textview replaced as a whole
  40. erik I'd say we replace it as a whole
  41. erik At last until we find performance problems
  42. lovetox Ok you listed what the current design does, maybe you could draft the idea what the listbox design will do
  43. lovetox like what object does what
  44. lovetox then its probably easier to see a path where we can get there
  45. erik Yes. I'm working on that. Let me jot that down and w can discuss both that and the path to it
  46. erik For what I've learned so far, an estimated the immediate next step looked like what I wrote, but with or discussion I'm able to get closer to the target
  47. lovetox and how these two textview classes came to be is, once there was the idea to have some textview that can display html, this was used in other places in Gajim as well, so all the stuff that you would need in a chat, you would not need there. So the ConversationsTextview was created as a wrapper around the htmltextview
  48. lovetox for example in the plugins window, authors could write descriptions for plugins using html code
  49. lovetox this has nothing to do with chat and does not need all the correction stuff etc
  50. erik Ok. With that background my immediate step does make less sense
  51. lovetox but this was removed
  52. lovetox only the conversationstextview uses the htmltextview now
  53. lovetox so maybe in your analysis dont treat them as separate things
  54. lovetox the conversations textview is just an extension of the htmltextview
  55. lovetox point is we need a textview for the listbox design
  56. erik Ok. That works for me. Yes, we need textview for the listbox indeed
  57. lovetox it does not need to do as much as the conversationstextview right now
  58. lovetox like tracking messages etc
  59. erik No, my idea is that we need something to track messages and tell the listbox on addition/correction
  60. erik Then the listbox can adjust appropriately
  61. erik I was thinking that that is the role of converssationtextview. But as you describe it, it's not.
  62. lovetox yeah everything was stuffed into it
  63. lovetox but i agree with your idea if i unsterstand it correctly, you want the a listbox object that only cares about displaying stuff
  64. erik Yes!
  65. erik Basically once we separate presentation from the logic that tracks the messages and what to update, I think we have room to experiment and swap various rendering options in and out until we're satisfied
  66. erik When I start editing that document again, later today, I'll have more questions, probably
  67. lovetox the most cumbersome thing i see to refactor is that now we call on the chat_control
  68. lovetox print_conversations_line
  69. lovetox this method has lots of args
  70. lovetox to many
  71. lovetox then it does some logic, and calls on the conversations textview, print conversation line
  72. lovetox again with 20 args
  73. erik Yes. The other probblem I identified is the history window
  74. lovetox actually its even worse
  75. lovetox we first call on the chat_control
  76. lovetox then we call on the chat_control_base
  77. lovetox then on the textview
  78. erik Right. I think that is where the message tracking object should come in
  79. erik Updating that should then propagate to whatever presentation is used
  80. lovetox Hm can you not just ignore the HistoryWindow for now?
  81. lovetox ah no
  82. lovetox is uses the Textview aswell
  83. erik Obviously that's an option which simplifies some of or work. I was thinking that it may actually help sharpen the solution.
  84. erik Obviously that's an option which simplifies some of our work. I was thinking that it may actually help sharpen the solution.
  85. erik Yes. It even duplicates some of the message rendering
  86. lovetox maybe thats a good first step, refactor that print_conversation_line maddness
  87. erik I think that is at the heart of the problem which complicates the current situation, yes.
  88. erik My thought would be that we try to create small increments which each add improvement to the codebase, to keep PRs small.
  89. lovetox yes but it will be hard to find small things :D
  90. erik So, this refactoring, when satisfactory, should not wait until the listbox is complete. Agreed
  91. erik I see it as my challenge to keep them small/simple.
  92. erik Ok. I'll extend the document with what I learned so far
  93. lovetox so most calls to print_conversation are status/info messges
  94. erik And start working on the refactoring of print_conversation_line
  95. lovetox print_conversation has like 15 arguments
  96. lovetox but to print a status message you need only text and kind=status
  97. lovetox maybe its worth to factor this out into a print_status_message
  98. lovetox then we call on much less places print_conversation
  99. lovetox and we can refactor this without all hell break lose
  100. bot Daniel Brötzmann closed an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9726 >: #9726: < Error when changing account status to offline - false alarm ? >
  101. erik I like that.Let me chew ok that a but
  102. erik Bit
  103. lovetox and we should also think about the role of the chatcontrol
  104. lovetox could this not be the object that does all the message tracking and message operations?
  105. lovetox the control is the main object where other parts of gajim act on it
  106. bot Daniel Brötzmann modified an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9726 >: #9726: < Error when changing account status to offline - false alarm ? >
  107. bot Daniel Brötzmann modified an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9726 >: #9726: < Error when changing account status to offline - false alarm ? >
  108. lovetox we have a control manager, so you can get from anywhere in gajim, all active or open controls
  109. lovetox so it would be only natural to call add_message on a control
  110. lovetox question is if it only passes it further to some other object that handles tracking of messages, or if it does it itself
  111. lovetox what speaks against putting more logic into the chatcontrol is, its already Huge
  112. erik We could make it a class with a special purpose too
  113. erik breakfast
  114. bot Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim_ < https://dev.gajim.org/gajim/gajim >: *0da3aa2d* < https://dev.gajim.org/gajim/gajim/commit/0da3aa2d310d8f12dfe7206ba7259d7ada3c8c4a > PluginsGUI: Disable expand for installed plugins box
  115. bot Philipp Hörist merged a merge request for _gajim/master_ < https://dev.gajim.org/gajim/gajim/merge_requests/449 >: PluginsGUI: Disable expand for installed plugins box
  116. hannibal lovetox, while refactoring textview, maybe xhtml-im support could be removed; xep-0071 is deprecated
  117. lovetox without a replacement? i dont think this is a good idea
  118. hannibal Markdown could be used
  119. erik hannibal, is there a xep for that?
  120. hannibal https://xmpp.org/extensions/xep-0393.html
  121. erik hannibal, well, that's experimental. that doesn't help much.
  122. erik also, Markdown allows embedded html
  123. erik or wait!
  124. erik that xep invents its own version of markdown?
  125. erik don't we have versions enough already?
  126. erik anyway, I'll concentrate on figuring out what to do with the current "print_conversation_line" first.
  127. erik lovetox, the reason I was thinking about some kind of listening or subscription model, is that the "ConversationMessagesModel" would be able to send updates of the model to all interested objects rather than to a single target.
  128. wurstsalat erik: there is an ongoing discussion about xhtml and markdown. Gajim supports a different kind of markdown and there is even an open issue about correcting this kind to the xep's markdown style.
  129. erik ok. I like to use markdown in my chats.
  130. erik however, I'm also aware that many clients in the XMPP space won't support such newfangled extensions.
  131. erik and since we already *have* xhtml-im, why can't we translate markdown in the client to xhtml-im?
  132. erik that way, older clients can support it too.
  133. erik (no idea how widespread the xhtml-im support is though)
  134. wurstsalat Fyi https://dev.gajim.org/gajim/gajim/issues/9670
  135. erik ok. for the purpose of my design, I'm going to be short and conclude "It's just another row type in the list box"
  136. lovetox Gajim already support parsing of text style markup
  137. lovetox its just a thing of adding more regex to recognize more things
  138. erik :-)
  139. erik ok.
  140. lovetox erik, first find things that other object would be interested in before designing some additional event system
  141. erik is my current assumption correct that there's only 1 conversationtextview for every muc or private chat going on?
  142. erik (agreed)
  143. lovetox yes
  144. lovetox every chatcontrol has one conversations textview
  145. erik right. and there's a one-to-one relationship between "muc membership on this Gajim instance" and a chatcontrol?
  146. erik oh. question: what's the difference between "print_conversation_line" for kind=status and kind=incoming/outgoing ?
  147. erik are the status messages temporary?
  148. erik or is it just that they are "different"?
  149. lovetox i dont understand what you mean be muc membership?
  150. lovetox are you refering to the muc contact list?
  151. erik let me rephrase: will all messages coming in from a chat (be it muc or private) always be presented in exactly 1 chat control?
  152. erik as in: there can't be more than one chat control for a specific muc or private chat, right?
  153. lovetox yes
  154. erik ok.
  155. lovetox there cant be more than one chatcontrol per JID
  156. erik then I don't need a notification system for now.
  157. lovetox per JID-Account pair
  158. lovetox sorry
  159. erik :-)
  160. erik thanks.
  161. lovetox the kind is only for styling
  162. erik ok.
  163. lovetox a kind=status will have a different color when in Ctextview printed
  164. lovetox then incoming / outgoing
  165. lovetox it also will not trigger printing the time
  166. lovetox in front
  167. erik ok. but it needs a time to be sorted correctly in the background, right?
  168. lovetox yes
  169. lovetox but status messages get automatic assigned a now timestamp if they are passed to the textview i think
  170. erik yes they are.
  171. erik After your explanation I'm now trying to figure out how this fits into the bigger picture.
  172. erik ok. another question: I found GroupChatControl and PrivateChatControl. The latter seems to be using "room_jid". Is that the jid of a user-in-a-muc? or a real user-jid?
  173. lovetox no its the jid of the room
  174. lovetox gajim@conference.gajim.org
  175. erik how does a direct-chat work then? I mean, which control deals with that?
  176. lovetox the PrivateChatControl
  177. lovetox ah mom
  178. lovetox there are 3 controls
  179. erik Private*, Group* and?
  180. lovetox ChatControl (1on1), GroupChatControl (Muc), PrivateChatControl (A direct message to another MUC participant)
  181. erik ah.
  182. erik ok.
  183. lovetox direct messages in a muc are different in the xmpp protocol
  184. lovetox from normal 1on1 messages
  185. erik maybe my first commit should be to add that to the description of the classes :-)
  186. erik right. I thought that is the case, which made me wonder how this is all handled.
  187. lovetox we call these direct messages
  188. lovetox PMs
  189. lovetox Private Messages
  190. lovetox because the MUC is public
  191. lovetox and you send a private message
  192. lovetox The GroupChatControl and ChatControl differ greatly
  193. lovetox because one has no roster for example
  194. lovetox and some things you cant do in groupchat which are possible in normal chat
  195. lovetox the private chat control though differs only slighty from the chat control
  196. lovetox so its based on that
  197. erik ok. I understand the structure.
  198. erik from reading the code, they also have different creators and probably different timing when they were last rewritten.
  199. lovetox its all rather ugly, but this is how its grown over years
  200. lovetox chatcontrolbase is probably the most ugly one, because it often has to do stuff differently depending on what control initialized it
  201. erik heh. I'm looking at the groupchat_control.py:_nec_gc_message_received handler
  202. lovetox Also the whole Contact module is flawed
  203. lovetox there are normal Contacts, and GCContacts
  204. lovetox GCContacts are the Muc participants
  205. lovetox Contacts are the normal 1:1 contacts, but also the Groupchat itself
  206. erik we have a very nice object which encapsulates basically *all* arguments for `print_conversation`, yet due to the call semantics, it needs to unpack the entire object!
  207. lovetox yes it would be nice if we had one object we just passed around
  208. lovetox instead of methods with 20 arguments
  209. erik well, I actually think that may be much easier than you think: if all those intermediate callers didn't meddle with the object but just got some state out of it
  210. pep. If only mutability wasn't the default..
  211. lovetox erik, have a go at it :)
  212. erik Yes, yes. I'm trying to get a handle on all this.
  213. erik I usually need a few rounds before I grasp all the aspects enough to come up with a good plan.
  214. erik but I hope you can see I'm starting to get an understanding of what's there at the moment.
  215. erik out of curiosity: I see that the GroupChat subscribes to the gc_message_received event and updates the parent's tab.
  216. erik I think that makes sense.
  217. erik but can't the ConversationTextview (in the current code base) subscribe to that event too and update its contents?
  218. erik instead of passing the event object's content through X layers?
  219. erik bbiab
  220. lovetox of course, but then you move much logic into the textview, the message object does not have all infos for a message correctly to be printed
  221. bot rfc2822 created an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9727 >: #9727: < Crash after opening a new tab and sending a message >
  222. lovetox for example textview does not know in what control it is, that we are in a muc and that we have a nickname
  223. lovetox and that if the message originator has the same nickname as us
  224. lovetox its a message from us
  225. lovetox and has to draw it accordingly
  226. lovetox this seems weird at first that we dont recognize a message we sent ourself immediatly
  227. lovetox but its due to the MUC concept
  228. lovetox we send a xml stanza
  229. lovetox the MUC server reflects the stanza to all participants, also ourself
  230. lovetox so if a message arrives from a MUC, we first have to determine if it is our own message we just sent
  231. lovetox and this logic right now does the chatcontrol
  232. lovetox it looks at the jid the message came from which could be gajim@conference.gajim.org/lovetox
  233. lovetox and if the jid == the jid we have in this muc, its a message by ourself
  234. lovetox so then it sets kind = outgoing
  235. lovetox of course you can move this logic into the textview
  236. lovetox but i think thats opposite of what you want to do
  237. lovetox there is another problem why you cant simply pass the message object around
  238. lovetox because print_conversation is also called not from message handlers
  239. lovetox if we issue a error message or status message
  240. lovetox these are not message objects we generated from the xml stream, like a groupchat message that we received
  241. lovetox thats why i meant it could be worth factoring that out, so printing real messages we received is not mixed with printing a status message
  242. lovetox for status message almost all args are None
  243. erik ok. while under the shower I already figured that the Ctextview doesn't know which chat it's part of.
  244. lovetox erik i try to factor the status and info message out, give me a moment, this will make things easier
  245. erik ok.
  246. erik I assume they still need to be rendered in the view though?
  247. lovetox yes of course
  248. erik ok. I'll just wait and see what you come up with.
  249. erik I'll be doing some work on the document and the desired end state.
  250. bot Daniel Brötzmann modified an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9727 >: #9727: < Crash after opening a new tab and sending a message >
  251. bot Daniel Brötzmann modified an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9727 >: #9727: < Crash after opening a new tab and sending a message >
  252. Owen Hi, I have an issue with file transfers. When I send it to a friend, it works (a link appears in conversation), but when he wants to send me a file, I get the notification, the tranfser window opens but no data is transferred (it stays at 0%).
  253. lovetox what client does he use?
  254. Owen gajim too
  255. lovetox probably the file is too big, your server has probably a file limit for http upload
  256. lovetox so direct file transfer is used
  257. lovetox and this fails for some reason
  258. Zash or they use a different server or a version of gajim without http upload
  259. Owen is there a way to tell?
  260. lovetox ask him, how big the file was
  261. lovetox what version of gajim does he use?
  262. Owen the file is only 46kb
  263. lovetox then his server probably does not support httpupload
  264. lovetox he can check that under accounts -> advanced -> server info
  265. Owen and why direct transfer isn't working?
  266. Zash NAT, firewalls, lack of proxy available maybe?
  267. EmleyMoor Whenever a new messenger contact occurs on Facebook. I get a "Roster Item Exchange" window, reading "facebook.firthpark.tinsleyviadut.com would like you to add some contacts in your roster." - fair enough, but what it offers me is all, or at least nearly all, of the ones I have. It also offers them only two viewable at a time and no obvious way to "deselect all". Is there any reason why it offers me hundreds I already have in my roster?
  268. Owen ok. He says "Gajim 0.16.9"
  269. lovetox thats pretty old
  270. lovetox he probably should upgrade to Gajim 1.1.x
  271. lovetox http upload in 0.16.9 is only available via plugin
  272. lovetox in 1.1.x its build in
  273. lovetox EmleyMoor, could be the transport doing weird things, or gajim just beeing shitty with transports
  274. lovetox i dont have a facebook account, so never tested this stuff
  275. EmleyMoor lovetox, It's more than likely the latter
  276. erik lovetox, quick question: I've updated the design doc and I'm contemplating there might be a type of status/info message that needs to be deleted sometimes: the "chat counterpart is typing" kind. Those have stanza_ids so they can be removed from from dispalay when the contact stops typing. Is that how it works? Most "status" messages don't have stanza_ids, I think? (the ones like "Role of {nick} has been set to '{role}'" have no stanza_id)
  277. EmleyMoor (it never did anything quite this crazy in psi+)
  278. EmleyMoor Besides, the "only two visible at a time" is DEFINITELY a gajim issue
  279. Owen ok, thank you
  280. lovetox erik the stanza-id can not be a unique identifier for rows, but we need the info to identify messages we want to correct
  281. lovetox because they refer to a stanza-id
  282. erik yes, I saw the mapping from stanza-id to buffer regoins.
  283. lovetox IF chatstates are displayed as a row
  284. lovetox its only one row, the chatstate row
  285. lovetox it will always be the same row, so you dont need sme unique number to identify it, the listbox should know it
  286. erik ah!
  287. erik thanks!
  288. erik that was a requirement I didn't have yet.
  289. lovetox depends of course on what you want to do, but there is no need to display chatstates in the listbox
  290. erik and actually, it's not really related to the chat content, is it?
  291. lovetox we dont have that yet
  292. erik ok. np. I think we want to place this outside of the scope of the chat content to be presented.
  293. erik for now at least.
  294. lovetox message rows of course need the stanza-id, status rows dont, we will never search a status row based on a stanza-id
  295. lovetox some other tracking mechanism has to be applied here, if we even have to track status rows at all
  296. lovetox you could assign some random id for now
  297. lovetox and return that id after adding the message, to whoever called add_message
  298. lovetox so whoever wants to remove that status message later can use this id to reference it
  299. erik ok. I think that works.
  300. lovetox but its hard to decide these things without a use case
  301. lovetox but every message should have some unique identifier i think thats for sure
  302. erik for now lets do that simply because "we can"
  303. EmleyMoor The Roster Item Exchange window needs to be bigger, or respond to being expanded
  304. lovetox EmleyMoor, please open an issue
  305. EmleyMoor lovetox, to do that do I follow "Bug reporting" at https://gajim.org/dev.php?lang=en
  306. EmleyMoor ?
  307. wurstsalat EmleyMoor: yes, just open one here https://dev.gajim.org/gajim/gajim/issues/new
  308. wurstsalat erik, lovetox: 'read' markers should also be considered for a future use case. These would be displayed between message rows, depending on until where the contact has read up
  309. erik wurstsalat: ok. I'll add that to the list of requirements.
  310. erik How does xmpp indicate that? Does it send a read notification for each stanza?
  311. lovetox yes
  312. lovetox referencing a stanza-id
  313. erik Ok. I need to think how such a future function would fit in with the content model.
  314. bot Philipp Hörist pushed 3 commits to branch _refs/heads/master_ of _gajim_ < https://dev.gajim.org/gajim/gajim >: https://conference.gajim.org:5281/pastebin/12b4b055-fc58-4770-b7a1-d3a49b70091f
  315. lovetox erik i refactored that now a bit
  316. lovetox the chatcontrolbase now has add_message, add_status_message, add_info_message
  317. erik Checking now
  318. erik Nice
  319. erik Ok. That's a nice clean-up already.
  320. bot Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim_ < https://dev.gajim.org/gajim/gajim >: *c3461a43* < https://dev.gajim.org/gajim/gajim/commit/c3461a43e36f980d3155b986e2adb945423fcac2 > Remove unused argument
  321. wurstsalat Great writeup there, erik!
  322. bot Phil Reynolds created an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9728 >: #9728: < Roster Item Exchange window too small, especially on large additions >
  323. erik Thanks. I'm trying to sort this out before making a (bigger) mess out of it
  324. pep. > erik> and since we already *have* xhtml-im, why can't we translate markdown in the client to xhtml-im? > that way, older clients can support it too. > (no idea how widespread the xhtml-im support is though) It still is widespread. Some are also not going to implement mark{up,down, right,left} either fwiw :)
  325. erik I think this may not be the place to discuss, but can't clients just translate to xhtml-im?
  326. pep. Yeah, that'd be a way to go. Keep markwhatever as the input method only
  327. erik All the more reason to simply push forward on xhtml-im instead which is implemented already in many places
  328. wurstsalat erik: restored_messages are are (user) defined number of past messages to be displayed when a chat window gets opened. These are displayed with a smaller font size per default, but this is a setting you can choose. There would be better types of styling in the future, I guess (maybe a lighter font color or even listbox row background color changes or such)
  329. erik Ok. I'll need to document the meaning of each of these fields to get a good grip on what I'm getting myself into.
  330. bot Philipp Hörist updated a merge request for _gajim/master_ < https://dev.gajim.org/gajim/gajim/merge_requests/447 >: Add avatar generator
  331. erik what's the difference between "count_as_new" and "restored_message"?
  332. lovetox restored_message is a text tag
  333. lovetox that applies some formatting in the textview
  334. lovetox count as new is a var that makes sure we issue no notification to the user for every old message we load
  335. erik ok. but then they both serve the same purpose?
  336. erik in the sense that they both indicate that the message is to be treated as "loaded from an old source"
  337. erik (mam or whatever)
  338. erik functionally, I mean. technically, they obviously don't.
  339. erik is there a difference between "delayed" and "count_as_new"?
  340. lovetox the var is only set so notification code is not executed
  341. lovetox delayed means there is a delay timestamp in the stanza
  342. lovetox means the message was delayed because of some reason and the server tells us
  343. lovetox now that could mean we just joined a chat and the server sends us old messages (history)
  344. lovetox or a server had some problems and sending us some messages delayed
  345. lovetox right now notification code is not executed when there is a delay tag in groupchat
  346. lovetox this is not optimal
  347. bot Daniel Brötzmann updated a merge request for _gajim/master_ < https://dev.gajim.org/gajim/gajim/merge_requests/452 >: CapsCache: Add room info query
  348. lovetox you dont want notifications when you join the muc and get 20 old messages
  349. lovetox but you probably want some when a server sends some message delayed
  350. erik ok. for now, I'm going to stick with how it works; but for the future, I guess we can simply disable notifications for 2 seconds after there has been one. that allows notification in regular cases, but prevents notification "flood"
  351. erik but that's out of scope from what I'm trying to achieve now.
  352. erik but it's good to be able to document what all these vars mean.
  353. erik my searching of the code base, I'm unable to find any occurrances of `simple=True`. Is that variable unused?
  354. erik oops. wrong working directory :-(
  355. erik still. every occurrance seems to set it to false.
  356. bot Daniel Brötzmann updated a merge request for _gajim/master_ < https://dev.gajim.org/gajim/gajim/merge_requests/453 >: RosterWindow: Fix Index out of range
  357. lovetox yes seems to be not used anymore
  358. lovetox i will remove it
  359. erik ok. thanks.
  360. bot Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim_ < https://dev.gajim.org/gajim/gajim >: *b1decf2b* < https://dev.gajim.org/gajim/gajim/commit/b1decf2b142a949a4e85d9ea07521fc36cdc4358 > Remove unused argument
  361. erik ok. I think I figured out the meaning of most of the arguments to "print_conversation_line".
  362. wurstsalat erik, I learned a lot by reading that wiki page, thanks :) the very last paragraph makes me happy
  363. erik wurstsalat, welcome! And thanks to all who helped me write it!
  364. erik I'm changing the order of the document: first the target and then the intermediate steps.
  365. erik I'm trying to test my solution before actually implementing it: I've added examples of event-handling flows for two cases of incoming messages.
  366. erik if anybody thinks there are other (special) cases to be considered, please let me know or add them yourself to: https://dev.gajim.org/ehuelsmann/gajim/wikis/ConversationListBox-approach#examples-flow-of-events
  367. wurstsalat erik, does that work for having multiple message corrections as well?
  368. wurstsalat by that I mean correcting the same message multiple times
  369. erik I'd expect you get a "string" of corrected messages, each message pointing to the prior one.
  370. erik is that how it works?
  371. lovetox https://xmpp.org/extensions/xep-0308.html
  372. lovetox erik about the docs about the arguments
  373. lovetox xep0184 is not a read receipt
  374. lovetox its a received receipt, small but important difference
  375. lovetox and restored_message is not a argument as i see it
  376. lovetox i dont think it fits into your list
  377. erik lovetox, indeed, it's a tag being added to the tag list.
  378. lovetox but i agree all the tag stuff should be moved to the textview
  379. erik Ok. read the xep (308) and I see that they all use the same stanza_id when sending multiple corrections.
  380. erik I'll need to find a way to address that.
  381. erik but I guess it's a special case of the case where multiple stanza's are merged into one "line" or logical grouping.
  382. lovetox also you should read into how a ListBox does work and what it can do
  383. lovetox for example a listbox orders items according to an attribute on the row
  384. lovetox there is nobody who needs to take care of it
  385. lovetox this is totally different to the textview, where only lines of text exists, and there is no order to them if we dont create it ourself
  386. lovetox but a list has items, and sorting, filtering fuctions are already backed into the listbox
  387. lovetox but a list has items, and sorting, filtering fuctions are already baked into the listbox
  388. lovetox The model / view concept is also already baked into the ListBox widget
  389. erik ok. I think it sounds logical to make it the responsibility of the content model to determine order.
  390. erik so, I guess to support the listbox, we simply have to choose the order value in a smart way.
  391. erik the textview can simply discard it and maintain its own mapping.
  392. lovetox we aleady have it, its the message time
  393. erik ok. well, it's the intent that the model has that too of course.
  394. erik ah. but I guess you're saying that there's no need to call insert?
  395. lovetox not on a specific position no
  396. lovetox you just call add() on the listbox
  397. lovetox the listbox decideds acording to a sorting function where to place the row
  398. lovetox the sorting function can be supplied by us
  399. erik ok.
  400. erik this will need a bit of experimenting from my part.
  401. erik s/from/on/
  402. erik dinner; bbiab
  403. lovetox things will get clearer if you read some documentation on the ListBox
  404. lovetox here it is btw, if you didnt find this site already
  405. lovetox https://lazka.github.io/pgi-docs/#Gtk-3.0/classes/ListBox.html#Gtk.ListBox
  406. erik lovetox, thanks.
  407. erik lovetox, from reading the listbox and listboxrow explanation as well as the listbox-model one, it seems the listbox-model is a container for Gtk widgets. Is that your reading too?
  408. lovetox yes the model holds widgets, GtkListBoxRow widgets
  409. wurstsalat Which are able to be styled in many ways :)
  410. bot Daniel Brötzmann modified an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9728 >: #9728: < Roster Item Exchange window too small, especially on large additions >
  411. erik lovetox, wurstsalat: I think I'm going to sleep on it before continuing that document. I think I have the outlines of where we want to go. Now I think I need to come up with a sufficiently small first step.
  412. bot Philipp Hörist pushed 7 commits to branch _refs/heads/master_ of _gajim_ < https://dev.gajim.org/gajim/gajim >: https://conference.gajim.org:5281/pastebin/fc57308c-575c-479e-b1f3-e9f7cb7c3cec
  413. lovetox erik, i simplified now even more code, around the textview, it should now be pretty easy to replace the conv textview
  414. erik lovetox, ok. xep0184 is gone from at least the chat_control and chat_control_base code. nice.
  415. erik there's no need for xep0184 anymore in my documentation page.
  416. erik I'll remove it.
  417. erik it does get simpler, yes!
  418. erik I must say that on Saturday 15:00, I didn't know much about the Gajim code base. And now I have that page and the basic direction of a design. I'm a bit exhausted; taking the night off. I hope you don't mind, but please don't hesitate to message me, or continue simplification. Also, that page should be writable to you so feel free to contribute to it if that's the fastest route you know.
  419. erik s/didn't know much/didn't know anything/
  420. lovetox yeah no stress, feel free to work on it whenever you like
  421. erik I seem to work in bursts like these.
  422. erik concentrating on one project for a number of days and then parking it for a few days again so I can develop new thoughts.
  423. erik s/seem to/find myself to/
  424. erik actually, out of all fields that determine "row rendering" or "line rendering" we didn't cover 2 fields: "msg_log_id" and "displaymarking"
  425. erik lovetox, is it hard for you to describe the two fields above?
  426. erik I'll add that to the document before I close up shop.
  427. lovetox displaymarking you can safely ignore for now, lets say its something like a label thats added to the message, it contains some string and we display it beside the message
  428. lovetox but this needs special server support, and is easily added later
  429. lovetox for reference its about this xep https://xmpp.org/extensions/xep-0258.html
  430. lovetox and the other one i have to look up myself
  431. erik :-) ok. for displaymarking, I'll simply mention "support for xep-0258".
  432. lovetox msg_log_id, holds the number of the database row a message was inserted into
  433. lovetox but this is not passed to the textview, so its unrelated for your work
  434. lovetox when a message is received, and you close gajim without reading it, we save the database row id of the message you didnt look at
  435. lovetox at the next start we query exactly these messages
  436. erik ok. is that related to the "restored_message" marking that I find as part of "restore_conversation" in chat_control?
  437. lovetox no
  438. lovetox i said that wrong
  439. lovetox we dont load messages, we issue new notifications of unread messages that have this id
  440. lovetox there is nothing loaded until the user clicks the notification
  441. erik you mean the notification in the main Gajim window? (As in, the window that opens when you open Gajim without opening any chat windows)
  442. lovetox the Roster we call it yeah
  443. erik ah. yes. the roster.
  444. bot Philipp Hörist updated a merge request for _gajim/master_ < https://dev.gajim.org/gajim/gajim/merge_requests/452 >: CapsCache: Add room info query
  445. bot Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim_ < https://dev.gajim.org/gajim/gajim >: *062b62db* < https://dev.gajim.org/gajim/gajim/commit/062b62db85dedf89bfdc7510789cdf89d4efa9ce > CapsCache: Add room info query
  446. bot Philipp Hörist merged a merge request for _gajim/master_ < https://dev.gajim.org/gajim/gajim/merge_requests/452 >: CapsCache: Add room info query
  447. bot Philipp Hörist updated a merge request for _gajim/master_ < https://dev.gajim.org/gajim/gajim/merge_requests/453 >: RosterWindow: Fix Index out of range
  448. bot Philipp Hörist updated a merge request for _gajim/master_ < https://dev.gajim.org/gajim/gajim/merge_requests/402 >: Rework contact info
  449. bot Philipp Hörist updated a merge request for _gajim/master_ < https://dev.gajim.org/gajim/gajim/merge_requests/447 >: Add avatar generator
  450. bot Philipp Hörist closed an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9549 >: #9549: < IndexError when dragging file on contact list >
  451. bot Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim_ < https://dev.gajim.org/gajim/gajim >: *29a7f5cd* < https://dev.gajim.org/gajim/gajim/commit/29a7f5cda0f068795feee03deafe5ba645392a9d > RosterWindow: Fix Index out of range Currently, detecting a file drop on the roster window is not recognized correctly. This fix avoids an Index error thrown after dropping a file on the roster by checking if there is a selection before continuing.
  452. bot Philipp Hörist merged a merge request for _gajim/master_ < https://dev.gajim.org/gajim/gajim/merge_requests/453 >: RosterWindow: Fix Index out of range
  453. fm https://conference.gajim.org:5281/pastebin/192217ef-3771-4dfc-a0e6-74cdc9e08d55
  454. bot Daniel Brötzmann modified an issue in _gajim_ < https://dev.gajim.org/gajim/gajim/issues/9060 >: #9060: < Meta: Message/conversation appearance >
  455. lovetox no i definitly will not have anything jumping
  456. erik fm: I think having stuff jump around isn't a good idea indeed.
  457. lovetox i dont know how a toast notification looks like in android
  458. erik having it "not be a message" is something that crossed my mind.
  459. erik I'm not sure how to deal with that though.
  460. lovetox we now show chatstates in single chat in the top banner
  461. lovetox the only argument against that is that people probably not looking at the top of the screen if they waiting down on the screen for a message
  462. erik lovetox, https://developer.android.com/guide/topics/ui/notifiers/toasts
  463. erik there's a picture of one there.
  464. andrey.g Maybe reserve the very last line (between listbox and message input) for displaying such chatstates?
  465. erik yea. I think there's a number of options.
  466. fm Damn, I m slow at typing on the phone ^^
  467. fm Alternative would be an overlay
  468. fm Btw, conversations does the jumping -.-
  469. lovetox yeah why not andrey.g a fixed height row that is just empty if nobody writes
  470. erik we need to consider the options and it might be that the "read confirmations" may be related to the conversation content (=lines) but that the current state is not.
  471. erik I think that the empty line is a good option.
  472. lovetox i have a problem with an overlay, because it over something
  473. lovetox and this means over text, that i might want to read
  474. erik it'll be up to the chat control to act on it then.
  475. erik lovetox, especially when it's too close to the bottom: that's the text that just came in, which you're most likely still reading.
  476. fm > i have a problem with an overlay, because it over something Valid point
  477. fm Empty line sounds good, but I guess keeping it out of the listview simplifies things....
  478. lovetox yes there is no real need to have it in the listbox then
  479. lovetox if its in the listbox you could only see who is typing if you scrolled down to the end
  480. fm ... Which could be an intentional design decision, as the bottom is "now"...
  481. erik I like how that locks the scope to what we analysed
  482. fm will catch up with the discussion tomorrow, got to be up early ;)
  483. erik so do I.
  484. erik later.
  485. bot Philipp Hörist updated a merge request for _gajim/master_ < https://dev.gajim.org/gajim/gajim/merge_requests/447 >: Add avatar generator
  486. bot Philipp Hörist updated a merge request for _gajim/master_ < https://dev.gajim.org/gajim/gajim/merge_requests/447 >: Add avatar generator