Daanct12 has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #maemo-leste
Juest has quit [Ping timeout: 255 seconds]
Juest has joined #maemo-leste
<sicelo> arno11: and anyone interested in solving N900/omap3 power management issues - hope some of what Andreas is working on here, https://marc.info/?l=linux-omap&m=173136502302181&w=2, can be directly applicable. i seem to recall that SPI was also our worst offender
Daanct12 has quit [Ping timeout: 252 seconds]
Daanct12 has joined #maemo-leste
_alice has quit [Ping timeout: 246 seconds]
_alice has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
joerg has quit [Ping timeout: 246 seconds]
joerg has joined #maemo-leste
ceene has joined #maemo-leste
xmn has quit [Ping timeout: 260 seconds]
xmn has joined #maemo-leste
pere has quit [Ping timeout: 260 seconds]
pere has joined #maemo-leste
akossh has joined #maemo-leste
pere has quit [Ping timeout: 252 seconds]
xmn has quit [Ping timeout: 244 seconds]
Livio has joined #maemo-leste
pere has joined #maemo-leste
<Wizzup> the main issues I am finding these days is that sometimes the modem drops from the usb bus and leste doesn't make this obvious to the user: things keep working and it will even still show the signal bar
<Wizzup> I suppose the connui-cellular rework might fix this
Livio has quit [Remote host closed the connection]
Livio has joined #maemo-leste
pere has quit [Read error: Connection timed out]
pere has joined #maemo-leste
n900 has quit [Read error: Connection reset by peer]
pere has quit [Read error: Connection timed out]
System_Error has quit [Ping timeout: 260 seconds]
n900 has joined #maemo-leste
pere has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
pere has quit [Ping timeout: 255 seconds]
Anasko has joined #maemo-leste
ceene has quit [Read error: Connection reset by peer]
ceene has joined #maemo-leste
System_Error has joined #maemo-leste
pere has joined #maemo-leste
DFP has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11> sicelo: sounds promising
<arno11> Wizzup: is it only on d4 or on all devices ?
<Wizzup> probably all, but the modem doesn't disappear as frequently on n900
<Wizzup> it happens maybe once every few weeks
<Wizzup> I am pretty sure fmg's work will at least make us aware of this problem
<arno11> ok
xmn has joined #maemo-leste
Daanct12 has quit [Quit: WeeChat 4.4.3]
ceene has quit [Ping timeout: 260 seconds]
<dsc_> freemangordon: hi
<dsc_> looking for a sgianl related to contacts changing attributes like presence, I think its contactChanged or some such
arno11 has quit [Ping timeout: 248 seconds]
arno11 has joined #maemo-leste
<arno11> Wizzup: btw most of the time when i lock the screen now, hsdpa connection is lost
<arno11> previously i was able to keep the connection for hours, even days
<Wizzup> wow, what :D
<arno11> *even days with a charger ofc
<arno11> i wonder what happened recently
pere has quit [Ping timeout: 255 seconds]
<freemangordon> dsc_: is that related to abook?
<freemangordon> Wizzup: re connui-cell - finally I am back on it since Sunday
<freemangordon> making steady progress, hopefully will hit -devel by the end of the week
<dsc_> freemangordon: looking for a way to track changes to contacts, since contacts are managed by abook, I suspect there may be a signal there somewhere
<dsc_> to detect incoming friend requests for example
<freemangordon> G_IMPLEMENT_INTERFACE() means inheritance, in c++ terms
<freemangordon> so, OssoABookContact is also OssoABookPresence
<dsc_> hmm
<freemangordon> also, OssoABookContact does https://github.com/maemo-leste/osso-abook/blob/master/lib/osso-abook-contact.c#L201 for all properties changed
<dsc_> ok ill try something
<dsc_> yes :) thats what I noticed just now
<freemangordon> so you should connect to "notify::presence-status"
<freemangordon> connecting to "notify::" is a bit tricky
<freemangordon> callback must have signature:
<freemangordon> void (*cb)(GObject *gobject, GParamSpec *pspec, gpointer user_data)
<dsc_> yes, i was looking at what is user_data
<dsc_> but ill figure it out thanks
<freemangordon> sec, will provide an example
<freemangordon> user_data is the data you want to be passed to callback
<dsc_> oh.
<freemangordon> usually pointer to structure, but can pass this if callback is static member
<dsc_> ok that work will work fine
<dsc_> ok that will work fine*
<dsc_> the roster code from yesterday also works
<dsc_> freemangordon: this snprintf is annoying https://plak.infrapuin.nl/selif/je57ex3q.txt
<freemangordon> don't use snprintf
<dsc_> alright
<freemangordon> also, no need to do e_vcard_get_attribute
<freemangordon> you can directly do osso_abook_contact_get_blocked(contact), for example
<freemangordon> or osso_abook_contact_get_value()
<dsc_> its probably neccesary for values that are not binary
<dsc_> ah ok
<freemangordon> you do osso_abook_contact_get_value(E_CONTACT(contact);
<freemangordon> E_CONTACT(contact) casts from OssoABookContact to EContact
<freemangordon> implementing E_TYPE_CONTACT means that it inherits EContact
<freemangordon> the same for the other interfaces/classes in the list
<freemangordon> so you can safely do OSSO_ABOOK_AVATAR(contact) etc
<dsc_> alright
<dsc_> one question
<freemangordon> keep in mind that you should get avatar of master contact, not roster contact
<freemangordon> ?
<dsc_> should I be storing a list of contacts
<dsc_> in conversations
<freemangordon> no
<dsc_> I reckon no
<freemangordon> you can always retreive them from abook
<dsc_> i was wondering because we are connecting to callbacks and idk what happens when we g_list_free(contacts)
<freemangordon> anyways it is storing all the contacts *and* their relations etc
<freemangordon> all you see in addressbook application (and things you don't see) are at your disposal
<freemangordon> no need to waste your time duplicating code
<dsc_> well
<freemangordon> also, if you need some functionality and you can;t find it, please, first check with me if it is not already in abook
<freemangordon> as it does lots of things
_whitelogger has joined #maemo-leste
<freemangordon> g_list_free() frees the list, not the data it contains
<freemangordon> however, you shoudl g_object_ref(contact) if you want to be sure it would not disappear under your feet
<dsc_> ok, dont think it will be a problem
<freemangordon> do not forget to unref once you don;t need it anymore
<freemangordon> also, you must explicitly disconnect from signals you connected to when you don;t need the object anymore
<freemangordon> a note: osso_abook_contact_get_uid() gets EBook contact uid
<dsc_> sure
<dsc_> i would have noticed that eventually hehe
<freemangordon> sorry, I meant master contact uid
<dsc_> yes
<freemangordon> IIUC
<freemangordon> ok
<dsc_> ill look at this notify::presence-status
<dsc_> which applies to a OssoABookContact
<freemangordon> mhm
<dsc_> or not?
<freemangordon> yes, it does
<dsc_> ok
<dsc_> thanks
<dsc_> actually
<dsc_> sorry I need more coffee
<dsc_> I'm looking for publication requests
<dsc_> hmm
* freemangordon hands dsc_ a cup of coffee
<dsc_> presence-status might be something else
<dsc_> but maybe its enough
<dsc_> let me check
<freemangordon> yeah, it is something else
<freemangordon> lemme find what you need
pere has joined #maemo-leste
ac_laptop has joined #maemo-leste
<freemangordon> dsc_: seems abook does not provide signals when published/blocked/etc has changed
<freemangordon> but, you said TP already provides those signals?
<freemangordon> lemme double-check
<dsc_> signals in TP are: subscriptionStateChanged, publishStateChanged, blockStatusChanged
<dsc_> these are Tp::Contact signals
<freemangordon> do you need those connected for all contacts?
<dsc_> yes
<dsc_> but only if the connection manager has those capabilities
arno11 has left #maemo-leste [#maemo-leste]
<freemangordon> osso_abook_contact_presence_get_handle() will give you TP handle
<dsc_> ah ok
<freemangordon> wait, wrong function
<dsc_> maybe there is a classmethod Tp::Contact::fromHandle()
<freemangordon> osso_abook_presence_get_handle()
<freemangordon> exactly
<dsc_> so if abook destroys a contact, I also need to know, I think
<dsc_> because I'm operating on it from tp-qt
<freemangordon> if you ref it, it will not destroy it
<dsc_> ah ok
<freemangordon> but yeah, you should be notified
<freemangordon> don;t ask me how though :), have to llok in the code
<freemangordon> *look
<dsc_> ContactPtr ContactManager::ensureContact(uint bareHandle, const QString &id, const Features &features)
<dsc_> it seems to lookup this handle in some private dict
<dsc_> so dont think this is it
<freemangordon> link?
<dsc_> well, this is contactManager
<dsc_> :)
<freemangordon> if it does not find it, it calls connection manager
Livio has quit [Remote host closed the connection]
<dsc_> alright
<dsc_> ill try
<freemangordon> so, I think once you use the handle, you no more need abook contacts
<freemangordon> but, my gut feeling tells me there must be a better way of watching for contacts changes
<freemangordon> instead of keeping all the contacts in the system
<dsc_> my gut feeling is "freemangordon will implement subscriptionStateChanged, publishStateChanged, blockStatusChanged in abook :D"
<freemangordon> no, TP should already provide that for you
<freemangordon> tp_cli_connection_interface_contact_info_connect_to_contact_info_changed
<dsc_> just like abook has presence-status
<dsc_> uhmmm
<dsc_> yes that can work
<freemangordon> thats what eds TP plugin uses
<freemangordon> you just need to find Qt equivalent
<freemangordon> btw, there is Tp::ContactManager::contactsForHandles()
<dsc_> its a bit annoying
<dsc_> lemme make a suggestion
<dsc_> we add 2 conditions here for PUBLICATION and SUBSCRIPTION
<dsc_> so we can do
<dsc_> osso_abook_contact_notify(contact, "publication-status");
<dsc_> at which point we have `notify::publication-status`
<freemangordon> no, thats suboptimal
Livio has joined #maemo-leste
<freemangordon> because you should get notified when contact changes and see what has changed
<freemangordon> without keeping all the contacts around
<freemangordon> what if contact appears or gets deleted? who will refresh your list?
<dsc_> abook should give me signals for new or removed contacts, no?
<dsc_> since abook manages all the contacts
<dsc_> basically, we're using abook where we would otherwise use tp-qt's contactManager
<freemangordon> but yeah, I may consider adding that to abook
<dsc_> ok, lets think about it for a bit
Livio has quit [Ping timeout: 260 seconds]
<freemangordon> BTW, did you check those 2 are properly set in vcard?
<dsc_> yes it works
<freemangordon> great
<freemangordon> ok, I will add those
<dsc_> ehh
<freemangordon> will take me a while though
<freemangordon> hmm?
<dsc_> sorry I lied, let me check
<dsc_> i checked the presence attribute
Juesto has joined #maemo-leste
<freemangordon> hmm abook should already notify on contact update
<freemangordon> and then you can just ask for blocked etc
Juest has quit [Ping timeout: 252 seconds]
Juesto is now known as Juest
<freemangordon> dsc_: OssoABookAggregator
<dsc_> < freemangordon> BTW, did you check those 2 are properly set in vcard? <== they work, I checked
Livio has joined #maemo-leste
<freemangordon> cool
<dsc_> freemangordon: what about OssoABookAggregator?
<freemangordon> it provides contacts added/removed/changed signals
<freemangordon> so, you can connect to those and check whatever needed as you receive them
<freemangordon> instead of keeping contacts list
<dsc_> great
<freemangordon> oops
<freemangordon> not that one
<dsc_> ok, ill try
<freemangordon> all callbacks have one more parameter (gpointer user_data)
<freemangordon> so your contacts_changed cb should look like 'void contacts_changed_cb(OssoABookRoster *roster, OssoABookContact **contacts, gpointer user_data);'
Livio has quit [Quit: Reconnecting]
Livio has joined #maemo-leste
ac_laptop has quit [Ping timeout: 260 seconds]
ac_laptop has joined #maemo-leste
Livio has quit [Remote host closed the connection]
Livio has joined #maemo-leste
ac_laptop has quit [Ping timeout: 264 seconds]
freemangordon has quit [Read error: Connection reset by peer]
freemangordon has joined #maemo-leste
ac_laptop has joined #maemo-leste
<dsc_> this does not trigger with for example presence changes (switching a contact from online to away)
<dsc_> I keep the roster/aggregator objects around, so thats not it
<dsc_> this is on an EBook*
<dsc_> maybe I should do that?
<dsc_> or EBookView* rather
<freemangordon> yes, it should not get triggered for presence changes
<freemangordon> as those come from telepathy, not as evcard
<freemangordon> see if those get triggered for some vcard property change
<freemangordon> like, change remote nick
<freemangordon> or name, or whatever
<dsc_> I changed my avatar to a cute rabbit, it did not trigger the callback
<dsc_> name change (I think this is 'alias') also did not trigger it
<freemangordon> your avatar?
<dsc_> profile picture
<freemangordon> yes, I know what avatar is, the question is - what contact is that?
<freemangordon> remote one?
<dsc_> yes
<dsc_> both contacts are already "friends"
<freemangordon> please repeat with OSSO_ABOOK_DEBUG=all
<freemangordon> and provide logs
<freemangordon> G_MESSAGES_DEBUG=all OSSO_ABOOK_DEBUG=all
fmg_leste_vm has joined #maemo-leste
<freemangordon> dsc_: what account is that? irc?
<dsc_> hmm ok sorry, it works now
<dsc_> not sure what happened
<freemangordon> heh :)
<dsc_> ok cool
<dsc_> next up we have: accepting/denying friend requests
<freemangordon> no
<freemangordon> you can't do that from abook
<freemangordon> this shall be done by TP
<dsc_> alright, that's fine
<dsc_> bbl, thanks
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
<sicelo> Wizzup: modem disappearing ... yes I've reported it before on D4. not yet seen it on N900
arno11 has joined #maemo-leste
<sicelo> we need to check carefully how we react to ModemRemoved and similar signals.
<sicelo> although I haven't experienced it on D4 in the last few weeks
<freemangordon> sicelo: this is properly handled in the new connui-cell
<sicelo> oh sweet
<sicelo> sneak preview? :-)
<freemangordon> no, sorry
<freemangordon> by the end of the week
<sicelo> sure
fmg_leste_vm has quit [Quit: fmg_leste_vm]
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
ac_laptop has quit [Quit: WeeChat 3.8]
doc has quit [Quit: Things to do]
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
Livio has quit [Ping timeout: 260 seconds]
akossh has quit [Ping timeout: 246 seconds]