freemangordon has quit [Ping timeout: 240 seconds]
freemangordon has joined #maemo-leste
Danct12 has quit [Quit: Quitting]
joerg has quit [Ping timeout: 250 seconds]
joerg has joined #maemo-leste
<kona>
Libcal builds, so my build vm probably works :)
Danct12 has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
<Wizzup>
kona: yes
<freemangordon>
kona: why do you build libcal, -dev it should be in the repos?
<freemangordon>
also, modest will need osso-abook (WIP) and HTML renderer replacement
<freemangordon>
I am working at osso-abook as we speak, so can prioritize whatever modest needs. It may already be there though
<Wizzup>
freemangordon: he's working on modest, so I think libcal is just a way to test the build vm
<freemangordon>
thought so, just wanted to be sure
belcher_ is now known as belcher
xmn has joined #maemo-leste
Pali has joined #maemo-leste
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
inky has joined #maemo-leste
peetah has quit [Ping timeout: 248 seconds]
_inky has quit [Ping timeout: 248 seconds]
peetah has joined #maemo-leste
inky has quit [Read error: Connection reset by peer]
inky has joined #maemo-leste
xes has quit [Remote host closed the connection]
xes has joined #maemo-leste
<kona>
freemangordon: yes, just testing
xes has quit [Read error: Connection reset by peer]
xes has joined #maemo-leste
uvos has joined #maemo-leste
xes has quit [Remote host closed the connection]
xes has joined #maemo-leste
xes has quit [Remote host closed the connection]
xes has joined #maemo-leste
xes has quit [Read error: Connection reset by peer]
xes has joined #maemo-leste
sunshavi has quit [Ping timeout: 240 seconds]
sunshavi has joined #maemo-leste
xes has quit [Read error: Connection reset by peer]
<freemangordon>
kona: ok. Did you see my note re osso-abook?
<kona>
Yes, will try to figure out what I need, sorting out a missing build dep on my vm presently
<freemangordon>
hmm, thre shouldn;t be any but a dependency to microb-dev (or something like that)
<freemangordon>
but, you'll need to build tinymail IIRC
<kona>
It might be because I cloned only modest instead of the whole leste repo?
<uvos>
freemangordon: so i have been looking at abook /lib
<freemangordon>
you don;t need the whole leste repo :)
<kona>
Some gtk doc dependency breaking autoconf
<freemangordon>
kona: however, I am not sure timymail is int ther repo
<freemangordon>
*tinymail
<freemangordon>
uvos: and?
<uvos>
freemangordon: im not sure i understand it quite yet, but is it correct so say that other apps shal use this to for instance show the avatar by creating a gtk widget of the type OssoABookAvatar?
<uvos>
and so on
<uvos>
for abook functionality
<freemangordon>
uvos: not really, all this is alreay there
<uvos>
ok but if i want to use abook
<uvos>
in some other app
<freemangordon>
you need only OssoAbookAccountSelector
<uvos>
how would i aquire the information
<uvos>
but i need the avatar
<freemangordon>
it is there
<freemangordon>
just a second
<freemangordon>
uvos: you need an avatar of a particular account, no?
<freemangordon>
so, how do you know which account you need avatar of?
<freemangordon>
you need that for sphone, correct?
<uvos>
freemangordon: yes im trying to figure out how "bad" it would be to have optional abook support in sphone
<uvos>
yeah so i have some number, i can look up what account i need via evolution (or abook but havent foudnd if it can yet)
<freemangordon>
sec
<uvos>
and then i need presence and the avatar and sutch
<freemangordon>
no, you don;t need evolution
<freemangordon>
all you need is abook, the functinality is already there
<freemangordon>
p, li { white-space: pre-wrap; } osso_abook_contact_get_photo
<freemangordon>
osso_abook_contact_get_photo()
<uvos>
hmm ok
<uvos>
and looking up a account from the number
<freemangordon>
actually it is '
<kona>
Freemangordon: tiny mail in 0mark repo
<freemangordon>
contact' not 'account'
<uvos>
sure
<uvos>
OssoABookContact
<freemangordon>
uvos: gimme a second to fint the functions you need to call
<freemangordon>
uvos: I think it is osso_abook_aggregator_find_contacts_for_phone_number()
<freemangordon>
maybe I shall feed ida with callui and see what functions it uses
xes has joined #maemo-leste
<uvos>
ah ok that looks like it would work
<uvos>
ok so there is something i really dont like about abook. it, correct me if im wrong, but its apears to be mixing frontend and backend. There seams no reason to have the thing that provides presence and
<kona>
Freemangordon: I'm planning to work with tinymail from repo:https://github.com/0mark/tinymail
<uvos>
account info and sutch depend and link to a gui toolkit
<freemangordon>
kona: why not use tinymail from CSSU?
<kona>
Cssu?
<freemangordon>
uvos: actually, it is the GUI toolkit
<uvos>
freemangordon: sure but there should be something below it
<freemangordon>
not a backend
<uvos>
that provides the account info presence and sutch
<freemangordon>
yes, telepathy and EDS
<uvos>
okay
<freemangordon>
telepathy provides presence
<uvos>
hmm
<freemangordon>
EDS - addressbooks
<uvos>
so maybe it would make more sense for me to avoid using abook and just geting the info from there...
<freemangordon>
if you look at OssoAbookContact it is based on EContact
<uvos>
since then i can also port sphone to gtk3
<freemangordon>
uvos: and you have to write all from scratch
<uvos>
also how are qt apps supposed to work
<freemangordon>
up to you ofc
<freemangordon>
how's that related/
<uvos>
like trojita
<freemangordon>
?
<uvos>
i also maintain that
<uvos>
well a qt app on maemo will have the same problem
<freemangordon>
don;t know, we have to look in some fremantle example
<freemangordon>
kona: sec
<freemangordon>
uvos: :nod:
<freemangordon>
it is a general issue
<kona>
K
<uvos>
maybe we should create (or exists) some thin wrapper
<uvos>
libmaemocontacts
<uvos>
or whatever that gives pixmaps and info in one place
<uvos>
just aggregates what abook gets from tp and from eds
<freemangordon>
but it is already aggregated
<uvos>
in abook
<freemangordon>
ah, you mean to rewrite abook?
<uvos>
no
<uvos>
not the gui part
<uvos>
just aggreate in a gui toolkit netural way
<freemangordon>
OssoAbookContact doesn't have GUI parts
<uvos>
yeah but it deppends on gtk2
<freemangordon>
so maybe we can split GUI from TP/EDS
<uvos>
yeah
<uvos>
thats what i was thinking
<uvos>
then we can make the backend lib something you can use elsewhere too
<freemangordon>
but, I am not going into this before abook is complete
<uvos>
since ofc hildoized gtk2 will be maemo specific forever
<freemangordon>
otherwise that's a wise move
<uvos>
sure
<freemangordon>
yeah, should be possible to split
<uvos>
great
<uvos>
ok finishing re first makes sense
<freemangordon>
but, you;ll be missing stuff like contact selector
<uvos>
ok
<freemangordon>
which does lot more that may look initially
<freemangordon>
because you have voicemail cointacts, for example
<uvos>
maybe we can spinn it into a seperate process for qt / gtk3 whatever apps
<freemangordon>
or 'me' contact
<uvos>
(thinking qt maemo apps here)
<freemangordon>
yes, I think this is wiser
<uvos>
ok
<freemangordon>
but maybe this is already implememted bu the addressbook application
<freemangordon>
*implemented by
<freemangordon>
which is in early REing stages
<uvos>
okay
<uvos>
carry on then
<freemangordon>
after the lib :(
<freemangordon>
uvos: I think maybe a better approach is to start with abook and implement something different after you are aware of all the requirements
<freemangordon>
what about the call history?
<freemangordon>
already said about the contact selector
<freemangordon>
it is not really trivial to implement one
<uvos>
sphone dose its own call history in sql rn, not sure how to integrate it
<uvos>
maybe we can have it infrom tp somehow
<freemangordon>
well, you can;t keep call history out of contact history
<freemangordon>
and contact history is in RtCom
<freemangordon>
by contact history I mean - calls, chats, SMSes, etc
<uvos>
ofono allso keeps its own history
xes has quit [Read error: Connection reset by peer]
<freemangordon>
it will become inconsistent otherwise
<uvos>
atm
<uvos>
so theres mutliple layers here allready doing the same stuff
<freemangordon>
sure, but this is not what you expect from a phone
<uvos>
not sure how to do it best
<uvos>
sure
<freemangordon>
uvos: I would say that's why Nokia integrated everything in one place
<uvos>
sure so we need something in the telephone stack inform that one place about calls/sms
<freemangordon>
maybe a better approach would be to de-hildonize osso-abook
<uvos>
im thinking about where
<freemangordon>
or rather - to have GUI parts in plain GTK/QT or whatever
<freemangordon>
but this is a huge amount of work
<freemangordon>
also, do you plan sphone to support dial over TP? like doing gtalk voice calls?
<uvos>
yeah i want to make the backend in sphone a plugin
<uvos>
so then you could have tp as one
<uvos>
but thats going to be a rather late addition
<uvos>
since it needs some kind of contacts and fully working calls (audio routing) first
<freemangordon>
ok, but what are you going to provide to the backend? EContact?
<uvos>
a string with what to dial
<uvos>
or what do you mean?
<freemangordon>
yes, that
<freemangordon>
but, how a string is going to describe a contact?
<freemangordon>
some internal format?
<uvos>
havent thought quite that far yet so at first ill just make a plugin of the ofono backend
<freemangordon>
just an idea - either use EContact or plain vcf
<uvos>
that just gets a string with the number rn
<uvos>
ok yeah something like that makes sense
<freemangordon>
everyone shall be able to understand vcf
<freemangordon>
if you want to avoid EDS dependency
<freemangordon>
vcf carries the avatar as well
<freemangordon>
BTW, that shall work with abook too
<uvos>
ok
<freemangordon>
abook can understand vcf I guess
<uvos>
ok
<uvos>
yeah vcf makes sense
<uvos>
but near term sphone will stay ofono so this is for later
<freemangordon>
I would still prefer full abook integration ofc :P
<freemangordon>
Which I am going to implement soon or later
<freemangordon>
have you ever seen fremantle dialer?
<uvos>
yeah
<freemangordon>
ok
xes has joined #maemo-leste
xes has quit [Read error: Connection reset by peer]
cockroach has joined #maemo-leste
xes has joined #maemo-leste
<Wizzup>
freemangordon: tinymail from cssu is too old for using the gtk html thing, it needs to be newer, see the notes from the same person @
<Wizzup>
freemangordon: ok, yeah, that wasn't used in that file
<kona>
Freemangordon, should I join cssu project?
<uvos>
Wizzup: yeah @ minimal html, i think the internal extreamly limited html5 renderer of qt5 seams pretty ideal for a mail client
<freemangordon>
Wizzup: see, basically I try to do my best to make the code 'beautiful' while REing, but sometimes I miss stuff. If you see I didn;t use defines on some places, please fix, it was not intentional
<freemangordon>
kona: no
<Wizzup>
uvos: I'd still like to get modest ported by just upgrading to newer libs if they exist, and then look at potential upgrades, it's quite low resource and nice, even on fremantle still
<Wizzup>
yes I fixed things by hand some minutes ago
<freemangordon>
ok, this line is an example of some weird, hardcoded QtCreator behaviour, it puts basically 3*indent spaces when continuing on the next line
<freemangordon>
I am not sure how to deal with that re auto indent
<Wizzup>
we could also just accept uncrustify behaviour in it perhaps
* Wizzup
going to get some sleep soon, intense day
<freemangordon>
me too
<freemangordon>
yeah, maybe
<Wizzup>
parazyd: btw, maybe if you have some time tomorrow you can think about some debhelper or re-usable postinst scripts to insert libicd_network_tor.so (or others) in the gconf string list for the network types
<freemangordon>
Wizzup: shall I merge the PR?
<Wizzup>
parazyd: and upon removal remove it from the list
<Wizzup>
freemangordon: should be good yeah
<freemangordon>
ping me when you at it (dh_ sthingie)