| arno11 | yes there is all that stuff to check, indeed better tomorrow :) | 00:12 |
|---|---|---|
| Wizzup | freemangordon: we have https://github.com/maemo-leste/userguide and https://github.com/maemo-leste/leste-manual | 12:24 |
| Wizzup | I will make leste-manual contain the built documentation | 12:24 |
| Wizzup | and I will delete the empty userguide repo | 12:24 |
| Wizzup | ok? | 12:24 |
| d4dsc | test | 13:06 |
| dsc_ | strange | 13:06 |
| Wizzup | I think I made a channel for testing | 13:07 |
| Wizzup | I need to remember the name | 13:07 |
| dsc_ | its not testing | 13:07 |
| Wizzup | ##maemotest | 13:07 |
| Wizzup | ok :D | 13:07 |
| dsc_ | its my main d4 | 13:07 |
| dsc_ | it didnt auto-join the channel upon reboot, lemme test | 13:08 |
| dsc_ | :P yes its a test | 13:08 |
| dsc_ | the touchscreen doesnt work when on power, thats normal right? | 13:11 |
| dsc_ | or "expected behavior" | 13:11 |
| Wizzup | not really | 13:13 |
| sicelo | it works ... but may be janky due to capacitance (not exclusive to leste ... i.e. not software/OS related) | 13:35 |
| Wizzup | I've seen some very bad chargers or cables occassionally throw it off | 13:36 |
| dsc_ | :) | 13:39 |
| Wizzup | maybe try a different cable | 13:40 |
| Wizzup | (for real) | 13:40 |
| dsc_ | i only have 2 micro-usb cables | 13:41 |
| dsc_ | they both have this | 13:41 |
| Wizzup | this is with the 4 port charger? | 13:41 |
| Wizzup | and if you try a different outlet? | 13:41 |
| dsc_ | both my d4's are turned off atm | 13:43 |
| dsc_ | i have always had this issue I think | 13:44 |
| dsc_ | yes with the 4 port charger | 13:44 |
| dsc_ | which is fairly new | 13:44 |
| Wizzup | it's not about new or not, there could be many reasons for this to happen, which is ultimately a hw problem on the d4 but could also point to poor electricity | 13:45 |
| dsc_ | also had this in my previous apartment | 13:46 |
| Wizzup | like if I am in the airplane and plug into usb on the airplane I get a constant beep on my headphones, both on my x13 and d4 | 13:46 |
| Wizzup | it's probably worth getting another charger and cable just in case | 13:46 |
| dsc_ | my d4 does not auto-connect to wifi @ boot | 15:41 |
| dsc_ | I need to manually go to status bar -> Internet Connection -> click my WIFI AP | 15:41 |
| dsc_ | "connect automatically" is turned on | 15:42 |
| dsc_ | in addition, IRC is not auto-joining this channel upon connecting to WIFI | 15:45 |
| Wizzup | well the auto joining is in conversations court | 15:52 |
| Wizzup | the wifi happens because of a kernel bug, but it will try again later | 15:52 |
| Wizzup | often it immediately says 'authentication timed out' | 15:52 |
| dsc_ | kk | 15:52 |
| dsc_ | so im calling joinChannel while there is no internet | 15:57 |
| dsc_ | but did receive 'TelepathyAccount::onAccReady' | 15:58 |
| dsc_ | i wonder how to check if its connected | 15:58 |
| dsc_ | suppose we can try `TelepathyAccount::onOnline` :P | 15:59 |
| freemangordon | Wizzup: currently we have issues with tp-haze and at least purple-fb in terms of marking messages as seen | 16:28 |
| Wizzup | yes, I don't think marking as read works at all | 16:28 |
| Wizzup | for the remote side | 16:28 |
| freemangordon | I plan to fix that, by implement support for has_focus and PURPLE_CONV_UPDATE_UNSEEN | 16:28 |
| freemangordon | however, I will need some UI support as well, | 16:29 |
| freemangordon | like - how do we know that the user has seen the messages | 16:29 |
| freemangordon | so far the only thing I found that is close to that is chat state | 16:29 |
| freemangordon | I don;t think TP has any other concept of user interaction | 16:30 |
| freemangordon | if you know any other way, please LMK | 16:30 |
| freemangordon | in either case, UI will have to set chat state | 16:30 |
| Wizzup | sounds good @ tp-haze fixing it :) | 16:30 |
| Wizzup | I am in a call atm but can get back to you in a bit | 16:30 |
| freemangordon | ok | 16:30 |
| Wizzup | back | 17:05 |
| Wizzup | freemangordon: so conversations now has a way to mark messages as read in the database, based on whether the user has seen it | 17:05 |
| Wizzup | I don't know how to communicate this over TP yet either | 17:05 |
| freemangordon | this https://pastebin.com/hDTYtbGh | 17:06 |
| freemangordon | there is no way to mark messages as read in libpurple :( | 17:06 |
| freemangordon | but they have concept of 'has_focus' | 17:07 |
| freemangordon | but that's implmentation detail anyway | 17:07 |
| freemangordon | however, conversations shall mark chat state no matter haze or not | 17:07 |
| freemangordon | this https://telepathy.freedesktop.org/doc/telepathy-glib-1/telepathy-glib-text-channel.html#tp-text-channel-set-chat-state-async | 17:08 |
| freemangordon | tp-glib, but in qt is the same | 17:08 |
| Wizzup | what state would we set here? | 17:08 |
| Wizzup | I don't see one specifically for message(s) seen | 17:08 |
| freemangordon | it is not message state, but chat state :) | 17:08 |
| freemangordon | like, I assume that if UI is visible to the user, then state is active | 17:09 |
| Wizzup | ok | 17:09 |
| Wizzup | yeah, sure, we can do that | 17:09 |
| freemangordon | if user is typing, then obviously chat state is TP_CHANNEL_CHAT_STATE_COMPOSING | 17:09 |
| freemangordon | etc | 17:09 |
| Wizzup | yeah | 17:09 |
| Wizzup | no I get that | 17:09 |
| freemangordon | but? | 17:10 |
| Wizzup | I was just under the impressed we wanted to let remote parties know we saw the messages | 17:10 |
| Wizzup | under the impression* | 17:10 |
| freemangordon | yes, that will allow at least haze to mark messages as seent | 17:10 |
| freemangordon | *seen | 17:10 |
| freemangordon | no idea how would that work for gabble | 17:10 |
| freemangordon | maybe they act on message being ack-ed | 17:11 |
| freemangordon | but that happens already | 17:11 |
| freemangordon | so no idea | 17:11 |
| freemangordon | I suggest to implement chat state and then to see if we still have issues | 17:11 |
| freemangordon | if you want more detail on how haze/purple behaves in terms of unseen messages, I can elaborate | 17:13 |
| Wizzup | I think this can be worked on without a lot more info, if we just need to ste the chat state | 17:13 |
| Wizzup | of course if the user reads it while offline there is nothing we can do | 17:13 |
| freemangordon | lets first make happy path functional | 17:14 |
| freemangordon | will try to support corner cases afterwards | 17:14 |
| freemangordon | re offline - that should not be an issue if we support duplicated messages matching | 17:16 |
| Wizzup | right now I don't think we reliably get message history upon (re)connect | 17:17 |
| Wizzup | the only one I get this for is telegram | 17:17 |
| Wizzup | I don't know if that is in haze or converastions | 17:18 |
| Wizzup | conversations | 17:18 |
| freemangordon | we get correct history from FB as well | 17:18 |
| freemangordon | haze/FB that is | 17:18 |
| freemangordon | no idea about the others | 17:18 |
| Wizzup | how does it know what new messages to send? | 17:18 |
| Wizzup | does the pruple plugin implement message markers or something? | 17:18 |
| Wizzup | like, how does it know where to continue | 17:18 |
| freemangordon | but FB is complicated enough to cover more if not all of the usecases | 17:18 |
| Wizzup | I care mostly for the xmpp path, but yeah :) | 17:18 |
| freemangordon | FB knows | 17:19 |
| freemangordon | it just resends starting from the first unseen | 17:19 |
| freemangordon | for xmpp I have no idea | 17:19 |
| freemangordon | but again, lets have chat states first | 17:20 |
| freemangordon | will iron it out as it comes | 17:20 |
| Wizzup | interesting, so it must keep some state then | 17:20 |
| Wizzup | like telegram | 17:21 |
| freemangordon | FB? | 17:21 |
| freemangordon | sure | 17:21 |
| Wizzup | I mean keep state on the d4 | 17:21 |
| freemangordon | no | 17:21 |
| freemangordon | whay shall we? | 17:21 |
| freemangordon | *why | 17:21 |
| Wizzup | to know exactly what message was last received | 17:21 |
| freemangordon | why do we care? | 17:21 |
| Wizzup | how can you know, if the client just authenticates but doesn't say what it last saw, what to send? | 17:22 |
| freemangordon | server sends the first message it didn;t get the "seen" notification | 17:22 |
| Wizzup | but we don't send the seen notification | 17:22 |
| Wizzup | so it's entirely based on you using it elsewhere | 17:23 |
| Wizzup | and this 'seen' state is shared with all devices | 17:23 |
| freemangordon | no, you send "ack" | 17:23 |
| freemangordon | and yes, it is shared | 17:23 |
| Wizzup | ok, so if you put your d4 on and it gets them, and then your bionic, the bionic won't get the messages | 17:23 |
| Wizzup | is my point | 17:23 |
| freemangordon | yes | 17:23 |
| Wizzup | which is fine, but with telegram it keeps local state and this is why it knows exactly what to deliver | 17:24 |
| freemangordon | which is pretty normal | 17:24 |
| Wizzup | in 2008 :) | 17:24 |
| Wizzup | for xmpp we will also need some message markers support with some local data | 17:24 |
| Wizzup | I'm not being negative, just stating where I think we should try to get to | 17:24 |
| freemangordon | are you sure it is 2008? | 17:24 |
| freemangordon | no, no, I understand | 17:24 |
| freemangordon | I will ask my GF, to power-off her android when she is back home | 17:25 |
| freemangordon | and will chat with her in FB | 17:25 |
| freemangordon | to test if device is going to get the full history | 17:25 |
| freemangordon | also, it is possible that fb-purple does not support the full FB protocol functionality | 17:25 |
| freemangordon | or to not expose it to pidgin, as it does not have concept of ack by message, IIUC | 17:26 |
| Wizzup | I understand | 17:30 |
| Wizzup | I'm pretty sure that currently we don't do message fetching for the most part, except in telegram but that is by accident | 17:30 |
| Wizzup | (and it also needs work) | 17:30 |
| freemangordon | and I am sure purple-fb receives all the unseen messages every time I log to FB from VM or d4 :D | 17:31 |
| freemangordon | hundreds of messages that is ;) | 17:31 |
| freemangordon | so it is not a minor issue | 17:31 |
| Wizzup | yeah | 17:35 |
| Wizzup | it probably takes a while to process them too, eh? | 17:35 |
| Wizzup | at least that is what happens for me now, it vibrates and makes sound for each of them :D | 17:35 |
| freemangordon | no, but makes fb chat useless | 17:35 |
| freemangordon | ah, right | 17:35 |
| freemangordon | so, which plugin do you have issues with? | 17:36 |
| freemangordon | tp-gabble, or telegram through haze? | 17:36 |
| freemangordon | or? | 17:36 |
| Wizzup | sorry, what issues specifically? | 17:40 |
| freemangordon | repeated messages | 17:40 |
| Wizzup | I do not have this problem | 17:40 |
| freemangordon | ah | 17:40 |
| freemangordon | ok | 17:40 |
| Wizzup | but when I connect telegram I might get like 50+ messages since i was last online | 17:41 |
| Wizzup | (I'm not popular, it's just some irc channel bridged to some telegram channel) | 17:41 |
| freemangordon | well, isn;t that a good feature actually? | 17:41 |
| Wizzup | it is, but they should be a single batch | 17:41 |
| Wizzup | now it is as if the messages are coming in at real time | 17:41 |
| Wizzup | so it will be vibration in my pocket for minutes | 17:41 |
| Wizzup | vibrating | 17:41 |
| Wizzup | but this is a conversations issue mostly, not tp per se | 17:41 |
| freemangordon | I see | 17:41 |
| freemangordon | right | 17:41 |
| dsc_ | i was going to fix that today or tomorrow | 17:42 |
| freemangordon | I think there is a way to get pending messages | 17:42 |
| freemangordon | Wizzup: ok, please LMK when you are ready with chat state | 17:43 |
| freemangordon | I think it is not *that* easy to be implemented though | 17:43 |
| freemangordon | as you have to account for chat window being active (maximized), but device is not locked, etc | 17:44 |
| freemangordon | dsc_: oh, please, fix focus lost issue in chat edit widget | 17:45 |
| freemangordon | on send button pressed, edit field should not lose focus | 17:45 |
| dsc_ | ah ok | 17:45 |
| dsc_ | easy fix | 17:45 |
| freemangordon | right | 17:45 |
| freemangordon | sorry for not doing it by myself, but it will take me a while to find which form/class is that | 17:46 |
| dsc_ | yeah | 17:46 |
| dsc_ | im actually using d4 as my main now, dogfooding | 17:47 |
| freemangordon | I need few more things working properly first | 17:48 |
| freemangordon | conversations being one of them | 17:48 |
| Wizzup | for me it's just dtmf now ;p | 18:05 |
| Wizzup | but I guess I could try to play dtmf tones for now using some other device | 18:05 |
| sicelo | which reminds me - lately i notice that i receive each sms 2 or 3 times on droid 4. haven't checked who/what's responsible for that | 19:35 |
| Wizzup | sicelo: we haven't seen that in a long time | 19:45 |
| sicelo | yes i thought so. i get it everytime now. | 19:51 |
| freemangordon | Wizzup: sorry, but I didn't get it: do you plan to implement chat state in conversations any time soon? | 19:53 |
| Wizzup | freemangordon: I can try to look at it this week.. | 20:35 |
| freemangordon | Wizzup: dsc_: I can look as well, but I need some hints where is the proper place for doing it | 21:16 |
| Wizzup | freemangordon: it feels to me like src/chatwindow.cpp has ChatWindow and then we can hook to its signals to get activated, focussed, deactivated, tec | 21:33 |
| Wizzup | s/tec/etc/ | 21:33 |
| Wizzup | I'd ignore the 'is typing...' for now | 21:33 |
| Wizzup | and then we need to match it to a conversations channel | 21:34 |
| Wizzup | s/conversations/telepathy/ | 21:34 |
| Wizzup | which we can do based on group uid | 21:37 |
| Wizzup | or remote_uid rather I guess | 21:38 |
| Wizzup | we have TelepathyAccount::hasChannel | 21:39 |
| freemangordon | Wizzup: I guess I have to add those signals, no? | 21:43 |
| Wizzup | yes, you can if you want to :) | 21:44 |
| freemangordon | ok, will try | 21:44 |
| Wizzup | the code to handle the telepathy side should probably go in src/lib/tp.cpp | 21:44 |
| Wizzup | I can't do it tonight | 21:44 |
| freemangordon | ok, will try to cook some code | 21:44 |
| freemangordon | ugh: | 21:58 |
| freemangordon | 14033 user 20 0 3465432 1.5g 8824 S 0.0 38.1 0:28.43 conversations | 21:58 |
| dsc_ | freemangordon: not sure what you're doing right now but feel free to delegate work to me and/or ask questions | 21:59 |
| freemangordon | dsc_: trying to implement TP chat state support | 21:59 |
| freemangordon | ok, thanks, lemme spend some time on it and if needed will ask for help | 22:00 |
| dsc_ | state = "now typing..." ? | 22:00 |
| freemangordon | mhm | 22:00 |
| Wizzup | dsc_: well more like window has been active / is active | 22:01 |
| Wizzup | I don't think the typing... notification is the goal here per se | 22:01 |
| Wizzup | freemangordon: yeah there's definitely still some memory issues to figure out | 22:01 |
| dsc_ | more accurate readings via: https://raw.githubusercontent.com/pixelb/ps_mem/master/ps_mem.py | 22:19 |
| dsc_ | python3 ps_mem.py -p <pid> | 22:20 |
| Wizzup | I am getting about 20-30MB for every incoming message it seems | 22:20 |
| Wizzup | 220.7 MiB + 7.8 MiB = 228.5 MiBconversations | 22:20 |
| Wizzup | --------------------------------- 228.5 MiB | 22:20 |
| Wizzup | ================================= | 22:20 |
| Wizzup | was 32MiB before | 22:20 |
| dsc_ | did you open the window too? | 22:20 |
| Wizzup | stopped here, after I didn't get more messages | 22:20 |
| Wizzup | # python ps_mem.py -p 4694 | 22:20 |
| Wizzup | Private + Shared = RAM usedProgram | 22:20 |
| Wizzup | 238.7 MiB + 7.8 MiB = 246.5 MiBconversations | 22:20 |
| Wizzup | --------------------------------- | 22:20 |
| Wizzup | 246.5 MiB | 22:20 |
| Wizzup | ================================= | 22:20 |
| Wizzup | no, the screen was off | 22:20 |
| dsc_ | interesting | 22:20 |
| Wizzup | closed the notifications and no resources were freed | 22:20 |
| Wizzup | so there's definitely something going on, but I've also seen this before | 22:21 |
| Wizzup | we had an issue before where the rtcom instance wasn't being freed | 22:21 |
| Wizzup | I think fmg fixed it but the code also changed again | 22:21 |
| Wizzup | it could also be related to notifications | 22:21 |
| dsc_ | looking into the mem stuff now | 22:27 |
| freemangordon | dsc_: what about https://pastebin.com/9TrJchKW | 22:33 |
| freemangordon | if that's ok, I need a hint how to get from chat windot to TpTextChannel (or whatever tpqt's class is) | 22:34 |
| Wizzup | I think hasChannel as mentioned above on our tp account class will give you that | 22:34 |
| dsc_ | freemangordon: cool :) | 22:35 |
| dsc_ | good q, let me check. | 22:35 |
| freemangordon | Wizzup: ok, will try | 22:35 |
| Wizzup | you would still need to iterate the accounts though | 22:36 |
| freemangordon | wait, chat window has channel() and remote_uid() | 22:36 |
| dsc_ | I fear the signal would also need to pass an identifier of some kind | 22:37 |
| dsc_ | remote_uid most likely | 22:37 |
| freemangordon | I will add that | 22:37 |
| freemangordon | but which one? | 22:37 |
| freemangordon | channel() or remote_uid()? | 22:37 |
| freemangordon | oh, wait | 22:37 |
| freemangordon | this is ChatMessage | 22:37 |
| dsc_ | m_local_uid but im not 100% sure | 22:38 |
| dsc_ | rtcom terminology | 22:38 |
| Wizzup | m_local_uid is likely not a channel | 22:38 |
| freemangordon | mhm | 22:38 |
| Wizzup | that will at best map to a tp account | 22:38 |
| dsc_ | but ill check for you | 22:38 |
| freemangordon | thanks | 22:39 |
| freemangordon | ugh, what a hackery :) https://github.com/maemo-leste/conversations/blob/master/src/mainwindow.cpp#L93 | 22:41 |
| freemangordon | so, is it possible to have multiple channels per ChatWindow? | 22:42 |
| Wizzup | I don't think so, what would that look like | 22:42 |
| dsc_ | [D] [chatwindow.cpp::34] m_local_uid "idle/irc/d4dsc0" | 22:43 |
| dsc_ | [D] [chatwindow.cpp::35] m_channel "##maemotest" | 22:43 |
| dsc_ | [D] [chatwindow.cpp::36] groupchat true | 22:43 |
| Wizzup | yes, the local_uid is you | 22:43 |
| Wizzup | that won't help find the channel | 22:43 |
| Wizzup | you need the remote_uid for this | 22:43 |
| freemangordon | no idea, just asking while trying to understand why ChatWindow does not have 'channel' property | 22:43 |
| Wizzup | I don't recall exactly why, but I believe dsc wanted to keep tp specific code out of the ui code | 22:44 |
| dsc_ | no | 22:44 |
| Wizzup | ok | 22:44 |
| Wizzup | in any case there's a lot of work that I have to do to make the tp.cpp interface more 'accessible' from outside | 22:44 |
| freemangordon | ok, I think of 2 options here: | 22:45 |
| dsc_ | the way chatWindow instanciates is a relic of when we were still figuring out how to even implement tpqt | 22:45 |
| freemangordon | in ChatWindow constructor, extract channel from ChatMessage and keep it for further usage | 22:45 |
| freemangordon | add channel to ChatWindow constructor | 22:46 |
| freemangordon | any other ideas? | 22:46 |
| dsc_ | for clarity; you mean `TelepathyChannel` right? | 22:47 |
| dsc_ | because it has a m_channel property currently, a hacky string | 22:47 |
| freemangordon | I was about to ask what is m_channel :) | 22:47 |
| dsc_ | see output above | 22:47 |
| freemangordon | and yeah, I need TelepathyChannel somewhere down the pipe | 22:47 |
| dsc_ | but yes the constructor is highly suspicious | 22:47 |
| freemangordon | ok, what is "##maemotest"? | 22:48 |
| Wizzup | ##maemotest on libera | 22:48 |
| freemangordon | ah, so option 1 is already in place | 22:48 |
| freemangordon | ok, can I use that to get TpChannel somehow? | 22:49 |
| Wizzup | yes, if m_channel is the same as remote_uid, then hasChannel give you the channel | 22:49 |
| freemangordon | don;t understand that | 22:50 |
| freemangordon | and what if its not? | 22:50 |
| dsc_ | im looking how to do option 1 | 22:50 |
| dsc_ | sec | 22:51 |
| freemangordon | dsc_: it is already there | 22:51 |
| dsc_ | yes, but to get it to tpqt | 22:51 |
| freemangordon | https://github.com/maemo-leste/conversations/blob/master/src/chatwindow.cpp#L32 | 22:51 |
| dsc_ | yep | 22:51 |
| freemangordon | that's easy, the question is how to map that string to TpChannel? | 22:52 |
| freemangordon | Wizzup: if m_channel is the same as remote_uid, why we have both? | 22:52 |
| dsc_ | there's `channels`, property of TelepathyAccount, which is a QMap, so easy lookup | 22:52 |
| dsc_ | let me confirm though | 22:52 |
| freemangordon | right, but key there seems to be remote_uid | 22:52 |
| Wizzup | I cannot answer that right now the channel name isn't always the remote_uid iirc | 22:53 |
| Wizzup | 22:53 < dsc_> there's `channels`, property of TelepathyAccount, which is a QMap, so easy lookup | 22:54 |
| Wizzup | this is what hasChannel does | 22:54 |
| Wizzup | given a remote_uid | 22:54 |
| freemangordon | seems there is either bug or... dunno | 22:56 |
| freemangordon | see https://github.com/maemo-leste/conversations/blob/master/src/lib/tp.cpp#L598 | 22:56 |
| freemangordon | vs https://github.com/maemo-leste/conversations/blob/master/src/lib/tp.cpp#L614 | 22:56 |
| freemangordon | and https://github.com/maemo-leste/conversations/blob/master/src/lib/tp.cpp#L570 | 22:56 |
| dsc_ | right. its m_channel, not remote_uid. | 22:56 |
| dsc_ | void TelepathyAccount::leaveChannel(const QString &channel) { <== this one is correctly named | 22:57 |
| freemangordon | remote_uid is inited from m_nickname | 22:57 |
| Wizzup | you probably realised this already but the problem with giving a chatwindow a direct pointer to a tp channel or account is that they can get invalidated | 22:57 |
| freemangordon | so this cannot be key | 22:57 |
| dsc_ | freemangordon: correct :) | 22:57 |
| dsc_ | so | 22:57 |
| freemangordon | Wizzup: why not using shared pointgers? | 22:58 |
| freemangordon | *pointers | 22:58 |
| Wizzup | I don't know what it means but the thing can still stop existing or be invalidated at any time | 22:58 |
| dsc_ | im not too worried about invalidating stuff | 22:58 |
| dsc_ | since we get signals for it | 22:58 |
| dsc_ | anyway | 22:58 |
| dsc_ | https://github.com/maemo-leste/conversations/blob/master/src/lib/tp.cpp#L140 | 22:58 |
| Wizzup | yes, but then you need a mechanism to find the new one | 22:58 |
| dsc_ | this is a helper thing | 22:58 |
| Wizzup | at which point you could use that mechanism anyway? | 22:59 |
| dsc_ | it loops the accounts (backends) to find the right one | 22:59 |
| dsc_ | so in your case | 22:59 |
| dsc_ | you want to communicate 'state' | 22:59 |
| freemangordon | mhm | 22:59 |
| dsc_ | Telepathy::setState(...) with a similar helper thing that loops the accounts | 22:59 |
| freemangordon | shall I add similar slot? | 22:59 |
| dsc_ | right | 22:59 |
| freemangordon | ok | 22:59 |
| dsc_ | then in `Conversations::onChatStateChanged` you can call this->telepathy->setState() | 23:00 |
| freemangordon | mhm | 23:00 |
| dsc_ | and then also `TelepathyChannel::setState()` | 23:00 |
| freemangordon | shall I rename the parameter in hasChannel? | 23:00 |
| dsc_ | or hmm, maybe you need 3 layers, not sure | 23:00 |
| dsc_ | freemangordon: yes | 23:01 |
| freemangordon | yeah, maybe, will see | 23:01 |
| freemangordon | ok | 23:01 |
| dsc_ | good catch btw, yes its confusing, remote_uid is wrong there | 23:01 |
| dsc_ | Wizzup: ive been wanting to refactor ChatWindow since I first made it but it was not possible since we're refactoring tp code every X months | 23:02 |
| dsc_ | well not refactoring, just working on it :) | 23:02 |
| dsc_ | not sure what exactly to provide chatWindow | 23:02 |
| dsc_ | but giving 20 variables like we do now is kinda sus | 23:03 |
| Wizzup | I think the group_uid should be the primary key for most things | 23:03 |
| Wizzup | I did rework most of the UI code to use this, but I am not sure if I did it everywhere | 23:03 |
| dsc_ | this QMap lookup stuff btw, was my last tp refactor | 23:03 |
| Wizzup | tbh there are some valid remote_uid lookups when coupled with account | 23:03 |
| Wizzup | I guess it was QList before or something? | 23:04 |
| Wizzup | I know I set it up to track all of these things | 23:04 |
| dsc_ | yeah, it was QList | 23:05 |
| dsc_ | btw, you could also access 'conversations.telepathy' from mainwindow via `m_ctx->telepathy`, or even directly from chatWindow | 23:08 |
| freemangordon | hmm, ok | 23:08 |
| freemangordon | getContext()? | 23:09 |
| dsc_ | up to you, sometimes I prefer to keep some logic in m_ctx instead of chatwindow, so that if we'd have another interface, maybe a text-based chat client, you wont have to reimplement stuff thats only in ChatWindow | 23:10 |
| dsc_ | just `m_ctx->telepathy->...` | 23:10 |
| dsc_ | it sets up m_ctx in the constructor | 23:10 |
| freemangordon | ok | 23:10 |
| Wizzup | uvos: on razr/xt912, we don't see glitching problems in the tty right, just in X? | 23:21 |
| freemangordon | ok, seems I have some working code | 23:36 |
| dsc_ | nice | 23:39 |
| freemangordon | ok, it seems channel is group id of group chat and remote id is accoutn id when single-user chat | 23:50 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!