**** BEGIN LOGGING AT Fri Oct 09 03:00:00 2009 Oct 09 06:47:09 TAsn: just found the index toupper problem :) Oct 09 06:47:40 TAsn: sometimes it helps to sleep before looking at some problem :P Oct 09 06:55:10 SHR: 03mok 07libframeworkd-phonegui-efl2 * r71ba01ed9e7e 10/src/ (8 files in 3 dirs): correctly exit E mainloop (via elm_exit()) when last window is destroyed Oct 09 06:55:20 SHR: 03mok 07libframeworkd-phonegui-efl2 * r479cb07e3fa5 10/src/view/contact-list-common.c: contact-list: fix uppercasing the index chars Oct 09 06:56:41 SHR: 03mok 07libframeworkd-phonegui-efl2 * r1eea430d5a08 10/src/view/contact-list-common.c: contact-list: fix uppercasing the index chars Oct 09 06:56:43 SHR: 03mok 07libframeworkd-phonegui-efl2 * r58ce516bd6d8 10/src/view/ (contact-show-view.c message-new-view.c): free some allocated data Oct 09 07:17:31 raster: do you have the email address of morphis? Oct 09 07:18:12 hello guys. Is there a tool available to create the Packages{,.gz} and similiar files for setting up a personal repository? Oct 09 07:30:25 blindcoder: these tools should be the same as for debian repos Oct 09 07:39:14 Heinervdm: ummm... morphis@gravedo.de Oct 09 07:40:14 raster: thx, will send him the python-bindings for his calendar widget and ask some questions about it ;) Oct 09 07:40:25 cool Oct 09 07:40:56 raster: testing it with C was too hard for me ;) Oct 09 07:41:12 http://scap.linuxtogo.org/files/1fc33f17dca88eefad2e1fe4ecc17b11.png Oct 09 07:41:13 c isn't hard! Oct 09 07:41:35 raster: not the writing, the cross compiling ;) Oct 09 07:41:38 ok Oct 09 07:41:42 tho doesnt seem to fit Oct 09 08:00:27 nice, shr-today crashes illume as of image 20090906 with upgraded packages :P Oct 09 08:53:13 mrmoku|away, what was the issue? Oct 09 08:53:30 mrmoku|away, I'm not a big fan of sleep. ;) Oct 09 08:53:58 raster, btw, confirmed, index works brilliantly with utf8, again, thanks :) Oct 09 08:54:12 TAsn: :) Oct 09 08:54:13 npo Oct 09 08:54:24 tho.. things broke resently Oct 09 08:54:29 ? Oct 09 08:54:32 in many plances Oct 09 08:54:34 mopstly scrolling Oct 09 08:54:50 hoversel doesn't work in the revision we are using. Oct 09 08:56:52 mrmoku|away, omg (toupper bug) I'm an idiot :) Oct 09 08:57:31 anyhow, I'm off to get something to eat. ciao. Oct 09 09:07:40 TAsn: :) Oct 09 09:08:56 TAsn: now trac admin Oct 09 09:09:32 Ainulindale: hey, how's life ? Oct 09 09:10:00 If I tell you "busy", will you trust me? :-) Oct 09 09:10:07 hehe Oct 09 09:10:28 Ainulindale: one thing I always forgot to tell you... Oct 09 09:10:33 no money arrived here :P Oct 09 09:11:07 Well you answered with your bank account thingy right? Oct 09 09:11:19 I never got the money myself I think you should check that with the guy who done it Oct 09 09:11:27 It seems though dos received some Oct 09 09:11:32 TAsn did you yourself? Oct 09 09:11:43 Ainulindale: ahh... I thought you forwarded the account data to him Oct 09 09:11:52 mrmoku: Hmmm I thought you replied to all :-) Oct 09 09:12:02 hehe... that might explain it :) Oct 09 09:12:04 (Didn't check it so it may be that I fumbled) Oct 09 09:12:29 np... just noticed the other day checking my account :) Oct 09 09:16:37 what do you want money for.... oktoberfest is over... Oct 09 09:16:41 :) Oct 09 09:16:44 heh :-) Oct 09 09:18:28 Ainulindale, what? Oct 09 09:18:50 btw, (trac admin) thanks.p Oct 09 09:19:10 * mrmoku ignores Oktoberfest quite successfully for at least 6 years now :P Oct 09 09:19:18 TAsn: you can do that yourself then :-) Oct 09 09:19:29 oh, yeah. Oct 09 09:19:33 will do in a sec. Oct 09 09:19:47 mrmoku, really? is'n that the coolest thing ever? Oct 09 09:20:04 TAsn: well... if you see it the first time... maybe yes Oct 09 09:20:19 :) Oct 09 09:20:25 nowadays I consider it just madness Oct 09 09:20:45 (which I'm too old for anyway ;) Oct 09 09:21:04 TAsn: btw... no-async stuff looks good Oct 09 09:21:10 what is missing is ophonekitd Oct 09 09:21:24 will attack that now :) Oct 09 09:21:33 Oktoberfest is madness (I haven't been there for 15 years though :-) ) Oct 09 09:21:46 mrmoku, COOL! :))) Oct 09 09:22:01 spaetz: it was already madness 15 years ago... but today it is just disgusting :P Oct 09 09:22:15 when can we move over to regular -unstable rather than tests/mrmoku again? Oct 09 09:22:30 I found the -unstable-mrmoku to work jsut fine Oct 09 09:22:52 mrmoku: I guess you are right about the disgusting part :) Oct 09 09:22:54 spaetz: we might want to wait for the hoversel fix Oct 09 09:23:11 ok Oct 09 09:23:24 raster: is somebody looking into he hoversels? :) Oct 09 09:24:10 mrmoku, btw, I think that with that migration we'll move efl2 to be default, don't you agree? Oct 09 09:24:27 Heinervdm, btw, is anyone working on Xorg's back from suspend issue? Oct 09 09:24:48 yup... two days of fixing and we will have a nice thing on monday :D Oct 09 09:24:54 Heinervdm: don't know, what back from suspend issue? Oct 09 09:25:05 slow Oct 09 09:25:34 (at least that's my only issue) Oct 09 09:25:46 same here. Oct 09 09:25:46 why do i address this to my self? :D Oct 09 09:25:58 :) Oct 09 09:26:07 yes it's slow. Oct 09 09:26:09 Heinervdm, because you (and jama) are our Xorg gods... Oct 09 09:26:09 :) Oct 09 09:26:41 Heinervdm, playya_: do your patches apply to org.oe.dev too? Oct 09 09:26:49 JaMa, first time I've seen you since you guys got xorg, THANKS A LOT! :) Oct 09 09:27:20 mrmoku: the xorg patch can't becaue oe.dev has no 1.7 Oct 09 09:29:02 mrmoku: but if you commit the xserver-xorg-1.7.0 recipe first, it will apply Oct 09 09:29:54 Heinervdm: ok.. hmm... probably would have to test it though Oct 09 09:30:22 mrmoku: we picked all depencies from oe.dev, so it should work :) Oct 09 09:30:29 mrmoku, I don't know Oct 09 09:30:44 Heinervdm: ok, great Oct 09 09:31:29 do you mean the navit or the other patches Oct 09 09:32:05 mrmoku: but i don't know if it's a good idea to apply that randr patch to oe.dev, because it's a hack and i don't know how it will behave with other drivers Oct 09 09:32:59 Heinervdm: can you look up pointsers by screen? Oct 09 09:33:09 playya_: all of the patches :) Oct 09 09:33:15 go through the pointers and see if they are the correct screen I mean Oct 09 09:34:00 tmzt: don't know, i got most of that patch form daniels and i just searched a function where i can call the notify mehtod Oct 09 09:34:45 Heinervdm: ok, I just looked briefly, don't know X Oct 09 09:34:51 tmzt: i don't know much about X :) Oct 09 09:38:36 mrmoku, the first 3: no. forget #4. 5 and 6 maybe. check it later. have to cook a "krustenbraten" Oct 09 09:39:53 mrmoku: we should tell Weiss and larsc to look at suspend/resume speed :) Oct 09 09:41:08 playya_: hmm... your move libeflvala patches don't apply for me Oct 09 09:41:39 yes. because there's no libeflvala/libeflvala_git.bb Oct 09 09:42:17 there're 2 recipes for libeflvala. one in freesmartphone and one in libeflvala (shr/import) Oct 09 09:42:31 that is what I thought too first... but there is Oct 09 09:42:35 the one in libeflvala is the new one Oct 09 09:42:46 playya_: I'm talking about shr/import Oct 09 09:42:52 Heinervdm: I think there aren't xserver-1.7 deps in org.oe.dev :/ Oct 09 09:43:25 JaMa: hey, how was your trip :) Oct 09 09:43:26 Heinervdm: I can prepare big patch for org.oe.dev too Oct 09 09:43:32 JaMa: you cherrypicked the latest xorg stuff form oe.dev? Oct 09 09:43:40 mrmoku: great.. still lots of gpx tracks to process :) Oct 09 09:43:47 hehe :) Oct 09 09:43:58 Heinervdm: no.. I generated all stuff here with that bumping script.. Oct 09 09:44:00 #1: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/libeflvala?h=shr/import #2: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/freesmartphone/libeflvala_git.bb?h=shr/import Oct 09 09:44:59 Heinervdm: I have still problem with that vala stuff :/ even clean rebuild didn't help Oct 09 09:46:35 JaMa: i've seen that playya_ written sth about that he has valac installed on host. I'm having that too Oct 09 09:47:02 so there can be sth still wrong Oct 09 09:47:08 mrmoku, anyhow, feel free to merge the no async branch after some basic testing. :) Oct 09 09:47:46 mrmoku: what about some shr/merge branch? I would like to push our xorg stuff to org.oe.dev, would be nice to prepare and test it in shr/merge and then just suggest cherrypick from shr/merge in oe.dev ml Oct 09 09:48:15 Heinervdm: yes its partialy solved in 1.7.7+fso1.. but second problem with auto* stuff is still there :/ Oct 09 09:48:20 JaMa: if that makes it easier... why not Oct 09 09:48:37 mickey|sofa: ^^^ what do you thing about a shr/merge branch? Oct 09 09:48:46 JaMa: playya_ broke it, so he has to fix it :D Oct 09 09:49:18 mrmoku: git can make branches that follow head, can't it? Oct 09 09:50:05 s/head/another branch/ Oct 09 09:50:06 Heinervdm meant: mrmoku: git can make branches that follow another branch, can't it? Oct 09 09:50:41 Heinervdm: what do you mean by following head? Oct 09 09:51:40 so that all changes in org.oe.dev are applied automatically to another branch Oct 09 09:51:41 TAsn: what about old efl? Oct 09 09:51:53 mrmoku, should probably die. Oct 09 09:52:00 as it was intended Oct 09 09:52:05 gives nothing good to users Oct 09 09:52:10 no real reason to maintain it Oct 09 09:52:14 etc etc Oct 09 09:52:16 don't you agree? Oct 09 09:52:24 efl2 was born to replace efl wasn't it? Oct 09 09:52:30 I agree yes... but does everybody agree? Oct 09 09:52:49 mrmoku: two more cookies in patchwork for you and why didn't you pushed playya's vala patch? it fixes few problems here.. Oct 09 09:52:52 ok, so if people cry somebody has to fix old efl then regarding async Oct 09 09:53:06 JaMa: it did not applly for me Oct 09 09:53:35 mrmoku, fine with me. Oct 09 09:53:41 though I don't think that'll happen. Oct 09 09:53:50 btw, we gotta find a way to upgrade everyone's efl to efl2 Oct 09 09:53:52 ... Oct 09 09:54:45 Heinervdm: he fixed problems introduced by him, but I have another one :/ http://lists.shr-project.org/pipermail/shr-devel/2009-October/000841.html Oct 09 09:55:11 efl should die in favor of efl2, yep Oct 09 09:55:35 JaMa: ah you have this problem with the tests? Oct 09 09:56:07 mrmoku: ah, ok, probably because he pushed some more vala patches before the last patch removing that bad 0.7.7 version Oct 09 09:56:15 spaetz, :) Oct 09 09:56:17 spaetz, mrmoku, TAsn:cant we ranme efl2 to efl? then it will automatically updated Oct 09 09:56:28 s/ranme/rename/ Oct 09 09:56:28 Heinervdm meant: spaetz, mrmoku, TAsn:cant we rename efl2 to efl? then it will automatically updated Oct 09 09:56:33 Heinervdm, we can. maybe we should. Oct 09 09:56:47 Heinervdm: yes.. the same for other stuff and I'm surprised that it doesn't apply for the rest oe builders.. because it looks wrong for me Oct 09 09:56:48 mrmoku, what say you? Oct 09 09:56:56 Heinervdm: with following you probably mean the git ---track stuff, right? Oct 09 09:56:59 as in http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#maintaining-topic-branches Oct 09 09:56:59 we should of course discuss it more throughly Oct 09 09:57:00 Heinervdm: see following patch on ml Oct 09 09:57:02 but still.. :) Oct 09 09:57:10 JaMa: i've seen it Oct 09 09:57:45 JaMa: i think that's becaue OE isn't a completly closed system, and the host playes a big role too Oct 09 09:57:47 anyhow, cya. Oct 09 09:58:19 Heinervdm: I tried to remove valac on my host system and its still the same.. Oct 09 09:58:36 Heinervdm: could you send me copy of your libgee work dir after build? Oct 09 09:58:39 lunch now.. Oct 09 09:58:40 spaetz: yes, that is what i meant, we should use that for a new branche Oct 09 09:59:02 JaMa: will pack it Oct 09 09:59:21 JaMa: but there will be just temp, you know? Oct 09 10:02:29 why is FRs power consumption going down significantly on opening dialer screen? Oct 09 10:02:58 JaMa, do you mean the missing linux.vapi? Oct 09 10:03:09 that's not my fault Oct 09 10:04:24 pkg-config looks into staging_libdir, which is correct until you use --variable because it returns a native path Oct 09 10:05:13 DocScrutinizer-8: really? Wow Oct 09 10:05:45 hmm, it's depending on whether the dialer screen is in front (visible). When I switch to homescreen then power consumption is back to normal (which is a diff of about same amount as power for backlite!) Oct 09 10:05:56 JaMa, if you need a workaround: sudo mkdir -p /usr/share/vala/vapi/ && sudo touch /usr/share/vala/vapi/linux.vapi /usr/share/vala/vapi/posixextra.vapi Oct 09 10:05:58 mickey|sofa ping Oct 09 10:06:20 BTW, what about giving one GTA02 to Alan Cox so he can debug his kernel-space 07.10 mux implementation? Oct 09 10:06:21 DocScrutinizer-8: shit, that's a lot Oct 09 10:06:32 is teh desktop thing refreshing all the time or something? Oct 09 10:06:56 i.e. backlite on with dialer in front is a little *lower* than homescreen and backlite dimm Oct 09 10:07:12 spaetz: looks like, yea Oct 09 10:09:18 hi ptitjes Oct 09 10:09:27 TAsn, Heinervdm: (rename efl2 to efl) hmm, don't know. maybe not yet Oct 09 10:09:40 ok, it's a little exaggerated to say it's *lower*. Actually it looks like it's roundabout identical Oct 09 10:09:42 hi playya_ Oct 09 10:09:45 how are you ? Oct 09 10:10:10 great Oct 09 10:10:19 and the backlite is set to 43% Oct 09 10:10:22 you,too? Oct 09 10:10:57 playya_: yeah fine thanks Oct 09 10:11:08 so it's not as much as my first statement suggested, but still Oct 09 10:11:08 playya_: comming back from one week in the south of France Oct 09 10:11:08 :p Oct 09 10:11:31 ok. had some nice holidays? Oct 09 10:11:55 yp :p Oct 09 10:12:52 i had so many questions to you. but i can't remember them :( Oct 09 10:13:07 mrmoku: git --track is what i meant with following Oct 09 10:13:39 playya_: héhé :p Oct 09 10:13:43 mrmoku: i think we need a own branche because we can't merge everything... Oct 09 10:13:58 ah there's one cominig back. can you write a patch which export the *_new methods to the.h? Oct 09 10:14:07 playya_: I won't have so much time this afternoon, but I'll be available this evening to answer any of your question :p Oct 09 10:14:25 makes libfso-glib more usable from C Oct 09 10:14:51 Heinervdm: question is if we need that branch before or after merging the mergeable stuff Oct 09 10:15:06 playya_: could you recall me that this evening ? I'll try to think bout in the meantime, oki ? Oct 09 10:16:20 hmm, illume launcher homescreen and shr-settings roundabout equally greedy, dialer and sketch power-savers Oct 09 10:16:35 ptitjes, ok Oct 09 10:16:58 mrmoku: the question is should we merge every app to org.oe.dev? because there are some apps that won't run on any other distribution then SHR or OM2009 Oct 09 10:18:18 and merge some of our changes will make the recipes in org.oe.dev ugly because of many overrides for SHR Oct 09 10:18:20 notes : saver Oct 09 10:19:05 Heinervdm: there are lots of apps not running on SHR... so I think that is no problem Oct 09 10:19:38 valaterm : hog Oct 09 10:19:51 mrmoku: ok Oct 09 10:19:57 Heinervdm, you can use some bitbake stuff to make it distro or machine dependant Oct 09 10:20:24 playya_: i know, it did that for midori Oct 09 10:20:48 but i make the recipe a lot longer ;) Oct 09 10:25:48 JaMa, about your libgee problem: ask ptitjes to add a disable-tests switch and we can add it to the recipe Oct 09 10:26:31 playya_: tests are only run when make test or make check is ran Oct 09 10:26:48 but you don't have to build them Oct 09 10:27:02 they fail sometimes Oct 09 10:27:18 playya_: they should not fail Oct 09 10:27:32 playya_: if they don't, this is what has to be fixed Oct 09 10:27:36 i can forward you something Oct 09 10:27:48 playya_: pastebin it ? Oct 09 10:28:02 yes. i have to write a mail first Oct 09 10:31:25 ptitjes, i think you only forgot a /tests for basdir in the makefile Oct 09 10:31:45 mrmoku: do you know the progress of merging our recipes to org.oe.dev? has stefan_schmidt commit some more recipes? Oct 09 10:32:17 playya_: that workaround is for tests or for building vala-native? Oct 09 10:32:28 playya_: or linux.vapi? Oct 09 10:32:42 it's for libfsobasics Oct 09 10:33:10 playya_: humm... could you make a patch for that ? Oct 09 10:33:16 please Oct 09 10:33:33 playya_: in libfsobasics there is same problem as in libgee with topdir Oct 09 10:33:46 ptitjes: I just send one to ml.. Oct 09 10:33:56 ptitjes: http://lists.shr-project.org/pipermail/shr-devel/2009-October/000842.html Oct 09 10:34:04 i just saw your log for libgee Oct 09 10:34:16 and replied to you mail Oct 09 10:34:17 ptitjes: remove or add /tests Oct 09 10:35:29 add test might be better, because you can change the topsrc_dir Oct 09 10:35:41 playya_: looking at your reply, I don't understand why it should fail.. only problem here is that valac generates .c files in wrong directory Oct 09 10:35:59 spaetz: would be interesting to SIGSTOP one of the hog apps while on top, to see if that reduces power consumption significantly Oct 09 10:36:22 i missunderstood the patch. i thought you removed the topsrc_dir for the --pkg Oct 09 10:36:57 atm I'm cooking and try to be available here Oct 09 10:42:44 JaMa, i have to leave here to the kitchen. i fix it later. Oct 09 10:43:10 playya_: ok.. Oct 09 10:44:02 playya_: and then ask mrmoku to revert 2a02100840664139cfb3618ad3415f7f3dbd81f1 and then to apply your http://patchwork.dev.bearstech.com/patch/255/ or recreate the last one, please Oct 09 10:47:46 Heinervdm: no idea... have'nt seen anything though Oct 09 10:49:05 TAsn: studying? Oct 09 10:49:26 mrmoku: shr-images and shr-tasks are still missing, so i assume he pulled nothing Oct 09 10:49:54 yeah Oct 09 10:50:31 Heinervdm: he told me that he wants to add tasks and images when they build Oct 09 10:50:32 mrmoku: can't we simply commit recipes that won't affect any other thing in org.oe.dev? Oct 09 10:50:42 sure Oct 09 10:50:58 mrmoku: so all out apps that aren't in or Oct 09 10:51:26 all apps we have that are not in org.oe.dev is no problem Oct 09 10:51:59 do they have to build? Oct 09 10:52:14 good question :P Oct 09 10:52:18 for other distir? Oct 09 10:53:35 Heinervdm: I think the rule more or less is to not impact others Oct 09 10:53:49 so... at least the .bb should parse correctly :) Oct 09 10:54:17 so we have to be shure to add SRC_REV for all svn, cvs and git recipes Oct 09 10:54:27 yup Oct 09 10:54:39 in sane-srcrev.conf Oct 09 10:58:16 mrmoku: i will make a patch Oct 09 11:09:04 spaetz: a "sleep 40; kill -SIGSTOP ; sleep 30; kill -SIGCONT " didn't yield clear results :-/ Oct 09 11:10:36 spaetz: a simple "kill -SIGSTOP..." and then switching to the frozen "screen" of shr-settings seem to show it actually reduced power consumption Oct 09 11:11:43 spaetz: probably the active "sleep" in bash is also consuming more power than a simple idle cursor. Not sure about how to read the results Oct 09 11:14:11 spaetz: actually I couldn't say it's not related to dark screens per se using more power than white screens Oct 09 11:17:32 nanosleep({10, 0}, Oct 09 11:17:38 (sleep 10 in bash) Oct 09 11:18:17 bash: builtin: sleep: not a shell builtin Oct 09 11:19:07 tmzt: huh? Oct 09 11:19:34 what did you mean by "active sleep" Oct 09 11:19:40 that's a syscall (strace output) Oct 09 11:19:47 so the kernel should handle it Oct 09 11:20:22 I simply mean a "sleep 101" that not returned yet Oct 09 11:21:18 I mean it should just cause the kernel thread to sleep Oct 09 11:21:28 so why would it use more power Oct 09 11:22:32 I dunno. And I thought I clearly stated I'm short on decent explanations Oct 09 11:22:58 well, might have missed that part Oct 09 11:23:02 powertop/latencytop? Oct 09 11:24:01 is there some blutooth manageing gui planned for shr ? Oct 09 11:25:27 duh Oct 09 11:25:39 wait... Oct 09 11:27:04 oh noes Oct 09 11:29:10 dark areas on display eat power o.O Oct 09 11:29:51 Heinervdm: I can prepare xorg stuff for org.oe.dev.. Oct 09 11:30:07 Heinervdm: I already have patch for that :) Oct 09 11:30:17 JaMa: i'm preparing now just missing packages, i'm not updateing other recipes Oct 09 11:30:20 sketch with white canvas is using less power than when I paint it black entirely Oct 09 11:31:01 zear itneeds a lot of power to twist the cristal Oct 09 11:31:44 I suspect it's the glamo->lcm interface Oct 09 11:31:49 to prevent the backlight shining throu Oct 09 11:32:06 Heinervdm: ok.. as xorg stuff are also missing packages/versions :) Oct 09 11:33:04 DocScrutinizer-8: how are you measuring the power used? Oct 09 11:33:18 whatever is the cause, I recommend to white-blank the screen content on dimming backlite to off Oct 09 11:33:49 can't you power off most lcd's/lcm's? Oct 09 11:33:53 tmzt: via a two-color LED in a custom wallwart charger Oct 09 11:34:09 so the difference between the two colors visually? Oct 09 11:34:24 tmzt: sure we can, and actually we do on suspend Oct 09 11:34:34 but not on dim though Oct 09 11:34:47 maybe you could import some of the android stuff for active power management Oct 09 11:34:51 but it needs cleaned up Oct 09 11:34:56 (color diff) exactly Oct 09 11:34:57 some of it is in staging now Oct 09 11:35:13 excuse me all: who made this ? http://scap.linuxtogo.org/files/ac94c50ea7df506700b3b92e8a275be1.png Oct 09 11:35:54 pbaxter: it's me ;), but its not released yet Oct 09 11:36:24 this is the shr-today edje rewrite Oct 09 11:37:18 tmzt: (android) I really doubt android power mgmt on FR is any more advanced than e.g. SHR + andi-tracking Oct 09 11:37:46 I mean it can do things like disable lcd when not in use Oct 09 11:38:09 but that might be a property of the lcdc chip and not compatible with glamo/s3c Oct 09 11:38:39 Slyon: and when you think you'll release it? Oct 09 11:38:41 I guess you also can't deinit/reinit fast enough to make it worth the effort Oct 09 11:38:45 tmzt: we *can* do as well Oct 09 11:38:56 ah, ok Oct 09 11:39:02 then I misunderstood you Oct 09 11:39:09 so this is just about dim to off level? Oct 09 11:39:25 tmzt: but before we *want* to do that, we need a clear idea of the effects to achieve that way Oct 09 11:39:48 tmzt: yes, exactly Oct 09 11:40:46 probably even about power consumption during "everything up" as dimming the backlite probably doesn't change the effect of dark areas using more power Oct 09 11:40:50 except Oct 09 11:41:04 if we actually disable lcm during dim Oct 09 11:41:16 pbaxter: dont know, i got it functional today at 1:00 am. but the slider is very laggy at the moment and i dont know why, have to see when i've got time. but i guess i can publish a version until next week Oct 09 11:41:26 and glamo needs to pump data against a powered down interface then Oct 09 11:41:48 which might also explain that tens of mA diff Oct 09 11:43:03 you can clear the display by zeroing lut can't you? Oct 09 11:43:05 or clut Oct 09 11:43:12 like the fb drivers do Oct 09 11:43:22 tmzt: alas I simply cant test the accurate power consumption value for backlite on (as that's out of the "sensible range" of that bicolor led ;-) Oct 09 11:43:25 so it would clear to white or black? Oct 09 11:43:33 yeah Oct 09 11:44:12 tmzt: probably we can do that easily, yes Oct 09 11:44:21 (clut) Oct 09 11:44:52 though I'm not sure glamo videobuffer actually has any clut Oct 09 11:45:10 ah Oct 09 11:45:16 I don't know Oct 09 11:45:22 Weiss must Oct 09 11:45:35 boing Oct 09 11:48:03 Weiss: hey, guess I pinged you Oct 09 11:48:10 Weiss: 00:11 < DocScrutinizer-8> though I'm not sure glamo videobuffer actually has any clut Oct 09 11:48:21 we were discussing power saving on freerunner Oct 09 11:48:33 Has anyone configured logitech dinovo mini to use with freerunner? A bluetooth keyboard Oct 09 11:48:40 and if there's a good way to clear to white assummingthat has less power Oct 09 11:50:56 well, actually all I found for sure was the surprising fact that a white screen uses some 20..40mA less than a completely black one Oct 09 11:51:31 at least for state "backlite dimmed" Oct 09 11:53:01 so this leads to considerations about implementation of xset -s (? if that's the command actually used) Oct 09 11:58:08 DocScrutinizer-8: when the display is off both glamo and lcm are turned of Oct 09 11:58:11 f Oct 09 12:00:47 larsc: I'm not sure. ATM I'm about to search for brighter flashlight to see if screencontent is still there when backlite off Oct 09 12:01:32 but afaik only backlite LEDs are turned off Oct 09 12:01:48 DocScrutinizer-8: ok, when it comes to andy-tracking i'm not sure either Oct 09 12:02:00 everything beyond that is actually suspending of LCM Oct 09 12:02:11 but in the 2.6.31 branch both are turned of Oct 09 12:02:23 well pixelclock of the glamo is turned of Oct 09 12:02:25 f Oct 09 12:02:30 sure they are - on suspend Oct 09 12:02:39 no idea on xset -s though Oct 09 12:02:53 ok Slyon|away thanks Oct 09 12:03:39 freerunner has led backlight? Oct 09 12:03:49 btw. now that you are mentioning it. the leds are not turned off. only powered down to their lowest value... Oct 09 12:04:23 larsc: not even sure if this were expected behaviour of setting backlite to off Oct 09 12:04:57 larsc: uhuh Oct 09 12:05:18 tmzt: what else :-D Oct 09 12:05:49 I guess ccfl, good to know Oct 09 12:06:06 haha, no Oct 09 12:06:10 DocScrutinizer-8: what is not expected behaviour? Oct 09 12:06:31 ccfl is much too big and much too cumbersome for small screens Oct 09 12:07:16 larsc: blank lcd on powering down backlite might not what we actually want to do Oct 09 12:07:28 I think zaurus sl5500 used it, and probably similar devices of the time Oct 09 12:07:33 if a bt keyb works on desktop easily, shouldn't it be easy to pair with Freerunner too? Oct 09 12:07:43 it might be worth bearing in mind that blanking works "differently" with KMS Oct 09 12:07:48 if that's relevant Oct 09 12:07:58 not sure a sysfs for backlight should change anything with lcm Oct 09 12:08:00 or glamo Oct 09 12:08:16 and yeah, X would handle things differently when the ddx supports talking to the driver Oct 09 12:08:16 tmzt: it does not Oct 09 12:08:17 tmzt: that's my point Oct 09 12:08:27 you're talking about using the CLUT as a faster way of blanking than just writing to the framebuffer? Oct 09 12:08:44 Weiss: I was, many fbdev driver use that, but most blank to black Oct 09 12:08:49 Weiss: tmzt does, yes Oct 09 12:08:55 it shouldn't matter what color is on the screen with backlight OFF Oct 09 12:09:00 you send a blank event to the framebuffer. and all three glamo, backlight and lcm listen to it Oct 09 12:09:04 and shut down Oct 09 12:09:43 larsc: aha, and you don't talk about suspend? Oct 09 12:10:00 notify chain I think he means Oct 09 12:10:08 didn't know there was one for blanking Oct 09 12:10:09 DocScrutinizer-8: i'm talking about framebuffer blanking Oct 09 12:10:54 hmm, I don't see this on a recent desktop linux anyway, on my laptop Oct 09 12:12:42 anyway, now you got a new rather marginal battlefield, courtesy joerg ;-) It's not exactly up to me what you do about it now ;-P Oct 09 12:12:48 * DocScrutinizer-8 off for coffee Oct 09 12:35:02 blanking by doing ioctls on /dev/fb0 is something we should move away from if possible - going via the DDX instead Oct 09 12:36:05 in a non-fbdev environment (e.g. KMS), /dev/fb0 is a "second class citizen" - it only exists to have something to draw a console on Oct 09 12:36:22 larsc: related: I'm in Hamburg now, although still finding my feet. There should be GlamoBeers Oct 09 12:39:26 mrmoku: i have now all new depencies of task-shr-feed, added all SRCREV's to sane-srcrev and all checksums to checksum.ini. Oct 09 12:40:54 mrmoku: should i make a all in one patch? Oct 09 12:43:02 tmzt: btw CCFL wear out on frequent on/off cycles. So it would be a bad idea to constantly dim the screen if it were CCFL Oct 09 12:45:04 DocScrutinizer: i'll try to reproduce your display power consumption results. Oct 09 12:47:10 Weiss: ah, finally :) when do you have time? Oct 09 12:47:11 mrmoku: sent a patch, i hope it will arrive, it's really big... Oct 09 12:49:29 Heinervdm: hmm... to apply it to OE we have to do that in single patches I think Oct 09 12:49:49 mrmoku: one for every package? Oct 09 12:50:05 think so, yes Oct 09 12:50:21 but can we update checksum and sane-srcrev all in one? Oct 09 12:50:44 Heinervdm: let me take a look at your patch... Oct 09 12:50:46 we can do that before commiting the others Oct 09 12:51:01 mrmoku: has it arrived? Oct 09 12:51:18 not yet :P Oct 09 12:51:22 how big was it? Oct 09 12:51:31 mrmoku, are sms/calls broken in tests feed now? Oct 09 12:51:44 mrmoku: 720 kb :D Oct 09 12:51:54 Sharwin_F: hmm... that might explain why nobody is calling me :P Oct 09 12:52:38 Sharwin_F: but it should work... are you using efl or efl2? Oct 09 12:52:51 mrmoku, well, it's not a matter of being popular or not, but I'd like to be able to call if I need something xD Oct 09 12:52:54 mrmoku, efl2 Oct 09 12:53:21 Sharwin_F: and outgoing calls do not work? Oct 09 12:54:02 mrmoku, just asking if packaes where broken in order to wait till you fix them to upgrade :P Oct 09 12:54:16 DocScrutinizer-8, lindi-: If you want to test power consumption you should probably abandon andy-tracking and use 2.6.31. There are already some issues fixed, i guess Oct 09 12:54:33 Sharwin_F: ahh, so you did not upgrade yet :) Oct 09 12:54:44 nope :P Oct 09 12:54:48 Sharwin_F: well... wait a little Oct 09 12:54:55 as we're doing nice things :) Oct 09 12:54:59 mrmoku: forwarded the patch to you Oct 09 12:55:04 Heinervdm: ok, thanks Oct 09 12:55:10 but if you tell me it "can", at least, work, I'll upgrade Oct 09 12:55:23 Sharwin_F: it should work yes Oct 09 12:55:36 the one known bug is that hoversels do not work Oct 09 12:55:45 which means you will have a hard time switching the profile :P Oct 09 12:55:54 mrmoku, yes, neither do now :P Oct 09 12:56:04 ahh ok Oct 09 12:56:04 I've done an script for it already :P Oct 09 12:56:09 hehe :) Oct 09 12:57:15 Heinervdm: good work :D Oct 09 12:57:19 mickey|sofa: ping Oct 09 12:57:26 larsc: DocScrutinizer: i seny my results to mailing list. at least with andy-tracking a3587e4ed77974a I do not see the problem Oct 09 12:57:28 btw, yesterday dos was asking on how to enable composite, and I tried to enable it in Xorg.conf... It happened that two times I booted FR with composite enable, verything looked ok, but the SIM request screen didn't appeared :S Oct 09 12:57:31 mrmoku: there is sth wrong in checksums.ini Oct 09 12:57:56 theire should be no deletion ;) Oct 09 12:59:58 well, Xorg looked fine, but opimd wasn't able to start, that was the problem Oct 09 13:00:15 hmm... what does the log say? Oct 09 13:00:26 no idea what's the relation between opimd and Xorg though :O Oct 09 13:00:32 mrmoku: if i hit options->sms in efl2 contactlist i come to a wired screen with 3 back buttons and a file chooser, whats that? Oct 09 13:02:47 Slyon: hmm.. which rev of efl2? Oct 09 13:02:58 Heinervdm: can't find no - though Oct 09 13:03:14 latest in tests/mrmoku/feed Oct 09 13:03:28 mrmoku, was the log thing addressed to me? Oct 09 13:03:35 mrmoku: found it, it's devmem2.c Oct 09 13:03:36 Sharwin_F: yup :) Oct 09 13:04:19 Heinervdm: ahh, it changes the sums? Oct 09 13:04:44 mrmoku: yes, and i think the one's in org.oe.dev are the corect one's ;) Oct 09 13:05:16 mrmoku: latest in /tests/mrmoku/feed -> 0.0.1+gitr101+989444895fdb9d78a73e8c035b4054b4c68d4bcd-r1 Oct 09 13:05:24 mrmoku, the thing is I noticed it when I was already out from home (I just rebooted before going out), and I couldn't save logs and all that. I'll get the logs after thought, as it's easy to reproduce ;) Oct 09 13:06:17 mrmoku, afair it was something about opimd being not able to load some/all SQLite backends Oct 09 13:06:45 Sharwin_F: that is normal though Oct 09 13:07:18 mrmoku: I just sent patch with xorg stuff directly to openembedded-devel@lists.openembedded.org Oct 09 13:07:35 Slyon: hmm, contactlist/options/SMS gives me the new message window... Oct 09 13:07:55 JaMa: good :) Oct 09 13:08:11 mrmoku, then I'll deep into it later to get more info, as that shouldn't be the problem then Oct 09 13:09:53 mrmoku: hmm, I'll try it again, have to boot in the other partition.... Oct 09 13:19:26 mrmoku: hmm, now it crashes: shr-contacts: view/contact-list-view.c:206: frame_list_message_clicked: Assertion `g_hash_table_lookup(properties, "number") != ((void *)0)' failed. Oct 09 13:20:15 mrmoku: and if i select a contact and click on actions->sms in detail-view i come to this screen: http://scap.linuxtogo.org/files/020503eb6f3173b72ee20b4d822a587c.png Oct 09 13:23:18 JaMa, i fixed it. could you try to test it before i push it: http://pastebin.com/f2c24866f Oct 09 13:23:37 Slyon: heh... forgot to remove my fileselector test :P Oct 09 13:24:01 SMS/Call in the contact view is not yet implemented and I abused the menu button :) Oct 09 13:24:42 I will change that behaviour Oct 09 13:25:01 coming from the list to the view will be longpressed and not selected as it's now Oct 09 13:25:27 and the crash is already fixed... just not built Oct 09 13:26:06 mrmoku: okay, nice :). Oct 09 13:26:27 playya_: I just removed my workdir again :/, so it will take time to test it.. but it looks pretty much the same as I have here.. Oct 09 13:26:41 ok. Oct 09 13:26:54 I'm rebuilding the 4 packages Oct 09 13:27:13 but it already compiled before this patch Oct 09 13:28:29 imho it's better to completely remove the tests, because we never use it Oct 09 13:30:26 Heinervdm: could you send me your oe.dev patch too? Oct 09 13:31:06 Heinervdm: I would like to start building shr image from oe.dev as I can share -native stuff between my shr and angstrom builds... Oct 09 13:32:10 JaMa: sent, but that are only the missing packages, we need to merge some other recipes and update some versions Oct 09 13:37:47 Heinervdm: I think that SRCPV is not possible to use in oe.dev Oct 09 13:38:19 ok, so sth that we have to change too in this patch Oct 09 13:38:28 Heinervdm: also .../include/preferred-xorg-versions-live.inc shouldn't be in your patch as preferred versions from this file aren't in oe.dev now Oct 09 13:39:15 JaMa: there are some more things that aren't right Oct 09 13:39:22 but i think it's a beginning Oct 09 13:40:08 and we should remove most stuff from preferred-shr-versions.inc and use newer from oe.dev :) Oct 09 13:40:57 JaMa: of course but that can we do afterwards Oct 09 13:41:28 mrmoku, JaMa: i think we should use a new branch for merging, it's still a lot to do :) Oct 09 13:41:49 a branch tracking org.oe.dev Oct 09 13:46:39 Heinervdm: agreed .. this patch is good enough for new branch where we can finish before pushing individual parts to oe.dev Oct 09 13:52:19 JaMa, mrmoku: i have a fixed patch, correct checksums.ini and no SRCPV Oct 09 13:52:50 eek... no SRCPV Oct 09 13:52:52 * mrmoku shudders ;) Oct 09 13:53:12 but yes... we have to drop that for getting it into oe.dev :( Oct 09 13:53:14 that will cause parsing errors for others Oct 09 13:53:47 mrmoku: what do you say? try another shr-oemerge? Oct 09 13:55:38 Heinervdm: send me your updated patch and I will create it Oct 09 13:56:07 TAsn: keep studying ;) Oct 09 13:56:33 mrmoku: sent Oct 09 13:56:37 mrmoku: apply there also this one http://thread.gmane.org/gmane.comp.handhelds.openembedded/26738 Oct 09 13:57:07 JaMa: ok Oct 09 13:57:48 JaMa, mrmoku: i haven't removed xorg-live.inc from the patch Oct 09 14:00:00 mrmoku: please remove conf/distro/include/preferred-xorg-versions-live.inc from Heinervdm's patch before applying as mine is generated just now and would create conflict for you later :) Oct 09 14:09:37 JaMa, Heinervdm: created and pushed shr/merge Oct 09 14:10:16 mrmoku: do you update the shr-makefile too? :) Oct 09 14:10:27 nah... can't do that until it builds Oct 09 14:10:37 mrmoku: ok Oct 09 14:11:02 Heinervdm: but you can easily do it locally Oct 09 14:11:18 mrmoku: does shr/merge track org.openembedded.dev? Oct 09 14:11:30 mrmoku: yes, no problem Oct 09 14:12:08 * mrmoku rereads about tracking branches Oct 09 14:14:39 mrmoku: great, thanks! Oct 09 14:14:50 all new stuff to shr/merge first now? Oct 09 14:16:32 yup Oct 09 14:18:36 mrmoku: packagekit 0.5.2 is missing in shr/merge Oct 09 14:18:52 dos1: gimme a patch then ;) Oct 09 14:19:03 just cp it Oct 09 14:19:05 :P Oct 09 14:19:35 navit is also without our patches Oct 09 14:20:01 dos1: i just added not existing recipes Oct 09 14:20:09 i didn't update anything Oct 09 14:20:30 well, that's not enough ;) Oct 09 14:20:36 but keep the great work going! Oct 09 14:22:16 Heinervdm: hmm... packagekit 0.5 is not existing in oe.dev, and it's not in shr/merge too ;x Oct 09 14:22:42 dos1: but another version of packagekit exists ;) Oct 09 14:22:51 which is not usable ;p Oct 09 14:23:04 updating the versions is next step Oct 09 14:23:14 ok :) Oct 09 14:25:33 dos1: (r.e. composite): as I understand it, it should just work. But it won't be accelerated.. Oct 09 14:26:13 Weiss: i don't expect acceleration Oct 09 14:26:20 Weiss: but xcompmgr says "No composite extension" Oct 09 14:27:44 hmm Oct 09 14:28:50 possibly some configure option needs to be set? Oct 09 14:29:21 playya__: btw: as your patch added fsoraw -r GPS,Display for navit, I prefer to run navit with just GPS,CPU on bike, as its tracking to gpx and saving power with Display off.. is there way to disable your fsoraw in launcher in runtime? Oct 09 14:29:37 Display in navit? Oct 09 14:29:40 oh Oct 09 14:29:50 of course it should be CPU! Oct 09 14:30:26 mrmoku: found tracking? else: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#maintaining-topic-branches Oct 09 14:30:27 JaMa, no. i suggested a a fso plugin for navit. but i don't have any experince with the navit code Oct 09 14:30:30 dos1: did you work on shr-setting for bluetooth ? Oct 09 14:30:50 I want to use navit for routing in a car, that's why I added Display Oct 09 14:30:56 playya__: http://patchwork.dev.bearstech.com/patch/234/ Oct 09 14:31:20 pwgen: what do you mean by "work on bluetooth"? Oct 09 14:32:01 playya__: i think that only CPU should be in launcher and Display added by user just if he needs it Oct 09 14:32:38 playya__: adding Display seems easier later than removing existing Display in launcher Oct 09 14:32:39 dos1 there is something to to enable/disable bt and make it visible. but i am seekeing for a solutuion to pair and select devices . Oct 09 14:33:12 without loggin in and typeing some stuff to the console Oct 09 14:33:13 pwgen: auto/manual(on/off), and visible/hidden. only that is implemented in shr-settings Oct 09 14:33:59 dos1: do you know something about a moko usable gui to handle the bt stuff ? Oct 09 14:34:20 no Oct 09 14:34:20 but navit is a map application which shows maps on the display, that's why I am pro display Oct 09 14:34:31 i'm against display unless user selects it Oct 09 14:34:41 this means whne i write someting its not a wate of time ( when my stuff works ) Oct 09 14:36:47 pwgen: well, it depends how you'll write it ;) Oct 09 14:36:58 Heinervdm: well... git defaults to tracking if you checkout a remote branch and don't tell it otherwise Oct 09 14:37:07 though that is a local thing Oct 09 14:37:30 well, it's easy to check if it's tracking branch Oct 09 14:37:32 dos1: add it to the setup stuff. browsing devices , pairing Oct 09 14:37:47 just wait for some commit in oe.dev, and do git pull Oct 09 14:38:02 :P Oct 09 14:39:00 mrmoku: hmm, but for our oemerge we need everything from oe.dev Oct 09 14:39:15 playya__: but you could still use navit for bike/car navigation with speech or just enable display from time to time... I know power consumption is ok in car with adapter.. but with adapter is display shutdown disabled automaticaly :) Oct 09 14:40:03 ok. shwitch to cpu, even i don't have a car adapter Oct 09 14:40:36 mrmoku: even better would be to have shr/merge patches rebased on top of oe.dev if its possible :) Oct 09 14:41:20 JaMa: rebasing would be possible... but means we can't build from it as history changes Oct 09 14:42:43 what I mean is... pulling will fail when we rebased it Oct 09 14:45:14 JaMa: you forgot to update sane-srcrev.inc for new xorg stuff Oct 09 14:47:04 JaMa: but it's just libdrm-glamo Oct 09 14:53:49 Heinervdm: I'm removing libdrm-glamo just now, but thanks for noticing.. it would be needed for libdrm_git.bb too Oct 09 14:54:11 JaMa: ok Oct 09 14:55:42 <\marco> hi to all :) Oct 09 14:59:38 <\marco> I'd like to write a paint-like app using elementary.. is it possible? for example, which class I've to use? Oct 09 15:01:26 dos1: you are using the hciconfig tool inside the settings/bt stuff and no dbus calls . why ?( downwards compatible dot bluez 3 ? ) Oct 09 15:05:08 pwgen: when it was implemented we were using bluez3 Oct 09 15:05:14 feel free to reimplement it to bluez4 Oct 09 15:05:16 ahh Oct 09 15:05:28 OMFG Oct 09 15:05:52 its better keeping bluez4 in fokus ? Oct 09 15:06:46 Obama has got Nobel Prize :x Oct 09 15:08:29 Peace Noble Prize for everyone .... Oct 09 15:09:14 give me one too please, i'm giving peace and love to my gf :P Oct 09 15:09:24 *FG* Oct 09 15:09:33 dos1: you're too young for that stuff Oct 09 15:09:37 (girlfriend) Oct 09 15:10:19 dos1: don't lie to us, we know that FR is your gf ;) Oct 09 15:10:28 Ainulindale: i said "peace and love". dunno what did you understand from that ;) Oct 09 15:10:43 soltys: well, i'm giving peace and love to my FR too ;D Oct 09 15:10:47 ;) Oct 09 15:10:54 lets create the Love Nobel Price ... Oct 09 15:11:06 but now i'll give peace and love to my stomach - LET'S EAT SOMETHING! :> Oct 09 15:12:18 aka Gastronomy Nobel Price Oct 09 15:12:57 <\marco> any hint for wrinting an elementary pain-like app? Oct 09 15:16:50 dos1: packagekit is the only package that has an older version in shr/merge Oct 09 15:17:47 <\marco> *paint! Oct 09 15:17:54 <\marco> pain-like app .. :D lol Oct 09 15:18:36 S&M! Oct 09 15:19:31 \marco: shouldn't be hard, thanks to elementary being evas based Oct 09 15:25:38 <\marco> dos1: mhm.. can you suggest me a start point? a widget for the drawing window for example? or it is simple to find in evas? Oct 09 15:25:58 \marco: evas is just canvas Oct 09 15:26:05 read some docs, i don't know much about it Oct 09 15:26:25 every elementary window is evas object Oct 09 15:26:35 so you can draw on it just like on evas Oct 09 15:26:53 so find some example for evas, read some docs etc. Oct 09 15:26:58 and then use it in your elementary app Oct 09 15:27:12 <\marco> dos1: ok :) I'll read some docs. Thanks for the suggestion ^^ Oct 09 15:48:29 mrmoku, I'm heer. Oct 09 15:48:35 re Oct 09 15:48:40 hey :) Oct 09 15:49:00 hope your head is full of complicated stuff you studied the whole day :P Oct 09 15:49:21 <\marco> bye! Oct 09 15:49:39 mrmoku, nah. Oct 09 15:49:43 I went to work instead :( Oct 09 15:49:46 on a friday!!! :( Oct 09 15:50:11 ouch Oct 09 15:50:43 yeah. Oct 09 15:50:45 well, merged? :) Oct 09 15:51:20 mrmoku, ^ :) Oct 09 15:51:50 oh, nvm I see you haven't. Oct 09 15:51:56 anyhow, you were looking for me earlier Oct 09 15:51:56 not yet, no Oct 09 15:51:58 anything special? Oct 09 15:52:16 ophonekitd is giving me a hard time :) Oct 09 15:52:40 btw, I think I f*** up calling, though I may have an idea why :) Oct 09 15:52:49 mrmoku, in doing what? removing async? Oct 09 15:52:55 but in some minutes I will try if it works what I did Oct 09 15:53:05 mrmoku, I hope you just dropped the loop from phonegui_init Oct 09 15:53:11 and not from shr-* Oct 09 15:53:14 and ophonekitd Oct 09 15:53:33 as phonegui_ is the one that assumes glib exists, shr-* can't do that. Oct 09 15:54:04 hmm... the loop is in efl2 phonegui Oct 09 15:54:22 it should be in shr-* and ophonekitd Oct 09 15:54:26 well anyhow, it's an easy minor change Oct 09 15:54:29 so no biggie. Oct 09 15:54:36 mrmoku, explanation to that^ Oct 09 15:54:42 ophonekitd needs glib Oct 09 15:54:42 it can't be there... is it is depending on the toolkit Oct 09 15:54:57 mrmoku, no, I mean. Oct 09 15:54:57 s/is/as/ Oct 09 15:54:57 mrmoku meant: it can't be there... as it is depending on the toolkit Oct 09 15:55:06 ophonekitd and such Oct 09 15:55:07 got glib Oct 09 15:55:11 yep Oct 09 15:55:19 so we SURELY need glib Oct 09 15:55:23 and shr-* has no loop at all Oct 09 15:55:24 backends may not have glib Oct 09 15:55:35 phonegui has no loop at allo Oct 09 15:55:47 mrmoku, I'm talking about efl2 (when I say phongeui) Oct 09 15:55:49 but the efl2 backend has glib mainloop integrated into efl mainloop Oct 09 15:55:54 hm.. :| Oct 09 15:55:59 no other way Oct 09 15:56:11 but it's a bit hidden Oct 09 15:56:14 from ophnekitd Oct 09 15:56:15 ok Oct 09 15:56:17 nvm you are right Oct 09 15:56:21 I'll think about something. Oct 09 15:56:56 ok, and I try if it works :) Oct 09 16:03:26 ok, I think I fixed a bug in efl2 :) Oct 09 16:03:32 (why it won't call from any window0 Oct 09 16:03:44 we sent the call initiate function the number + "tel:" Oct 09 16:03:46 or so it seems Oct 09 16:03:50 verifying. Oct 09 16:06:46 Heinervdm: great to see merge going, please include vala-0.7.7+fso1 from http://patchwork.dev.bearstech.com/patch/255/ instead of old 0.7.7 Oct 09 16:07:11 JaMa: i'm doing a testbuild currently Oct 09 16:07:14 Heinervdm: and how did you updated versions in preferred-shr? Just packages where preferred version didn't exist to latest? Oct 09 16:07:38 JaMa: just where it doesn't exists Oct 09 16:07:39 Heinervdm: vala-native_0.7.7 will fail then for you :/ Oct 09 16:07:57 JaMa: you know, for me it compiled ;) Oct 09 16:08:11 SHR: 03tom 07shr * r7922e89492cd 10/libframeworkd-phonegui/src/frameworkd-phonegui-utility.c: added a debug message Oct 09 16:08:22 SHR: 03tom 07shr * r87ada01a33dc 10/libframeworkd-phonegui/ (3 files in 2 dirs): Merge branch 'master' of git+ssh://shr.bearstech.com/shr Oct 09 16:08:35 Heinervdm: even playya said that his 0.7.7 was wrong :) Oct 09 16:12:40 JaMa: patch does not apply, either in import nor in merge Oct 09 16:16:12 Heinervdm: I know.. but its easy to resolve.. or you can just revert one commit before that Oct 09 16:16:40 revert 2a02100840664139cfb3618ad3415f7f3dbd81f1 Oct 09 16:17:42 or I'll send another one Oct 09 16:19:50 mrmoku: pong Oct 09 16:21:08 mickeyl: hola amigo Oct 09 16:25:10 hi DocScrutinizer-8 Oct 09 16:28:20 Heinervdm: sent Oct 09 16:28:41 mrmoku, I know it's a bit hackish Oct 09 16:28:44 but I added a Oct 09 16:28:54 common-utils.h|c Oct 09 16:29:12 *but I added Oct 09 16:29:27 so please dump there all the general functions that will be used by all the other files Oct 09 16:29:39 like g_value_safe_get or whatever it's name is ;) Oct 09 16:29:54 and all of those Oct 09 16:30:01 I started filling that up Oct 09 16:31:56 mrmoku, btw: ** ERROR **: row does not exist in /usr/share/libframeworkd-phonegui-efl2/contacts.edj Oct 09 16:31:58 :( Oct 09 16:32:47 SHR: 03tom 07libframeworkd-phonegui-efl2 * rad55cc304927 10/src/ (6 files in 2 dirs): added common-utils.h|c and started using common_utils_skip_tel_prefix everywhere Oct 09 16:34:48 mickeyl: hey Oct 09 16:35:07 mickeyl: we started shr/merge branch to organize getting our stuff upstream Oct 09 16:35:16 YES!!! Oct 09 16:35:21 :) Oct 09 16:35:29 where can i help? Oct 09 16:35:35 or rather... how? Oct 09 16:35:55 Heinervdm made one huge patch with all recipes that we have but are *not* in oe.dev Oct 09 16:36:04 I guess we have to apply them recipe by recipe? Oct 09 16:36:22 i'm afraid so Oct 09 16:36:29 i can take take of all python recipes Oct 09 16:36:39 s/take/care/ Oct 09 16:36:39 mickeyl meant: i can care take of all python recipes Oct 09 16:36:42 heh Oct 09 16:36:58 so is it recipe + sane-srcrev or just the recipe and then one patch with all srcrevs? Oct 09 16:37:08 or better srcrevs first as otherwise parsing will fail? Oct 09 16:37:53 i reckon you first you SRCREV, not SRCPV Oct 09 16:37:55 TAsn: hehe... there is already a helper for tel skipping :P Oct 09 16:37:57 then parsing will work Oct 09 16:38:05 as SRCREV is 1 per default Oct 09 16:38:12 just builing won't work, but that's ok Oct 09 16:38:16 mrmoku, hehe, nvm :) Oct 09 16:38:23 ahh... ok, so no sane-srcrevs is not needed Oct 09 16:38:23 mrmoku, anyhow I'm copying more functions there... Oct 09 16:38:24 so you can commit one patch that adds all srcrevs Oct 09 16:38:33 good :) Oct 09 16:38:38 (to both :) Oct 09 16:39:39 mickeyl: have you heard stefan? has he some merging pending? Oct 09 16:40:11 heyho Oct 09 16:40:14 mrmoku: not recently Oct 09 16:40:18 k Oct 09 16:40:46 we're probably starting our weekly telco again next wek Oct 09 16:40:49 week, even Oct 09 16:41:05 when is palm pre day? Oct 09 16:41:33 13th... Oct 09 16:41:42 that is pretty soon :D Oct 09 16:42:14 TAsn: my ophonekitd fails badly :P Oct 09 16:43:01 mrmoku, :( Oct 09 16:43:22 TAsn: I have to rework it... that ophonekitd has one phoneui thread Oct 09 16:43:45 do what you gotta do. :) Oct 09 16:44:06 * mrmoku goes downstairs to think about what he's gotta do :P Oct 09 16:44:08 brb Oct 09 16:54:08 * mrmoku 's body would need some sports too :P Oct 09 16:56:59 Heinervdm: ping Oct 09 17:03:28 TAsn: ping Oct 09 17:03:46 TAsn: I don't know what I've got to do :P Oct 09 17:04:03 hey mickey the sofapotato is back Oct 09 17:12:08 mrmoku: spank TAsn, always a good choice ;-) Oct 09 17:12:30 TAsn: all your fault ;) Oct 09 17:12:58 pwgen, no. he's not doin sofasports Oct 09 17:13:25 *G* Oct 09 17:20:42 mrmoku, :) Oct 09 17:21:52 Weiss: what about rebasing libdrm after you rebased also mesa-glamo? Oct 09 17:22:26 TAsn: need to talk about mainloops with you :) Oct 09 17:22:27 mrmoku, I can only do real work and debugging after my test (monday) Oct 09 17:22:31 mrmoku, sure thing. Oct 09 17:22:33 go ahead Oct 09 17:22:50 mrmoku, first of all Oct 09 17:22:56 gdb: where's the segfault Oct 09 17:23:21 segfault ? Oct 09 17:23:31 we don't have segfaults... never ;) Oct 09 17:24:43 TAsn: the elm backends have to call elm_init(), elm_run(), elm_exit() and elm_shutdown() Oct 09 17:24:55 before elm_run() they integrate the glib mainloop Oct 09 17:24:59 what happens where? Oct 09 17:25:34 If I get you right Oct 09 17:25:38 there are two possible solutions Oct 09 17:25:43 either you should run Oct 09 17:25:47 elm_run Oct 09 17:25:51 or start the glib main loop Oct 09 17:25:52 not both. Oct 09 17:26:13 you create the glib main loop, attach it to the ecore loop and then do elm_run Oct 09 17:26:19 oh, ok. Oct 09 17:26:47 then what's your issue? (or in other words, got a working example somewhere?) Oct 09 17:26:56 now *I* think the only sane way is to have that elm_run() inside ophonekitd Oct 09 17:27:55 mrmoku, I agree. Oct 09 17:28:02 just drop it from efl2 Oct 09 17:28:17 and put it in ophonekitd Oct 09 17:28:19 that means though that shr-contacts needs to start contacts via ophonekitd Oct 09 17:28:25 or Oct 09 17:28:32 guidaemon ;) Oct 09 17:28:38 :) Oct 09 17:28:41 I'd like that Oct 09 17:28:43 you know that. Oct 09 17:28:58 if you are up for the job, I'm up as well. :) Oct 09 17:29:16 ok, wanna make ophonekitd the GUI daemon? Oct 09 17:29:40 my thought would be do have a gui thread in ophonekitd Oct 09 17:29:47 running the mainloop Oct 09 17:29:49 (elm) Oct 09 17:29:57 s/do/to/ Oct 09 17:30:03 sounds reasonable enough. Oct 09 17:30:19 but then we need our dbus interface Oct 09 17:30:28 what dbus interface? Oct 09 17:30:30 and shr-contacts is just a dbus call Oct 09 17:30:32 for the gui daemon Oct 09 17:30:33 yeah. Oct 09 17:30:45 which is just fine. Oct 09 17:31:02 but means it won't be finished today :P Oct 09 17:31:23 mrmoku, I believe in working in segments. Oct 09 17:31:26 i.e one step at a time. Oct 09 17:31:32 :) Oct 09 17:31:50 first of all, drop all the async crap from efl2 Oct 09 17:31:51 then Oct 09 17:32:02 add a function Oct 09 17:32:05 phonegui_run_loop Oct 09 17:32:07 or something Oct 09 17:32:14 phonegui_loop Oct 09 17:32:17 is probably better Oct 09 17:32:35 then we are ready to commit (to a branch) Oct 09 17:32:48 and we'll be able to work on ophonekitd (in a branch) on a later day. Oct 09 17:33:28 phonegui_loop would then call phonegui_backend_loop, right? Oct 09 17:35:42 TAsn: how would be the situation with a phoneguid? Oct 09 17:35:52 mrmoku, not quite. Oct 09 17:36:01 phonegui_loop atm will call phonegui_backend_loop Oct 09 17:36:03 but after that Oct 09 17:36:12 there'll be a bit more complex thereading Oct 09 17:36:17 threading* Oct 09 17:36:35 there'll be an array of mainloops Oct 09 17:36:39 as we need on thread per bacckend Oct 09 17:36:45 not quite Oct 09 17:36:53 thread per unique loop backend Oct 09 17:37:01 but, yeah, almost the same. Oct 09 17:37:07 was what I meant :) Oct 09 17:37:10 :) Oct 09 17:37:32 but yeah. Oct 09 17:37:44 at least it'll be in phonegui, and backends will remain clean. Oct 09 17:37:57 backends should not know about internal design of phonegui and ophonekitd (as they do now) Oct 09 17:40:00 ok, will think some more... and play a bit Oct 09 17:41:50 hehe :) Oct 09 17:41:53 btw Oct 09 17:41:57 adding contacts from sms Oct 09 17:42:00 SHR: 03tom 07libframeworkd-phonegui-efl2 * re112e1ffca54 10/src/view/ (common-utils.c common-utils.h): renamed common_utils_add_prefix Oct 09 17:42:01 SHR: 03tom 07libframeworkd-phonegui-efl2 * r504d8d1a850d 10/src/view/ (common-utils.c common-utils.h): added more utility functnios Oct 09 17:42:01 SHR: 03tom 07libframeworkd-phonegui-efl2 * rd598aeb400c6 10/src/ (7 files in 2 dirs): renamed and fixed all the uses for skip_prefix_ Oct 09 17:42:02 SHR: 03tom 07libframeworkd-phonegui-efl2 * r6e96920d3dc5 10/src/phonegui-contacts.c: fixed a typo Oct 09 17:42:04 and answering an sms Oct 09 17:42:07 do not work here :( Oct 09 17:44:10 ok, we do nothing with content, wth?! Oct 09 17:44:39 uhhhh, this looks nice: http://scap.linuxtogo.org/files/09d6e276ecef45c31997f32dcaac0821.png Oct 09 17:46:46 someone has forgotten to change phonegui_contacts_new_show() to phonegui_contact_new_show() in contacts-main.c Oct 09 17:47:49 * mrmoku hides Oct 09 17:50:04 SHR: 03tom 07libframeworkd-phonegui-efl2 * rb096a6a1bcda 10/src/view/message-new-view.c: removed all the data saving mess and put it where it belongs, content change (where we already strip and do everything needed, this keeps consistency of data) Oct 09 17:50:05 betheg, thanks :) Oct 09 17:51:15 betheg, what's contacts-main.c? Oct 09 17:52:06 TAsn: shr-contacts Oct 09 17:52:59 betheg, not only there :) Oct 09 17:53:02 (I just noticed) Oct 09 17:53:15 ok Oct 09 17:53:28 mrmoku, here? Oct 09 17:53:34 yup Oct 09 17:53:34 do you want it to be Oct 09 17:53:39 contacts_new_show Oct 09 17:53:45 or contact_new_show? Oct 09 17:54:00 singular if you ask me Oct 09 17:54:08 and what did you add contact_hide for? Oct 09 17:54:19 for completeness :P Oct 09 17:54:23 lol. Oct 09 17:54:33 I think it should be in plural Oct 09 17:54:37 for consistency Oct 09 17:54:43 otherwise many will make mistakes Oct 09 17:55:02 what do you think about that? Oct 09 17:55:02 hmm... so rule would be that it is the domain? Oct 09 17:55:05 fine for me too Oct 09 17:55:19 ok cool. Oct 09 17:55:21 thinking about it... even better Oct 09 17:56:56 so should I also change in messages? Oct 09 17:57:01 to a more coherent name? Oct 09 17:57:15 yup Oct 09 17:57:41 cool. Oct 09 17:57:48 TAsn: I was looking at GAsyncQueue... but that won't work out Oct 09 17:58:07 phonegui_messages_message_show Oct 09 17:58:10 mrmoku, what's that for? Oct 09 17:58:26 for communication between the two threads Oct 09 18:00:07 TAsn: if there is for example an incoming call... the dbus/glib ophonekitd thread has to tell the phonegui ophonekitd thread to show the incoming call window Oct 09 18:00:43 oh, ok. Oct 09 18:00:45 SHR: 03tom 07shr * r7da17da185d6 10/libframeworkd-phonegui/src/ (frameworkd-phonegui.c frameworkd-phonegui.h.in): renamed to phonegui_messages and phonegui_contacts Oct 09 18:01:29 mrmoku, btw Oct 09 18:01:32 I see you didn't yet add Oct 09 18:01:39 phonegui_backend_messages_message_show... Oct 09 18:01:53 furthermore, there's no such thing as a message id anymore Oct 09 18:01:56 only message paths Oct 09 18:01:56 iirc. Oct 09 18:02:05 or do you call the suffix of the path an id? Oct 09 18:02:06 that was another question I had for youP Oct 09 18:04:02 mrmoku, just path Oct 09 18:04:04 (I think) Oct 09 18:05:01 mrmoku, although that's terribly ugly. Oct 09 18:05:08 maybe we should start considering the suffix of the path Oct 09 18:05:12 as the id. Oct 09 18:05:18 dos1|away, what do you think? ^ Oct 09 18:05:25 mrmoku, he's the opimd dude after all... Oct 09 18:05:40 is there somewhere documentation about python elementary ? Oct 09 18:05:44 mrmoku, btw, resolving still doesn't work here :( Oct 09 18:06:26 hmm... strange thing... but lucky you... for me nothing works right now :P Oct 09 18:07:01 TAsn: so... any preference for the thread communication thingie? Oct 09 18:07:15 I need something that interrupts the running mainloop Oct 09 18:07:25 (that's why GAsyncQueue is not an option) Oct 09 18:07:47 mrmoku, lol, though still adding contacts from messages Oct 09 18:07:53 or sending sms Oct 09 18:07:55 do not work :( Oct 09 18:07:57 mrmoku, hm... Oct 09 18:09:49 http://library.gnome.org/devel/glib/unstable/glib-The-Main-Event-Loop.html Oct 09 18:09:54 there are many resources there. Oct 09 18:10:00 I'm no glib expert. Oct 09 18:24:26 yay, found the issue :) Oct 09 18:24:28 now fixing it :( Oct 09 18:24:36 which one? Oct 09 18:25:10 oh, vm. Oct 09 18:25:11 nvm ;( Oct 09 18:29:28 sorry but now there is to fix src/ophonekitd-main.c:364 phonegui_message_show to phonegui_messages_show Oct 09 18:30:56 betheg, :) Oct 09 18:31:17 self-interest :) Oct 09 18:31:48 it's not relevant anymore anyway Oct 09 18:31:51 but cool :) Oct 09 18:31:56 thanks, fixed. Oct 09 18:32:25 i have build problems with this :( Oct 09 18:32:31 betheg, lol, hehe :) Oct 09 18:32:41 betheg, that's why I fixed Oct 09 18:32:41 SHR: 03tom 07shr * r3b3788f2de62 10/ophonekitd/src/ophonekitd-main.c: fixed the phonegui_message vs phonegui_messages_message error Oct 09 18:33:01 though we'll have to change that to opimd signal anyway. Oct 09 18:33:29 ok i say nothing more Oct 09 18:37:43 :) Oct 09 18:44:51 <[Rui]> hi, any efl savvy around? Oct 09 18:48:36 mrmoku, exactly what I thought Oct 09 18:48:43 phonegui_backend_contacts_new_show passes strings Oct 09 18:48:51 and the function that accepts them Oct 09 18:49:01 needs gvalues Oct 09 18:49:12 the gvalue boogie :( Oct 09 18:49:12 we should really sort stuff out Oct 09 18:49:20 I added a hackish gvalue set Oct 09 18:49:30 though I really don't want everything to be passed as gvalues Oct 09 18:49:43 in my pov we need core functions that work with strings Oct 09 18:49:49 and wrappers for function who work with gvalues Oct 09 18:49:52 what do you think? Oct 09 18:50:22 that would be much nicer yes Oct 09 18:50:40 ok, so next time you write a function, follow this code, I'll do the same. Oct 09 18:50:47 in the meanwhile Oct 09 18:50:52 I'm commiting the hack Oct 09 18:50:57 committing* Oct 09 18:54:40 we'll have to change internal existing stuff and naming at some point. Oct 09 18:54:57 at least let's try to isolate modules Oct 09 18:55:01 i.e contact show Oct 09 18:55:04 vs contact list Oct 09 18:55:08 TAsn: I would like to change phonegui_init Oct 09 18:55:17 from what and to what? Oct 09 18:55:30 it now gets argc, argv and exitcb Oct 09 18:55:40 and none of that we need Oct 09 18:55:50 but what I need instead is idle_callback Oct 09 18:58:00 then change it ;) Oct 09 18:58:08 ok :) Oct 09 18:58:31 mrmoku, btw, don't forget about the coding style!! Oct 09 18:58:34 nested ifs Oct 09 18:58:35 SHR: 03tom 07libframeworkd-phonegui-efl2 * r6cab9bab86fb 10/TODO: changed todo Oct 09 18:58:36 SHR: 03tom 07libframeworkd-phonegui-efl2 * rd8740b72943c 10/src/ (phonegui-contacts.c view/contact-show-view.c): added a workaround for the gvalue hell can't add contact from sms/phonelog issue Oct 09 18:58:38 always need brackets! Oct 09 18:58:44 s/need/get/ Oct 09 18:58:44 TAsn meant: always get brackets! Oct 09 18:59:03 TAsn: hmm... where did I forget that? Oct 09 18:59:33 contact-show-view.c:744 Oct 09 18:59:46 for instance. Oct 09 19:00:42 you mean Oct 09 19:00:43 data->path = g_value_get_string(tmp); Oct 09 19:00:43 else Oct 09 19:00:43 data->path = NULL; Oct 09 19:00:47 yes. Oct 09 19:01:00 that is not nested though? Oct 09 19:01:20 sure it is. Oct 09 19:01:28 or do you mean that if there is an if inside an if the inner if needs brackets too? Oct 09 19:01:45 * mrmoku likes that sentence :P Oct 09 19:01:49 mrmoku, yeah. Oct 09 19:01:51 TAsn: id, path, can you explain? Oct 09 19:01:58 dos1, atm you have Oct 09 19:02:01 dbus path Oct 09 19:02:13 for messages Oct 09 19:02:25 that ends with a number Oct 09 19:02:27 right? Oct 09 19:02:35 yup Oct 09 19:02:42 will forever be a number Oct 09 19:02:44 right? Oct 09 19:02:53 (we should always expect a number there) Oct 09 19:02:56 right? Oct 09 19:02:59 hmm Oct 09 19:03:17 if nothing changes dramaticaly in api, then yes :P Oct 09 19:03:17 mrmoku, then it's settled, we'll keep id as ints Oct 09 19:03:20 :) Oct 09 19:03:26 mrmoku, ^ Oct 09 19:03:38 and i won't change api dramatically Oct 09 19:04:02 hmm... and if I want to write an git message backend? ;) Oct 09 19:04:20 then? Oct 09 19:04:29 ID in dbus path = id in opimd cache, not in backend Oct 09 19:04:41 look at CSV-Contacts Oct 09 19:04:47 it doesn't have ids in backend :P Oct 09 19:04:47 dos1: I know :P Oct 09 19:04:51 just kidding Oct 09 19:04:59 git pim suite Oct 09 19:05:00 :D Oct 09 19:05:23 dos1: and the numbers are volatile... is there something not volatile to identify let's say a contact? Oct 09 19:06:48 * mrmoku goes downstairs to get a beer to give dos1 time to think about how to link two contacts :P ... Oct 09 19:17:44 mrmoku: yes, of course there is: the record index in central sqlite database (which replaces cache and is the only place to access, read from, modify, and create new contacts) Oct 09 19:19:45 DocScrutinizer: I thought that would be memory based? how to have that non volatile? Oct 09 19:22:09 err, sqlite? isn't it file-based by definition? ;-) Oct 09 19:22:41 TAsn: ^^^ ??? Oct 09 19:23:16 DocScrutinizer, no, it's actually not ;) Oct 09 19:23:20 you can load a special file Oct 09 19:23:21 called Oct 09 19:23:26 ":memory:" Oct 09 19:23:30 that resides on ram. Oct 09 19:23:54 I don't think copying to a central non volatile db is a good idea Oct 09 19:24:06 as I sometimes insert random sim cards (i.e not mine) Oct 09 19:24:21 and I definitely don't want those contacts on my device. Oct 09 19:25:16 so disable automatic syncing on sim-insertion Oct 09 19:26:06 but if you don't sync with sim, you just have your device sqlite db. Oct 09 19:26:15 but then you still have the contacts "on your device" but have no way to access them. Oct 09 19:26:46 DocScrutinizer, sure you do, you have a volatile path :) Oct 09 19:26:53 So maybe a better idea is to delete all the contacts tagged with the special sim's source-label Oct 09 19:27:05 mrmoku, what do you need non volatile contact ids anyawy? Oct 09 19:27:16 to link two of them? Oct 09 19:27:22 huh? Oct 09 19:27:27 oh, groups? Oct 09 19:27:29 what's the use of THAT? Oct 09 19:27:41 I might want to have a field wife in my contact that links to my wife :) Oct 09 19:27:52 mrmoku, i c. Oct 09 19:28:00 ayayay Oct 09 19:28:22 mrmoku goes nuts and asks for symlinks in contacts db Oct 09 19:28:30 DocScrutinizer, :) Oct 09 19:28:42 yup, not that I need it now... but we might want that someday Oct 09 19:28:50 so we should not design against it ;) Oct 09 19:29:03 mrmoku, I agree. Oct 09 19:29:08 I don't even see future uses for that. Oct 09 19:29:15 though we still don't want to design against that. Oct 09 19:29:27 :P Oct 09 19:29:31 in every decent db you have one unique primary key that doesn't change and mustn't be dupkey Oct 09 19:29:42 yup Oct 09 19:29:46 DocScrutinizer, you have that in each backend Oct 09 19:30:00 the problem is with multi backends. Oct 09 19:30:08 (actually not in each backend, only in sqlite) Oct 09 19:30:11 TAsn: I want to kill backends completely Oct 09 19:30:21 DocScrutinizer, I also suggested that. Oct 09 19:30:24 NO Oct 09 19:30:30 I hate this abstract idea ;) Oct 09 19:30:32 I like sqlite Oct 09 19:30:37 and the possibility to export Oct 09 19:30:38 and import. Oct 09 19:30:40 what about remote contacts? Oct 09 19:30:56 anyhow, I'm off. Oct 09 19:30:58 ciao. Oct 09 19:31:04 I might not want to sync my company's LDAP server ;) Oct 09 19:31:16 (not that my company would have such a beast...) Oct 09 19:31:29 * mrmoku back to mainloop hacking Oct 09 19:32:03 hmmm, actually a point for mrmoku Oct 09 19:32:10 :) Oct 09 19:32:39 but not yet set or game ;-D Oct 09 19:36:14 mrmoku: compare contacts in Kontact maybe. It's never a bad idea to learn from existing systems, even if we only learn how we don't want to do it Oct 09 19:36:34 hehe Oct 09 19:38:16 anyway a rarely known feature of Kontact is the "resources" management Oct 09 19:38:57 those resources are similar to our backends Oct 09 19:39:32 you can't create a resource out of every import source though Oct 09 19:41:09 actually for local resources you only have file and dir, but you can create a shitload of different remote resources Oct 09 19:42:29 nevertheless you can *import* and *export* to a lot of different *local* data-sources which you can NOT use as a resource Oct 09 19:42:56 e.g. cellphone ;-) Oct 09 19:43:28 or csv, vcard Oct 09 19:44:20 mrmoku: you guess there might be a reason why those data-types (vcard, CSV) are not allowed to become resources ;-) Oct 09 19:45:04 hmm Oct 09 19:45:34 mrmoku: and yes KABC (the contacts "framework" of Kontact) has a unique ID for each contact in resource Oct 09 19:45:38 but as you said there are lots of possible remote resources... or even multiple local resources of type file Oct 09 19:45:43 yup Oct 09 19:46:19 dos1, here Oct 09 19:46:20 ? Oct 09 19:46:32 btw maybe KABC is now (or once has been) called KAddressBook Oct 09 19:46:45 TAsn: i think yes Oct 09 19:47:02 it's Phone or Number? Oct 09 19:47:04 hi guys I just got my first shr-unstable build done. Now I really want to start programming what editor / IDE would you prefer? Oct 09 19:47:41 ok, phone Oct 09 19:47:42 nvm. Oct 09 19:47:43 :) Oct 09 19:48:29 SHR: 03tom 07libframeworkd-phonegui-efl2 * re5c3e21c6874 10/src/phonegui-contacts.c: fixed a typo, should have been phone, though it was number Oct 09 19:49:02 opimd-cli c query Phone tel:12345 Oct 09 19:49:07 dos1, makes sense, right? Oct 09 19:49:10 phild: gvim :) Oct 09 19:49:11 yup Oct 09 19:49:12 as it doesn't resolve :( Oct 09 19:49:33 give me contact which you want to resolve Oct 09 19:49:35 mrmoku: you don't use eclipse ? :-> Oct 09 19:49:39 hm.. but it did just resolve something else Oct 09 19:49:43 Ainulindale: :P Oct 09 19:49:44 only part of the numbers it doesn't. Oct 09 19:49:48 mrmoku: (ptitjes does) Oct 09 19:49:52 and maybe enable DEBUG in frameworkd.conf Oct 09 19:49:55 and check logs Oct 09 19:50:00 Ainulindale: I know... and at least I don't use nano ;) Oct 09 19:50:02 dos1, it seems that it doesn't resole names Oct 09 19:50:06 that are saved in the db Oct 09 19:50:07 mrmoku: I don't either for devel Oct 09 19:50:09 as non normalized numbers Oct 09 19:50:17 sec, verifying this claim. Oct 09 19:50:21 mrmoku: from times to times when I have to a simple thing I tend to use nano, not that often though Oct 09 19:50:26 s/to a/to do a/ Oct 09 19:50:27 Ainulindale meant: mrmoku: from times to times when I have to do a simple thing I tend to use nano, not that often though Oct 09 19:50:56 Ainulindale: I'm sooo used to vim that I refuse to use anything else ;) Oct 09 19:51:12 Well you're a weathered man :-) Oct 09 19:51:21 dos1, yeah. Oct 09 19:51:23 that's the issue... :| Oct 09 19:51:47 TAsn: check if python-phoneutils works for you correctly Oct 09 19:52:02 dos1, I just told you Oct 09 19:52:08 (I'm testing with opimd-utils) Oct 09 19:52:12 I just told you where it fails... Oct 09 19:52:20 opimd-utils-cli that is. Oct 09 19:52:27 i still don't have any clue ;x Oct 09 19:52:52 it means that when comparing Oct 09 19:52:54 you don't Oct 09 19:52:59 normalize the number in db... Oct 09 19:53:06 as you probably pass it with a tel: prefix Oct 09 19:53:12 or something stupid as that ;) Oct 09 19:53:12 so how it works here? :P Oct 09 19:53:24 dos1, you got non normalized numbers in db? Oct 09 19:53:34 i.e numbers with a + ? Oct 09 19:53:43 (saved) Oct 09 19:53:50 numbers are non normalized in database, yup Oct 09 19:53:55 but they are normalized when comparing Oct 09 19:53:56 mrmoku:thx, will try it out :) Oct 09 19:54:00 when Oct 09 19:54:01 hm... weird. Oct 09 19:54:02 not Oct 09 19:54:08 on loading to cache Oct 09 19:54:23 i c. Oct 09 19:54:24 as every cache entry has 4 "fields" Oct 09 19:54:35 name, value, comparition value, name of backend Oct 09 19:54:44 here it doesn't work. Oct 09 19:54:49 and value = "tel:+48 (0-61) 666" Oct 09 19:54:50 btw DocScrutinizer ^ I bet you hate him :) Oct 09 19:55:07 mrmoku, can you try to confirm my issue? Oct 09 19:55:11 and comp value is "+48061666" Oct 09 19:55:28 and that concept isn't mine Oct 09 19:55:31 TAsn: via opimd-cli? Oct 09 19:55:37 mrmoku, not only Oct 09 19:55:39 but having Oct 09 19:55:40 i just used existing design ;) Oct 09 19:55:45 non normalized numbers Oct 09 19:55:48 in db Oct 09 19:56:04 and trying to match non normalized numbers Oct 09 19:56:07 with opimd-cli Oct 09 19:56:08 ok, but querying via opimd-cli is enough Oct 09 19:56:09 ? Oct 09 19:56:11 ok Oct 09 19:56:25 yeah. Oct 09 19:56:48 here it works brilliantly with numbers that are saved normalized in db. (sim) Oct 09 19:57:37 * mrmoku is installing opimd-utils Oct 09 19:57:56 mrmoku, DONT Oct 09 19:58:01 don't install that devil Oct 09 19:58:03 just Oct 09 19:58:07 opimd-utils-cli Oct 09 19:58:07 :) Oct 09 19:58:08 too late ;) Oct 09 19:58:23 damn, I tried to save you from this awful notifier ;] Oct 09 19:58:28 anyhow Oct 09 19:58:29 notifier is awesome :P Oct 09 19:58:39 opimd-cli c query Phone tel:number Oct 09 19:59:45 mrmoku, well? Oct 09 19:59:59 yep, does not work Oct 09 20:00:07 dos1, YOU SUCK! Oct 09 20:00:18 dos1, how come you can't confirm that as well? Oct 09 20:01:05 anyhow, that's my issue. Oct 09 20:01:05 i'll check it Oct 09 20:01:05 again Oct 09 20:01:05 :P Oct 09 20:01:09 well, it worked Oct 09 20:01:11 i'm sure :P Oct 09 20:01:25 it also worked here at some point in history Oct 09 20:01:29 TAsn: without tel: it works Oct 09 20:01:34 really? Oct 09 20:01:37 yup Oct 09 20:01:39 wow, dos, you suck :) Oct 09 20:01:44 without tel: it does matching by string Oct 09 20:01:44 (j/k) Oct 09 20:01:49 so you don't want that :P Oct 09 20:01:59 ahh, ok Oct 09 20:02:05 then it does not work ;) Oct 09 20:02:11 AFAIR Oct 09 20:02:11 mrmoku, hehe :) Oct 09 20:02:22 dos1, well.. got a solution? :) Oct 09 20:02:25 i need to check some things in opimd, as i forgotten some Oct 09 20:02:49 dos1, just fix this, please :) Oct 09 20:02:53 this is quite a core feature Oct 09 20:02:57 (contact resolving) Oct 09 20:03:02 please conisder using Oct 09 20:03:05 phoneutil's Oct 09 20:03:07 compare_numbers Oct 09 20:03:14 instead of caching the normalized strings Oct 09 20:03:38 TAsn: why? Oct 09 20:03:52 TAsn: quering is slow now. i don't want it to be even slower :P Oct 09 20:03:55 :| Oct 09 20:04:08 you just need to move to sqlite for internal cache Oct 09 20:04:12 that's what's really important. Oct 09 20:04:23 TAsn: what is coding style for structs? bracket on its own line or on the struct line? Oct 09 20:04:23 dos1: when it's slow that definitively is your fault ;-) Oct 09 20:04:24 this way you'll have supersonic speed everywhere. Oct 09 20:04:24 "just" Oct 09 20:04:26 hahahah Oct 09 20:04:27 :P Oct 09 20:04:32 struct bla { Oct 09 20:04:38 ok Oct 09 20:05:18 dos1, it's probably not that hard. Oct 09 20:05:22 as you probably wrapped Oct 09 20:05:36 your cache access with functions Oct 09 20:05:38 haven't you? :) Oct 09 20:06:00 TAsn: that's not my cache Oct 09 20:06:04 it was already there Oct 09 20:06:06 :P Oct 09 20:06:13 waaah Oct 09 20:06:17 dos1, but, now for real. Oct 09 20:06:24 please move to sqlite. Oct 09 20:06:30 it's probably not *that* hard. Oct 09 20:06:36 it it'll solve 99% of your todo Oct 09 20:06:39 as it's faster Oct 09 20:06:41 more correct Oct 09 20:06:44 i won't. at least not soon. Oct 09 20:06:47 more flexible Oct 09 20:06:51 dos1, why not? Oct 09 20:07:34 i've got a really hard headache with that code when doing GenericDomain Oct 09 20:07:40 i still feel it ;p Oct 09 20:07:52 and that's really huge task Oct 09 20:07:55 TAsn: it's SQL, not Vala, C, or python Oct 09 20:08:14 and i agree, it should be done Oct 09 20:08:15 DocScrutinizer-8, what are you talking about? Oct 09 20:08:21 that's the whole reason Oct 09 20:08:34 for dos to be reluctant Oct 09 20:08:59 but it's too much for me alone, when having also school and doing that just as my hobby Oct 09 20:09:18 dos1, :| Oct 09 20:09:39 well... I can relate to that. Oct 09 20:09:41 but still Oct 09 20:09:48 think of how cool sqlite opimd can be :) Oct 09 20:10:08 dos1, anyhow, so at least, even if not moving to sqlite Oct 09 20:10:09 really, give me small team - 2 or 3 coders, or even just one addintional coder, and i'll be really happy with coordinating them Oct 09 20:10:12 try to figure out this bag ;) Oct 09 20:10:20 and i'll even do majority of work Oct 09 20:10:25 dos1, lol. :) Oct 09 20:10:38 but it's different to code alone and to code with someone Oct 09 20:10:49 different motivation, different coordination Oct 09 20:10:55 :P Oct 09 20:11:33 dos1, please post a blog post/mail in ML requesting for help... :) Oct 09 20:11:35 Ainulindale, lol. Oct 09 20:11:47 :DDDD Oct 09 20:11:52 well Oct 09 20:11:55 Ainulindale, you have great fooling instincts (coming at the right time) Oct 09 20:12:04 dos1, I'm not joking, this is a good idea. Oct 09 20:12:17 i would like to see even one female openmoko dev :P Oct 09 20:12:21 I know many people would really like helping out. Oct 09 20:12:30 TAsn: well kinda yeah :-) Oct 09 20:12:42 Ainulindale, :) Oct 09 20:12:46 anyhow, I'm really off Oct 09 20:12:47 ciao. Oct 09 20:13:10 i'm off whole day today Oct 09 20:13:19 i feel like i didn't wake up at all... Oct 09 20:13:56 probably that's matter of weather, as everyone today from my environment feels the same :P Oct 09 20:15:31 dos1, mind pointing me to the part of code where you normalize at loading? Oct 09 20:15:36 (caching) Oct 09 20:15:40 s/environment/surrounding/ Oct 09 20:15:40 dos1 meant: probably that's matter of weather, as everyone today from my surrounding feels the same :P Oct 09 20:15:46 I'm pretty sure the problem is there. Oct 09 20:15:54 mompl Oct 09 20:15:57 i'll look at it Oct 09 20:16:12 you probably Oct 09 20:16:22 no, nvm what I just said. Oct 09 20:16:27 (the you probably) Oct 09 20:17:44 TAsn: 138 in pimd_generic.py Oct 09 20:17:50 thanks. Oct 09 20:18:01 that's make_comp_value, for all types of fields (now implemented only tel: :P) Oct 09 20:18:19 TAsn: and 42 in helpers.py Oct 09 20:18:34 dos1, saw the things I can grep. Oct 09 20:18:43 dos1, but pimd Oct 09 20:18:47 sim* Oct 09 20:18:48 doesn't have Oct 09 20:18:49 tel: Oct 09 20:18:50 ... Oct 09 20:18:50 :| Oct 09 20:18:52 noob. Oct 09 20:18:59 really? Oct 09 20:19:09 or is that artifically added by opimd Oct 09 20:19:10 i don't think so Oct 09 20:19:14 I mean in the sim. Oct 09 20:19:17 as i have almost all contacts on sim Oct 09 20:19:24 and they are loaded with tel: Oct 09 20:19:26 :P Oct 09 20:19:36 so opimd artificially adds that Oct 09 20:19:37 right? Oct 09 20:20:39 I really smell cans of worms :-/ Oct 09 20:20:40 oh, just read the function Oct 09 20:20:41 ok. Oct 09 20:21:02 dos1, Oct 09 20:21:03 res = tel_value[4:] Oct 09 20:21:03 48 Oct 09 20:21:03 49 res = normalize_number(res) Oct 09 20:21:03 50 Oct 09 20:21:03 51 return 'tel:'+res Oct 09 20:21:12 you ass. Oct 09 20:21:17 I think this is the issue. Oct 09 20:21:29 removing the tell even if there is none... Oct 09 20:21:33 when loading from sim Oct 09 20:21:50 or is the tel artifically added in sim backend? Oct 09 20:22:17 TAsn: in sim backend Oct 09 20:22:22 i c. Oct 09 20:22:29 (another thing which was there before i started to work on it :P) Oct 09 20:22:36 and well, that code isn't perfect Oct 09 20:22:44 but i never claimed it is :P Oct 09 20:23:08 dos1, I can't see where in sim backend Oct 09 20:23:17 I can only see stripping on save Oct 09 20:23:25 (though I only did search for tel: Oct 09 20:23:31 this is abysmally wrong, from just the 5 lines i've seen Oct 09 20:23:51 look for phone_number_to_tel_uri Oct 09 20:24:11 phone_number_to_tel_uri(number Oct 09 20:24:13 yeah Oct 09 20:24:22 just saw it. Oct 09 20:24:24 DocScrutinizer, I agree. Oct 09 20:26:28 I don't even know where to start, maybe at "hardcoded strings in code", or at "hardcoded length of string", or at "mixing a label with a content", or... nah, really :-S Oct 09 20:28:56 dos1, opimd also writes to a log, right? Oct 09 20:29:00 so a print will show, rightL Oct 09 20:29:06 dos1: you should have refused to use any part of that code. That's how I get it right now. You better have had started from scratch Oct 09 20:29:27 DocScrutinizer-8: that one which TAsn posted is mine ;D Oct 09 20:30:02 it needs some URI parsing Oct 09 20:30:51 anyhow, dos1 I'll get a print in logs, right? is frameworkd's output logged? Oct 09 20:30:55 and also few other things Oct 09 20:31:01 dos1: to me it seems the structures were imposed to you Oct 09 20:31:10 from former code Oct 09 20:31:16 but well, that function will always get string starting with "tel:" Oct 09 20:31:33 and these structures were a quick hack obviously, stating with cache etc Oct 09 20:32:19 dos1: (tel:) even in russia, and in pakistan? Oct 09 20:32:30 DocScrutinizer-8: yes Oct 09 20:32:37 DocScrutinizer-8: it's URI Oct 09 20:32:40 ascii or utf-8? Oct 09 20:32:57 you're not getting different http: in different countries Oct 09 20:33:00 :P Oct 09 20:33:04 or ftp: Oct 09 20:33:06 or others Oct 09 20:33:11 where's the RFC purring that in concrete? Oct 09 20:33:18 there was some Oct 09 20:33:26 someone even posted in on maillist Oct 09 20:33:49 dos1, does the framework store output to logs or not?! Oct 09 20:33:55 (opimd output, i.e a print) Oct 09 20:34:05 or in other words, how can I write to it's log?) Oct 09 20:34:11 dos1: *if* that's the case, then this needs to be a global constant Oct 09 20:34:29 TAsn: "print" won't be stored to log Oct 09 20:34:35 but logger.info (or logger.debug) will Oct 09 20:34:40 thanks. Oct 09 20:35:42 DocScrutinizer-8: Oct 09 20:35:51 "If the content is a proper URI then we shouldn't have any trouble parsing it. Oct 09 20:35:52 tel: is the right way to start a phone number URI. See RFC3966. voip: is Oct 09 20:35:54 probably wrong, but sip: or h323: are well defined." Oct 09 20:35:55 part of mail from ml Oct 09 20:36:07 not mine Oct 09 20:36:29 * TAsn is going to check out RFC3966 Oct 09 20:36:51 http://tools.ietf.org/html/rfc3966 Oct 09 20:36:54 he's right. Oct 09 20:36:58 (tel) Oct 09 20:37:49 dos1: I know those RFC (as I maintain twinklephone for quite some years now), but you see h232: zhas more chars than tel: has. and string constants have to be defined centrally, not in situ Oct 09 20:38:12 DocScrutinizer-8: but that's helper function, which is only called when string starts with tel: Oct 09 20:39:29 aha, so you use this value at least at some other place where you compare if you have a string starting with "tel:" Oct 09 20:40:31 a string value that's used in several places has to be defined in a central place (almost I had said .h file ;-) Oct 09 20:40:43 freesmartphone.org: 03seba.dos1 07dos/opimd-tracking * r03d45469bc1c 10framework/framework/subsystems/opimd/helpers.py: opimd: helpers: little cosmetic fix Oct 09 20:40:48 DocScrutinizer-8: i agree Oct 09 20:41:05 and you never ever can use a hardcoded stringlemgth like (4:... Oct 09 20:41:19 i agree Oct 09 20:41:23 dos1, Oct 09 20:41:25 ;P Oct 09 20:41:25 just for you to know Oct 09 20:41:30 I added Oct 09 20:41:33 logger.info(res) Oct 09 20:41:42 into get_compare_for_tel Oct 09 20:41:45 either you define this as another constant, or you use length-of() Oct 09 20:41:51 nothing in logs when loading Oct 09 20:41:54 sim backend. Oct 09 20:41:54 hmm Oct 09 20:42:06 * TAsn smells a bug. Oct 09 20:42:07 i'll check that on neo, probably tomorrow Oct 09 20:42:26 yup, maybe when moving to GenericDomain something got broken Oct 09 20:43:20 dos1: the purpose of those conventions is you don't get lost on "wtf is this code meant to do" like tasn was 15min ago Oct 09 20:43:40 hehe Oct 09 20:43:59 i have to make some "opimd cleaning week" ;) Oct 09 20:44:03 dos1, I really don't think URI is the way to go. Oct 09 20:44:13 maybe having a set of names Oct 09 20:44:16 loaded by a config Oct 09 20:44:21 for each type is better. Oct 09 20:44:23 i.e Oct 09 20:44:25 you can set Oct 09 20:44:35 Phone, p, number and whatever to be of type phone number Oct 09 20:44:48 TAsn: that's what I meant with "evil structures heritage" Oct 09 20:44:48 void to be of type voip Oct 09 20:44:59 DocScrutinizer-8, do you agree with my alternative design? Oct 09 20:45:06 sounds more coherent. Oct 09 20:45:06 yup Oct 09 20:45:16 less confusing Oct 09 20:45:25 at least better than with this url approach Oct 09 20:45:32 DocScrutinizer-8, that's for sure. Oct 09 20:45:40 I was talking about absolute good though. Oct 09 20:46:15 dos1, usually in relational db, a column has to be from the same type Oct 09 20:46:26 so having uri in db for that Oct 09 20:46:30 is a bit weird. Oct 09 20:46:43 (almost like forcing a cast when reading) Oct 09 20:47:09 I really think a consistent set of types Oct 09 20:47:17 and maybe a way to define computed types Oct 09 20:47:21 let's say we define Oct 09 20:47:28 Name to be computed as Oct 09 20:47:42 cat: FirstName, LastName Nick Oct 09 20:48:00 that will make everything more clear and usable for the user of the API. Oct 09 20:48:12 dos1, DocScrutinizer-8, comment please. Oct 09 20:48:23 100% ack Oct 09 20:48:46 dos1, ? Oct 09 20:49:22 dos1, btw, don't feel bad about big changes, mrmoku and I are now almost (actually we do) write phonegui write scratch. Oct 09 20:49:35 s the last write Oct 09 20:49:36 with from Oct 09 20:49:37 :) Oct 09 20:49:39 * TAsn is tired. Oct 09 20:49:59 ok actually re read the whole sentence Oct 09 20:50:04 doesn't make sense :) Oct 09 20:50:21 hehe :D Oct 09 20:50:31 the content is clear Oct 09 20:50:32 i think i'll go to sleep now Oct 09 20:50:35 the syntax is not. :) Oct 09 20:50:42 dos1, okie ;) but wait. Oct 09 20:50:47 please comment on the fields idea. Oct 09 20:51:33 btw, this way you'll be able to do comparisons on computed types (on Name for instance when regexing for a name when searching) Oct 09 20:51:50 this will make the whole design a lot more simple Oct 09 20:51:53 and easier to read as well. Oct 09 20:52:17 and most of all easier for the API user (me) :) Oct 09 20:52:29 which is what I care about the most. Oct 09 20:52:41 anyhow, ciao. Oct 09 20:53:48 mrmoku, no index in adding contact to sms :( Oct 09 20:54:09 though doesn't work anyway, bah. ;| Oct 09 20:54:16 good night Oct 09 20:54:20 bah, I'm off. Oct 09 20:54:24 dos1, night. :) Oct 09 20:56:06 * mrmoku off too Oct 09 20:56:10 night all Oct 09 21:06:10 SHR: 03jesus 07shr-themes * r6ec764bcfcba 10/elementary/elementary-theme-neo/ (bubble_1.png bubble_2.png bubble_3.png bubble_4.png): fixed elm bubbles in nEo theme(elm) Oct 09 21:42:09 DocScrutinizer-8: if the backlight is off it makes sense to turn off glamo pixel clock which gives 30% more throughput for uSD in larsc's tests. Oct 09 21:42:38 sure Oct 09 21:44:01 but in the end it's not what this story is all about. Rather it's about whether theme-niemiee is maybe more powerhungry than a bright-white theme Oct 09 21:44:26 DocScrutinizer-8: sure, just fyi Oct 09 21:45:48 DocScrutinizer-8: otoh it's strange to see any considerable change in power consumption depending only on pixel state. Probably i'm not familiar with the technology enough to make reasonable assumptions, and your results just "feel" unnatural. Oct 09 21:47:54 well, imagine 16pixel-data lines pulling an input to low all the time, vs leaving it high on the pullup R. that's easily 2mA per line - just a speculative example Oct 09 21:48:29 It's just like an interference picture from a stream of electrons passed one-by-one to the grid. Oct 09 21:48:43 Feels counter-intuitive but can be proved true. Oct 09 21:51:16 actually most LCD technologies are normaly-transparent. So the LCM itself also will eat power just to switch (and keep) the liquid crystal to the "non-transparent" palorization state Oct 09 21:52:06 so this effect can have a number of reasons. And it's not really surprising in the end Oct 09 21:52:36 <[Rui]> yes, I got rid of the buttons on the left of bubbles in elmdentica! :) Oct 09 22:37:54 <[Rui]> is there a way to launch the sms app with some preloaded text message? Oct 09 23:43:51 ~log Oct 09 23:43:51 log is probably http://logs.nslu2-linux.org/livelogs/openmoko-cdevel/ for #openmoko-cdevel only. Maybe you meant "~logs" ? Oct 09 23:45:58 morphis: pong... **** ENDING LOGGING AT Sat Oct 10 02:59:56 2009