10:10 <Wizzup> arno11: yes that is possible, I think the code should mostly just work tbh

10:10 <Wizzup> like it still works on my droid4, but I did a dist upgrade

10:11 <Wizzup> at least I think it does..

10:11 <Wizzup> I think I might be wrong

10:12 <Wizzup> yeah ok, there's no python2 pyqt, that is the problem

10:13 <Wizzup> I think someone can just run 2to3 on this

10:14 <Wizzup> I'll do this now.

10:23 <Wizzup> arno11: ok, yeah I mostly got this to work now

10:30 <Wizzup> should be in repo momentarily

11:24 <arno11> Wizzup: ok thx man, it works again: good news, it doesn't overwrite current transitions config.

11:26 <arno11> lot of options are missing btw so i'll have a look in the code and try to add more options

11:29 <arno11> i mean parameters

11:29 <arno11> bbl

11:32 <Wizzup> arno11: sweet, ty

12:42 <Wizzup> arno11: so is the idea that we have leste-config postinst touch /home/user/.nomedia or something similar?

12:42 <Wizzup> (and then perhaps in the future, don't try to do the touch again)

12:44 <uvos__> i mean that dosent feal that great (ie more like a hack)

12:55 <arno11> maybe a bit hacky yes, but the trick is comming from the official gnome documentation

12:55 <arno11> so yes my idea was to use touch .nomedia

12:56 <arno11> until we find a cleaner way

12:56 <arno11> for all devices

13:09 <Wizzup> uvos__: well how would we ensure that the tracker ignore file exists in home

13:09 <Wizzup> we can do it in image builder, which won't work for any current devices

13:09 <Wizzup> and is also a hack

13:09 <Wizzup> or we can rebuild tracker just to change the default in gsettings

13:10 <Wizzup> but it all boils down to the same: how do we deal with the case where someone does want their home indexed

13:10 <arno11> true

13:11 <uvos__> if a user dosent want a directory indext creating the dotfile is the correct thing to do

13:11 <uvos__> i dont think that the awnser is the same if the distro maintainers dont want a directory indexed

13:11 <uvos__> here the package should be changed instead

13:12 <uvos__> ofc i understand you dont want to fork the package just for this default

13:12 <uvos__> but it is theoreticly the right thing to do in this case

13:13 <uvos__> toching the dotfile has for instance also the issue that the user will be faced with the repeatly self-recreating dotfile if he DOSE want $HOME indexed

13:13 <Wizzup> we already forked the package

13:14 <uvos__> its just a default after all

13:14 <Wizzup> (to fix it)

13:14 <Wizzup> ok, let me try to get these regs

13:14 <uvos__> btw sphone loging

13:15 <uvos__> so is group_uid supposed to be unique to what exactly?

13:15 <Wizzup> the account + the remote party

13:15 <uvos__> the remote contact? the remote endpoint? what exactly?

13:15 <uvos__> what if someone has multiple phone numbers?

13:15 <Wizzup> what do you mean

13:15 <uvos__> (the remote party that is)

13:16 <uvos__> if remote party a has 3 phone numbers should they share group_uid

13:16 <Wizzup> then they have a different group_uid but the contacts application will know they belong to the same contact

13:16 <Wizzup> no they should not

13:16 <Wizzup> ideally you'd just write whatever we write with ring because then everything would be grouped together

13:16 <Wizzup> but I understand potential resistant to this

13:17 <uvos__> hmm

13:17 <Wizzup> btw, for the reg dump, should I dump headset?

13:17 <Wizzup> or handset I mean

13:17 <uvos__> sure

13:17 <uvos__> i mean anything would be fine

13:17 <uvos__> as long as its conistant

13:17 <uvos__> i dont see what the point of group_uid is then

13:18 <uvos__> what dose it add that you cant figure out with the other fields?

13:18 <Wizzup> it's how rtcom is designed, it's literally what things are grouped by

13:19 <Wizzup> your account + remote party

13:19 <uvos__> i get its designed that way

13:19 <uvos__> but i dont see why

13:19 <Wizzup> what would you replace it with?

13:20 <Wizzup> https://github.com/maemo-leste/conversations/blob/master/src/lib/tp.cpp#L276

13:20 <uvos__> if you still have to look up what contact the group_uid belongs to i dont see how this is better than just looking up the contact based on the line_id + account

13:20 <uvos__> not sure what those fields are called exactly off hand

13:20 <uvos__> but they are there

13:20 <Wizzup> you don't need to look up the contact to group correctly when group_uid is set

13:20 <Wizzup> any many things are not mapped to a contact

13:21 <uvos__> ok

13:21 <uvos__> i need too look at the database again to comment further

13:22 <Wizzup> I also need to double check whether it's both for sms and call where fremantle logs only the last 7 digits and not the account id

13:23 <Wizzup> but if it's all the same to you then setting it to something compatible with conversations and fremantle would be best, or let a plugin provide this info

13:23 <Wizzup> for example for xmpp calls or sip calls we will need it to do something specific

13:24 <uvos__> leting a plugin directly provide this is not really an option

13:24 <uvos__> since i dont want to tie the plugin interface to the storage format

13:25 <Wizzup> ok, then just have the plugins expose the right information needed

13:26 <Wizzup> so for non-ring it is the name of the account in dbus, followed by a dash (-), and then the telepathy name of the channel

13:26 <Wizzup> all this info is available to the voicecallmgr plugin at least

13:28 <Wizzup> uvos__: https://wizzup.org/call-6.1-handset.txt

13:28 <Wizzup> https://wizzup.org/call-6.6-handset.txt

14:59 <Wizzup> uvos__: do you need anything else regs wise

16:37 <Wizzup> uvos: could 'ASoC: ti: Allocate dais dynamically for TDM and audio graph card' be related

16:38 <Wizzup> ah no, we did have that in 6.1

16:43 <Wizzup> from a dmesg perspective things look the same for voicecall at least

16:44 <Wizzup> uvos: maybe a first step is to check if we get EINVAL or not from snd_soc_dapm_force_enable_pin

17:09 <arno11> Wizzup: i had a look @cssufeatures and finally i'm not sure it is a great idea to let users tweaking too much transitions parameters (that's useless and too easy to break the UI in a second lol). Instead, i think we could add a new button able to load a stable custom config with no blur and cool effects like waves (next to 'Current', 'Default' and 'Update' buttons)

17:10 <arno11> this way advanced users can continue to tweak transitions file but can easely reload the default one

17:13 <arno11> and this way we can speed up N900 easely with an existing extras pkg

17:15 <arno11> *just adding a button and a additional transitions.ini file in cssufeatures pkg

17:24 <Wizzup> arno11: there is a 'restore to defaults' button already right

17:24 <Wizzup> or something like this

17:24 <Wizzup> so you just want some different buttons, like 'light' vs 'normal' vs 'heavy' ?

17:25 <Wizzup> arno11: but still, how do you want the n900 to be without blur by default

17:28 <arno11> that's the problem lol

17:28 <Wizzup> we could still displace the file from leste-config-n900

17:29 <arno11> yes indeed

17:29 <Wizzup> we'd just give users an easier way to back out

17:31 <arno11> (and yes indeed there is a restore to default button)

17:34 <arno11> bbiab

22:11 <arno11> Wizzup: i added a new button (in the top bar menu next to 'restore defaults') in cssufeatures to test if we can easely switch between transitions configs and it works fine

22:13 <Wizzup> great

22:16 <arno11> btw this app could be useful to configure/tweak other stuff

22:19 <arno11> because at the end it calls a bash script (updateTransitions)

22:27 <Wizzup> yeah, I think for some things

22:27 <Wizzup> I wouldn't necessary say put the tracker config in there

22:27 <Wizzup> necessarily*

22:32 <arno11> maybe not but a 'clone' of this app could do the job

22:35 <sixwheeledbeast> isn't there already a tracker config app?

22:40 <arno11> good question

22:45 <arno11> btw dconf-editor can do the trick

22:48 <Wizzup> I don't think a tracker ui is very high on the list of things tbh, but even so it'd be better for it to be a controlpanel applet

22:51 <arno11> yep but i just tried dconf editor and it takes few sec to add/remove $HOME or something else

22:55 <arno11> *just to say that tracker config is not a problem in fact