**** BEGIN LOGGING AT Mon Oct 13 02:59:57 2008
Oct 13 03:38:00 <CIA-57> freesmartphone.org: 03charlie 07framework * rfef3e43576da 10/framework/subsystems/oeventsd/fso_actions.py: oeventsd: Don't start the AudioAction in the RingToneAction if the volume is set to 0
Oct 13 04:05:54 <CIA-57> freesmartphone.org: 03charlie 07framework * rf24421e9ce9e 10/framework/subsystems/oeventsd/fso_actions.py: oeventsd: Access preferences service via DBus, instead of using direct python access
Oct 13 04:22:09 <CIA-57> freesmartphone.org: 03charlie 07framework * r8139b3c160f9 10/framework/subsystems/oeventsd/fso_actions.py: oeventsd: Added the 'SetProfile' Action
Oct 13 08:30:54 <Ainulindale> Damn connection
Oct 13 08:53:47 <CIA-57> freesmartphone.org: 03charlie 07framework * r43911cc45026 10/ (3 files in 2 dirs): 
Oct 13 08:53:47 <CIA-57> freesmartphone.org: oeventsd: Added a 'Test' Trigger
Oct 13 08:53:47 <CIA-57> freesmartphone.org: This is useful for testing the rules.
Oct 13 08:54:32 <CIA-57> freesmartphone.org: 03charlie 07framework * r1cf949bc11af 10/tools/cli-framework: cli-framework: Added events interface
Oct 13 08:57:07 <Ainulindale> charlie137 ? Aren't you sick of breaking oeventsd ? :p
Oct 13 09:01:44 <Ainulindale> hey MarcOChapeau :-)
Oct 13 09:02:48 <MarcOChapeau> Ainulindale: hey :-)
Oct 13 09:02:56 <MarcOChapeau> just got back from my holidays
Oct 13 09:03:15 <Ainulindale> how was it ? :-)
Oct 13 09:03:17 <Ainulindale> ready to code ?
Oct 13 09:04:11 <MarcOChapeau> Ainulindale: feels beter now :-)
Oct 13 09:05:02 <Ainulindale> MarcOChapeau: did you see my mail ?
Oct 13 09:05:18 <MarcOChapeau> Ainulindale: not yet. I have tons to read...
Oct 13 09:05:26 <MarcOChapeau> Ainulindale: I'll have a look
Oct 13 09:05:36 <Ainulindale> MarcOChapeau: SHR dialer (efl) is working
Oct 13 09:05:48 <Ainulindale> we have a dialer and daemon managing calls, contacts, messages and suspend
Oct 13 09:06:01 <Ainulindale> this week I'll do lock and manual suspend
Oct 13 09:06:16 <MarcOChapeau> Ainulindale: cool !
Oct 13 09:06:28 <Ainulindale> You can test the image as soon as you can
Oct 13 09:06:33 <Ainulindale> it's built on shr.bearstech.Com
Oct 13 10:19:18 <mickeyl> yo
Oct 13 10:23:28 <alphaone> hey mickeyl 
Oct 13 10:23:35 <mickeyl> heya!
Oct 13 10:23:50 <mickeyl> slept well? :)
Oct 13 10:24:34 <alphaone> mickeyl: Yeah
Oct 13 10:25:00 <alphaone> I even got a birthday cake yesterday :-)
Oct 13 10:25:10 <mickeyl> cool! we managed to stay awake until 19:00 but then we passed out :)
Oct 13 10:25:15 <alphaone> Hehe
Oct 13 10:25:33 <alphaone> I was awake until somewhere around midnight
Oct 13 10:25:45 <alphaone> But woke up at 8 already
Oct 13 10:26:17 <alphaone> mickeyl: Already posted the first two blogposts.
Oct 13 10:26:34 <quickdev> Hey
Oct 13 10:27:47 <quickdev> Ainulindale, what's up? ;)
Oct 13 10:27:55 <mickeyl> alphaone: wah, that's cool!
Oct 13 10:28:01 <mickeyl> alphaone: will write today as well
Oct 13 10:29:19 <quickdev> alphaone, should I create a ticket for message timestamps?
Oct 13 10:29:28 <alphaone> mickeyl: For the tutorial parts I have a GPS tutorial written covering the basics.
Oct 13 10:30:07 <alphaone> For the rest I think I wont go over every method or signal and explain it, but concentrate on some usecases and how you can accomplish them.
Oct 13 10:30:21 <mickeyl> alphaone: right, good plan. we have the reference for a reason.
Oct 13 10:30:22 <quickdev> what are you talking about? :) gypsy?
Oct 13 10:30:25 <alphaone> i.e. Notify me when I'm in the area
Oct 13 10:30:38 <alphaone> Or send a long SMS
Oct 13 10:30:39 <alphaone> ...
Oct 13 10:31:12 <alphaone> quickdev: more like how to use different subsystems
Oct 13 10:31:24 <quickdev> ah, ok :)
Oct 13 10:40:00 <alphaone> mickeyl: zhone seems to poll for unread messages, is that correct?
Oct 13 10:41:59 <mickeyl> correct
Oct 13 10:42:07 <mickeyl> because we had that problem with ACK 
Oct 13 10:42:18 <mickeyl> so sending didn't always work
Oct 13 10:42:22 <mickeyl> you remember?
Oct 13 10:42:30 <mickeyl> (or timeout)
Oct 13 10:42:33 <mickeyl> we need to revisit that
Oct 13 10:43:36 <alphaone> ah, right
Oct 13 10:43:41 <alphaone> so that's unsent, not unread
Oct 13 10:44:48 <mickeyl> oh right
Oct 13 10:44:54 <mickeyl> hmm
Oct 13 10:45:04 <mickeyl> need to increase COPS timeout
Oct 13 10:45:06 <mickeyl> 15 seconds does not cut it
Oct 13 10:46:13 <alphaone> okay
Oct 13 10:46:23 <alphaone> but not COPS=?
Oct 13 10:46:29 <alphaone> that's way longer already
Oct 13 10:46:58 <mickeyl> hmm
Oct 13 10:47:02 <mickeyl> should we unify it?
Oct 13 10:47:16 <mickeyl> might make sense. 80 seconds for both
Oct 13 10:47:20 <mickeyl> since also registering can take a long time
Oct 13 10:47:24 <mickeyl> especially when you're roaming
Oct 13 10:48:23 <quickdev> I encounter a modem wakeup interrupt if I'm in suspend for about 20 minutes...although there's no incoming call or sms. Why may this happen?
Oct 13 10:48:51 <mickeyl> quickdev: sounds like we did enable something that we do not shut down on suspend
Oct 13 10:48:56 <mickeyl> i can not think of anything
Oct 13 10:49:01 <mickeyl> but if you send me logs, i can look
Oct 13 10:49:20 <raster> quickdev: it could be some other gsm network info/data
Oct 13 10:49:22 <quickdev> mickeyl, which logs? kernel? frameworkd?
Oct 13 10:49:30 <mickeyl> quickdev: frameworkd is sufficient
Oct 13 10:49:46 <quickdev> ok
Oct 13 10:50:09 <quickdev> raster, is there a way to increase illume's keyboard height?
Oct 13 10:50:14 <raster> mickeyl:  are haralds ts filterign changes in oe git for fso yet?
Oct 13 10:50:27 <raster> quickdev: hmm thats determined by kbd files
Oct 13 10:50:34 <raster> ie keyboard is stretched to screen width
Oct 13 10:50:45 <alphaone> mickeyl: I'm not sure about merging these timeouts. In my experience COPS=? always took much longer than COPS
Oct 13 10:50:49 <raster> height is a result of kbd layout size scaled proprtionally
Oct 13 10:50:57 <raster> there is no config to have a separate kbd scaling factor
Oct 13 10:51:03 <alphaone> But I don't really care
Oct 13 10:51:22 <Ainulindale> quickdev: dialer is pretty buggy =)
Oct 13 10:51:45 <quickdev> Ainulindale, news about the trac?
Oct 13 10:52:11 <mickeyl> raster: no, but they're not necessary any more. 
Oct 13 10:52:11 <Ainulindale> quickdev: I'll ask
Oct 13 10:52:15 <Ainulindale> quickdev: and just so you know
Oct 13 10:52:16 <Ainulindale> ** (process:1685): DEBUG: w: 480, h: 604
Oct 13 10:52:17 <Ainulindale> Illegal instruction
Oct 13 10:52:19 <raster> mickeyl:  hmm why not?
Oct 13 10:52:28 <mickeyl> raster: see my mail on smartphones-standards
Oct 13 10:52:33 <raster> ok
Oct 13 10:52:55 <Ainulindale> quickdev: sometimes it doesn't do that, sometimes it does
Oct 13 10:53:01 <raster> mickeyl:  the quick bandaid?
Oct 13 10:53:02 <quickdev> raster, if I change the values, then the key buttons are smaller or higher, but not the height of the keyboard
Oct 13 10:53:04 <mickeyl> raster: yep
Oct 13 10:53:17 <mickeyl> raster: that should serve us until we use the Vala plugins
Oct 13 10:53:40 <raster> ok
Oct 13 10:53:41 <raster> cool
Oct 13 10:53:50 <raster> this means i might snarf fso back into the illume image...
Oct 13 10:53:53 <raster> or at least the back-end
Oct 13 10:53:56 <mickeyl> yeah
Oct 13 10:53:57 <raster> not too sure though
Oct 13 10:54:03 <raster> i like it beingt as tiny as it is...
Oct 13 10:54:05 <mickeyl> well
Oct 13 10:54:14 <mickeyl> think about it being a statement
Oct 13 10:54:19 <mickeyl> encouraging people to adopt fso 
Oct 13 10:54:28 <mickeyl> :)
Oct 13 10:54:30 <raster> also zohne starting up on boot - well i'd prefer it not do that for now as it is just a debug app
Oct 13 10:54:30 <raster> :)
Oct 13 10:54:34 <mickeyl> sure
Oct 13 10:54:35 <mickeyl> skip zhone
Oct 13 10:54:40 <raster> cool
Oct 13 10:54:45 <raster> i'll put the rest back in then
Oct 13 10:54:48 <raster> i just commented it out
Oct 13 10:54:50 <mickeyl> excellent
Oct 13 10:55:05 <mickeyl> talked w/ om for a lot recently
Oct 13 10:55:06 <raster> i'll do it tomorrow
Oct 13 10:55:20 <mickeyl> they will use upstream for unstable & testing
Oct 13 10:55:27 <raster> i've been busy getting OE on my treo650
Oct 13 10:55:36 <raster> and its working amazingly well...
Oct 13 10:55:36 <mickeyl> so we're going to do a fso-console and fso-illume
Oct 13 10:55:47 <mickeyl> fso-illume being more or less based on your work
Oct 13 10:55:48 <raster> in fact.. maybe better than freerunner in many ways
Oct 13 10:55:50 <raster> :)
Oct 13 10:55:54 <mickeyl> (treo) heh, amazing
Oct 13 10:55:55 <raster> aaha cool
Oct 13 10:56:08 <Ainulindale> mickeyl: hey there
Oct 13 10:56:09 <raster> i havent done much code/theme work recently
Oct 13 10:56:12 <raster> but i do it in spurts
Oct 13 10:56:14 <Ainulindale> Did you hear our image is mostly working ? :-)
Oct 13 10:56:24 <mickeyl> Ainulindale: heard it. had no time to actually try yet. congrats though!
Oct 13 10:56:47 <raster> and yes
Oct 13 10:56:49 <Ainulindale> mickeyl: in between we worked a lot on libframeworkd-glib which reflects now the subsystem architecture
Oct 13 10:56:51 <raster> treo650.. is interesting
Oct 13 10:56:59 <mickeyl> Ainulindale: yay.
Oct 13 10:56:59 <raster> despite only having 32m ram... it runs fine
Oct 13 10:57:06 <Ainulindale> mickeyl: only thing I was wondering about
Oct 13 10:57:08 <mickeyl> raster: / wX?
Oct 13 10:57:08 <raster> i'm a bit worried adding frameworkd etc. in...
Oct 13 10:57:10 <raster> but lets see
Oct 13 10:57:13 <raster> yup
Oct 13 10:57:16 <raster> with x, e, illume
Oct 13 10:57:16 <mickeyl> amazing
Oct 13 10:57:18 <raster> everything
Oct 13 10:57:20 <Ainulindale> Why are things such as events managed in frameworkd ?
Oct 13 10:57:27 <raster> http://www.rasterman.com/
Oct 13 10:57:32 <mickeyl> Ainulindale: which kind of events?
Oct 13 10:57:35 <raster> http://download.enlightenment.org/misc/Illume/Treo-650/2008-10-12/
Oct 13 10:57:38 <Ainulindale> I was wondering last night about incoming calls and so on
Oct 13 10:57:47 <raster> http://www.rasterman.com/files/illume-treo-650.avi
Oct 13 10:57:54 <Ainulindale> And I was trying to think about why you thought it was useful to define events for ringtone etc
Oct 13 10:58:00 <Ainulindale> And not for "display phone UI"
Oct 13 10:58:28 <mickeyl> Ainulindale: helper activation has not been covered yet, that's all
Oct 13 10:58:40 <Ainulindale> what do you mean by helper activation ?
Oct 13 10:58:47 <mickeyl> "run phone app"
Oct 13 10:58:56 <mickeyl> "run sms app"
Oct 13 10:58:57 <mickeyl> etc.
Oct 13 10:59:03 <Ainulindale> mickeyl: that wasn't the true meaning of my question :-)
Oct 13 10:59:08 <Ainulindale> Do you intend to d o that ?
Oct 13 10:59:30 <Ainulindale> I mean, is this the direction frameworkd will take in the future ?
Oct 13 10:59:42 <mickeyl> i don't know to be honest
Oct 13 10:59:47 <mickeyl> there's pros and cons for that
Oct 13 10:59:52 <raster> http://www.rasterman.com/files/illume-freerunner.avi
Oct 13 10:59:54 <raster> for comparison
Oct 13 10:59:55 <mickeyl> i tell you why i did define events though
Oct 13 11:00:00 <mickeyl> to support people doing console apps
Oct 13 11:00:03 <mickeyl> ncurses etc.
Oct 13 11:00:11 <Ainulindale> My point was I was trying to know why different types of events were treated using different methods
Oct 13 11:00:14 <mickeyl> without having to take care about ringing and sms notification tones
Oct 13 11:00:20 <quickdev> raster, "height is a result of kbd layout size scaled proprtionally", so if I change the first value of "kbd 130 45", the height is not increasing. Always the same.
Oct 13 11:00:26 <Ainulindale> mickeyl: I see, I see
Oct 13 11:00:35 <Ainulindale> It makes sense
Oct 13 11:00:40 <quickdev> raster, is there a way at all to change the height?
Oct 13 11:00:43 <mickeyl> Ainulindale: at the end of the day, my recommendation for a full phone app is:
Oct 13 11:00:43 <raster> quickdev:  thats width height
Oct 13 11:00:47 <mickeyl> Ainulindale: remove most of the rules
Oct 13 11:00:50 <raster> u'll have to adjust all keys too
Oct 13 11:00:52 <mickeyl> Ainulindale: and do the stuff in your app
Oct 13 11:00:54 <Ainulindale> Oh and did you see my mail about IdleNotifier ?
Oct 13 11:01:01 <mickeyl> Ainulindale: that's why we have it in the rules, not hardcoded
Oct 13 11:01:02 <Ainulindale> (and my hilight)
Oct 13 11:01:07 <raster> as they are given geometry within that region
Oct 13 11:01:19 <mickeyl> Ainulindale: sure, i see all mails. i have a slight backlog though :
Oct 13 11:01:19 <mickeyl> )
Oct 13 11:01:31 <Ainulindale> mickeyl: specs are wrong
Oct 13 11:01:37 <Ainulindale> mickeyl: for IdleNotifier
Oct 13 11:01:43 <raster> quickdev: if u make it 130 20
Oct 13 11:01:46 <raster> u'll see a big difference
Oct 13 11:01:47 <Ainulindale> GetState(s) and SetState() => s
Oct 13 11:01:51 <Ainulindale> Which should be the other way around
Oct 13 11:01:54 <raster> but i'tl need a full kdb restart
Oct 13 11:02:01 <mickeyl> Ainulindale: ouch. thanks. will fix later today
Oct 13 11:02:10 <mickeyl> will also recheck the logic while I'm there
Oct 13 11:02:12 <quickdev> raster, I'll try it. Thanks!
Oct 13 11:02:14 <Ainulindale> mickeyl: and about the fact that frameworkd triggers SUSPEND while on call ?
Oct 13 11:02:21 <Ainulindale> And the AWAKE signal before LOCK ?
Oct 13 11:02:34 <Ainulindale> (for the first one we talked about that some time ago)
Oct 13 11:02:35 <mickeyl> Ainulindale: first thing is because we don't have CPU resource yet
Oct 13 11:02:40 <mickeyl> which will come soon
Oct 13 11:02:45 <mickeyl> second think is strange.
Oct 13 11:02:47 <Ainulindale> But you have GSM resource
Oct 13 11:02:48 <mickeyl> need to check that
Oct 13 11:02:54 <Ainulindale> Which mean you can know there's a call going on
Oct 13 11:02:57 <Ainulindale> +s
Oct 13 11:03:11 <mickeyl> well, aquiring CPU resource means "do not fall into suspend"
Oct 13 11:03:12 <Ainulindale> (Or am I mistaken ?)
Oct 13 11:03:19 <mickeyl> aquiring GSM resource does not mean that
Oct 13 11:03:25 <mickeyl> since it may as well be idle
Oct 13 11:03:30 <mickeyl> and then you can fall into suspend
Oct 13 11:03:35 <Ainulindale> Oh I see
Oct 13 11:03:36 <mickeyl> technically you can even do phone calls in suspend
Oct 13 11:03:36 <mickeyl> :)
Oct 13 11:03:41 <Ainulindale> Ok, I didn't thought it was that way
Oct 13 11:03:49 <Ainulindale> mickeyl: we talked about that and I disagreed
Oct 13 11:04:00 <Ainulindale> (For "hang up", "speaker out", etc...)
Oct 13 11:04:17 <Ainulindale> (If device is suspended, you can't hang up while on call, you have to unsuspend the device first)
Oct 13 11:04:19 <mickeyl> yeah
Oct 13 11:04:23 <mickeyl> that's right
Oct 13 11:04:33 <raster> device shoudl never suspend during a call
Oct 13 11:04:34 <Ainulindale> And anyway it's not working right now :-)
Oct 13 11:04:56 <mickeyl> raster: that depends on what chips you have in the phone
Oct 13 11:04:56 <Ainulindale> mickeyl: right now we can work around that in SHR because I can prevent suspend if there's an active call
Oct 13 11:05:08 <Ainulindale> But I don't think this is a good idea to put it there
Oct 13 11:05:12 <mickeyl> Ainulindale: agreed
Oct 13 11:05:24 <mickeyl> Ainulindale: i'd rather have a rule in the rules file
Oct 13 11:05:28 <Ainulindale> Seems to me it should be in frameworkd, seems you think that way too
Oct 13 11:05:29 <mickeyl> that requests CPU while in call
Oct 13 11:05:32 <mickeyl> *nod*
Oct 13 11:05:42 <mickeyl> so if you don't want that people can rip it out
Oct 13 11:05:43 <Ainulindale> Ok great then :-)
Oct 13 11:05:43 <raster> mickeyl: phones shouldnt suspend.. they should go into low-power standby modes :)
Oct 13 11:05:55 <mickeyl> Ainulindale: agreed. will take care of that 
Oct 13 11:06:02 <mickeyl> raster: true in an ideal system
Oct 13 11:06:16 <raster> (and have tickless kernels)
Oct 13 11:06:20 <Ainulindale> quickdev ?
Oct 13 11:06:20 <mickeyl> yap
Oct 13 11:07:29 <Ainulindale> mickeyl: anyway, even if it's buggy dialer is mostly working, but I'm waiting eagerly for PIM
Oct 13 11:07:32 <Ainulindale> any news about PIM ?
Oct 13 11:09:36 <quickdev> Ainulindale ?
Oct 13 11:09:52 <mickeyl> Ainulindale: yes, there's news
Oct 13 11:10:10 <mickeyl> charlie137 has been assigned to integrate the first GSoC PIM results into the framework until end of this month
Oct 13 11:10:17 <Ainulindale> quickdev: did you see my mails ?
Oct 13 11:10:19 <mickeyl> i'm going to do a largish blog post today
Oct 13 11:10:23 <mickeyl> that'll explain some more things
Oct 13 11:10:31 <quickdev> Ainulindale, on the mailing list, yes
Oct 13 11:10:34 <Ainulindale> mickeyl: if he integrates as well as oeventsd I'm expecting a lot of broken things then :-p
Oct 13 11:10:38 <charlie137> mickeyl: yep
Oct 13 11:10:49 <charlie137> Ainulindale: :(
Oct 13 11:10:52 <Ainulindale> charlie137: bad boy ! :-)
Oct 13 11:10:55 <mickeyl> heh, don't worry
Oct 13 11:10:58 <Tm_T> hi mickeyl and kids
Oct 13 11:10:59 <mickeyl> sometimes things have to be broken
Oct 13 11:11:03 <charlie137> oeventsd is totally different from what it uses to be
Oct 13 11:11:04 <Ainulindale> Because of you I didn't have sound for a week :-p
Oct 13 11:11:10 <Ainulindale> charlie137: I know, I'm joking ;-)
Oct 13 11:11:11 <mickeyl> Tm_T: yo
Oct 13 11:12:27 <alphaone> charlie137: Sorry if my commit sounded annoyed.
Oct 13 11:12:44 <Ainulindale> charlie137: in any case, I'm interested in speeding up things on the PIM side if I can be of help
Oct 13 11:12:53 <charlie137> Ainulindale: ok
Oct 13 11:12:56 <mickeyl> i try to get hold of abraxa
Oct 13 11:12:58 <Ainulindale> That's the second most important thing to me after basic telephony
Oct 13 11:13:00 <alphaone> But I spent more than two days trying to get to the ground of this (with mickey assuring me that "everything worked" for him)
Oct 13 11:13:01 <mickeyl> will write him an email
Oct 13 11:13:09 <mickeyl> alphaone: *cough* ;)
Oct 13 11:13:18 * mickeyl mumbles about nfs
Oct 13 11:13:21 <charlie137> I already tried it on my desktop using text files backends
Oct 13 11:13:23 <alphaone> And in the end it was because you both are using NFS mounts to test stuff
Oct 13 11:13:36 <Ainulindale> charlie137: what do you plan to implement exactly ?
Oct 13 11:13:46 <Ainulindale> Just basic storage or things such as fuzzy contact matching ?
Oct 13 11:13:57 <Ainulindale> Reconciliation PIM/SIM N?
Oct 13 11:14:15 <charlie137> Ainulindale: for PIM, I am using the code from Soeren Apel
Oct 13 11:14:30 <charlie137> it has fuzzy matching
Oct 13 11:14:39 <Ainulindale> That was just an example
Oct 13 11:14:47 <Ainulindale> I was trying to get a good idea of what kind of things will be available
Oct 13 11:14:50 <alphaone> mickeyl: Yeah, which just proves we badly need testing
Oct 13 11:14:58 <Ainulindale> oh quickdev I had an idea by the way about contacts
Oct 13 11:15:08 <quickdev> tell me :)
Oct 13 11:15:09 <mickeyl> alphaone: true
Oct 13 11:15:13 <Ainulindale> quickdev: could you put on top of the contacts list a "wheel" of letters ?
Oct 13 11:15:26 <quickdev> Ainulindale, mh?
Oct 13 11:15:29 <Ainulindale> quickdev: meaning a kind of slider A-Z to easily find contacts ?
Oct 13 11:15:48 <Ainulindale> Because if I want to call someone called "Zeta" it's kind of painful with your contact application
Oct 13 11:15:51 <quickdev> Ainulindale, I get you, of course :)
Oct 13 11:16:02 <Ainulindale> quickdev: I thought it should be easy to implement
Oct 13 11:16:07 <quickdev> yes, it should
Oct 13 11:16:07 <Ainulindale> quickdev: is it ?
Oct 13 11:16:10 <Ainulindale> Ok :-)
Oct 13 11:17:06 <quickdev> Ainulindale, first thing we need now is a trac :)
Oct 13 11:17:07 <Ainulindale> And how far is the implementation of audio scenario pushing/popping in frameworkd ? ( mickeyl, charlie137)
Oct 13 11:17:17 <Ainulindale> I was thinking about a "Speaker out" button in our dialer
Oct 13 11:17:36 <quickdev> raster, how do I trigger illumes screen lock?
Oct 13 11:17:46 <Ainulindale> quickdev: currenty it's coming
Oct 13 11:17:52 <charlie137> alphaone: sorry what commit are you referring to ?
Oct 13 11:17:52 <raster> quickdev: ummm aux
Oct 13 11:17:54 <quickdev> perfect :)
Oct 13 11:18:08 <raster> well thats the key its bound to
Oct 13 11:18:21 <raster> but on FSO the xserver doesnt see power ot aux as keys
Oct 13 11:18:24 <raster> i have yet to check why
Oct 13 11:18:28 <raster> so all of that is broken'
Oct 13 11:18:28 <alphaone> charlie137: 0f631a3dfa374726c31f72761d63bd76592e07a0
Oct 13 11:18:31 <CIA-57> freesmartphone.org: 03mickey 07framework * r2fbdad682f88 10/framework/subsystems/ogsmd/gsm/const.py: ogsmd: increase valid modem timeout for COPS to 30 seconds
Oct 13 11:18:57 <mickeyl> raster: ya that's strange
Oct 13 11:19:02 <Ainulindale> raster: by the way regarding the lock function
Oct 13 11:19:03 <mickeyl> input devices can be opened concurrently
Oct 13 11:19:07 <Ainulindale> And my question related to that yesterday
Oct 13 11:19:11 <raster> mickeyl: i'm sure its just some missing patch for x
Oct 13 11:19:16 <raster> just need to look into it
Oct 13 11:19:19 <mickeyl> raster: cool
Oct 13 11:19:26 <Ainulindale> My point was : I want to lock the full WM, not do a zhone-like locking
Oct 13 11:19:39 <Ainulindale> And I want to be able to trigger it 
Oct 13 11:19:39 <mickeyl> Ainulindale, raster: we have a bug wrt. that in trac
Oct 13 11:19:49 <raster> Ainulindale: how much about x do u know?
Oct 13 11:19:51 <Ainulindale> mickeyl: regarding what ? locks ?
Oct 13 11:19:55 <mickeyl> Ainulindale: yah
Oct 13 11:19:56 <Ainulindale> raster: Not a single little thing
Oct 13 11:20:00 <raster> aha!
Oct 13 11:20:01 <Ainulindale> raster: Hence my questions :-)
Oct 13 11:20:02 <mickeyl> i'd love to be able to tell illume to lock
Oct 13 11:20:06 <mickeyl> (see bug report)
Oct 13 11:20:07 <raster> there's our first problem :)
Oct 13 11:20:12 <mickeyl> bbiab
Oct 13 11:20:14 <mickeyl> coffee
Oct 13 11:20:19 <Ainulindale> raster: I fly whenever I hear about UIs 
Oct 13 11:20:26 <Ainulindale> s/fly/flee/
Oct 13 11:20:31 <raster> heheheh
Oct 13 11:20:44 <Ainulindale> raster: I have the taste of an oyster when it comes to UIs
Oct 13 11:20:56 <raster> mickeyl:  i m currently dubious on the "i want to request a lock now" from an arbitrayr client app usage scenario
Oct 13 11:21:05 <raster> basically u can always convince me with good usage scenarios
Oct 13 11:21:13 <raster> right now i'm not convinced :)
Oct 13 11:21:22 <Ainulindale> raster: take the following
Oct 13 11:21:27 <raster> Ainulindale:  same with you. usage secnario
Oct 13 11:21:27 <Ainulindale> I hang up from a call
Oct 13 11:21:40 <Ainulindale> I put my phone in my pocket
Oct 13 11:21:49 <Ainulindale> If frameworkd detects no activity it will eventually send a LOCK signal
Oct 13 11:21:56 <Ainulindale> there's no way for illume as is to know it has to lock
Oct 13 11:22:04 <Ainulindale> (regarding framewordk functionnalities)
Oct 13 11:22:07 <Ainulindale> but frameworkd does
Oct 13 11:22:12 <Ainulindale> So if it sends a LOCK signal
Oct 13 11:22:19 <Ainulindale> I want to be able to lock the full window manager
Oct 13 11:22:20 <raster> illume currently does do that
Oct 13 11:22:27 <raster> thats how it tries to suspend
Oct 13 11:22:27 <Ainulindale> Listens to frameworkd ?
Oct 13 11:22:31 <raster> it knows abotu screen idle
Oct 13 11:22:36 <raster> no it doesnt
Oct 13 11:22:44 <Ainulindale> I'm not talking about screen idle but frameworkd idle
Oct 13 11:22:46 <raster> but eventually i will get to making it do so
Oct 13 11:22:54 <raster> it already listens for gsm signal changes for the gadget
Oct 13 11:22:59 <raster> (gsm gadget)
Oct 13 11:23:15 <raster> frameworkd idle != screenlock
Oct 13 11:23:17 <raster> thats my point
Oct 13 11:23:28 <raster> a screenlock is either explicitly requested by a user
Oct 13 11:23:30 <raster> OR
Oct 13 11:23:36 <Ainulindale> I see that's your point, unfortunately my point is otherwise ;-)
Oct 13 11:23:38 <raster> its automatic after some timeout of idleness
Oct 13 11:23:48 <Ainulindale> raster: agree with you on that
Oct 13 11:24:02 <raster> OR its a state you were in and temporatily came out of and want to go back into when you deal with the temporary thing
Oct 13 11:24:04 <Ainulindale> Only thing, I think the only thing able to have a full awareness of the system is currently frameworkd
Oct 13 11:24:19 <Ainulindale> You could be idle in GSM but active in GPS
Oct 13 11:24:20 <Ainulindale> or DATA
Oct 13 11:24:28 <raster> yes
Oct 13 11:24:34 <raster> but lock is not relevant to that
Oct 13 11:24:44 <raster> lock covers user input (the screen and inptu devices)
Oct 13 11:24:58 <Ainulindale> That's why my thought was : power management is not relevant in the WM, nor is lock (apart from user triggered lock)
Oct 13 11:25:00 <raster> whatever gps is doing in the backgorund is not relevant
Oct 13 11:25:11 <Ainulindale> raster: I was extending my point to the suspend thing
Oct 13 11:25:28 <raster> the wm will be listening for some sort of "ui is idle - let's lock" info
Oct 13 11:25:29 <alphaone> raster: It also covers output, no? Like watching a movie
Oct 13 11:25:32 <raster> right now it already does that
Oct 13 11:25:36 <raster> xscreensaver events
Oct 13 11:25:41 <raster> alphaone:  correct
Oct 13 11:26:00 <Ainulindale> raster: my problem with that is that frameworkd handles level of idleness
Oct 13 11:26:04 <raster> alphaone: though any media player shoudl sue the xscreensaver extension to temporarily disable any screenblank/dim while watching
Oct 13 11:26:11 <raster> all that already exists in the screensaver extn
Oct 13 11:26:13 <Ainulindale> e.g. BUSY, IDLE, IDLE_DIM, LOCK
Oct 13 11:26:13 <raster> if the client segv's
Oct 13 11:26:15 <raster> or exits
Oct 13 11:26:22 <raster> its "hold" on screewnsaver is removed
Oct 13 11:26:32 <Ainulindale> If an application wants to trigger the "LOCK" state, it can do that through frameworkd
Oct 13 11:26:33 <raster> imhol right now dimming/blanmign in frameworkd is wrong
Oct 13 11:26:37 <Ainulindale> but it won't be doing a thing right now
Oct 13 11:26:40 <alphaone> raster: So all the GUI applications that don't want lock should use the xscreensaver extension?
Oct 13 11:26:42 <raster> it will compete with x and existing systems used on the desktop 
Oct 13 11:26:46 <raster> and in existign media players
Oct 13 11:26:55 <raster> (mplayer, xine etc. already use this extension etc.)
Oct 13 11:27:01 <raster> alphaone:  yup
Oct 13 11:27:03 <raster> exactly
Oct 13 11:27:24 <alphaone> raster: So how can we achieve staged blanking/dimming in x?
Oct 13 11:27:28 <raster> Ainulindale:  my question is.. WHY would an app want to trigger a lock?
Oct 13 11:27:52 <raster> alphaone: thats currently a problem with x
Oct 13 11:28:05 <Ainulindale> raster: let's say you have a password protected lock and you try to access protected data, and fail to do that
Oct 13 11:28:12 <Ainulindale> I would want to trigger the lock on three failures
Oct 13 11:28:19 <raster> http://gitweb.freedesktop.org/?p=xorg/app/xbacklight.git
Oct 13 11:28:22 <raster> is the solution
Oct 13 11:28:22 <Ainulindale> (it's the first thing out of my head)
Oct 13 11:28:30 <raster> along with proper x driver support
Oct 13 11:28:46 <raster> http://packages.ubuntu.com/gutsy/x11/xbacklight
Oct 13 11:28:48 <raster> in ubuntu
Oct 13 11:28:49 <raster> etc.,
Oct 13 11:28:53 <raster> dont work around x
Oct 13 11:28:56 <raster> work through it
Oct 13 11:29:30 <Ainulindale> I agree with you on that part, my personal problem is that I won't be able to work with X, I'm just trying to figure out what we should do on the SHR side to integrate with that kind of stuff :-)
Oct 13 11:29:51 <raster> Ainulindale: zeems a bit of a straneg use case
Oct 13 11:30:12 <Ainulindale> raster: it is one nonetheless :-p
Oct 13 11:30:13 <raster> (the enter ps wrong 3 times then lock whole device/screen suddenly)
Oct 13 11:30:14 <raster> btw
Oct 13 11:30:19 <raster> u dont need the wm to do that
Oct 13 11:30:23 <raster> you can do that direct from that process
Oct 13 11:30:31 <raster> no need for the wm.
Oct 13 11:30:32 <raster> grab kbd
Oct 13 11:30:32 <Ainulindale> Meaning ?
Oct 13 11:30:34 <raster> grab mouse
Oct 13 11:30:40 <Ainulindale> raster: ah you already told me that yes
Oct 13 11:30:40 <raster> pop up override-redirect window
Oct 13 11:30:41 <raster> done
Oct 13 11:30:44 <raster> u "take over the screen":
Oct 13 11:30:52 <raster> any x client can do it
Oct 13 11:30:54 <Ainulindale> My point was not to reimplement what's already implemented
Oct 13 11:31:07 <Ainulindale> If there's a nice locking screen in illume, why shouldn't I use it
Oct 13 11:31:12 <Ainulindale> (that was my point)
Oct 13 11:31:15 <raster> sure
Oct 13 11:31:35 <Ainulindale> Anyway, as I won't be the one to do the actual implementation, I'm just merely trying to find ideas :-)
Oct 13 11:31:40 <raster> i still see it aa very surpious use case
Oct 13 11:31:49 <raster> i can make it possible
Oct 13 11:31:50 <Ainulindale> That's because you're spurious yourself :-p
Oct 13 11:31:52 <raster> but i wont expose via dbus
Oct 13 11:31:55 <raster> i'd expose via x properites
Oct 13 11:32:01 <raster> or messages
Oct 13 11:32:03 <Ainulindale> I don't care about dbus raster :-)
Oct 13 11:32:04 <raster> as this is an x thing
Oct 13 11:32:09 <Ainulindale> If you give me a primitive to do that, in any way
Oct 13 11:32:11 <Ainulindale> I will use it
Oct 13 11:32:13 <raster> but.. it'd be on the very bottom of a todo list
Oct 13 11:32:14 <raster> :)
Oct 13 11:32:19 <raster> not a high priority
Oct 13 11:32:23 <alphaone> raster: And how can we tell X that it should ignore some input events for unblanking the screen?
Oct 13 11:32:27 <Ainulindale> My point was just to have the ability to do that
Oct 13 11:32:35 <raster> alphaone: that doesnt exist right now
Oct 13 11:32:49 <alphaone> i.e. if you want to be in pseudo suspend but keep your phone in your pocket
Oct 13 11:32:53 <raster> alphaone: BUT - x should be extended to be able to do that
Oct 13 11:32:54 <Ainulindale> raster: oh by the way I watched your video yesterday
Oct 13 11:32:58 <quickdev> Ainulindale, what was the dialer problem?
Oct 13 11:33:08 <charlie137> alphaone: sorry for forgetting to add the files in setup.py, I'll be more careful in the future
Oct 13 11:33:25 <Ainulindale> raster: what seems weird to me is : why does it seems really fast on your device and the fso ying/yang loading screen seems... well... slow at times ?
Oct 13 11:33:42 <Ainulindale> quickdev: illegal instruction on updates triggered by a button pushed on the dialpad
Oct 13 11:33:52 <alphaone> raster: Yeah, I agree that it should be in X, but what do we do now?
Oct 13 11:33:53 <raster> Ainulindale: i am not busy running a mountain of python apps on startup
Oct 13 11:33:59 <raster> its just launching e
Oct 13 11:34:09 <Ainulindale> raster: Watch your mouth :-p
Oct 13 11:34:40 <Ainulindale> But true, frameworkd should be nice'd on a lower priority just to see what is the result on e
Oct 13 11:34:56 <raster> alphaone: live with the lack of a feature
Oct 13 11:35:05 <raster> on screen blank suspend asap to coverit up
Oct 13 11:35:07 <raster> or
Oct 13 11:35:10 <alphaone> charlie137: No problem. As I said, I was just really annoyed because I was looking for the problem in my OE setup all the time.
Oct 13 11:35:14 <raster> add a kernel control to the ts device
Oct 13 11:35:16 <raster> or to tslib
Oct 13 11:35:23 <raster> to allow it to stop reporting ts eventsd
Oct 13 11:35:29 <alphaone> raster: One usecase: I want to use my phone as a GPS logger
Oct 13 11:35:36 <alphaone> For that suspend is not an option
Oct 13 11:35:49 <alphaone> And I don't want to burn battery while not in suspend
Oct 13 11:35:52 <raster> setting backlight to 0 is almsot as good as full blank
Oct 13 11:35:54 <charlie137> alphaone: yeah I can imagine it is quit tricky to track, I will add some more debug info in case of missing files
Oct 13 11:38:07 <alphaone> charlie137: That would be goog
Oct 13 11:38:10 <alphaone> good even
Oct 13 11:38:21 <alphaone> raster: Hmm
Oct 13 11:38:32 <raster> the actual backlight itself burns most of the power
Oct 13 11:38:34 <raster> sure
Oct 13 11:38:49 <raster> full blank (with lcd out off and glamo put into self-refresh" is better
Oct 13 11:38:58 <raster> if x driver was smart
Oct 13 11:39:55 <raster> if backlight brightness == 0 then it should issue the fb blanking ioctl
Oct 13 11:40:04 <raster> as a brighness of 0 == "no output" anyway
Oct 13 11:40:07 <raster> or should be
Oct 13 11:41:06 <raster> you go via the "right path" at least
Oct 13 11:41:16 <raster> and then its only a matter of all the right steps on that path being done
Oct 13 11:41:29 <raster> as such you will NEVER be able to get as good power saving outside of x as through
Oct 13 11:41:36 <CIA-57> freesmartphone.org: 03charlie 07framework * r484793b83301 10/framework/subsystems/oeventsd/ (oevents.py parser.py): oeventsd: Added 'AddRule' dbus method for dynamic creation of new rules
Oct 13 11:41:40 <raster> as you can never shut down the glamo's lcd out scan
Oct 13 11:41:47 <raster> that will still happen as the pixelclock keeps going
Oct 13 11:41:52 <raster> even tho u turned the backlight off
Oct 13 11:42:23 <alphaone> raster: No, there's a difference if you have transflective displayw
Oct 13 11:42:41 <raster> Ainulindale: as such i was thinkign that maybe frameworkd should be brought up in the background separately?
Oct 13 11:42:43 <alphaone> But we don't even have the backlight extension in xglamo, do we?
Oct 13 11:43:01 <raster> alphaone:  *IF* u have one
Oct 13 11:43:08 <raster> but then just set brightness to 1
Oct 13 11:43:10 <raster> ie almost off
Oct 13 11:43:16 <raster> as good as power-wise
Oct 13 11:43:36 <raster> and no xglamo/kdrive dont suprpo the BACKLIGHT xrandr property
Oct 13 11:43:40 <raster> that would need to be added
Oct 13 11:43:45 <raster> get the xblacklight source to see what iuts using
Oct 13 11:43:51 <raster> (its using output properties)
Oct 13 11:44:02 <raster> you could extend output properties withotu extending x protocol
Oct 13 11:44:12 <raster> as long as the driver knows about it in xrandr
Oct 13 11:44:22 <alphaone> okay
Oct 13 11:44:23 <raster> and your client-side code knows what property to fiddle with
Oct 13 11:44:28 <quickdev> Ainulindale, could we configure it somehow to not suspend if there's a usb connection?
Oct 13 11:44:36 <raster> you dont need to do any tricky x protocol extensions
Oct 13 11:48:00 <Ainulindale> quickdev: I suppose we could
Oct 13 11:48:29 <quickdev> Ainulindale, it's quite annoying when suspend is triggered although there's a usb connection
Oct 13 11:48:48 <Ainulindale> raster: I agree with you, there's an initscript for that anyway
Oct 13 11:49:02 <Ainulindale> quickdev: you wished suspend, now you have it and you complain ! :-)
Oct 13 11:50:59 <Ainulindale> quickdev: we can know if we're on battery or not
Oct 13 11:51:01 <Ainulindale> so we can do that
Oct 13 11:51:11 <quickdev> yeah, fine
Oct 13 11:52:10 <Ainulindale> mickeyl: I found the PowerControl interface quite funny
Oct 13 11:52:27 <Ainulindale> "GetPower() => b" : b = on if device is powered on
Oct 13 11:52:45 <Ainulindale> and off is somehow you managed to use frameworkd with your device powered off ?
Oct 13 11:52:55 <quickdev> hrr :)
Oct 13 11:53:57 <Ainulindale> mickeyl: anyway, would you be so kind as to tell me if there's any way to be sure I'm using an external alimentation with frameworkd ?
Oct 13 11:55:15 <Ainulindale> quickdev: accounts are currently created for trac
Oct 13 11:56:28 <quickdev> Ainulindale, should the usb thingy be handled in ophonekitd of frameworkd? Should frameworkd not send the SUSPEND state if there's an alimentation?
Oct 13 11:56:34 <quickdev> Ainulindale, fine.
Oct 13 11:57:03 <Ainulindale> quickdev: My opinion is that shouldn't be handled in frameworkd
Oct 13 11:58:11 <mickeyl> Ainulindale: PowerControl -- where's that?
Oct 13 11:58:24 <mickeyl> external alimentation?
Oct 13 11:58:28 <mickeyl> you mean... battery power?
Oct 13 11:58:51 <mickeyl> you will receive signals, if you're on external power
Oct 13 11:59:30 <mickeyl> we use the power LED for showing power status
Oct 13 11:59:35 <mickeyl> red = charging
Oct 13 11:59:37 <mickeyl> blue = power full
Oct 13 11:59:40 <mickeyl> blank = discharging
Oct 13 11:59:45 <mickeyl> we do that in the rules file
Oct 13 11:59:55 <mickeyl> depending on the PowerStatus signal
Oct 13 12:00:06 <Ainulindale> There's something on the documentation which I find weird
Oct 13 12:00:29 <Ainulindale> "A wall power supply will always return "full"."
Oct 13 12:00:38 <mickeyl> yeah
Oct 13 12:00:42 <mickeyl> run frameworkd on a laptop
Oct 13 12:00:49 <mickeyl> you have two power supplies
Oct 13 12:00:52 <mickeyl> one is battery
Oct 13 12:00:53 <mickeyl> one is AC
Oct 13 12:00:58 <mickeyl> they're seperately
Oct 13 12:01:08 <mickeyl> handled
Oct 13 12:01:15 <Ainulindale> My point was to find out what signal I should wait :-)
Oct 13 12:01:15 <mickeyl> (which is just what the kernel does)
Oct 13 12:01:37 <Ainulindale> If I'm "charging" or "full", I'm plugged in, right ?
Oct 13 12:01:42 <Ainulindale> otherwise I'm not
Oct 13 12:01:54 <mickeyl> correct
Oct 13 12:01:58 <Ainulindale> Good then
Oct 13 12:02:01 <Ainulindale> i'll do powercontrol
Oct 13 12:02:05 <Ainulindale> err
Oct 13 12:02:06 <Ainulindale> supply
Oct 13 12:02:14 <Ainulindale> mickeyl: http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.PowerControl.html;hb=HEAD
Oct 13 12:02:18 <Ainulindale> (power control)
Oct 13 12:02:29 <mickeyl> right
Oct 13 12:02:36 <mickeyl> that's for peripheral devices
Oct 13 12:02:50 <Ainulindale> Such as usb key ?
Oct 13 12:02:59 <mickeyl> such as
Oct 13 12:03:01 <mickeyl> GSM
Oct 13 12:03:01 <mickeyl> WiFi
Oct 13 12:03:03 <mickeyl> Bluetooth
Oct 13 12:03:12 <mickeyl> peripheral devices outside your SoC
Oct 13 12:03:29 <Ainulindale> mickeyl: by the way 
Oct 13 12:03:49 <Ainulindale> mickeyl: is there any way to prevent dimming if I'm charging or full ?
Oct 13 12:04:05 <Ainulindale> I don't find dimming pertinent if you're plugged in
Oct 13 12:04:07 <mickeyl> pretty soon, ya
Oct 13 12:04:14 <Ainulindale> Through rules ?
Oct 13 12:04:16 <mickeyl> charlie is working on profile support
Oct 13 12:04:17 <mickeyl> ya
Oct 13 12:04:22 <mickeyl> one profile = one set of rules
Oct 13 12:04:34 <mickeyl> plus you can change the profile by a rule
Oct 13 12:04:38 <mickeyl> should be almost done
Oct 13 12:04:56 <Ainulindale> Nice :-)
Oct 13 12:05:08 <Ainulindale> In between I'll implement suspend prevention in ophonekitd
Oct 13 12:05:08 <mickeyl> ya, that should allow for some fun stuff
Oct 13 12:05:12 <mickeyl> like EnterArea, LeaveArea
Oct 13 12:05:19 <mickeyl> oki
Oct 13 12:05:26 <Ainulindale> EnterSandman, etc ?
Oct 13 12:05:30 <mickeyl> heh
Oct 13 12:06:06 <Ainulindale> mickeyl: as I told charlie before I'm available these times to work on PIm or things directly usable in SHR if necessary
Oct 13 12:06:35 <mickeyl> Ainulindale: good to know. PIM and Networking are the 2 major things landing in framework soon
Oct 13 12:06:44 <mickeyl> then we're feature complete for 1.0
Oct 13 12:07:00 <Ainulindale> mickeyl: by the way we were talking about names yesterday with quickdev 
Oct 13 12:07:02 <mickeyl> i'll try to coordinate w/ abraxa. haven't seen him for a while
Oct 13 12:07:16 <mickeyl> names?
Oct 13 12:07:17 <Ainulindale> Do you think OM the company will see with a wary eye our names for our applications ?
Oct 13 12:07:22 <Ainulindale> i.e. openmoko-dialer3 ?
Oct 13 12:07:30 <Ainulindale> Should I mail Sean ?
Oct 13 12:08:10 <mickeyl> feel free to, but I don't think there's any problems
Oct 13 12:08:14 <mickeyl> Om is a pretty open company
Oct 13 12:08:27 <Ainulindale> THat was my thought too
Oct 13 12:08:35 <Ainulindale> I'll mail him anyway just to be on the safe side
Oct 13 12:08:43 <Ainulindale> I was thinking about some kind of endorsment for SHR
Oct 13 12:08:58 <Ainulindale> i.e. OM the company telling "we morally support SHR bleh bleh bleh"
Oct 13 12:09:08 <mickeyl> cool
Oct 13 12:09:24 <mickeyl> we should do that on FSO as well
Oct 13 12:09:28 <Ainulindale> If that's doable it would give some legitimity to SHR
Oct 13 12:09:28 <mickeyl> SHR being FSO-compliant
Oct 13 12:09:35 <mickeyl> just as Om 2009 will be
Oct 13 12:09:35 <Ainulindale> SHR being FSO plus things
Oct 13 12:09:39 <mickeyl> yep
Oct 13 12:09:53 <Ainulindale> When will OM2009 be ASU compliant ?
Oct 13 12:10:00 <Ainulindale> I was thinking about recommending lfg use for that
Oct 13 12:10:03 <mickeyl> ASU? 
Oct 13 12:10:09 <Ainulindale> sorry FSO
Oct 13 12:10:11 <mickeyl> heh
Oct 13 12:10:12 <mickeyl> ah
Oct 13 12:10:14 <mickeyl> next year
Oct 13 12:10:19 <Ainulindale> Hence 2009 ok
Oct 13 12:10:23 <mickeyl> OM 2009 will be FSO + Om new userland
Oct 13 12:10:29 <Ainulindale> Will they use lfg or will the directly bind to dbus ?
Oct 13 12:10:42 <Ainulindale> +y
Oct 13 12:11:06 <mickeyl> depends on the language 
Oct 13 12:11:20 <mickeyl> if they'd use C, then definitly lfg
Oct 13 12:11:34 <Ainulindale> is that their intention ?
Oct 13 12:11:56 <Ainulindale> Because as is if their intention is to reimplement things on top of frameworkd
Oct 13 12:12:02 <Ainulindale> they definitely should use lfg/lfp paradigm
Oct 13 12:12:15 <Ainulindale> see how fast it went for quickdev to build a working thing
Oct 13 12:12:28 <mickeyl> sure
Oct 13 12:12:34 <mickeyl> right now it looks they're going py
Oct 13 12:12:45 <Ainulindale> Yuk :-p
Oct 13 12:12:47 <mickeyl> but if they reconsider that for performance, i'll force them into lfg
Oct 13 12:12:49 <mickeyl> ;)
Oct 13 12:13:02 <Ainulindale> I like py so I don't really care
Oct 13 12:13:14 <Ainulindale> I'm just not that fluent in py
Oct 13 12:13:46 <quickdev> mickeyl, am I wrong or is py for efl apps noticeable slower?
Oct 13 12:14:53 <mickeyl> i don#t think so
Oct 13 12:15:02 <mickeyl> of course it depends
Oct 13 12:15:03 <mickeyl> it's simple
Oct 13 12:15:06 <mickeyl> more py => slower
Oct 13 12:15:19 <mickeyl> so if the major parts are in .edj
Oct 13 12:15:27 <mickeyl> then you shouldn't perceive differences
Oct 13 12:17:00 <Ainulindale> mickeyl: which object should I bind to for power supply ?
Oct 13 12:17:28 <mickeyl> Ainulindale: all
Oct 13 12:17:31 <mickeyl> or the first one
Oct 13 12:17:32 <alphaone> wow, I just spent 5 mins reading http://en.wikipedia.org/wiki/Lexical_functional_grammar only to realize you probably mean libframework-glib
Oct 13 12:17:33 <mickeyl> that implements it
Oct 13 12:17:36 <mickeyl> e.g. use
Oct 13 12:17:51 <mickeyl> ListObjectsByInterface("org.freesmartphone.Device.PowerSupply")
Oct 13 12:17:51 <Ainulindale> alphaone: hahaha :-)
Oct 13 12:17:57 <mickeyl> alphaone: hehe
Oct 13 12:18:08 <mickeyl> alphaone: time worth spent!
Oct 13 12:18:13 <mickeyl> spending
Oct 13 12:18:19 <Ainulindale> I agree :-)
Oct 13 12:18:22 <raster> just make it introspectable... and i'm happy
Oct 13 12:18:23 <alphaone> :-)
Oct 13 12:18:26 <raster> (and sane)
Oct 13 12:18:51 <mickeyl> either exalt or e_dbus is creating unintrospectable interfaces
Oct 13 12:19:01 <raster> hmm
Oct 13 12:19:09 <mickeyl> invalid xml
Oct 13 12:19:15 <mickeyl> dbus introspection breaks :)
Oct 13 12:19:25 <raster> e works for me
Oct 13 12:19:29 <raster> and it doesnt even have xml
Oct 13 12:19:46 <raster> its generated on the fly
Oct 13 12:19:56 <raster> edbus could be screwign somethnig up...
Oct 13 12:19:56 <Ainulindale> crap
Oct 13 12:19:58 <mickeyl> sure, that's what i meant
Oct 13 12:20:03 <mickeyl> introspection _is_ xml
Oct 13 12:20:12 <Ainulindale> my powersupply interface is waaaay more different than the documentation
Oct 13 12:20:15 <raster> but i know e's dbsu wm service is there and happy in dfeet
Oct 13 12:20:27 <mickeyl> then probably exalt's fault
Oct 13 12:20:55 <Ainulindale> mickeyl: is this normal ?
Oct 13 12:20:56 <raster> dbus interfaces that cznt be introspected are bad
Oct 13 12:21:03 <raster> badd mmmkay
Oct 13 12:21:49 <Ainulindale> I have no "[METHOD]    org.freesmartphone.Device.PowerSupply.GetOnBattery()
Oct 13 12:21:52 <Ainulindale> "
Oct 13 12:21:53 <Ainulindale> In the documentation
Oct 13 12:22:00 <Ainulindale> And interface for apm and bat are quite different indeed
Oct 13 12:22:15 <Ainulindale> +s
Oct 13 12:22:44 <mickeyl> Ainulindale: apm is going away, feel free to ignore that
Oct 13 12:23:17 <Ainulindale> Ok then some things are missing on the documentation
Oct 13 12:23:22 <mickeyl> i guess there are some things missing in the docs
Oct 13 12:23:24 <mickeyl> heh, right
Oct 13 12:23:31 * mickeyl notes
Oct 13 12:23:47 <Ainulindale> Do you that in the end you'll get spanked for that ?
Oct 13 12:24:13 <mickeyl> well, i'd rather have faulty docs than no docs
Oct 13 12:24:15 <mickeyl> must be me ;)
Oct 13 12:25:42 <Ainulindale> :-)
Oct 13 12:33:06 <quickdev> Ainulindale, I don't know if modified packages like libframeworkd-glib or ophonekitd are updated through opkg upgrade without incremeting the package revision..
Oct 13 12:34:52 <Ainulindale> I don't know either
Oct 13 12:35:09 <Ainulindale> In any case packages are badly conceived
Oct 13 12:35:14 <Ainulindale> As I built them
Oct 13 12:35:53 <quickdev> badly conceived?
Oct 13 12:36:06 <Ainulindale> I didn't take enough time to do them properly
Oct 13 12:39:48 <quickdev> Ainulindale, fwHandler.deviceIdleNotifierState = NULL; should be set in openmoko-* applications. Otherwise there will be problems. I fix it now.
Oct 13 12:40:28 <Ainulindale> Wait
Oct 13 12:40:32 <Ainulindale> What are you talking about ?
Oct 13 12:40:39 <Ainulindale> Don't fix things about that while I'm working on them please
Oct 13 12:40:56 <Ainulindale> quickdev !
Oct 13 12:41:25 <quickdev> Ainulindale, openmoko-dialer for example...it needs the idlenotifierstate = NULL; otherwise the frameworkd-glib registers the signal handler
Oct 13 12:41:33 <quickdev> are you doing that atm? I doubt.. :)
Oct 13 12:42:00 <Ainulindale> I'm working on odeviced so yes
Oct 13 12:42:06 <Ainulindale> And on frameworkd-glib-dbus.c
Oct 13 12:42:14 <Ainulindale> What are you talking about right now ?
Oct 13 12:42:20 <Ainulindale> Where is this idle notifier NULL ?
Oct 13 12:42:26 <Ainulindale> in ophonekitd ?
Oct 13 12:42:40 <quickdev> it isn't in openmoko-dialer etc....that's the prob
Oct 13 12:42:46 <Ainulindale> Why is that a problem ?
Oct 13 12:42:55 <Ainulindale> Why should dialer know the idle state ?
Oct 13 12:42:59 <quickdev> if it isn't set = NULL, memory isn't initialized and the signal is registered
Oct 13 12:43:11 <quickdev> it shouldn't, that's why = NULL
Oct 13 12:43:39 <Ainulindale> Where ?
Oct 13 12:44:02 <Ainulindale> lfg, om-dialer ?
Oct 13 12:44:07 <quickdev> in openmoko-dialer for example
Oct 13 12:44:13 <Ainulindale> Ok so here I disagree
Oct 13 12:44:13 <quickdev> I don't talk about lfg
Oct 13 12:44:24 <Ainulindale> lfg should init this structure at "boot"
Oct 13 12:44:34 <Ainulindale> not the underlying applications
Oct 13 12:44:46 <quickdev> so atm it's handled wrong?
Oct 13 12:45:09 <quickdev> Ainulindale, FrameworkdHandlers fwHandler; <- how do you init that?
Oct 13 12:45:28 <Ainulindale> manually :-)
Oct 13 12:45:51 <Ainulindale> I'll declare a fwHandler in fg-dbus.c
Oct 13 12:45:57 <Ainulindale> and set everything to null there
Oct 13 12:46:11 <Ainulindale> And use a "creator" method
Oct 13 12:46:19 <Ainulindale> As I intended to do in the first time
Oct 13 12:46:45 <Ainulindale> e.g. fwhandler = dbus_create_empty_handler();
Oct 13 12:47:36 <quickdev> yeah, ok..do it :) and please update the openmoko-* apps :)
Oct 13 12:47:53 <Ainulindale> I'll do that later on
Oct 13 12:47:59 <Ainulindale> First thing prevent suspend on charging
Oct 13 12:48:05 <quickdev> yeah, right
Oct 13 12:48:10 <quickdev> and the trac, hehe :)
Oct 13 12:48:19 <Ainulindale> Though I'll have to stop in 15 minutes
Oct 13 12:48:22 <Ainulindale> conference..
Oct 13 12:58:26 <quickdev> Ainulindale, you said the apps are buggy (Illegal instruction). That's because of the idle notifier state callback, which isn't initialized with NULL.
Oct 13 13:01:43 <Ainulindale> That's good to know :-)
Oct 13 13:01:55 <Ainulindale> Listen, while I can't do that, please put the handler to NULL
Oct 13 13:02:01 <Ainulindale> I'll modify that later on
Oct 13 13:02:57 <quickdev> ok
Oct 13 13:04:42 <Ainulindale> quickdev: but do you agree on principle ?
Oct 13 13:04:50 <quickdev> of course I do
Oct 13 13:04:55 <Ainulindale> wurp2|gone suggested the idea a while ago I think he's right
Oct 13 13:05:00 <quickdev> avoid code duplications :)
Oct 13 13:06:51 <quickdev> although there's a small overhead, but that's no problem, hehe
Oct 13 13:15:55 <quickdev> mickeyl, woglinde updated e2fsprogs which require gettext 0.17, atm 0.14.1 is configured in preferred-om-2008-versions.inc, are you permitted to change that?
Oct 13 13:17:16 <alphaone> quickdev: Ah, so that's what breaks my build
Oct 13 13:17:25 <quickdev> alphaone, yes
Oct 13 13:17:34 <quickdev> our shr build, too
Oct 13 13:20:02 <mickeyl> hmm
Oct 13 13:20:04 <mickeyl> ~lart woglinde
Oct 13 13:20:06 * mickeyl changes
Oct 13 13:21:07 <alphaone> gettext-native as well I assume
Oct 13 13:21:10 <mickeyl> yap
Oct 13 13:21:11 <quickdev> yes
Oct 13 13:21:20 <mickeyl> usually you are supposed to add this information in the dependencies
Oct 13 13:21:31 <mickeyl> DEPENDS = gettext-0.17 e.g.
Oct 13 13:21:33 <mickeyl> *shrug*
Oct 13 13:22:06 <quickdev> tell it woglinde on #oe ;)
Oct 13 13:22:18 <alphaone> mickeyl: Is there a way to say gettext version 0.17 or greater?
Oct 13 13:22:23 <mickeyl> unfortunately not
Oct 13 13:22:41 <mickeyl> (not in DEPENDS, that is)
Oct 13 13:22:46 * alphaone hugs ebuild syntax
Oct 13 13:22:47 <alphaone> :-(
Oct 13 13:22:56 <mickeyl> in RDEPENDS we have support for that
Oct 13 13:25:30 <alphaone> mickeyl: When should we start to settle down for MS4 release?
Oct 13 13:25:43 <alphaone> I want to have a greater testing period than for MS3
Oct 13 13:26:02 <alphaone> And I think we should start more or less now.
Oct 13 13:26:21 <alphaone> Unless there are some critical features that need to get in there
Oct 13 13:26:41 <mickeyl> alphaone: if we want to get that stable, we should branch
Oct 13 13:26:50 <mickeyl> i have a bunch of new things i want to get into framework
Oct 13 13:27:05 <mickeyl> so i'd rather branch off for ms4
Oct 13 13:27:15 <Ainulindale> By the way
Oct 13 13:27:20 <mickeyl> and i agree, we should test more than for 3
Oct 13 13:27:24 <Ainulindale> You should have a look at zhone for stabilization process
Oct 13 13:27:32 <Ainulindale> It's pretty inconsistent
Oct 13 13:27:43 <Ainulindale> Sometimes call are releaser before being initialized
Oct 13 13:27:46 <Ainulindale> With no apparent reasons
Oct 13 13:27:48 <alphaone> mickeyl: okay, sounds fine
Oct 13 13:28:04 <mickeyl> alphaone: lets give charlie some more days for events/preferences
Oct 13 13:28:12 <quickdev> Ainulindale, I committed the bufixes..with = NULL
Oct 13 13:28:14 <mickeyl> and lets announce that branch
Oct 13 13:28:16 <alphaone> mickeyl: okay
Oct 13 13:28:22 <mickeyl> so lets branch on weekend
Oct 13 13:29:32 <alphaone> mickeyl: And we need to make sure GSM is powered off if the resource is not in use
Oct 13 13:30:12 <mickeyl> yeah
Oct 13 13:30:24 <mickeyl> i guess i can't hope for that to magically appear?
Oct 13 13:30:27 <mickeyl> :D
Oct 13 13:30:45 <alphaone> mickeyl: If you ask nicely :-)
Oct 13 13:30:45 <mickeyl> ~lart todo lists with own name on it
Oct 13 13:30:54 <mickeyl> hehe
Oct 13 13:30:55 <alphaone> But magic wont have anything to do with it :-)
Oct 13 13:31:00 <mickeyl> agreed
Oct 13 13:31:14 <alphaone> you or me?
Oct 13 13:31:23 <mickeyl> i'll take care of it, you have other important things
Oct 13 13:31:28 <alphaone> okay
Oct 13 13:31:42 <alphaone> heh, that's right
Oct 13 13:31:57 <quickdev> mickeyl, could you update the gettext? :)
Oct 13 13:31:59 <alphaone> ~lart todo list items with own name on it :-)
Oct 13 13:32:01 <mickeyl> it's just that i need to decide whether to change the muxer or just turn it off in the framework atm.
Oct 13 13:32:05 <mickeyl> hehe
Oct 13 13:32:08 <mickeyl> quickdev: on it...
Oct 13 13:32:13 <quickdev> :)
Oct 13 13:32:52 <mickeyl> emdete: did you notice the new muxer segfaults if you ctrl-d it?
Oct 13 13:33:14 <mickeyl> err ctrl-c
Oct 13 13:36:30 <quickdev> alphaone, should I create a ticket for sms timestamp support?
Oct 13 13:38:24 <alphaone> quickdev: please do
Oct 13 13:38:52 <alphaone> It's not a big fix, but I'll forget it again if you don't create a ticket :-)
Oct 13 13:40:45 <quickdev> added it to milestone4
Oct 13 13:41:20 <alphaone> thanks
Oct 13 13:57:46 <CIA-57> freesmartphone.org: 03mickey 07specs * r700269a4c10d 10/ (3 files in 3 dirs): 
Oct 13 13:57:46 <CIA-57> freesmartphone.org: odevice: fix parameter direction in org.freesmartphone.Device.IdleNotifier.SetState and org.freesmartphone.Device.IdleNotifier.GetState. Thanks Ainulindale for
Oct 13 13:57:46 <CIA-57> freesmartphone.org: spotting.
Oct 13 14:02:16 <quickdev> raster, whatever value I change in the keyboard file, everything is adjusted relatively. I think we didn't understand each other. I'd like to change the height of the black box at the bottom containg the keyboard..
Oct 13 14:02:39 <Ainulindale> mickeyl: by the way, could I take the liberty to correct these kind of bugs myself ?
Oct 13 14:02:49 <Ainulindale> mickeyl: (i.e. doc inconsistency)
Oct 13 14:03:32 <trupheenix> someone once told me that libgsmd has serious issues. but after installing debian i find that libgsmd actually has better voice clarity compared to zhone
Oct 13 14:03:46 <mickeyl> Ainulindale: absolutely
Oct 13 14:03:49 <trupheenix> anyone want to comment on that?
Oct 13 14:04:31 <Ainulindale> I think it is  oincidental trupheenix 
Oct 13 14:04:34 <Ainulindale> +c
Oct 13 14:04:56 <alphaone> trupheenix: Voice clarity on call is dependent on a number of factors like signal strength, configuration of the GSM modem and statefiles used during call
Oct 13 14:04:59 <mickeyl> in theory the gsm server can't really have any effect on voice quality
Oct 13 14:05:08 <mickeyl> in practice, there's a bug wrt. %CBHZ
Oct 13 14:05:25 <trupheenix> Ainulindale: what u mean incidental? i made 3 calls to 3 different ppl. one using libgsmd and the other using zhone. everyone agreed that zhone is bad
Oct 13 14:05:31 <mickeyl> well
Oct 13 14:05:32 <mickeyl> first
Oct 13 14:05:34 <mickeyl> it's not zhone
Oct 13 14:05:38 <alphaone> Even if you tweak everything for a specific scenario you might worsen the quality in other cases
Oct 13 14:05:39 <mickeyl> but framework's ogspd
Oct 13 14:05:41 <mickeyl> second
Oct 13 14:05:44 <mickeyl> it's a bug in the TI Calypso
Oct 13 14:05:48 <mickeyl> http://trac.freesmartphone.org/ticket/151
Oct 13 14:06:06 <mickeyl> which ogpsd will work around soon
Oct 13 14:06:18 <mickeyl> third
Oct 13 14:06:19 <alphaone> gsmd
Oct 13 14:06:25 <mickeyl> *sigh*
Oct 13 14:06:26 <mickeyl> yes, of course
Oct 13 14:06:26 <alphaone> ogpsd doesn't have any bugs
Oct 13 14:06:28 <alphaone> :-)
Oct 13 14:06:30 <mickeyl> i remember ;)
Oct 13 14:06:57 <mickeyl> me not being able to reproduce this problem is another major problem
Oct 13 14:06:59 <mickeyl> but well...
Oct 13 14:07:12 <mickeyl> going to retry with an MP device this week
Oct 13 14:09:09 <mickeyl> 151 definitely is a strong case against closed GSM stacks
Oct 13 14:09:49 <quickdev> mickeyl, 1024 was it, too
Oct 13 14:09:54 <mickeyl> agreed
Oct 13 14:09:58 <alphaone> still is
Oct 13 14:11:19 <mickeyl> that reminds me
Oct 13 14:11:23 * mickeyl unpacks the MP
Oct 13 14:11:31 <mickeyl> device, that is
Oct 13 14:14:26 <quickdev> mickeyl, how many new neos have you got in your desk drawer? ;)
Oct 13 14:15:01 <mickeyl> too many
Oct 13 14:15:03 <mickeyl> but let me count
Oct 13 14:15:29 <mickeyl> on first glance 8
Oct 13 14:15:32 <Ainulindale> mickeyl: if you have too many let joerg fix one for the gsm stuff and send it to me so I can test ! :-p
Oct 13 14:15:43 <mickeyl> joerg has more than enough as well
Oct 13 14:15:45 <Ainulindale> It's truly a pain in the ass this gsm thing
Oct 13 14:15:55 <mickeyl> well
Oct 13 14:15:55 <Ainulindale> (buzzing)
Oct 13 14:15:59 <mickeyl> yeah
Oct 13 14:16:12 <mickeyl> the buzzing is a major showstopper
Oct 13 14:16:16 <mickeyl> dunno the current status
Oct 13 14:16:17 <Ainulindale> Indeed
Oct 13 14:16:21 <mickeyl> here in .de it's almost fine
Oct 13 14:16:22 <Ainulindale> mickeyl: joerg needs tester
Oct 13 14:16:39 <quickdev> joerg is docscrutinizer?
Oct 13 14:16:41 <Ainulindale> But I won't be able to test as I'm as clumsy as a bear with a cupholder
Oct 13 14:16:45 <Ainulindale> yes
Oct 13 14:16:47 <mickeyl> quickdev: ya
Oct 13 14:18:17 <quickdev> If GPS is on for example, will the idle notifier send SUSPEND?
Oct 13 14:18:35 <alphaone> yes
Oct 13 14:18:35 <mickeyl> atm. yeah
Oct 13 14:18:47 <mickeyl> we will add suspend policies pretty soon
Oct 13 14:18:53 <quickdev> ok, fine
Oct 13 14:19:18 <quickdev> just noticing that it's the same thing as active calls
Oct 13 14:19:44 <Ainulindale> quickdev: thus justifying the need for my modification
Oct 13 14:19:47 <Ainulindale> which is almost done
Oct 13 14:19:56 <Ainulindale> unfortunately I'm forced to listen a conference between sanofi-aventis and Oracle right now
Oct 13 14:22:29 <AinuFallback> Damn my connection is borking again
Oct 13 14:31:41 <trupheenix> AinuFallback: i think i will stick with libgsmd because it's written in C
Oct 13 14:32:57 <alphaone> trupheenix: What are you doing with it?
Oct 13 14:33:19 <trupheenix> alphaone: make a lightweight dialer. i'm not happy with the dialer on openmoko
Oct 13 14:33:25 <mickeyl> trupheenix: that's a bad strategy
Oct 13 14:33:28 <mickeyl> libgsmd is dead.
Oct 13 14:33:41 <mickeyl> but it's your call, of course
Oct 13 14:33:54 <trupheenix> mickeyl: why would u say so? it's a part of the toolchain and seems to be the best way at present to embed telphony into ur application
Oct 13 14:33:58 <alphaone> trupheenix: Well, your choice
Oct 13 14:34:07 <mickeyl> trupheenix: i say so, because it's the fact.
Oct 13 14:34:22 <trupheenix> mickeyl: please enlighten me on the facts
Oct 13 14:34:23 <mickeyl> no one does works on it anymore
Oct 13 14:34:28 <mickeyl> it has bugs
Oct 13 14:34:29 <quickdev> trupheenix, if you want to create a lightweight dialer, join us
Oct 13 14:34:42 <mickeyl> and supports only parts of the telephony stack
Oct 13 14:35:01 <quickdev> trupheenix, join the shr team..we're doing that atm
Oct 13 14:35:01 <trupheenix> mickeyl: ok...
Oct 13 14:35:12 <trupheenix> quickdev: i know... am aware of shr
Oct 13 14:35:13 <mickeyl> Om will use the FSO backend for their future distros
Oct 13 14:35:23 <mickeyl> so that's recommended
Oct 13 14:35:28 <trupheenix> mickeyl: FSO backend written in py?
Oct 13 14:35:32 <mickeyl> right now, yes.
Oct 13 14:35:42 <mickeyl> w/ more parts going Vala/C soon
Oct 13 14:35:43 <trupheenix> mickeyl: shucks! i don't like py 
Oct 13 14:35:49 <mickeyl> erm
Oct 13 14:35:53 <trupheenix> mickeyl: would like to write it in C
Oct 13 14:35:54 <mickeyl> why would the language of the backend matter?
Oct 13 14:35:57 <mickeyl> err
Oct 13 14:36:02 <alphaone> trupheenix: The last three commits made in the libgsm repository were at 2008-03-25, 2008-07-03 and 2008-09-02
Oct 13 14:36:10 <trupheenix> mickeyl: performance on embedded systems
Oct 13 14:36:11 <mickeyl> the language of the backend has no relationship to the language of the frontend
Oct 13 14:36:20 <mickeyl> don't tell me about performance when using GSM
Oct 13 14:36:27 <mickeyl> python runs circles around the modem
Oct 13 14:36:36 <mickeyl> do actual measurements
Oct 13 14:36:42 <trupheenix> mickeyl: performance is very important
Oct 13 14:36:48 <mickeyl> yes, it is
Oct 13 14:36:52 <mickeyl> and performance is fine
Oct 13 14:36:54 <trupheenix> mickeyl: py is just convenient
Oct 13 14:37:16 <trupheenix> mickeyl: i didn't like the results from zhone :( 
Oct 13 14:37:23 <mickeyl> zhone is a python UI
Oct 13 14:37:35 <alphaone> trupheenix: Have you ever timed how long it takes for the AT command reading your Messagebook to actually complete?
Oct 13 14:37:41 <mickeyl> now how can you transfer the results to the frameworkd?
Oct 13 14:37:45 <quickdev> trupheenix, the important parts of frameworkd will use C later on!
Oct 13 14:37:55 <trupheenix> ok
Oct 13 14:38:29 <Ainulindale> trupheenix: if you want to build applications using frameworkd in C, use libframeworkd-glib
Oct 13 14:39:02 <trupheenix> Ainulindale: ok
Oct 13 14:40:00 <CIA-57> freesmartphone.org: 03ainulindale 07libframeworkd-glib * r731d2590e669 10/src/ (10 files in 3 dirs): 
Oct 13 14:40:00 <CIA-57> freesmartphone.org: - Draft of Device.PowerSupply.
Oct 13 14:40:00 <CIA-57> freesmartphone.org: - Typo in IdleNotifier header.
Oct 13 14:40:00 <CIA-57> freesmartphone.org: 03ainulindale 07libframeworkd-glib * r44ac0a73055c 10/src/frameworkd-glib-dbus.c: - Included power supply in main. (typo)
Oct 13 14:40:38 <mickeyl> looks like we have to use freeze
Oct 13 14:40:44 <mickeyl> or anything that hides the fact that we're using python
Oct 13 14:40:49 <AinuFallback> haha :-)
Oct 13 14:41:05 <mickeyl> no seriously, it's amazing how much prejudices I encounter
Oct 13 14:41:12 <mickeyl> without people doing actual measurements
Oct 13 14:41:20 <AinuFallback> Did you ever heard about hidden sausages in frameworkd ?
Oct 13 14:41:31 <mickeyl> sausages??
Oct 13 14:41:37 <AinuFallback> You're german, aren't you ? :-)
Oct 13 14:41:57 <AinuFallback> (and now you regret not being op :-p)
Oct 13 14:42:30 <mickeyl> hehe
Oct 13 14:42:42 <mickeyl> actually I'm not that fond of "typical german food"
Oct 13 14:42:52 <mickeyl> although i love a Schnitzel once an then
Oct 13 14:43:01 <quickdev> hehe, fond of "typical american food"?
Oct 13 14:43:39 <mickeyl> i like italian, french, chinese
Oct 13 14:43:44 <mickeyl> mexican
Oct 13 14:43:48 <mickeyl> indian
Oct 13 14:44:10 <quickdev> italian is my favourite food, too
Oct 13 14:44:15 <AinuFallback> i recently ate at an ethiopian restaurant
Oct 13 14:44:17 <AinuFallback> it was very nice
Oct 13 14:44:21 <trupheenix> mickeyl: Indian is good for u
Oct 13 14:44:28 <mickeyl> AinuFallback: cool, never tried that
Oct 13 14:45:14 <trupheenix> AinuFallback: try lebanese it's better 
Oct 13 14:45:49 <AinuFallback> It's not better, it's different
Oct 13 14:45:53 <AinuFallback> I love libanese either way
Oct 13 14:50:59 <Ainulindale> quickdev: commited but could not test right now
Oct 13 14:51:04 <Ainulindale> (ophonekitd)
Oct 13 14:51:06 <Ainulindale> It compiles though
Oct 13 14:51:20 <Ainulindale> As soon as it's on buildhost I'll test it
Oct 13 14:51:35 <Ainulindale> By the way could you remove image generation again ?
Oct 13 14:51:36 <quickdev> Ainulindale, you always have to increment PR
Oct 13 14:51:43 <quickdev> yeah
Oct 13 14:52:16 <Ainulindale> PR should be generated automatically
Oct 13 14:52:19 <quickdev> AinuFallback, done...will apply in some minutes
Oct 13 14:52:27 <Ainulindale> THanks
Oct 13 14:53:13 <AinuFallback> quickdev: you should have a mail
Oct 13 14:54:15 <AinuFallback> Currently administering trac
Oct 13 15:02:09 <Hire> (16:42:03) quickdev: italian is my favourite food, too <-- great because I am italian :)
Oct 13 15:02:40 <Tm_T> Hire: means people like to eat _you_ ?
Oct 13 15:03:27 <Hire> erhm, no, because I am italian and I know much is good the italian's food :D
Oct 13 15:03:36 <Hire> how much
Oct 13 15:04:20 <AinuFallback> mickeyl: could you add libframeworkd-glib component to freesmartphone trac ?
Oct 13 15:04:26 <AinuFallback> And create a user for me ? :-)
Oct 13 15:04:54 <mickeyl> yep. will do after dinner
Oct 13 15:05:02 <AinuFallback> Ok :-)
Oct 13 15:05:06 <AinuFallback> There's a shr trac now
Oct 13 15:05:10 <Tm_T> hmmmm
Oct 13 15:07:04 <quickdev> mickeyl, we want to recompile our packages each time a commit is there. Is PR=${SRCREV} ok or what would you suggest?
Oct 13 15:07:47 <mickeyl> leave PR as it is
Oct 13 15:07:53 <mickeyl> do
Oct 13 15:08:00 <mickeyl> PV = "0.0.0+svnr${SRCREV}"
Oct 13 15:08:02 <mickeyl> and in your local.conf
Oct 13 15:08:11 <mickeyl> do SRCREV_pn-<yourProgram> = "${AUTOREV}"
Oct 13 15:08:25 <mickeyl> this is what we usually do for that in OE
Oct 13 15:09:11 <AinuFallback> oh and by the way
Oct 13 15:09:12 <quickdev> autorev is already set...I should confirm if packages are installed by opkg upgrade with a different src revision
Oct 13 15:09:19 <AinuFallback> why on earth does bitbake appends a 0 to the ipk name ?
Oct 13 15:09:23 <AinuFallback> s/appends/append/
Oct 13 15:10:37 <quickdev> AinuFallback, it's the debian package epoch...it only applies to libraries
Oct 13 15:10:55 <quickdev> for example libc6
Oct 13 15:11:33 <mickeyl> that's debian style shlib renaming, yeah
Oct 13 15:22:15 <mickeyl> AinuFallback: username for trac?
Oct 13 15:23:20 <AinuFallback> mickeyl: I thought "pimpmypants" was good enough
Oct 13 15:23:29 <AinuFallback> But if you prefer ainulindale I'll settle for that
Oct 13 15:23:56 <mickeyl> *cough* ;)
Oct 13 15:24:03 <AinuFallback> Sorry for the delay but there's an oracle consultant blabbering about the latest version of Identity Manager on the phone
Oct 13 15:25:29 <mickeyl> :)
Oct 13 15:26:29 <AinuFallback> quickdev: I can spam you too ! :-)
Oct 13 15:26:41 <quickdev> mh?
Oct 13 15:26:51 <AinuFallback> Just reassigned tickets
Oct 13 15:27:00 <mickeyl> user added
Oct 13 15:27:00 <AinuFallback> They're lf-phonegui-efl issues
Oct 13 15:27:04 <AinuFallback> mickeyl: thanks a lot
Oct 13 15:27:06 <mickeyl> confirmation mail underway
Oct 13 15:27:10 <AinuFallback> mickeyl: please also add the component
Oct 13 15:27:14 <mickeyl> done
Oct 13 15:27:42 <AinuFallback> Hmmm I like my password
Oct 13 15:27:45 <AinuFallback> Is this an invitation ? :-)
Oct 13 15:27:58 <quickdev> AinuFallback, could you add a component SHR Image ?
Oct 13 15:28:06 <AinuFallback> quickdev: you can do that you're admin
Oct 13 15:28:08 <mickeyl> haha
Oct 13 15:28:08 <AinuFallback> but I'll do it
Oct 13 15:28:09 <mickeyl> NO! :)
Oct 13 15:28:12 <quickdev> ok
Oct 13 15:28:22 * mickeyl catches up with kernel mailinglist
Oct 13 15:28:22 <mickeyl> [PATCH 0/1]: Acceleration threshold configuration
Oct 13 15:28:24 <mickeyl> yay!
Oct 13 15:28:32 <AinuFallback> quickdev: done
Oct 13 15:28:36 <quickdev> thanks
Oct 13 15:29:20 <AinuFallback> quickdev: please put tickets where they should be or else I shall destroy you :-)
Oct 13 15:30:00 <AinuFallback> I agree for message timestamp though :-)
Oct 13 15:30:34 <quickdev> AinuFallback, it's a libframeworkd-phonegui-efl issue, too
Oct 13 15:31:34 <AinuFallback> quickdev: yes but right now it's global :-)
Oct 13 15:31:41 <AinuFallback> wurp2|working: you're the proud owner of an account on SHR trac
Oct 13 15:31:47 <wurp2|working> I saw that
Oct 13 15:31:53 <wurp2|working> I thanked Benjamin
Oct 13 15:31:56 <AinuFallback> wurp2|working: would you be so kind so as to modify SHR wiki ?
Oct 13 15:32:00 <wurp2|working> Thanks :-)
Oct 13 15:32:03 <wurp2|working> Surely
Oct 13 15:32:16 <AinuFallback> wurp2|working: I expect tests from you in the week to come :-)
Oct 13 15:33:58 <wurp2|working> Are you still working on the SHR Milestone
Oct 13 15:34:02 <wurp2|working> I don't think you'll get them
Oct 13 15:34:20 <AinuFallback> Not enough time ?
Oct 13 15:34:21 <quickdev> wurp2|working, not the openmoko shr milestone
Oct 13 15:34:31 <AinuFallback> openmoko shr milestone ? 
Oct 13 15:34:47 <wurp2|working> There is already a trac for SHR at http://docs.openmoko.org/trac/query?status=in_testing&status=reopened&status=assigned&status=new&status=accepted&group=status&milestone=SHR
Oct 13 15:35:01 <AinuFallback> yeah but in a different location wurp2|working 
Oct 13 15:35:03 <quickdev> AinuFallback, if(error == NULL && status != DEVICE_POWER_STATE_CHARGING && status != DEVICE_POWER_STATE_FULL) - what about a full battery without a usb connection? phone won't go into suspend?
Oct 13 15:35:12 <AinuFallback> quickdev: no
Oct 13 15:35:17 <AinuFallback> Because full battery without USB = discharging
Oct 13 15:35:23 <AinuFallback> Asked the same question two hours ago
Oct 13 15:35:40 <quickdev> ah, ok..if there's a state for DISCHARGING
Oct 13 15:35:46 <AinuFallback> There is :-)
Oct 13 15:36:01 <wurp2|working> I can't update the wiki because I don't know what the new trac is
Oct 13 15:36:12 <wurp2|working> There was an existing one, and I don't know what goes in that vs what goes in the new one
Oct 13 15:36:12 <quickdev> wurp2|working, http://shr.bearstech.com/trac/
Oct 13 15:36:18 <wurp2|working> I know *where* it is
Oct 13 15:36:21 <wurp2|working> I don't know *what* it is
Oct 13 15:36:22 <AinuFallback> wurp2|working: for me, old one is outdated
Oct 13 15:36:30 <AinuFallback> Because I really prefer to have everything in the same place
Oct 13 15:36:34 <wurp2|working> Well, I'm out of it
Oct 13 15:36:43 <AinuFallback> hence buildhost, trac, and soon git
Oct 13 15:36:50 <wurp2|working> I don't know what SHR is any more, or what is happening with it
Oct 13 15:37:11 <wurp2|working> I am happy to see that it has a purpose in life
Oct 13 15:38:25 <Hire> wow nice ! 
Oct 13 15:38:32 <Hire> trac for SHR :D
Oct 13 15:38:40 <Hire> put the link into the wiki 
Oct 13 15:47:05 <quickdev> back..
Oct 13 15:48:34 <wurp2|working> So the old trac is deprecated, and the new trac is the way to go
Oct 13 15:48:52 <wurp2|working> Do any tasks from the old trac need to be moved?
Oct 13 15:49:09 <AinuFallback> I think so for some of them
Oct 13 15:49:13 <AinuFallback> The thing about packages and so
Oct 13 15:49:14 <wurp2|working> OK
Oct 13 15:49:21 <AinuFallback> i would like to install a file manager as an example
Oct 13 15:49:22 <AinuFallback> a media player
Oct 13 15:49:30 <wurp2|working> I will probably just create a task in the new trac to do that :-)
Oct 13 15:49:32 <AinuFallback> quickdev: still no update on the buildhost
Oct 13 15:49:36 <AinuFallback> wurp2|working: good :-)
Oct 13 15:49:42 <wurp2|working> What about the media player?
Oct 13 15:49:48 <AinuFallback> there are some components to do that
Oct 13 15:49:53 <AinuFallback> SHR image is the way to go I think
Oct 13 15:49:53 <wurp2|working> Or did alphaone not update it to work w/o pulse?
Oct 13 15:49:59 <AinuFallback> I think he did
Oct 13 15:50:03 <AinuFallback> Can't remember
Oct 13 15:50:19 <alphaone> I didn't do anything, I swear!
Oct 13 15:50:20 <wurp2|working> If he did, I think media player support should be either already there or quite easy
Oct 13 15:50:26 <wurp2|working> alphaone: darn
Oct 13 15:50:40 <alphaone> But nobody asked me to, either
Oct 13 15:50:48 <alphaone> (I think)
Oct 13 15:51:00 <AinuFallback> alphaone: you commited the mediaplayer to the SVN some time ago
Oct 13 15:51:04 <AinuFallback> I thought you fixed it
Oct 13 15:51:06 <alphaone> I did?
Oct 13 15:51:28 <alphaone> Now that's strange. When and where to?
Oct 13 15:51:44 <AinuFallback> Ah, no
Oct 13 15:51:46 <AinuFallback> It was abraxa
Oct 13 15:51:56 <AinuFallback> wurp2|working is drunk again
Oct 13 15:52:12 <alphaone> Hehe
Oct 13 15:52:21 <alphaone> Better him than me :-)
Oct 13 15:52:32 <AinuFallback> Yeah you tend to forget letters :-)
Oct 13 15:56:29 <wurp2|working> OK, new trac is linked in wiki
Oct 13 15:56:38 <wurp2|working> and new task to migrate items from old to new is there
Oct 13 15:57:08 <wurp2|working> alphaone: Agh, sorry, I mix your and abraxa's usernames up :-/
Oct 13 15:57:09 <AinuFallback> ~Haha :-)
Oct 13 15:57:36 <wurp2|working> Julien likes to keep me on my toes
Oct 13 15:57:36 <alphaone> np
Oct 13 15:57:53 <wurp2|working> He's all nice when I get miffed, then once I make up with him he starts harassing me
Oct 13 15:58:10 <wurp2|working> It's some French instinct
Oct 13 15:58:40 <AinuFallback> :-)
Oct 13 15:59:05 <wurp2|working> quickdev: Sorry for the task assignment; it defaulted to you
Oct 13 15:59:10 <wurp2|working> I switched it to me now
Oct 13 15:59:20 <quickdev> which task assignment?
Oct 13 15:59:26 <wurp2|working> Not that I'm going to do it, but it shouldn't show as assigned to you
Oct 13 15:59:27 <quickdev> however, ok ;)
Oct 13 15:59:31 <wurp2|working> To move stuff from the old trac to new
Oct 13 16:05:47 <quickdev> AinuFallback, your usb non suspend thing does not work
Oct 13 16:11:18 <wurp2|working> Can someone point me to where the best image builds of SHR are located?
Oct 13 16:12:45 <quickdev> wurp2|working, http://shr.bearstech.com/shr-testing/images/neo1973/openmoko-shr-image-glibc-ipk--20081012-om-gta02.rootfs.jffs2 - and then you need to perform opkg update && opkg upgrade
Oct 13 16:15:12 <wurp2|working> great, thanks!
Oct 13 16:17:08 <quickdev> AinuFallback?
Oct 13 16:18:45 <wurp2|working> Hey, quickdev, can I ask your real name? :-)
Oct 13 16:18:52 <quickdev> Niklas
Oct 13 16:20:58 <AinuFallback> quickdev: still on the phone
Oct 13 16:21:06 <AinuFallback> quickdev: I couldn't test it so I guess that's normal
Oct 13 16:21:14 <quickdev> found the bug, will fix it
Oct 13 16:21:19 <AinuFallback> What was it ?
Oct 13 16:21:33 <wurp2|working> Thanks
Oct 13 16:21:41 <quickdev> 'full' instead of 'Full'
Oct 13 16:21:46 <AinuFallback> weird
Oct 13 16:21:50 <AinuFallback> I followed documentation
Oct 13 16:22:01 <quickdev> root@om-gta02:~# mdbus -s org.freesmartphone.odeviced  /org/freesmartphone/Device/PowerSupply/bat GetPowerStatus
Oct 13 16:22:02 <quickdev> 'Full'
Oct 13 16:22:05 <AinuFallback> Guess which documentation is inconsistent then ? :-)
Oct 13 16:22:20 <AinuFallback> mickeyl !
Oct 13 16:23:54 <mickeyl> *cough*
Oct 13 16:24:18 <mickeyl> let me check who's wrong
Oct 13 16:24:28 <mickeyl> [docs or frameworkd]
Oct 13 16:25:05 <mickeyl> hmm
Oct 13 16:25:25 <mickeyl> this should really be more consistent
Oct 13 16:25:28 <mickeyl> ~lart mickeyl
Oct 13 16:25:35 <mickeyl> i'm using pure lowercase everywhere else right?
Oct 13 16:25:38 <mickeyl> [for properties]
Oct 13 16:25:45 <quickdev> #define DBUS_DEVICE_IDLE_STATE_BUSY "BUSY"
Oct 13 16:25:51 <quickdev> #define DBUS_DEVICE_POWER_STATE_CHARGING "Charging"
Oct 13 16:26:00 <mickeyl> eeks
Oct 13 16:26:04 <mickeyl> ok
Oct 13 16:26:27 <mickeyl> i will change that after dinner
Oct 13 16:26:31 <quickdev> mickeyl, what way to go?
Oct 13 16:26:33 <quickdev> lowercase?
Oct 13 16:26:36 <mickeyl> yep
Oct 13 16:26:41 <mickeyl> BUSY = "busy"
Oct 13 16:26:42 <quickdev> ok
Oct 13 16:26:46 <mickeyl> Charging = "charging"
Oct 13 16:27:00 <mickeyl> will write that down in our dbus style guide as well
Oct 13 16:27:20 <wurp2|working> hah, style guide
Oct 13 16:27:37 <wurp2|working> If they won't memorize every tiny idiosyncracy of how you wrote the code, their client code deserves to fail
Oct 13 16:27:40 <quickdev> #define DBUS_CALL_STATUS_INCOMING "incoming", that's fine
Oct 13 16:27:54 <mickeyl> wurp2|working: ;)
Oct 13 16:28:27 <quickdev> mickeyl, what about: #define DBUS_SIM_PIN_REQUIRED "SIM PIN"
Oct 13 16:28:48 <mickeyl> this i don't want to change since it directly passes the GSM responses through
Oct 13 16:28:55 <quickdev> ok
Oct 13 16:28:57 <wurp2|working> People will forget their place (far beneath you) if you start catering to them in how you write your framework
Oct 13 16:28:58 <mickeyl> people are familiar with that constants
Oct 13 16:29:03 <mickeyl> (or should be)
Oct 13 16:29:25 <mickeyl> wurp2|working: true, but at the end of the day, i'm a consistency freak :)
Oct 13 16:29:42 <mickeyl> and there may come the day that i can (finally) write apps on top of FSO as well
Oct 13 16:29:43 <wurp2|working> :-)
Oct 13 16:29:45 <mickeyl> i don't want to make life hard for me :)
Oct 13 16:29:48 <quickdev> mickeyl, the only thing to change is the idlenotifier and the power supply
Oct 13 16:29:58 <mickeyl> quickdev: ok, good, that's not too bad
Oct 13 16:30:11 <wurp2|working> Yeah, this is the kind of conversation you get from someone (aka me) who has realized it will be a long time, if ever, that he contributes something useful to this :-/
Oct 13 16:30:29 <mickeyl> wurp2|working: why's that? spare time? 
Oct 13 16:30:34 <wurp2|working> Yeah
Oct 13 16:30:38 <mickeyl> *nod*
Oct 13 16:30:42 <wurp2|working> And... I hate to say it...
Oct 13 16:31:06 <wurp2|working> but until I have much more spare time, my goal with after-hours development is to make enough money to quit my day job
Oct 13 16:31:19 <mickeyl> nothing to be ashamed of
Oct 13 16:31:23 <wurp2|working> so free stuff falls far down on my list :-/
Oct 13 16:31:31 <mickeyl> ya, can understand that
Oct 13 16:32:47 * mickeyl hungry
Oct 13 16:32:52 * mickeyl goes and pesters wifey
Oct 13 16:32:53 <mickeyl> bbl
Oct 13 16:40:51 <CIA-57> freesmartphone.org: 03niklas.coding 07libframeworkd-glib * r2b3a275cafe3 10/src/odeviced/frameworkd-glib-odeviced-powersupply.h: Adjusted powersupply status strings.
Oct 13 16:50:36 <AinuFallback> quickdev: temporary adjustement I guess ?
Oct 13 16:50:43 <quickdev> yes, right
Oct 13 16:50:44 <AinuFallback> as mickeyl will surely modify it
Oct 13 16:51:04 <AinuFallback> quickdev: that's a pity, when I do code working directly, frameworkd isn't working ! :-)
Oct 13 16:51:38 <quickdev> doing code working directly?
Oct 13 16:53:07 <quickdev>     } else if(!strcmp(status, DBUS_DEVICE_POWER_STATE_EMPTY)) {
Oct 13 16:53:08 <quickdev>         return DEVICE_POWER_STATE_EMPTY;
Oct 13 16:53:08 <quickdev>     } 
Oct 13 16:53:08 <quickdev>     
Oct 13 16:53:08 <quickdev>     return DEVICE_POWER_STATE_CRITICAL;
Oct 13 16:53:23 <quickdev> AinuFallback, instead, we should fail if there isn't a proper condition..
Oct 13 16:53:38 <quickdev> else { g_error("invalid value"); }
Oct 13 16:53:59 <mickeyl> g_error( "undocumented value, spank FSO developers" );
Oct 13 16:54:01 <AinuFallback> I know, but I seriously don't care right now :-)
Oct 13 16:54:06 <quickdev> AinuFallback, it's working now
Oct 13 16:54:13 <AinuFallback> And in fact I almost did what mickeyl just told :-)
Oct 13 16:54:23 <AinuFallback> quickdev: we should normalize strings a bit too
Oct 13 16:54:32 <AinuFallback> and rename thingyBus in thingyInterface
Oct 13 16:54:47 <AinuFallback> But that's not important as is
Oct 13 16:55:03 <AinuFallback> quickdev: (doing code working directly : when my code works without even testing it)
Oct 13 16:55:21 <AinuFallback> (mickeyl's style, though with good strings :-p)
Oct 13 16:55:25 <quickdev> hrr :)
Oct 13 16:55:45 <AinuFallback> quickdev: did you think about the icons ?
Oct 13 16:56:13 <quickdev> not really yet, I think it's more important to have functionality ;)
Oct 13 16:56:22 <AinuFallback> I agree, I agree
Oct 13 16:56:33 <AinuFallback> Speaker out and dtmf then ?
Oct 13 16:56:41 <AinuFallback> mickeyl: what is the level of implementation of set audio scenario ?
Oct 13 16:56:49 <AinuFallback> Didn't see an answer to that before
Oct 13 16:57:07 <mickeyl> set/get/push/pop works
Oct 13 16:57:12 <mickeyl> no mixer control yet
Oct 13 16:57:16 <AinuFallback> What should we use then ?
Oct 13 16:57:17 <mickeyl> (individual)
Oct 13 16:57:20 <AinuFallback> Push/Pop ?
Oct 13 16:57:24 <mickeyl> yes
Oct 13 16:57:29 <mickeyl> push/pop is the best way
Oct 13 16:57:29 <AinuFallback> What is the behavior on Push then no pop ?
Oct 13 16:57:45 <AinuFallback> (i.e. I push "speaker out", and my correspondant hang up)
Oct 13 16:57:45 <AinuFallback> +s
Oct 13 16:57:50 <mickeyl> it will stay there forever atm.
Oct 13 16:57:56 <mickeyl> but i just have an idea
Oct 13 16:58:06 <mickeyl> i should listen for NameOwnerChangtes
Oct 13 16:58:08 <quickdev> AinuFallback, insert tickets....with things you want to have done ;)
Oct 13 16:58:24 <AinuFallback> mickeyl: I agree completly
Oct 13 16:58:30 <mickeyl> hmm *sigh* more work ;)
Oct 13 16:58:34 * mickeyl creates a ticket for him
Oct 13 16:59:24 <AinuFallback> Though it may be painful when I think about it
Oct 13 16:59:29 <AinuFallback> Let's take the following process :
Oct 13 16:59:32 <AinuFallback> ophonekitd binds to frameworkd
Oct 13 16:59:37 <AinuFallback> ophonekitd launches the dialer
Oct 13 16:59:40 <AinuFallback> dialer hits speaker out
Oct 13 16:59:48 <AinuFallback> dialer exits (ophonekitd is still there, dialer thread exited)
Oct 13 16:59:52 <AinuFallback> What now ?
Oct 13 17:00:04 <mickeyl> hmm, wait
Oct 13 17:00:18 <mickeyl> NameOwnerChange is only a bandaid against whole process crashes
Oct 13 17:00:26 <mickeyl> if your thread crashes, you should have a thread monitor builtin
Oct 13 17:00:33 <mickeyl> and deal with that there
Oct 13 17:00:41 <AinuFallback> mickeyl: I would suggest a whole different way
Oct 13 17:00:49 <AinuFallback> mickeyl: scenarii are dependant of a situation
Oct 13 17:00:56 <AinuFallback> you set scenarii within a given "state"
Oct 13 17:00:59 <AinuFallback> i.e. "on call"
Oct 13 17:01:10 <AinuFallback> why not pop everything until the initial state is reached ?
Oct 13 17:01:21 <AinuFallback> i.e. build a kind of frame pointer ?
Oct 13 17:01:50 <mickeyl> interesting
Oct 13 17:01:52 <mickeyl> food for thought
Oct 13 17:02:25 <AinuFallback> mickeyl: and it could fit well in oeventsd
Oct 13 17:02:40 <AinuFallback> on an event, historize the current state, and push the expected state
Oct 13 17:02:58 <AinuFallback> then at the end of the event, pop everything until state is reached
Oct 13 17:03:28 <mickeyl> who defines what kind of events we know and what scenario relates to which event
Oct 13 17:03:49 <AinuFallback> I thought this was opreferencesd
Oct 13 17:04:21 <quickdev> mickeyl, were you able to correct the build error?
Oct 13 17:04:39 <mickeyl> quickdev: i don't know, at least i changed the preferred versions
Oct 13 17:04:44 <mickeyl> my build crashes on something else atm.
Oct 13 17:05:43 <alphaone>  make[1]: MKDIR_P@: Command not found
Oct 13 17:05:46 <mickeyl> wrt. audio scenario, i really don't want to change too much until i have at least seen _one_ other command
Oct 13 17:05:53 <mickeyl> s/command/set of scenarios
Oct 13 17:06:06 <mickeyl> i.e. openezx
Oct 13 17:06:11 <mickeyl> or HTC
Oct 13 17:06:13 <mickeyl> or wahtnot
Oct 13 17:06:26 <quickdev> alphaone, yes, still the same issue
Oct 13 17:06:33 <quickdev> wrong autotools version..
Oct 13 17:06:38 <AinuFallback> mickeyl: I don't think the two things are truly related
Oct 13 17:06:58 <AinuFallback> If you push a scenario for calls, you can restore the previous one regardless of the "type"
Oct 13 17:07:42 <mickeyl> bbiab, dinner finally
Oct 13 17:08:53 <mwester> alphaone:  if the version of gettext or autotools has been changed, you need to arrange to have the configure task re-run on the failing recipes.
Oct 13 17:09:33 <alphaone> mwester: Which is what I did
Oct 13 17:09:45 <mwester> :( Ok.
Oct 13 17:09:46 <AinuFallback> wurp2|working: thanks for your mail
Oct 13 17:09:56 <AinuFallback> it's really good to see your words again :-p
Oct 13 17:10:14 <AinuFallback> Even if you made a huge mistake about what I did :-p
Oct 13 17:10:32 <AinuFallback> I did naught on libframeworkd-gtk which doesn't exist :-)
Oct 13 17:10:46 <AinuFallback> I worked on ophonekitd/libframeworkd-glib and an abstract definition of libframeworkd-phonegui :-)
Oct 13 17:11:00 <AinuFallback> quickdev: is buildhost up to date regarding our latest patches ?
Oct 13 17:11:41 <quickdev> girlfriend is here...I don't know...check it ;)
Oct 13 17:11:51 <quickdev> I'm away
Oct 13 17:12:01 <AinuFallback> Lazy ass :-)
Oct 13 17:12:05 <AinuFallback> (good night then :-) )
Oct 13 17:12:52 <wurp2|working> AinuFallback: np :-)
Oct 13 17:12:56 <wurp2|working> dammit
Oct 13 17:13:08 <AinuFallback> What ?
Oct 13 17:13:20 <mwester> he stubbed his toe.
Oct 13 17:13:32 <wurp2|working> AinuFallback: You said thx for email, I said np
Oct 13 17:13:42 <wurp2|working> dammit, I messed up the name of the lfg
Oct 13 17:13:54 <AinuFallback> mwester: I thought he had broken his hip
Oct 13 17:14:54 <wurp2|working> awesome
Oct 13 17:15:05 <wurp2|working> "Help, I've fallen and I can't get up!"
Oct 13 17:15:12 <AinuFallback> :-)
Oct 13 17:21:24 <AinuFallback> Does anybody knows how to play sid files on the freerunner ?
Oct 13 17:32:50 <dos1> hmm, hi
Oct 13 17:33:38 <dos1> what do efl applications on shr?
Oct 13 17:34:12 <AinuFallback> I didn't tell you were a fucknut wurp2|working :-)
Oct 13 17:34:14 <AinuFallback> dos1: yes
Oct 13 17:35:33 <dos1> AinuFallback: but what they do? :D i was sure that shr is a project to port GTK/2007.2 gui apps to fso frameworkd
Oct 13 17:36:04 <AinuFallback> Oh I misread your question
Oct 13 17:36:14 <dos1> maybe i was wrong, so i'm asking ;)
Oct 13 17:36:16 <AinuFallback> SHR isn't a project to strictly port GTK apps to FSO
Oct 13 17:36:28 <AinuFallback> It's first and foremost intended to be a community driven distro
Oct 13 17:36:38 <AinuFallback> Fact : the people working on the gtk port of the dialer are quite busy these days
Oct 13 17:36:38 <wurp2|working> heh
Oct 13 17:36:43 <AinuFallback> feel free to help them :-)
Oct 13 17:36:58 <wurp2|working> dos1: Julien and I had just this argument this morning :-)
Oct 13 17:37:26 <dos1> hmm
Oct 13 17:38:14 <AinuFallback> dos1: the whole system is intended to offer the user the ability to chose its UI based on some stable choices
Oct 13 17:38:24 <AinuFallback> +o
Oct 13 17:39:05 <AinuFallback> The main goal being to control a distribution as a community
Oct 13 17:39:19 <AinuFallback> And to offer stable choices for telephony applications
Oct 13 17:39:20 <dos1> ok, but porting gtk apps is still doing and will continue (of course if there will be people working on it), is it?
Oct 13 17:39:26 <AinuFallback> Indeed
Oct 13 17:39:41 <AinuFallback> Though right now I don't know anyone working on it :-p
Oct 13 17:40:13 <dos1> AinuFallback: you said that they are busy :x
Oct 13 17:40:23 <AinuFallback> Busy on personal matters
Oct 13 17:40:28 <dos1> yes
Oct 13 17:40:37 <AinuFallback> Hence they're not working on it :-)
Oct 13 17:40:53 <AinuFallback> And I won't try by myself as I have no taste whatsoever
Oct 13 17:41:08 <dos1> but when personal matters... finish? (heh, my english :D) they maybe will do it?
Oct 13 17:41:41 <AinuFallback> I do hope so
Oct 13 17:41:48 <AinuFallback> But we would welcome your help
Oct 13 17:41:54 <dos1> or when someone will continue their work, he can do it in shr project?
Oct 13 17:41:56 <dos1> ok :)
Oct 13 17:41:58 <AinuFallback> A lot of work has already been done on that
Oct 13 17:42:10 <AinuFallback> We're open to everyone
Oct 13 17:42:18 <AinuFallback> And wurp2|working's more open than anyone
Oct 13 17:42:20 <AinuFallback> :->
Oct 13 17:42:43 <dos1> i will check what can i do in spare time ;)
Oct 13 17:43:49 <AinuFallback> You're indeed w elcome to do it
Oct 13 17:43:57 <AinuFallback> Anyhow I have to go home
Oct 13 17:44:01 <AinuFallback> See you guys :-)
Oct 13 17:44:06 <dos1> cu ;)
Oct 13 17:51:59 <wurp2|working> AinuFallback: You always flirt, but you never follow through.
Oct 13 18:23:35 <Ainulindale> quickdev ?
Oct 13 18:23:41 <Ainulindale> Did you commit the fix for the NULL handler ?
Oct 13 18:25:15 <sicu> i think he's commited to his gf right now :p
Oct 13 18:25:20 <sicu> hey btw =D
Oct 13 18:25:56 <dos1> Ainulindale: yep:
Oct 13 18:25:57 <dos1> (19:09:34) quickdev: girlfriend is here...I don't know...check it ;)
Oct 13 18:25:57 <dos1> (19:09:44) quickdev: I'm away
Oct 13 18:25:58 <dos1> ;)
Oct 13 18:26:46 <Ainulindale> I don't think he did as last update still bugs on idle notification
Oct 13 18:28:41 <sicu> sigh, my gf has driven off with my car (FR neatly stacked away in the glove compartment) and she'll be gone for a few hrs ... *cries*
Oct 13 18:28:52 <sicu> i need something to keep me occupied
Oct 13 18:28:53 <Ainulindale> Life is a bitch :-)
Oct 13 18:29:59 <sicu> Ainulindale: any specific way of moving tickets from old track to new?
Oct 13 18:30:08 <Ainulindale> Hmmm
Oct 13 18:30:10 <Ainulindale> Elbow grease ?
Oct 13 18:30:20 <sicu> meh ;p
Oct 13 18:31:01 <sicu> so just creating duplicate tickets in the new track and then deleting from the old ? ie manual labour? ;p
Oct 13 18:31:17 <quickdev> Ainulindale, yes, I commited the NULL fix
Oct 13 18:32:20 <Ainulindale> Then it wasn't compiled
Oct 13 18:32:26 <quickdev> yeah
Oct 13 18:32:27 <Ainulindale> Or PR wasn't incremented
Oct 13 18:33:46 <Ainulindale> Meanwhile in Paris, I'm eating pickles
Oct 13 18:33:54 <Ainulindale> Yay o/
Oct 13 18:34:13 <Ainulindale> quickdev: will you increment PR or do you want me to do it ?
Oct 13 18:34:25 <quickdev> Ainulindale, revision was incremented to 4(!)...but it was not compiled..
Oct 13 18:34:30 <Ainulindale> Weird
Oct 13 18:34:43 <Ainulindale> Same for lfg modification I guess ?
Oct 13 18:35:05 <quickdev> http://shr.bearstech.com/shr-testing/ipk/armv4t/ - here we can have a look
Oct 13 18:35:11 <Ainulindale> I know, I did
Oct 13 18:35:13 <Ainulindale> No modification
Oct 13 18:36:07 <quickdev> bitbake libframeworkd-glib ; bitbake package-index....but that does not work
Oct 13 18:37:27 <Ainulindale> My guess is PR is wrong :-)
Oct 13 18:37:40 <Ainulindale> It must base its versioning on lexical order
Oct 13 18:38:18 <quickdev> I don't know...
Oct 13 18:38:28 <quickdev> but there are still build errors
Oct 13 18:39:03 <quickdev> maybe you can compare it for example with the frameworkd_git.bb package
Oct 13 18:39:10 <Ainulindale> I was just doing that
Oct 13 18:39:15 <quickdev> ok, fine :)
Oct 13 18:39:20 <quickdev> afk..see you later
Oct 13 18:50:52 <Ainulindale> quickdev: well, regenerating the package right now
Oct 13 18:51:00 <Ainulindale> +s
Oct 13 19:21:31 <quickdev> Ainulindale, how did you do it?
Oct 13 19:59:57 <sicu> quickdev?
Oct 13 20:01:56 <quickdev> sicu?
Oct 13 20:02:26 <sicu> it's alive! =]
Oct 13 20:04:44 <sicu> quickdev: i just moved tasks from old to new trac, but you guys that have login credentials will have to make sure the tasks are assigned correctly
Oct 13 20:09:11 <sicu> quickdev: you were probably assigned a few of the first tickets mistakenly as you were selected by default ... *g* ... and once created i couldnt go back in and edit
Oct 13 20:09:53 <quickdev> brb
Oct 13 20:09:55 <sicu> quickdev: and ofcourse i don't have access to delete the tasks from old track either
Oct 13 20:19:11 <Ainulind1le> quickdev: bitbaked them clean and compiled again
Oct 13 20:25:00 <quickdev> back
Oct 13 20:25:15 <quickdev> sicu, first of all, thanks for participating :)
Oct 13 20:29:26 <sicu> quickdev: np, needed something to do while waiting for my FR to come back home
Oct 13 20:30:03 <sicu> quickdev: hope i didn't clutter the trac too much =p
Oct 13 20:31:08 <quickdev> sicu, you could have saved some work, because there are a few invalid / already fixed tickets :) I'll clean it up a bit...but anyway it's a valuable work ;)
Oct 13 20:31:14 <wurp2|working> AinuFallback: regarding you calling me a fucknut
Oct 13 20:31:19 <wurp2|working> Of course you didn't
Oct 13 20:31:31 <wurp2|working> But it's much more entertaining if I imply that you did
Oct 13 20:32:14 <quickdev> just read it, hehe
Oct 13 20:35:51 <sicu> quickdev: i did figure a few of them were invalid whilst going through, but by then i was already in copy&paste mindset, so there was no stopping me ;p
Oct 13 20:36:18 <wurp2|working> Does anyone know if om-mediaplayer3 plays on SHR?
Oct 13 20:37:51 <Ainulindale> quickdev: bitbaked them clean and compiled again
Oct 13 20:37:52 <quickdev> wurp2|working, see comment: http://shr.bearstech.com/trac/ticket/19
Oct 13 20:38:14 <quickdev> Ainulindale, that should somehow work automatically in future..
Oct 13 20:38:14 <Ainulindale> Anyway I probably won't be able to answer any comment on that
Oct 13 20:38:25 <Ainulindale> First because I'm going to take a bath
Oct 13 20:38:33 <Ainulindale> Second because my connection thinks it's a yoyo
Oct 13 20:38:44 <Ainulindale> quickdev: that's the way it's supposed to be
Oct 13 20:39:01 <Ainulindale> But I don't know which var has to be set to what to build automatically on HEAD and consider revision
Oct 13 20:39:12 <Ainulindale> I started a little shr-autorev.inc file in the conf directory
Oct 13 20:39:20 <Ainulindale> But didn't manage to include it, it failed miserably
Oct 13 20:39:32 <Ainulindale> Anyway, I'm off to bath, see you in an hour or so if my connection is alive by then
Oct 13 20:39:33 <quickdev> ok..
Oct 13 20:39:47 <Ainulindale> quickdev: oh and
Oct 13 20:39:50 <quickdev> yeah..don't know if I'm still here in an hour, we'll see ;)
Oct 13 20:39:57 <Ainulindale> all the things work perfectly here now
Oct 13 20:40:11 <Ainulindale> except that the hang up button is really reaaaaally badly located
Oct 13 20:40:16 <Ainulindale> I keep hanging up answered calls
Oct 13 20:40:23 <quickdev> hrrr :)
Oct 13 20:40:27 <Ainulindale> Anyway, see you
Oct 13 20:40:34 <quickdev> suspend works well :)
Oct 13 20:42:57 <sicu> quickdev: http://shr.bearstech.com/trac/report/6
Oct 13 20:43:15 <sicu> quickdev: see, it wasnt wasted ... looks much better with a few fixed tickets =]
Oct 13 20:43:29 <sicu> and more realistic with a few invalid ones too ;p
Oct 13 20:49:03 <quickdev> sicu, I changed a few titles and tickets are almost clean now :)
Oct 13 20:49:41 <mwester> quickdev:  yes, but suspend is the easy half of the job!
Oct 13 20:49:46 <sicu> quickdev: looking good =]
Oct 13 20:50:35 <quickdev> mwester, yes, but it kept me from using it as my sole phone
Oct 13 20:54:06 <mwester> I mean, does it resume also?
Oct 13 20:54:51 <quickdev> mwester, yes, it does
Oct 13 20:55:03 <mwester> :)  That's good then!
Oct 13 20:55:54 <quickdev> mwester, have you ever tested the battery lifetime in suspend?
Oct 13 20:56:59 <mwester> I've tried, but never obtained very consistent results -- I now believe the "bouncy calypso" is the reason; "big sleep" vs "deep sleep" on the calypso is a 5x difference in power draw for the GSM while suspended.
Oct 13 20:57:11 <mwester> Approx 24 - 36 hours is what I generally see.
Oct 13 20:57:14 <mwester> Should be better.
Oct 13 21:00:54 <quickdev> ah, ok...hopefully bouncy calypso gets fixed eventually
Oct 13 21:02:02 <mwester> I have little hope, actually. :(
Oct 13 21:03:28 <mwester> I think that GSM has been obsolete for many years, and it's unlikely that TI will dust off the backup copies of source code and set up a dev system, just to help out Openmoko with a total unit volume of only a few thousand or so units.
Oct 13 21:04:15 <wurp2|working> How well does SHR handle an incoming call while the phone is suspended?
Oct 13 21:04:28 <mwester> Money fixes everything, but since Om dumped support for the GTA01 before the GTA02 was even shipping in quantity, I can't see Om being willing to make the many tens of thousands of dollars commitement that TI would probably demand to get that GSM fixed.
Oct 13 21:04:30 <wurp2|working> mwester: What is the alternative to GSM?
Oct 13 21:04:54 <mwester> GSM is the standard; there are many alternate GSM modems available.
Oct 13 21:05:11 <wurp2|working> You said GSM has been obsolete for many years
Oct 13 21:05:18 <wurp2|working> To me that implies that there is a better alternative
Oct 13 21:05:18 <quickdev> wurp2|working, he meant the modem ;)
Oct 13 21:05:32 <wurp2|working> Oh!
Oct 13 21:05:33 <mwester> :)  I should have put emphasis on "THAT" gsm.
Oct 13 21:05:34 <wurp2|working> Not "I think that"
Oct 13 21:05:40 <wurp2|working> But "that GSM"
Oct 13 21:05:42 <mwester> The Calypso has been obsolete.
Oct 13 21:05:45 <wurp2|working> ic now
Oct 13 21:06:28 <wurp2|working> so why the hell did OM choose it if it's been obsolete for years?
Oct 13 21:07:00 <mwester> As someone phrased in on IRC when the GSM modem was first identified a couple of years ago, they said that FIC must have rescued a few pallet-loads of them from the dumpster in back of the building.
Oct 13 21:07:10 <wurp2|working> agh
Oct 13 21:07:42 <mwester> THe GTA01 hardware design was inherited, it had that GSM on it.
Oct 13 21:07:45 <wurp2|working> With how independent it is, I would think it wouldn't be untenable to replace it w/ something else
Oct 13 21:07:45 <mwester> (I think)
Oct 13 21:08:03 <wurp2|working> I know any hw redesign is not cheap by a long shot
Oct 13 21:08:13 <mwester> It would be easy to replace during design.
Oct 13 21:08:41 <wurp2|working> but the press you get from delivering something broken is not cheap either
Oct 13 21:09:20 <mwester> You know, I believe that -- but Om has constantly amazed me by seeming to not believe that.
Oct 13 21:10:24 <mwester> Assuming Om sold 5000 of the GTA0x units, consider the traffic on the ML and IRC -- where are all those people?
Oct 13 21:10:44 <quickdev> mwester, the calypso does not bounce after an outgoing call, right?
Oct 13 21:10:45 <mwester> At $500 each, I would think they would be storming the headquarters over these issues.
Oct 13 21:11:01 <mwester> quickdev:  Only with Qtopia 4.3.x
Oct 13 21:11:19 <mwester> quickdev:  with FSO, it continued to bounce.  Dunno why!?
Oct 13 21:11:57 <quickdev> I don't know either, but maybe one could try to send a USSD...it could make it act like an outgoing call 
Oct 13 21:14:44 <mwester> I tried various things that I could, not sure about a USSD though.  Text messages in or out do not fix it, dialing a non-existent number does not fix it, but an incoming or outgoing call will fix it, even if that call is not answered.
Oct 13 21:14:58 <mwester> But only on Qtopia 4.3.x -- not on FSO, nor on QT Extended.
Oct 13 21:16:29 <quickdev> very strange ;)
Oct 13 21:16:34 <quickdev> alphaone, here?
Oct 13 21:17:29 <lpotter> hmm
Oct 13 21:32:45 <sicu> ok, just finished flashing SHR
Oct 13 21:33:48 <sicu> let's take this baby for a test-ride =]
Oct 13 21:34:47 <quickdev> sicu, upgrade your packages ;)
Oct 13 21:39:29 <sicu> ..done..
Oct 13 21:42:57 <quickdev> very basic things should work
Oct 13 21:44:31 <sicu> will test it ...
Oct 13 21:44:37 <sicu> but gotta run now
Oct 13 21:44:40 <sicu> back later ... ciao
Oct 13 21:46:22 <FilipLinux4BE> mwester: could it be related to the uart it's connected to , and not the actual modem ? 
Oct 13 21:46:57 <wurp2|working> mwester: So you just have to decide what toll free # you're going to call, let ring once, & hang up on when the bouncy problem starts
Oct 13 21:47:46 <mwester> FilipLinux4BE:  very unlikely, but I do not have equipment to get access to the modem control lines on the FR to see what happens during suspend.  I asked Om to do that test, they did not ever respond.
Oct 13 21:48:31 <mwester> wurp2|working:  :D  I hacked in code to make it call my voicemail number each time it restarted.
Oct 13 21:48:48 <mwester> Then found the %SLEEP which seemed the better solution. :)
Oct 13 21:52:06 <Ainulindale> quickdev: we should put the image generation back in the process for the night
Oct 13 21:52:07 <DocScrutinizer> mwester: did U compare the reulting quiescent current though?
Oct 13 21:52:28 <DocScrutinizer> *resulting
Oct 13 21:52:51 <mwester> DocScrutinizer:  No.  That's a task on a yellow sticky-note stuck on my desk here that I've not ever gotten to.
Oct 13 21:53:18 <quickdev> Ainulindale, done
Oct 13 21:53:19 <Ainulindale> Hey guys, do you have any kind of software to do suspend monitoring ?
Oct 13 21:53:19 <DocScrutinizer> mwester: I hope on topmost position
Oct 13 21:53:31 <Ainulindale> that wasn't a request quickdev :-)
Oct 13 21:53:36 <Ainulindale> just merely a request for your opinion
Oct 13 21:53:40 <mwester> It's important, because it would tell us if the phone call completion set the sleep mode to 2, or if it did something to make deep sleep actually work.
Oct 13 21:53:45 <quickdev> ack and done ;)
Oct 13 21:54:54 <quickdev> Ainulindale, do you know how to copy a g_value_array?
Oct 13 21:55:09 <DocScrutinizer> mwester: just send LEEP=4 after call, and see the osc restart?
Oct 13 21:55:17 <DocScrutinizer> DUH???
Oct 13 21:55:36 <wurp2|working> mwester: But I thought sleep put it into non-deep sleep
Oct 13 21:55:37 <DocScrutinizer> % SLEEP = 4
Oct 13 21:55:46 <Ainulindale> quickdev: no but google does I think :-p
Oct 13 21:55:51 <Ainulindale> I had to do that somewhere but can't remember how
Oct 13 21:55:54 <wurp2|working> It sounded as if making a call just made deep sleep work until it goes bouncy again
Oct 13 21:56:05 <quickdev> Ainulindale, google does not..I already tried
Oct 13 21:56:40 <mwester> wurp2|working:  We don't know that making a call makes deep sleep work, or if it does something to limit the device to only using big sleep.
Oct 13 21:56:42 <Ainulindale> is g_value_array a glib type ?
Oct 13 21:56:46 <Ainulindale> or some efl construction ?
Oct 13 21:56:47 <DocScrutinizer> sorry have to test  as it seems strange
Oct 13 21:56:55 <mwester> Looks strange here.
Oct 13 21:57:21 <mwester> HTML encoding?
Oct 13 21:57:27 <quickdev> Ainulindale, a glib type
Oct 13 21:57:31 <DocScrutinizer> dunno
Oct 13 21:57:43 <Ainulindale> quickdev: weird then, can't find mention of this type anywhere
Oct 13 21:57:57 <Ainulindale> 10 results on google
Oct 13 21:58:00 <quickdev> GValueArray
Oct 13 21:58:02 <DocScrutinizer> percent-S
Oct 13 21:58:13 <Ainulindale> Ah yes sounds better
Oct 13 21:58:14 <Ainulindale> dumb me
Oct 13 21:58:25 <Ainulindale> Then I would suggest g_value_array_copy :-)
Oct 13 21:58:27 <DocScrutinizer> maybe a shortcut of Konversation
Oct 13 21:58:35 <Ainulindale> (says google)
Oct 13 21:58:40 <mwester> KDE user, then?
Oct 13 21:58:45 <Ainulindale> http://library.gnome.org/devel/gobject/unstable/gobject-Value-arrays.html
Oct 13 21:58:45 <DocScrutinizer> yup
Oct 13 21:59:55 <DocScrutinizer> mwester: this really puzzeld me: /nyu (uʍop ǝpısdn sı ɹoʇıuoɯ ɹnoʎ)
Oct 13 22:00:11 <mwester> hehe!
Oct 13 22:00:11 <Ainulindale> marf
Oct 13 22:00:13 <DocScrutinizer> mwester: from some user nick
Oct 13 22:00:48 <Ainulindale> You should work rather than procrastinating DocScrutinizer ! :-)
Oct 13 22:00:56 <quickdev> Ainulindale, argh, how could I have overlooked that -_-
Oct 13 22:01:10 <Ainulindale> quickdev: seems you're getting as lazy as me
Oct 13 22:01:22 <quickdev> no, I'm young!
Oct 13 22:01:23 <DocScrutinizer> just woke up, doing finger warmup only ;-)
Oct 13 22:01:43 <Ainulindale> DocScrutinizer: This leads me to some really naughty thoughts
Oct 13 22:01:58 <Ainulindale> Which I won't talk about as we have some youngster here
Oct 13 22:02:06 <DocScrutinizer> well it's Ur thoughts ;-)
Oct 13 22:02:27 <Ainulindale> Going to do my house here and pop my pills (nicopass o/) down
Oct 13 22:02:38 <Ainulindale> (House as in House MD)
Oct 13 22:02:49 <DocScrutinizer> :D
Oct 13 22:02:59 <Ainulindale> People call me House at the office :-/
Oct 13 22:03:08 <Ainulindale> They say I'm cranky and sarcastic
Oct 13 22:03:10 <DocScrutinizer> prefer the real stuff, as long as not on flight
Oct 13 22:03:36 <DocScrutinizer> Ainulindale: so probably you're my hero
Oct 13 22:03:45 <Ainulindale> What ?
Oct 13 22:04:03 <DocScrutinizer> *LOVE* House- MD
Oct 13 22:04:13 <Ainulindale> Heh
Oct 13 22:04:18 <Ainulindale> Same here
Oct 13 22:04:25 <Ainulindale> And by the way you should watch Black Adder
Oct 13 22:04:35 <DocScrutinizer> lol
Oct 13 22:04:38 <Ainulindale> Laurie playing some stupid noble
Oct 13 22:04:44 <DocScrutinizer> know it
Oct 13 22:04:46 <Ainulindale> Quite funny, I love it
Oct 13 22:05:49 <wurp2|working> mwester: I see (re: big vs deep sleep after making call) 
Oct 13 22:06:04 <wurp2|working> So, you can't ask the gsm what sleep mode it's in?
Oct 13 22:06:07 <Ainulindale> By the way quickdev 
Oct 13 22:06:08 <wurp2|working> Or at least, we dunno how?
Oct 13 22:06:11 <Ainulindale> Only thing left to do for suspend
Oct 13 22:06:16 <Ainulindale> prevent suspend while in a call
Oct 13 22:06:28 <quickdev> Ainulindale, yes...but that's no problem...right?
Oct 13 22:06:31 <quickdev> could you do it?
Oct 13 22:06:35 <Ainulindale> Indeed, indeed
Oct 13 22:06:39 <wurp2|working> Ainulindale: How well does resume on incoming call work?
Oct 13 22:06:45 <Ainulindale> wurp2|working: very well
Oct 13 22:06:52 <wurp2|working> Woohoo!
Oct 13 22:06:54 <Ainulindale> I didn't notice any loss
Oct 13 22:06:57 <mwester> wurp2|working:  Yes, TI left the %SLEEP=<n> command in, but they did not implement the %SLEEP=? command.
Oct 13 22:07:02 <wurp2|working> 'cause it doesn't work so well on qtopia
Oct 13 22:07:09 <wurp2|working> mwester: :-(
Oct 13 22:07:18 <Ainulindale> That's because qtopia is crap !
Oct 13 22:07:26 <wurp2|working> I should say, it doesn't work so well on qtext
Oct 13 22:07:29 <wurp2|working> dunno about others
Oct 13 22:08:38 <ljp> itsnot that qtopia is crap, its that the friggin hardware doesn't always respnd well withthat sleep command
Oct 13 22:08:38 <alphaone> quickdev: What's up?
Oct 13 22:09:02 <ljp> so, in essence, the hardware is crap
Oct 13 22:09:16 <ljp> or should I say firmware
Oct 13 22:09:33 <quickdev> alphaone, when getting an incoming call in suspend the screens brightness is not set....screen stays black...when I touch the touchscreen everything is there..is that known?
Oct 13 22:10:08 <Ainulindale> quickdev: do you know how to count items in a gptrarray ? :-)
Oct 13 22:10:13 <Ainulindale> Or should I google it ?
Oct 13 22:10:43 <Ainulindale> quickdev: we can listen for AWAKE and set the brightness to 100
Oct 13 22:10:47 <quickdev> Ainulindale, I don't know
Oct 13 22:11:04 <alphaone> quickdev: Maybe just set brightness as well in the incoming call rule?
Oct 13 22:11:10 <quickdev> Ainulindale, shouldn't frameworkd handel that?
Oct 13 22:11:21 <Ainulindale> quickdev: Yes it should but if it doesn't
Oct 13 22:11:29 <Ainulindale> Ah, if we can do what alphaone describes then yay
Oct 13 22:11:51 <alphaone> should be entirely possible
Oct 13 22:13:08 <Ainulindale> quickdev: FYI : array->len
Oct 13 22:13:25 <quickdev> Ainulindale, FYI?
Oct 13 22:13:29 <Ainulindale> For your information
Oct 13 22:15:01 <Ainulindale> Ok, implementation done
Oct 13 22:15:05 <Ainulindale> will try that immediately
Oct 13 22:15:22 <quickdev> fine :)
Oct 13 22:15:58 <Ainulindale> quickdev: see ? things tend to go faster when there's some emulation
Oct 13 22:16:08 <Ainulindale> it's always better to work when you're not alone :-)
Oct 13 22:16:53 <quickdev> yes, it is..hehe ;)
Oct 13 22:17:16 <Ainulindale> I'm quite happy with this suspend thing
Oct 13 22:17:25 <Ainulindale> Will have a look at rules also
Oct 13 22:17:31 <quickdev> yes, it's quite usable :)
Oct 13 22:17:38 <Ainulindale> quickdev: please please please
Oct 13 22:17:42 <Ainulindale> "close" button !
Oct 13 22:17:54 <Ainulindale> And do you think it's possible to set actual names to windows ?
Oct 13 22:18:02 <Ainulindale> Because if you launch dialer & contacts
Oct 13 22:18:06 <Ainulindale> it's "phonegui"
Oct 13 22:18:42 <quickdev> yes, it is possible to set window titles
Oct 13 22:18:54 <quickdev> and the X button is a little bit more difficult..we have to change the illume theme
Oct 13 22:18:59 <quickdev> maybe raster could do that
Oct 13 22:19:09 <quickdev> can you please create tickets for all these things? :)
Oct 13 22:19:15 <Ainulindale> Why not just put a little button ?
Oct 13 22:19:36 <Ainulindale> (when I'll get through my ophonekitd modification of course I will)
Oct 13 22:19:49 <Ainulindale> (Seeing tons of tickets assigned to you warms my cold heart)
Oct 13 22:20:25 <quickdev> a button in our applications or in illume? Illume should be the way to go..
Oct 13 22:20:32 <Ainulindale> In our application, as for now
Oct 13 22:20:39 <Ainulindale> illume already has remove and I think it is enough
Oct 13 22:20:40 <quickdev> that would be possible
Oct 13 22:20:45 <Ainulindale> Although the key is redundancy
Oct 13 22:20:54 <quickdev> yes, shouldn't be redundant
Oct 13 22:20:59 <quickdev> illume should have X
Oct 13 22:21:11 <Ainulindale> Err no
Oct 13 22:21:12 <Ainulindale> My point was
Oct 13 22:21:17 <Ainulindale> illume has X ("remove")
Oct 13 22:21:21 <Ainulindale> It should be redundant :-)
Oct 13 22:21:30 <Ainulindale> The remove button isn't that practical
Oct 13 22:21:38 <Ainulindale> And as for now, redundancy is the way to go :-)
Oct 13 22:21:52 <Ainulindale> A little X somewhere isn't that space consuming to me
Oct 13 22:21:55 <Ainulindale> but you're the efl master
Oct 13 22:22:32 <quickdev> yes, but on the long term illume should provide that X
Oct 13 22:22:45 <Ainulindale> I think raster will object somehow :-p
Oct 13 22:22:51 <Ainulindale> And ask for use cases
Oct 13 22:26:20 <methril|laptop> someone up?
Oct 13 22:26:28 <Ainulindale> yep
Oct 13 22:26:38 <Ainulindale> quickdev: experienced a weird bug testing my modification
Oct 13 22:26:42 <Ainulindale> which is working by the way
Oct 13 22:26:47 <Ainulindale> Call was active
Oct 13 22:27:02 <methril|laptop> i'd like to test the latest frameworkd (python) what dependencies i need?
Oct 13 22:27:06 <Ainulindale> But the active window gave way to the dialer window
Oct 13 22:27:18 <Ainulindale> gsm0710muxd I'd say
Oct 13 22:27:22 <methril|laptop> well, i really like to port it, but i don't know the daemon services
Oct 13 22:27:25 <methril|laptop> only?
Oct 13 22:27:31 <Ainulindale> And a recent kernel
Oct 13 22:27:35 <Ainulindale> methril|laptop: port what ?
Oct 13 22:27:37 <methril|laptop> this is for gsm, isn't it?
Oct 13 22:27:42 <Ainulindale> yes
Oct 13 22:27:49 <raster> Ainulindale: i've removed remove
Oct 13 22:27:50 <methril|laptop> well, test the frameworkd to antoher platform
Oct 13 22:27:50 <quickdev> Ainulindale, reproduce it ;)
Oct 13 22:28:02 <Ainulindale> quickdev: GLib-GObject-WARNING **: gvalue.c:89: cannot initialize GValue with type `GPtrArray_GValueArray_gint+gchararray+GHashTable_gchararray+GValue___', the value has already been initialized as `(null)'
Oct 13 22:28:04 <raster> i really dont like the sean-designed remove + list of apps
Oct 13 22:28:05 <methril|laptop> port gsm071muxd :)
Oct 13 22:28:07 <Ainulindale> Hmpf hmpf hmpd
Oct 13 22:28:09 <raster> its silly
Oct 13 22:29:03 <Ainulindale> quickdev: there's some bug here it seems, probably introduced by me
Oct 13 22:29:06 <Ainulindale> Now the question is
Oct 13 22:29:14 <Ainulindale> Is list active calls working at all ?
Oct 13 22:29:36 <quickdev> good question, try the mdbus utility first
Oct 13 22:29:44 <Ainulindale> I meant the lfg one
Oct 13 22:29:46 <Ainulindale> quickdev: oh and
Oct 13 22:29:53 <Ainulindale> you should definitely implement DTMF
Oct 13 22:29:56 <raster> http://www.rasterman.com/files/illume-buttons.png
Oct 13 22:29:59 <raster> thats how i now have it
Oct 13 22:30:00 <Ainulindale> I had a message from someone's pocket
Oct 13 22:30:05 <raster> back to my original illume ui design
Oct 13 22:30:44 <quickdev> raster, better, but why no X in the main bar? one click close
Oct 13 22:31:00 <quickdev> Ainulindale, DTMF, yes, ticketed..
Oct 13 22:31:02 <Ainulindale> quickdev: Ah and well it killed ophonekitd
Oct 13 22:31:11 <quickdev> what killed ophonekitd? ;)
Oct 13 22:31:14 <Ainulindale> So I guess marshalling is borking
Oct 13 22:31:28 <Ainulindale> My modification
Oct 13 22:31:44 <raster> quickdev: safety
Oct 13 22:31:51 <raster> as its a touchscreen
Oct 13 22:31:56 <raster> u cant accidentally close as easily
Oct 13 22:32:01 <raster> as its inaccurate
Oct 13 22:32:17 <raster> and pressing some thnig on the top of a window may result in a press of a close button instead
Oct 13 22:32:20 <Ainulindale> What's annoying with raster is that he has an answer to everything
Oct 13 22:32:20 <quickdev> Ainulindale, have you seem raster's theme?
Oct 13 22:32:24 <Ainulindale> But as he's often right... =)
Oct 13 22:32:34 <raster> heheheh
Oct 13 22:32:36 <Ainulindale> quickdev: yes
Oct 13 22:32:36 <raster> :)
Oct 13 22:32:46 * raster dials up his annoying meter to max
Oct 13 22:33:15 <Ainulindale> quickdev: you didn't use listcalls in your implementation did you ?
Oct 13 22:33:22 <raster> i tend to think stuff through when i do things
Oct 13 22:33:23 <raster> or before
Oct 13 22:33:31 <raster> so thats why i tend to have an answer to it...
Oct 13 22:33:31 <wurp2|gone> I prefer afterwards
Oct 13 22:33:32 <raster> :)
Oct 13 22:33:32 <Ainulindale> quickdev: because just by seeing the marshalling needed for that he's an eloquent answer
Oct 13 22:33:37 <Ainulindale> s/by//
Oct 13 22:33:39 <Ainulindale> => a(isa{sv})
Oct 13 22:33:57 <methril|laptop> well, time to sleep here
Oct 13 22:34:01 <methril|laptop> you never sleep?
Oct 13 22:34:03 <methril|laptop> :)
Oct 13 22:34:55 <quickdev> Ainulindale, haven't ever used list calls
Oct 13 22:35:04 <Ainulindale> quickdev: ok so I think this is a marshalling problem
Oct 13 22:35:13 <quickdev> yeah, as always ;)
Oct 13 22:35:16 <Ainulindale> I don't want to dwelve in dbus marshalling again :-/
Oct 13 22:35:34 <Ainulindale> grmbl
Oct 13 22:35:35 <Ainulindale> to dive
Oct 13 22:36:56 <Ainulindale> dbus_g_type_get_collection ("GPtrArray", dbus_g_type_get_struct ("GValueArray", G_TYPE_INT, G_TYPE_STRING, dbus_g_type_get_map ("GHashTable", G_TYPE_STRING, G_TYPE_VALUE), G_TYPE_INVALID)) <= meeeh
Oct 13 22:41:04 <Ainulindale> Weird it seems to be registered
Oct 13 22:41:40 <Ainulindale> Could you please check frameworkd-glib-dbus.c:122 quickdev ?
Oct 13 22:41:49 <Ainulindale> Maybe I'm not seeing something obvious
Oct 13 22:43:01 <quickdev> Ainulindale, execute dbus-monitor --system type=signal
Oct 13 22:43:07 <Ainulindale> signal is working
Oct 13 22:43:16 <Ainulindale> I just want to see the signature in C :-)
Oct 13 22:43:17 <quickdev> and then you receive the signal SIGNATURE
Oct 13 22:43:23 <Ainulindale> s/signal/method/
Oct 13 22:43:29 <quickdev> have you verified that the xml is right?
Oct 13 22:43:34 <Ainulindale> twice
Oct 13 22:44:05 <Ainulindale> quickdev: how do we match calls ?
Oct 13 22:44:08 <Ainulindale> and not signals ?
Oct 13 22:44:19 <quickdev> match calls? mH?
Oct 13 22:44:23 <Ainulindale> method calls
Oct 13 22:45:13 <quickdev> I don't get you
Oct 13 22:45:22 <Ainulindale> type=signal, ok
Oct 13 22:45:24 <quickdev> but you have to register a special marshaller
Oct 13 22:45:26 <Ainulindale> what is type = method call ?
Oct 13 22:45:35 <Ainulindale> what do I give to dbus-monitor ? :-)
Oct 13 22:45:46 <quickdev> don't know..test type=*...
Oct 13 22:45:54 <DocScrutinizer> raster: (meter) ???
Oct 13 22:46:50 <Ainulindale> Seems to me this marshaller is wrong
Oct 13 22:46:53 <rwhitby> morning
Oct 13 22:46:57 <raster> DocScrutinizer:  yo!
Oct 13 22:47:03 <Ainulindale> hey raster 
Oct 13 22:47:05 <Ainulindale> grmbl
Oct 13 22:47:08 <Ainulindale> hey rwhitby 
Oct 13 22:47:25 <raster> Ainulindale: boo
Oct 13 22:47:50 <quickdev> Ainulindale, register that marshaller ;)
Oct 13 22:48:34 <Ainulindale> quickdev: I had to find how now
Oct 13 22:48:48 <Ainulindale> raster: yes I admit I'm your secret lover
Oct 13 22:48:49 <Ainulindale> Shame on me
Oct 13 22:49:13 <raster> hahahahahha
Oct 13 22:49:30 <quickdev> Ainulindale, append it to the dialer-marshal.list file and execute the gen-marshal dbus command
Oct 13 22:49:34 <DocScrutinizer> Ainulindale: you betray on me - didn't you ask me to marry you :-D
Oct 13 22:49:51 <Ainulindale> quickdev: once again : I'd have to find out how to express the type in terms compatible with that
Oct 13 22:49:52 <quickdev> Ainulindale, you need to pass a prefix
Oct 13 22:49:56 <Ainulindale> Which was indeed my problem
Oct 13 22:50:15 <quickdev> for that you have to know the exact types of the signature, use dbus-monitor
Oct 13 22:50:22 <quickdev> argh, it's not a signal.mh
Oct 13 22:50:27 <Ainulindale> Yes :-)
Oct 13 22:50:34 <raster> ok
Oct 13 22:50:37 <Ainulindale> Little padawan listen doesn't do :-)
Oct 13 22:50:44 <raster> time to build a zaurus flash image... muhahahahha!
Oct 13 22:50:58 <Ainulindale> raster: I see you like to do naughty things for a living
Oct 13 22:51:11 <raster> nah
Oct 13 22:51:20 <raster> thats just going to suck up 1 of my cores for a while...
Oct 13 22:51:24 <quickdev> Ainulindale, http://git.freesmartphone.org/?p=libframeworkd-glib.git;a=blob;f=src/ogsmd/dbus/call.h;h=5bf62c799ef6e06c96603ad3eccc9b53ddcaed6a;hb=HEAD, line 390
Oct 13 22:51:29 <raster> while i get on with stuff i get paid to do...
Oct 13 22:51:52 <raster> i already did a little illume work last night to start bringing it back to sanity
Oct 13 22:51:56 <Ainulindale> quickdev: I know, but that won't tell me the types in textual format ! :-)
Oct 13 22:52:22 <quickdev> Ainulindale, do we need a marshaller for methods? not only for signals?
Oct 13 22:52:25 <Ainulindale> How would you write a PtrArray ? ValueArray ? HashTable ?
Oct 13 22:52:27 <Ainulindale> yes
Oct 13 22:52:39 <Ainulindale> For complex types
Oct 13 22:52:45 <Ainulindale> Such as boxed craps
Oct 13 22:52:59 <quickdev> aren't there arleady boxed types? for example retrieve messagebook
Oct 13 22:53:05 <quickdev> it hasn't got a marshaller
Oct 13 22:53:12 <Ainulindale> Which one ?
Oct 13 22:53:16 <Ainulindale> (I was looking for that just now)
Oct 13 22:53:53 <Ainulindale> ok
Oct 13 22:53:54 <quickdev> http://git.freesmartphone.org/?p=libframeworkd-glib.git;a=blob;f=src/ogsmd/dbus/sim.h;h=1958f40f4eac2277d394ab9467f09c645300b9df;hb=HEAD
Oct 13 22:53:55 <Ainulindale> a(iss)
Oct 13 22:53:56 <quickdev> line 670
Oct 13 22:54:12 <Ainulindale> a(iss) is just a basic boxed marshalling with an extra thing
Oct 13 22:54:13 <quickdev> no, it was adjusted
Oct 13 22:54:30 <quickdev> dbus_g_type_get_collection ("GPtrArray", dbus_g_type_get_struct ("GValueArray", G_TYPE_INT, G_TYPE_STRING, G_TYPE_STRING, G_TYPE_STRING, dbus_g_type_get_map ("GHashTable", G_TYPE_STRING, G_TYPE_VALUE), G_TYPE_INVALID))
Oct 13 22:54:50 <Ainulindale> Ah damn me I was looking at phonebook
Oct 13 22:54:53 <quickdev> a(isssa{sv})
Oct 13 22:55:04 <Ainulindale> A lot of s for naught
Oct 13 22:55:21 <Ainulindale> well quickdev 
Oct 13 22:55:28 <Ainulindale> I'm proud to say I don't have the slightest id'ea
Oct 13 22:56:10 <quickdev> where did that error occur?
Oct 13 22:56:25 <Ainulindale> ophonekitd, but I can't know if it's in lfg or in ophonekitd itself
Oct 13 22:56:30 <Ainulindale> I'll try to set some debugging there
Oct 13 22:57:18 <sicu> raster: good to see you got rid of the app list ... your orig design is much better
Oct 13 22:58:28 <sicu> raster: and the gta03 prototype looks promising too =]
Oct 13 22:59:46 <quickdev> Ainulindale, did you try list calls?
Oct 13 22:59:50 <quickdev> with mdbus
Oct 13 22:59:51 <Ainulindale> indeed
Oct 13 23:00:59 <raster> sicu:  the app list is there.. just its an extra click away on the "applist" button
Oct 13 23:01:16 <raster> but i think its better that way
Oct 13 23:01:30 <raster> there is no need for it to be only 1 click away
Oct 13 23:01:44 <raster> users dont swpa between apps SO often on such devices
Oct 13 23:02:27 <sicu> so if you select the app button, does the app list populate the dropdown, or the entire screen ?
Oct 13 23:03:09 <raster> it slides up from the bottom of the screen
Oct 13 23:03:15 <raster> like the kbd
Oct 13 23:03:33 <raster> its as big as needed to hold the list
Oct 13 23:03:50 <raster> up to the max of the available area under the slipshelf
Oct 13 23:03:53 <raster> (top shelf)
Oct 13 23:04:34 <quickdev> raster, as I asked you before. There's no way to change the height of the keyboard window in the kbd file. Or is there a way?
Oct 13 23:05:02 <quickdev> Ainulindale, I don't know...you're the educated developer ;)
Oct 13 23:05:15 <Ainulindale> quickdev: I'm investigating
Oct 13 23:06:16 <raster> quickdev:  there is
Oct 13 23:06:25 <quickdev> raster, how? did you ever tried it?
Oct 13 23:06:27 <raster> i told you :)
Oct 13 23:06:49 <quickdev> the second parameter of kbd does not work...it's relative
Oct 13 23:07:27 <raster> kbd 130 45
Oct 13 23:07:28 <raster> that
Oct 13 23:07:33 <raster> make it 130 10
Oct 13 23:07:35 <raster> and see
Oct 13 23:09:02 <raster> the kbd will be much less "tall"
Oct 13 23:09:05 <Ainulindale> Grmbl
Oct 13 23:09:07 <quickdev> changed it, restarting x
Oct 13 23:09:09 <Ainulindale> Need a dbus-glib expert
Oct 13 23:09:11 <Ainulindale> And none at hand
Oct 13 23:09:12 <raster> rememebr it bases its size off the Default.kbd
Oct 13 23:09:15 <raster> as thats whats loaded
Oct 13 23:09:17 <raster> to start with
Oct 13 23:09:34 <quickdev> argh, is the height determined by default.kbd?
Oct 13 23:09:35 <raster> i just did it myself and the kbd is tiny
Oct 13 23:09:36 <raster> unusable
Oct 13 23:09:42 <raster> as u also have to redo all the key layout
Oct 13 23:09:47 <raster> yes
Oct 13 23:09:56 <raster> as it determines size on initial start
Oct 13 23:09:59 <raster> and thats whats loaded
Oct 13 23:10:16 <raster> it doesnt re-evaluate size later on layout change
Oct 13 23:10:25 <raster> all other layouts are stuffed into the same keyboard size
Oct 13 23:10:26 <quickdev> that's what I need to know :)
Oct 13 23:10:39 <raster> (retaining aspect)
Oct 13 23:10:43 <raster> thats just how it happens to work
Oct 13 23:10:45 <quickdev> I always modified alpha and numeric
Oct 13 23:11:03 <raster> well default *IS* alpha
Oct 13 23:11:21 <raster> there is only Default.kbd, Numbers.kbd and Terminal.kbd
Oct 13 23:11:26 <raster> in illumes default source
Oct 13 23:11:30 <raster> unless you changed it
Oct 13 23:11:36 <raster> and added more
Oct 13 23:11:38 <Ainulindale> quickdev: Well I think this is far too late for me to understand that type of proble
Oct 13 23:11:42 <Ainulindale> +m
Oct 13 23:11:52 <Ainulindale> Plus I don't think I'm able to as dbus marshalling stays obscure to me
Oct 13 23:12:00 <quickdev> raster, then I always modified only numbers.kbd
Oct 13 23:12:09 <raster> heheh
Oct 13 23:12:15 <Ainulindale> I couldn't find documentation of what should be marshalled with a registered marshaller and what shouldn't
Oct 13 23:12:20 <quickdev> didn't know that default.kbd specifies the size...and that the size isn't changed later on
Oct 13 23:12:34 <quickdev> Ainulindale, do it tomorrow ;) I'll leave now
Oct 13 23:12:39 <quickdev> raster, thanks!
Oct 13 23:12:43 <quickdev> have a good night/day
Oct 13 23:13:08 <raster> :)
Oct 13 23:17:18 <raster> MUHAHAHAHAHHA
Oct 13 23:17:20 <raster> http://www.rasterman.com/files/the-gang-01.jpg
Oct 13 23:19:57 <Ainulindale> Haha :-)
**** ENDING LOGGING AT Tue Oct 14 02:59:57 2008