Gajim - 2019-04-03

  1. bot Daniel Brötzmann proposed a new merge request for _gajim/master_ < >: Only show avatar Save As menu if sha not None
  2. bot Daniel Brötzmann modified an issue in _gajim_ < >: #9643: < Error when receiving and transmitting a file, invalid literal for int() with base 10: '8.1' >
  3. bot Daniel Brötzmann modified an issue in _gajim_ < >: #9604: < Windows - credentials gone when started 2 times >
  4. bot Daniel Brötzmann modified an issue in _gajim_ < >: #9620: < Error during account creation breaks display of all other accounts on that server configured in client >
  5. bot Karsten Vieth closed an issue in _gajim_ < >: #9629: < Autostart in Windows 10 >
  6. lovetox Zash yes, that dialog uses the old forms impl its not really good, if you want to see the new one look at the groupchat config dialog
  7. lovetox i take it on my list to use the new dialog in the adhoc command window
  8. bot Daniel Brötzmann updated a merge request for _gajim/master_ < >: WIP: Revise some text strings
  9. bot Daniel Brötzmann updated a merge request for _gajim/master_ < >: WIP: Revise some text strings
  10. lovetox wurstsalat, maybe you can take another stab at this
  11. lovetox if you work on that you dont have to use hers, but take the discussion into consideration
  12. wurstsalat yes, I actually just had a look at it :) but to have a revealer for that message input box, this would have to be a separate dialog (non standard), right?
  13. lovetox hm if you only need a special widget in the content area, you always can inherit from NewConfirmationDialog
  14. lovetox and just call in the init get_content_area().add(yourwidget)
  15. lovetox where you add a grid or box, and then there is everything in there
  16. wurstsalat a yeah, right! I'll have a look :)
  17. lovetox but yeah do this only if it makes sense as in you dont have to make crazy workaround to make it fit into the NewConfirmationDialog
  18. wurstsalat alright!
  19. susanejones hello, I've got a question that I couldn't answer by myself through a quick read through the documentation: When I have omemo enabled, will there then also all files share being encrypted by it?
  20. susanejones (while I was looking for help, I also noted that when you click in Gajim at help -> FAQ it links to the wrong page. )
  21. lovetox what version susanejones
  22. lovetox depends, if your server supports httpupload, and the file is transfered as such, its encrypted
  23. lovetox if the file is too big, and it falls back to p2p file transfer its only encrypted Gajim -> Gajim
  24. wurstsalat susanejones, thanks for the pointer, I'll have a look after that link / wiki page
  25. susanejones thx for the respond @lovetox but I'm not shure if I understand you correct. I thought what your are describing is how jinlge file transfer in general works. (I might confuse stuff, I'm absolutly new to gajim and new to using xmpp for file transfer)
  26. susanejones If I have omemo enabled, why to not force encryption through omemo? From a user perspective, it is what I expect when I have a secure chat enabled under OMEMO and upload something.
  27. susanejones (how can I turn off "[name] has joined/left"?)
  28. wurstsalat susanejones, which gajim version are you using?
  29. wurstsalat lovetox, you mentioned that `reason` will be displayed in the room when declining an invitation (with a reason), right?
  30. lovetox yes
  31. lovetox it should
  32. wurstsalat I don't see this when declining an invitation.. Xml console shows that 'reasom' is sent, but there is nothing on the receiving side. Could this be a server config problem? Could you test if this is actually working?
  33. lovetox it does depend how the invite is sent
  34. lovetox if its a mediated invite over the MUC service
  35. lovetox then answer is sent to the MUC and not you
  36. lovetox i think
  37. lovetox hm the decline is sent to the MUC jid
  38. lovetox not the jid we got the invite from
  39. lovetox thats the reason its not shown
  40. lovetox hm but that seems correct from the xep
  41. lovetox that seems a server bug
  42. lovetox ah no im not actually joined the muc wait
  43. lovetox oh no wait i think i found a bug
  44. wurstsalat Wohoo :) I'm running a local ejabberd but am totally new to that..
  45. raver Welcome 🙂
  46. fm
  47. fm doh.
  48. fm lovetox, a while ago we were talking about me maybe taking over some tasks concerning the message view. There were basically two things we talked about, first handling of widgets (such as code or image) in the textview and second, the textview itself.
  49. fm I haven't started actually doing anything in that direction, as I still want to close the issue-to-self tasks first ;)
  50. fm But: I had some ideas in mind that I wanted to try out, so I created a little mock up, that I would like to share, if you are interested
  51. fm everybody else is welcome, too, of course
  52. lovetox yes please share
  53. fm
  54. fm it's a tar file. simple unpack, and run the
  55. fm except for the pane handle and the "fullscreen" button, nothing works, just show ;)
  56. fm except for the pane handle and the "fullscreen" button, nothing works, its just for show ;)
  57. fm ah, and: moving the pane handle to the lowest possible position switches the view on the send part of the window
  58. lovetox so your proposal is to make the input textview detachable
  59. fm yes, among others ;)
  60. fm second, the toolbar, that expands below the input as soon as the message textview is large enough
  61. fuesschen Now you've made me curious
  62. fm fuesschen, try it out, I'm curious about what others think myself ;)
  63. fm ah, and about the send button, that appears: idea here (which is obviously not getting very clear in the mock) is, that when having a large input window, users will most likely also want to send more than a single line. I would like to switch (automatically or offer a toggle button or so) from sending when the users hits enter in the small input to sending with either the button or ctrl+enter when in the large input view
  64. lovetox yeah when in a large editor you kind of forget that enter means sending
  65. lovetox i get the idea
  66. fm :)
  67. fuesschen thats nice. i like the idea of the detachable inputbox
  68. fm yay! that means I'm not the only one seeing a use case for that ;)
  69. lovetox hmmm
  70. lovetox im not sure it makes much sense to export any of the non formatting buttons to the detached window
  71. fm depends how they are implemented. I agree, something like the upload does not make any sense if it directly uploads.
  72. fm however, if it would rather add the upload to the textview first, that would make sense again
  73. fm btw, is there any reason why having images (e.g.) in a message also containing text does not work? neither on sending nor on receiving side? or simply not implemented that way?
  74. lovetox thats only possible right now with xhtml xep0071
  75. lovetox its also used for when we mark stuff as bold etc
  76. lovetox but httpupload back then didnt exist so yeah this could be added
  77. lovetox but xhtml is currently not useable with encryption for example
  78. fuesschen in the most cases i use gajim in the one window mode but sometimes i would like to focus just on the actual message. In this Case this feature would be great. The formating features are also part of that.
  79. lovetox but this should not stop you, it would be useful to add that
  80. lovetox but i would not try to do this all together
  81. lovetox this is rather much
  82. fm well, iirc this does not require xhtml support. it _could_ be implemented without, too. simply replacing the image when sending with the upload url and search for image file extensions when displaying (or checking encrypted uploads)
  83. fm yeah, should be broken down into smaller chunks, I agree ;)
  84. lovetox but we already have that, its called the url image preview plugin
  85. fm yeah, I know ;)
  86. fm just does not work (reliably) when sending text with an image url in my experience...
  87. fm just does not work (reliably) when sending text and an image url in one message in my experience...
  88. fm does not work in other clients, too. conversations for example also just displays the link
  89. fm that's why I was wondering if there was any restriction that forbidds showing the image and the text at the same time...
  90. lovetox its a security issue
  91. fm oh? what am I missing?
  92. lovetox especially in mucs you dont want to automatically download all links
  93. fm yeah, sure, but that's no different from the current situation, right? same settings could apply
  94. lovetox not really, but we try to differntiate between files uploaded by a user
  95. lovetox and random links copy pasted into a chat
  96. lovetox this makes it a bit better
  97. lovetox but for filesharing there are other approaches
  98. lovetox if you want to add a description, you dont have to do that in the textview
  99. lovetox we dont want to creat html documents, with all kind of formated text and images
  100. lovetox The IM usecase means having a few chosen formatting methods, and a way to share files and images
  101. fm hm. yeah. actually I did not spend any thought on what would happen with non-image uploads with that aproach
  102. lovetox so the stuff we have now + code highlighting is i think enough for the iM usecase, as formatting goes. If you want to go really fancy you could add also a list option
  103. lovetox but i dont think anyone needs more
  104. lovetox and filesharing with text/description i would approach a bit different like, showing a dialog with the uploaded picture as preview with a small input that lets the user add a description
  105. fm from sender's perspective, that's not too far from what I've been thinking... just, that I would let users have both in the message textview, not in an extra dialog
  106. fm lists would be realy nice to have, too. I miss them often ;)
  107. lovetox i think its not easy doable in the textview and would not look that nice
  108. lovetox you would have to disable all formatting options
  109. lovetox somehow prevent that the user just moves the picture and adds text above and after
  110. lovetox dont allow to load into a second picture
  111. lovetox the whole textview will give him the impression he can move things around and edit freely
  112. lovetox when in reality all he can do is add a non formatted description
  113. lovetox i rather make a nice looking file sending dialog
  114. lovetox i just see it as two separate things, writing text and on the other side share files
  115. lovetox but i like the detachable editor, it maybe useful to add the formatting buttons to the input widget
  116. lovetox now they are inside the chatcontrol
  117. lovetox but not sure about that
  118. fm hm. when you say description, do you have anything special in mind? or simply plain text, just like a normal message?
  119. lovetox
  120. lovetox file sharing xeps allow a description
  121. lovetox and yes its plain text
  122. fm yeah, a lot of movement in the chat window would be required....
  123. fm oh, so yeah, we were thinking in different directions ;)
  124. lovetox actually sims would allow you to set the location in the body where the image should appear
  125. lovetox hm
  126. fm what I had in mind with file sharing would be something like: - select the file by clicking the upload button - upon selection, a preview is added as child anchor widget to the textview - user can add text and further files as desired - when sending, a send method of the widget - send method does the actual upload and replaces the widget (in the sent message, not visible to the user) with the upload url
  127. lovetox i think the upload must happen if you pull the image into the view
  128. lovetox otherwise you can not be sure when you send the message that the uploads really happen
  129. lovetox like you have a limit on the server and you could run into it
  130. fm you would have to wait until the upload has finished, before actually sending, yes
  131. lovetox yeah i just mean it would be nice if i know i cant upload that file before i finished crafting my whole message
  132. fm on the other hand, wouldn't that be weird for the user, that something gets uploaded and displayed in the input view?
  133. fm i guess most people would expect they can add and remove files as they wish from the input, stuff should get uploaded once the message is send
  134. lovetox i think people expect it to just work
  135. fm depends how they define what "just works" means to them ;)
  136. lovetox uploading once you press send, means also you have to store all the input in case something goes wrong
  137. fm i would have disabled the input, maybe overlay it with a spinner or so in that case
  138. lovetox it means you have to show some progress somewhere
  139. fm until the message is send
  140. fm yeah
  141. lovetox but these are really details
  142. lovetox i guess with sims you can do it your way
  143. lovetox with putting stuff into the textview
  144. fm important to be discussed, though^^
  145. fm what's sims?
  146. lovetox >[20:51:33] ‎lovetox‎:
  147. fm wanted to ask when you mentioned it before but forgot
  148. fm ah, didn't get its called sims
  149. fm ;)
  150. fm well, should have checked the title ;)
  151. lovetox just putting links into the body and hoping clients parse it and do stuff with it, will never work good
  152. fm i will have a deeper look at the xep
  153. lovetox if we want to send something we want to describe exactly what it is and that gives clients the option to handle it correctly
  154. fm xhtml tags as hints are better, i agree
  155. lovetox but if you want to follow your idea, i would just start with making the editor detachable
  156. lovetox this alone is a big task, to make it good and so everything still works
  157. lovetox without adding something new
  158. fm sure, small steps ;)
  159. lovetox then on the next step i would suggest to improve the formatting buttons, because they dont work really good now, and then add new formattings like code tags
  160. lovetox we could also get rid of color and font formatting
  161. fm completely ? or disable them when sending encrypted messages?
  162. fm i.e. disable everything that needs xhtml
  163. lovetox i think completely, they just dont make a lot of sense
  164. lovetox you cannot know what fonts other clients support
  165. lovetox nor what color themes they have applied to your system
  166. fm that's right, yeah.
  167. lovetox if they use dark theme
  168. lovetox you cant send dark color text
  169. lovetox because clients dont want to deal with stuff like that, they will mostly ignore colors anyway
  170. fm new secret mode :D
  171. fm yes, probably
  172. fm i never had the need for colors in IM
  173. fm nor for fonts ;)
  174. fm anyway, as I already said, real implementation will have to wait anyway until I'm done with the other tasks I have ;)
  175. fm should I record stuff that we just discussed somewhere for the future and further discussion?
  176. fm open an issue, i mean
  177. fm or add it to the meta: message/chat view one?
  178. lovetox nah leave it, save it for yourself if you want to come back to it :)
  179. fm ok, sure
  180. lovetox its also here
  181. lovetox if we want to look it up some day
  182. fm got to go, SO is waiting... ;)
  183. lovetox though search functionalltiy would be nice for the weblog
  184. lovetox cu :)
  185. bot Philipp Hörist pushed 2 commits to branch _refs/heads/master_ of _python-nbxmpp_ < >: *a161f7fa* < > Add Software Version (XEP-0092) module *79330a50* < > Detect direct invite correctly
  186. lovetox should work now wurstsalat
  187. bot André proposed a new merge request for _gajim/master_ < >: Remove color and font formatting
  188. wurstsalat Nice, thanks lovetox, I'll try again tomorrow!