| Wizzup | arno11: yes that is possible, I think the code should mostly just work tbh | 12:10 |
|---|---|---|
| Wizzup | like it still works on my droid4, but I did a dist upgrade | 12:10 |
| Wizzup | at least I think it does.. | 12:11 |
| Wizzup | I think I might be wrong | 12:11 |
| Wizzup | yeah ok, there's no python2 pyqt, that is the problem | 12:12 |
| Wizzup | I think someone can just run 2to3 on this | 12:13 |
| Wizzup | I'll do this now. | 12:14 |
| Wizzup | arno11: ok, yeah I mostly got this to work now | 12:23 |
| Wizzup | should be in repo momentarily | 12:30 |
| arno11 | Wizzup: ok thx man, it works again: good news, it doesn't overwrite current transitions config. | 13:24 |
| arno11 | lot of options are missing btw so i'll have a look in the code and try to add more options | 13:26 |
| arno11 | i mean parameters | 13:29 |
| arno11 | bbl | 13:29 |
| Wizzup | arno11: sweet, ty | 13:32 |
| Wizzup | arno11: so is the idea that we have leste-config postinst touch /home/user/.nomedia or something similar? | 14:42 |
| Wizzup | (and then perhaps in the future, don't try to do the touch again) | 14:42 |
| uvos__ | i mean that dosent feal that great (ie more like a hack) | 14:44 |
| arno11 | maybe a bit hacky yes, but the trick is comming from the official gnome documentation | 14:55 |
| arno11 | so yes my idea was to use touch .nomedia | 14:55 |
| arno11 | until we find a cleaner way | 14:56 |
| arno11 | for all devices | 14:56 |
| Wizzup | uvos__: well how would we ensure that the tracker ignore file exists in home | 15:09 |
| Wizzup | we can do it in image builder, which won't work for any current devices | 15:09 |
| Wizzup | and is also a hack | 15:09 |
| Wizzup | or we can rebuild tracker just to change the default in gsettings | 15:09 |
| Wizzup | but it all boils down to the same: how do we deal with the case where someone does want their home indexed | 15:10 |
| arno11 | true | 15:10 |
| uvos__ | if a user dosent want a directory indext creating the dotfile is the correct thing to do | 15:11 |
| uvos__ | i dont think that the awnser is the same if the distro maintainers dont want a directory indexed | 15:11 |
| uvos__ | here the package should be changed instead | 15:11 |
| uvos__ | ofc i understand you dont want to fork the package just for this default | 15:12 |
| uvos__ | but it is theoreticly the right thing to do in this case | 15:12 |
| 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 | 15:13 |
| Wizzup | we already forked the package | 15:13 |
| uvos__ | its just a default after all | 15:14 |
| Wizzup | (to fix it) | 15:14 |
| Wizzup | ok, let me try to get these regs | 15:14 |
| uvos__ | btw sphone loging | 15:14 |
| uvos__ | so is group_uid supposed to be unique to what exactly? | 15:15 |
| Wizzup | the account + the remote party | 15:15 |
| uvos__ | the remote contact? the remote endpoint? what exactly? | 15:15 |
| uvos__ | what if someone has multiple phone numbers? | 15:15 |
| Wizzup | what do you mean | 15:15 |
| uvos__ | (the remote party that is) | 15:15 |
| uvos__ | if remote party a has 3 phone numbers should they share group_uid | 15:16 |
| Wizzup | then they have a different group_uid but the contacts application will know they belong to the same contact | 15:16 |
| Wizzup | no they should not | 15:16 |
| Wizzup | ideally you'd just write whatever we write with ring because then everything would be grouped together | 15:16 |
| Wizzup | but I understand potential resistant to this | 15:16 |
| uvos__ | hmm | 15:17 |
| Wizzup | btw, for the reg dump, should I dump headset? | 15:17 |
| Wizzup | or handset I mean | 15:17 |
| uvos__ | sure | 15:17 |
| uvos__ | i mean anything would be fine | 15:17 |
| uvos__ | as long as its conistant | 15:17 |
| uvos__ | i dont see what the point of group_uid is then | 15:17 |
| uvos__ | what dose it add that you cant figure out with the other fields? | 15:18 |
| Wizzup | it's how rtcom is designed, it's literally what things are grouped by | 15:18 |
| Wizzup | your account + remote party | 15:19 |
| uvos__ | i get its designed that way | 15:19 |
| uvos__ | but i dont see why | 15:19 |
| Wizzup | what would you replace it with? | 15:19 |
| Wizzup | https://github.com/maemo-leste/conversations/blob/master/src/lib/tp.cpp#L276 | 15: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 | 15:20 |
| uvos__ | not sure what those fields are called exactly off hand | 15:20 |
| uvos__ | but they are there | 15:20 |
| Wizzup | you don't need to look up the contact to group correctly when group_uid is set | 15:20 |
| Wizzup | any many things are not mapped to a contact | 15:20 |
| uvos__ | ok | 15:21 |
| uvos__ | i need too look at the database again to comment further | 15:21 |
| 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 | 15:22 |
| 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 | 15:23 |
| Wizzup | for example for xmpp calls or sip calls we will need it to do something specific | 15:23 |
| uvos__ | leting a plugin directly provide this is not really an option | 15:24 |
| uvos__ | since i dont want to tie the plugin interface to the storage format | 15:24 |
| Wizzup | ok, then just have the plugins expose the right information needed | 15:25 |
| 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 | 15:26 |
| Wizzup | all this info is available to the voicecallmgr plugin at least | 15:26 |
| Wizzup | uvos__: https://wizzup.org/call-6.1-handset.txt | 15:28 |
| Wizzup | https://wizzup.org/call-6.6-handset.txt | 15:28 |
| Wizzup | uvos__: do you need anything else regs wise | 16:59 |
| Wizzup | uvos: could 'ASoC: ti: Allocate dais dynamically for TDM and audio graph card' be related | 18:37 |
| Wizzup | ah no, we did have that in 6.1 | 18:38 |
| Wizzup | from a dmesg perspective things look the same for voicecall at least | 18:43 |
| Wizzup | uvos: maybe a first step is to check if we get EINVAL or not from snd_soc_dapm_force_enable_pin | 18:44 |
| 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) | 19:09 |
| arno11 | this way advanced users can continue to tweak transitions file but can easely reload the default one | 19:10 |
| arno11 | and this way we can speed up N900 easely with an existing extras pkg | 19:13 |
| arno11 | *just adding a button and a additional transitions.ini file in cssufeatures pkg | 19:15 |
| Wizzup | arno11: there is a 'restore to defaults' button already right | 19:24 |
| Wizzup | or something like this | 19:24 |
| Wizzup | so you just want some different buttons, like 'light' vs 'normal' vs 'heavy' ? | 19:24 |
| Wizzup | arno11: but still, how do you want the n900 to be without blur by default | 19:25 |
| arno11 | that's the problem lol | 19:28 |
| Wizzup | we could still displace the file from leste-config-n900 | 19:28 |
| arno11 | yes indeed | 19:29 |
| Wizzup | we'd just give users an easier way to back out | 19:29 |
| arno11 | (and yes indeed there is a restore to default button) | 19:31 |
| arno11 | bbiab | 19:34 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!