<Wizzup>
I will make leste-manual contain the built documentation
<Wizzup>
and I will delete the empty userguide repo
<Wizzup>
ok?
d4dsc has joined #maemo-leste
<d4dsc>
test
<dsc_>
strange
pere has quit [Ping timeout: 252 seconds]
d4dsc has left #maemo-leste [#maemo-leste]
<Wizzup>
I think I made a channel for testing
<Wizzup>
I need to remember the name
<dsc_>
its not testing
<Wizzup>
##maemotest
<Wizzup>
ok :D
<dsc_>
its my main d4
<dsc_>
it didnt auto-join the channel upon reboot, lemme test
<dsc_>
:P yes its a test
d4dsc has joined #maemo-leste
<dsc_>
the touchscreen doesnt work when on power, thats normal right?
<dsc_>
or "expected behavior"
<Wizzup>
not really
d4dsc has left #maemo-leste [#maemo-leste]
<sicelo>
it works ... but may be janky due to capacitance (not exclusive to leste ... i.e. not software/OS related)
<Wizzup>
I've seen some very bad chargers or cables occassionally throw it off
<dsc_>
:)
<Wizzup>
maybe try a different cable
<Wizzup>
(for real)
<dsc_>
i only have 2 micro-usb cables
<dsc_>
they both have this
<Wizzup>
this is with the 4 port charger?
<Wizzup>
and if you try a different outlet?
<dsc_>
both my d4's are turned off atm
<dsc_>
i have always had this issue I think
<dsc_>
yes with the 4 port charger
<dsc_>
which is fairly new
<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
<dsc_>
also had this in my previous apartment
<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
<Wizzup>
it's probably worth getting another charger and cable just in case
vectis has joined #maemo-leste
noidea__ has quit [Quit: Leaving]
noidea_ has joined #maemo-leste
Livio has quit [Ping timeout: 264 seconds]
<dsc_>
my d4 does not auto-connect to wifi @ boot
<dsc_>
I need to manually go to status bar -> Internet Connection -> click my WIFI AP
<dsc_>
"connect automatically" is turned on
<dsc_>
in addition, IRC is not auto-joining this channel upon connecting to WIFI
<Wizzup>
well the auto joining is in conversations court
<Wizzup>
the wifi happens because of a kernel bug, but it will try again later
<Wizzup>
often it immediately says 'authentication timed out'
<dsc_>
kk
<dsc_>
so im calling joinChannel while there is no internet
<dsc_>
but did receive 'TelepathyAccount::onAccReady'
<dsc_>
i wonder how to check if its connected
<dsc_>
suppose we can try `TelepathyAccount::onOnline` :P
nmdv has joined #maemo-leste
Guest3630 is now known as buZz
d4dsc has joined #maemo-leste
<freemangordon>
Wizzup: currently we have issues with tp-haze and at least purple-fb in terms of marking messages as seen
<Wizzup>
yes, I don't think marking as read works at all
<Wizzup>
for the remote side
<freemangordon>
I plan to fix that, by implement support for has_focus and PURPLE_CONV_UPDATE_UNSEEN
<freemangordon>
however, I will need some UI support as well,
<freemangordon>
like - how do we know that the user has seen the messages
<freemangordon>
so far the only thing I found that is close to that is chat state
<freemangordon>
I don;t think TP has any other concept of user interaction
<freemangordon>
if you know any other way, please LMK
<freemangordon>
in either case, UI will have to set chat state
<Wizzup>
sounds good @ tp-haze fixing it :)
ac_laptop has quit [Ping timeout: 268 seconds]
<Wizzup>
I am in a call atm but can get back to you in a bit
<freemangordon>
ok
moparisthebest has joined #maemo-leste
ac_laptop has joined #maemo-leste
Madda has quit [Remote host closed the connection]
<Wizzup>
back
<Wizzup>
freemangordon: so conversations now has a way to mark messages as read in the database, based on whether the user has seen it
<Wizzup>
I don't know how to communicate this over TP yet either
<Wizzup>
I don't see one specifically for message(s) seen
<freemangordon>
it is not message state, but chat state :)
<freemangordon>
like, I assume that if UI is visible to the user, then state is active
<Wizzup>
ok
<Wizzup>
yeah, sure, we can do that
<freemangordon>
if user is typing, then obviously chat state is TP_CHANNEL_CHAT_STATE_COMPOSING
<freemangordon>
etc
<Wizzup>
yeah
<Wizzup>
no I get that
<freemangordon>
but?
<Wizzup>
I was just under the impressed we wanted to let remote parties know we saw the messages
<Wizzup>
under the impression*
<freemangordon>
yes, that will allow at least haze to mark messages as seent
<freemangordon>
*seen
<freemangordon>
no idea how would that work for gabble
<freemangordon>
maybe they act on message being ack-ed
<freemangordon>
but that happens already
<freemangordon>
so no idea
<freemangordon>
I suggest to implement chat state and then to see if we still have issues
<freemangordon>
if you want more detail on how haze/purple behaves in terms of unseen messages, I can elaborate
<Wizzup>
I think this can be worked on without a lot more info, if we just need to ste the chat state
<Wizzup>
of course if the user reads it while offline there is nothing we can do
<freemangordon>
lets first make happy path functional
<freemangordon>
will try to support corner cases afterwards
Madda has joined #maemo-leste
<freemangordon>
re offline - that should not be an issue if we support duplicated messages matching
<Wizzup>
right now I don't think we reliably get message history upon (re)connect
<Wizzup>
the only one I get this for is telegram
<Wizzup>
I don't know if that is in haze or converastions
<Wizzup>
conversations
<freemangordon>
we get correct history from FB as well
<freemangordon>
haze/FB that is
<freemangordon>
no idea about the others
<Wizzup>
how does it know what new messages to send?
<Wizzup>
does the pruple plugin implement message markers or something?
<Wizzup>
like, how does it know where to continue
<freemangordon>
but FB is complicated enough to cover more if not all of the usecases
<Wizzup>
I care mostly for the xmpp path, but yeah :)
<freemangordon>
FB knows
<freemangordon>
it just resends starting from the first unseen
<freemangordon>
for xmpp I have no idea
<freemangordon>
but again, lets have chat states first
<freemangordon>
will iron it out as it comes
<Wizzup>
interesting, so it must keep some state then
<Wizzup>
like telegram
<freemangordon>
FB?
<freemangordon>
sure
<Wizzup>
I mean keep state on the d4
<freemangordon>
no
<freemangordon>
whay shall we?
<freemangordon>
*why
<Wizzup>
to know exactly what message was last received
<freemangordon>
why do we care?
<Wizzup>
how can you know, if the client just authenticates but doesn't say what it last saw, what to send?
<freemangordon>
server sends the first message it didn;t get the "seen" notification
<Wizzup>
but we don't send the seen notification
<Wizzup>
so it's entirely based on you using it elsewhere
<Wizzup>
and this 'seen' state is shared with all devices
<freemangordon>
no, you send "ack"
<freemangordon>
and yes, it is shared
<Wizzup>
ok, so if you put your d4 on and it gets them, and then your bionic, the bionic won't get the messages
<Wizzup>
is my point
<freemangordon>
yes
<Wizzup>
which is fine, but with telegram it keeps local state and this is why it knows exactly what to deliver
<freemangordon>
which is pretty normal
<Wizzup>
in 2008 :)
<Wizzup>
for xmpp we will also need some message markers support with some local data
<Wizzup>
I'm not being negative, just stating where I think we should try to get to
<freemangordon>
are you sure it is 2008?
<freemangordon>
no, no, I understand
<freemangordon>
I will ask my GF, to power-off her android when she is back home
<freemangordon>
and will chat with her in FB
<freemangordon>
to test if device is going to get the full history
<freemangordon>
also, it is possible that fb-purple does not support the full FB protocol functionality
<freemangordon>
or to not expose it to pidgin, as it does not have concept of ack by message, IIUC
<Wizzup>
I understand
<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
<Wizzup>
(and it also needs work)
<freemangordon>
and I am sure purple-fb receives all the unseen messages every time I log to FB from VM or d4 :D
<freemangordon>
hundreds of messages that is ;)
<freemangordon>
so it is not a minor issue
<Wizzup>
yeah
<Wizzup>
it probably takes a while to process them too, eh?
<Wizzup>
at least that is what happens for me now, it vibrates and makes sound for each of them :D
<freemangordon>
no, but makes fb chat useless
<freemangordon>
ah, right
<freemangordon>
so, which plugin do you have issues with?
<freemangordon>
tp-gabble, or telegram through haze?
<freemangordon>
or?
<Wizzup>
sorry, what issues specifically?
<freemangordon>
repeated messages
<Wizzup>
I do not have this problem
<freemangordon>
ah
<freemangordon>
ok
<Wizzup>
but when I connect telegram I might get like 50+ messages since i was last online
<Wizzup>
(I'm not popular, it's just some irc channel bridged to some telegram channel)
<freemangordon>
well, isn;t that a good feature actually?
<Wizzup>
it is, but they should be a single batch
<Wizzup>
now it is as if the messages are coming in at real time
<Wizzup>
so it will be vibration in my pocket for minutes
<Wizzup>
vibrating
<Wizzup>
but this is a conversations issue mostly, not tp per se
<freemangordon>
I see
<freemangordon>
right
<dsc_>
i was going to fix that today or tomorrow
<freemangordon>
I think there is a way to get pending messages
<freemangordon>
Wizzup: ok, please LMK when you are ready with chat state
<freemangordon>
I think it is not *that* easy to be implemented though
<freemangordon>
as you have to account for chat window being active (maximized), but device is not locked, etc
<freemangordon>
dsc_: oh, please, fix focus lost issue in chat edit widget
<freemangordon>
on send button pressed, edit field should not lose focus
<dsc_>
ah ok
<dsc_>
easy fix
<freemangordon>
right
<freemangordon>
sorry for not doing it by myself, but it will take me a while to find which form/class is that
<dsc_>
yeah
<dsc_>
im actually using d4 as my main now, dogfooding
<freemangordon>
I need few more things working properly first
<freemangordon>
conversations being one of them
Livio has joined #maemo-leste
<Wizzup>
for me it's just dtmf now ;p
<Wizzup>
but I guess I could try to play dtmf tones for now using some other device
Livio has quit [Read error: Connection reset by peer]
Livio has joined #maemo-leste
Livio has quit [Ping timeout: 264 seconds]
Livio has joined #maemo-leste
d4dsc has left #maemo-leste [#maemo-leste]
d4dsc has joined #maemo-leste
d4dsc has left #maemo-leste [#maemo-leste]
norly has quit [Read error: Connection reset by peer]
norly has joined #maemo-leste
Livio has quit [Read error: Connection reset by peer]
Livio has joined #maemo-leste
<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
System_Error has quit [Remote host closed the connection]
<Wizzup>
sicelo: we haven't seen that in a long time
<sicelo>
yes i thought so. i get it everytime now.
<freemangordon>
Wizzup: sorry, but I didn't get it: do you plan to implement chat state in conversations any time soon?
System_Error has joined #maemo-leste
<Wizzup>
freemangordon: I can try to look at it this week..
ceene has quit [Remote host closed the connection]
Livio has quit [Ping timeout: 255 seconds]
<freemangordon>
Wizzup: dsc_: I can look as well, but I need some hints where is the proper place for doing it
<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
<Wizzup>
s/tec/etc/
<Wizzup>
I'd ignore the 'is typing...' for now
<Wizzup>
and then we need to match it to a conversations channel
<Wizzup>
s/conversations/telepathy/
<Wizzup>
which we can do based on group uid
arno11 has joined #maemo-leste
<Wizzup>
or remote_uid rather I guess
<Wizzup>
we have TelepathyAccount::hasChannel
pere has joined #maemo-leste
<freemangordon>
Wizzup: I guess I have to add those signals, no?
<Wizzup>
yes, you can if you want to :)
<freemangordon>
ok, will try
<Wizzup>
the code to handle the telepathy side should probably go in src/lib/tp.cpp
<Wizzup>
I can't do it tonight
<freemangordon>
ok, will try to cook some code
<freemangordon>
ugh:
<freemangordon>
14033 user 20 0 3465432 1.5g 8824 S 0.0 38.1 0:28.43 conversations
<dsc_>
freemangordon: not sure what you're doing right now but feel free to delegate work to me and/or ask questions
<freemangordon>
dsc_: trying to implement TP chat state support
<freemangordon>
ok, thanks, lemme spend some time on it and if needed will ask for help
<dsc_>
state = "now typing..." ?
<freemangordon>
mhm
<Wizzup>
dsc_: well more like window has been active / is active
<Wizzup>
I don't think the typing... notification is the goal here per se
<Wizzup>
freemangordon: yeah there's definitely still some memory issues to figure out
<dsc_>
void TelepathyAccount::leaveChannel(const QString &channel) { <== this one is correctly named
<freemangordon>
remote_uid is inited from m_nickname
<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
<freemangordon>
so this cannot be key
<dsc_>
freemangordon: correct :)
<dsc_>
so
<freemangordon>
Wizzup: why not using shared pointgers?
<freemangordon>
*pointers
<Wizzup>
I don't know what it means but the thing can still stop existing or be invalidated at any time
<dsc_>
im not too worried about invalidating stuff
<Wizzup>
yes, but then you need a mechanism to find the new one
<dsc_>
this is a helper thing
<Wizzup>
at which point you could use that mechanism anyway?
<dsc_>
it loops the accounts (backends) to find the right one
<dsc_>
so in your case
<dsc_>
you want to communicate 'state'
<freemangordon>
mhm
<dsc_>
Telepathy::setState(...) with a similar helper thing that loops the accounts
<freemangordon>
shall I add similar slot?
<dsc_>
right
<freemangordon>
ok
<dsc_>
then in `Conversations::onChatStateChanged` you can call this->telepathy->setState()
<freemangordon>
mhm
<freemangordon>
shall I rename the parameter in hasChannel?
<dsc_>
and then also `TelepathyChannel::setState()`
<dsc_>
or hmm, maybe you need 3 layers, not sure
<dsc_>
freemangordon: yes
<freemangordon>
yeah, maybe, will see
<freemangordon>
ok
<dsc_>
good catch btw, yes its confusing, remote_uid is wrong there
<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
<dsc_>
well not refactoring, just working on it :)
<dsc_>
not sure what exactly to provide chatWindow
<dsc_>
but giving 20 variables like we do now is kinda sus
<Wizzup>
I think the group_uid should be the primary key for most things
<Wizzup>
I did rework most of the UI code to use this, but I am not sure if I did it everywhere
<dsc_>
this QMap lookup stuff btw, was my last tp refactor
<Wizzup>
tbh there are some valid remote_uid lookups when coupled with account
<Wizzup>
I guess it was QList before or something?
<Wizzup>
I know I set it up to track all of these things
<dsc_>
yeah, it was QList
arno11 has quit [Quit: leaving]
akossh has quit [Ping timeout: 255 seconds]
<dsc_>
btw, you could also access 'conversations.telepathy' from mainwindow via `m_ctx->telepathy`, or even directly from chatWindow
<freemangordon>
hmm, ok
<freemangordon>
getContext()?
<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
<dsc_>
just `m_ctx->telepathy->...`
<dsc_>
it sets up m_ctx in the constructor
<freemangordon>
ok
<Wizzup>
uvos: on razr/xt912, we don't see glitching problems in the tty right, just in X?
<freemangordon>
ok, seems I have some working code
<dsc_>
nice
<freemangordon>
ok, it seems channel is group id of group chat and remote id is accoutn id when single-user chat
<freemangordon>
right, ChatWindow needs lots of refactoring/cleanup,