**** BEGIN LOGGING AT Sun Jan 04 02:59:57 2009 Jan 04 03:54:48 mickey|tv: ok, trying :) Jan 04 04:03:17 mickey|tv: syslogd -C Jan 04 04:03:28 mickey|tv: logread -f Jan 04 04:03:42 mickey|tv: logread: can't find syslogd buffer: Function not implemented Jan 04 04:09:23 that is in the fso-console-image Jan 04 04:15:55 mw|: Just in case you're curious, I got it to work (ID'ing focused window) with xdpyinfo | grep focus to get window ID, and xprop -id 0x###### | grep _NET_WM_PID to get PID. Jan 04 08:35:56 mickey|tv: fso-testing images should now be up to date in http://ipkg.nslu2-linux.org/images/freesmartphone/fso-testing/ Jan 04 08:36:21 (make that http://downloads.freesmartphone.org/fso-testing/images/ instead) Jan 04 08:37:07 mickey|tv: any idea what the MACHINE_CLASS thing is in http://downloads.freesmartphone.org/fso-testing/feeds/ ? Jan 04 09:28:29 rwhitby: see http://shr.bearstech.com/trac/wiki/Building%20SHR#Troubleshooting for a fix Jan 04 09:31:53 AndreasD: thx - any idea why the def is missing? Jan 04 09:32:39 since I will be building for om-gta01, om-gta02 and a780, a machine class of armv4t is not appropriate for a site.conf file (which should be constant for building any machine or distro at a specific site) Jan 04 09:32:39 rwhitby: no Jan 04 09:33:48 * rwhitby does a grep of OE metadata for MACHINE_CLASS ... Jan 04 09:33:55 there must be a better fix ... Jan 04 09:38:13 hmm - under openembedded/conf/... it's only used in openmoko.conf Jan 04 10:04:50 * rwhitby is going to change ${MACHINE_CLASS} to armv4t in OE metadata ... Jan 04 11:36:56 hello phonelog crashes: http://rafb.net/p/PYZkXh83.html Jan 04 11:45:43 heyho Jan 04 12:01:23 freesmartphone.org: 03mickey 07framework * rcbddf72db7ee 10/framework/ (3 files in 2 dirs): ogsmd: pdp: subprocess handling is now using the common ProcessGuard Jan 04 12:06:14 Sargun: om needs an app market? :p Jan 04 12:12:58 dcordes_: why don't you read the logs (tail -f /var/log/messages) directly? Jan 04 12:14:08 Gnutoo: what version of ophonekitd are you using? This looks like an anonymous call with uninitialized number... that was fixed some time ago Jan 04 12:15:26 ophonekitd - 0.0.1+gitr514+b3961977c3c2b3ce8fabded3a7cbea9115b4ca6f-r12.1 - Ophonekitd daemon Jan 04 12:15:36 Ainulindale: do I have write access to shr-themes.git? I want to upload elm-theme-shr-brave ;) Jan 04 12:16:21 Gnutoo: too old ;) Jan 04 12:16:57 ok...but is the new one in the SHR repos? Jan 04 12:18:50 Gnutoo: unstable for sure... testing I don't know. It was fixed on 22 Dec Jan 04 12:19:27 ok what are the drawbacks on switching from testing to unstable Jan 04 12:19:40 no, testing does not have it :( Jan 04 12:19:54 ok that's what i thought Jan 04 12:20:21 dolf1074: what is elm-theme-shr-brave? a new theme for elementary? Jan 04 12:20:26 apart from having to reflash... I'm quite happy with unstable in its current state Jan 04 12:20:53 morphis: yes, and it will look like: http://alasal.be/openmoko/shr2/contacts/r5/contactlist_r5.jpg Jan 04 12:20:56 ok...i'll search the images on the web Jan 04 12:21:11 yeah, very cool Jan 04 12:21:25 is the theme already available? Jan 04 12:21:39 it looks very nice Jan 04 12:21:46 no, and there is still a lot to do Jan 04 12:22:34 iPhone competitive :) Jan 04 12:23:09 It doesn't want to compete with the iphone (yet) ;) Jan 04 12:23:30 hehe Jan 04 12:34:17 dolf1074: i like it Jan 04 12:34:36 thanks Jan 04 12:35:05 this is how far I am at the moment: http://scap.linuxtogo.org/files/31708fdccfdee7d941b4b41820be46b8.png Jan 04 12:35:49 thanks a lot Jan 04 12:36:49 dolf1074: do you plan to change the illume bar too so that it fits to the theme? Jan 04 12:36:59 dolf1074: the scrollbar could be a bit wider Jan 04 12:37:16 otherwise I can't drag it with my fingers Jan 04 12:37:23 bumbl: maybe, but now I'm first doing the elementary theme Jan 04 12:37:49 morphis: you scroll with draging the whole space up or down. (you don't need to actually hit the scrollbar) Jan 04 12:38:08 ok Jan 04 12:38:08 but I can? Jan 04 12:38:47 morphis: you can - but where is the point? Jan 04 12:38:49 morphis: yes you can scroll with hitting the scrollbar. (but now the scrollbar is to thin, as designed) Jan 04 12:39:20 the whole data field is a single "scrollbar" and the bar only shows you where you are Jan 04 12:40:56 jepp, but I think, if you could scroll with the scrollbar it should be wider or it should not be scrollable Jan 04 12:58:22 bumbl, Fact: Oms are expensive, therefore OM owners are rich, ergo owners shall be robbed! Jan 04 12:59:00 Sargun, tut.. tut.. Oms are free... its the neos that are expensive Jan 04 12:59:56 Sargun: haha Jan 04 13:00:41 well you are right Jan 04 13:03:58 Hey Jan 04 13:04:01 morphis, here? Jan 04 13:04:16 hi quickdev Jan 04 13:04:20 quickdev: jepp Jan 04 13:05:09 morphis, what's wrong here? http://rafb.net/p/7ZgPZP17.html Jan 04 13:05:29 cython and pyrex installed? Jan 04 13:08:35 morphis, thanks. pyrex was missing Jan 04 13:09:14 np Jan 04 13:16:16 morphis, http://rafb.net/p/pqtxot77.html Jan 04 13:18:41 quickdev: try mkdir /usr/lib/python2.5/site-packages Jan 04 13:18:57 if it does not exist Jan 04 13:19:06 i wonder why it shouldn't though Jan 04 13:19:09 it is there Jan 04 13:22:03 and python setup.py build in ecore: http://rafb.net/p/ocY6C460.html Jan 04 13:25:44 /home/deluxe/software/enlightenment/e/trunk/BINDINGS/python/python-ecore/ecore/ecore.c_ecore.pyx:18:8: 'evas.python.pxd' not found Jan 04 13:25:46 ah :) Jan 04 13:34:44 mom Jan 04 16:49:04 stefan_schmidt: Hi :) Any updates on stability, design and communication among developers issue? Jan 04 17:51:22 morphis, here? Jan 04 17:53:51 morphis, what's wrong here? :) http://img61.imageshack.us/img61/3879/screensd1.png Jan 04 17:54:12 quickdev: Is it okay that I patch a enlightenment package? At the moment the default font color of etk is white. While the default color of etk whould be black. (because white font color on a white background isn't good) Jan 04 17:54:28 s/whould/should/ Jan 04 17:54:29 dolf1074 meant: quickdev: Is it okay that I patch a enlightenment package? At the moment the default font color of etk is white. While the default color of etk should be black. (because white font color on a white background isn't good) Jan 04 17:54:46 quickdev: good question Jan 04 17:54:57 can you paste the code somewhere? Jan 04 17:55:06 dolf1074, you shouldn't patch the package. Isn't there any other way? Jan 04 17:55:20 morphis, it's the elementary test app Jan 04 17:55:22 Not that I know Jan 04 17:55:35 quickdev: oh Jan 04 17:55:41 thats misterious Jan 04 17:55:55 etk test apps are working Jan 04 17:56:14 which svn rev do you have of e? Jan 04 17:56:30 If you don't specify the default color in the default theme by the etk, I can't remove the color tags in the libframework-phonegui-efl and can't I specify another color in my theme Jan 04 17:56:32 could be that there is something broken Jan 04 17:56:52 this "feature" I had several times when developing python-elementary :) Jan 04 17:56:56 morphis, latest Jan 04 17:57:10 hm Jan 04 17:57:14 I will check tomorrow Jan 04 17:57:41 morphis, which revision are you currently using? (I assume it's working :) ) Jan 04 17:58:08 dolf1074, thus..why not changing it in the default theme? Jan 04 17:58:48 morphis, when clicking on background image...then it's balck.....same with plain background Jan 04 17:58:49 because that theme is in the etk package. Jan 04 17:59:04 wooh? Jan 04 17:59:56 dolf1074, currently we're overwriting the default etk theme of the etk package with our custom etk theme......that's why the font color is white Jan 04 18:00:25 quickdev: ah so, I though it was the default theme. Why is the color white? Jan 04 18:00:42 38347 Jan 04 18:00:48 I have Jan 04 18:00:57 dolf1074, it's white, because that makes the text on the black etk list background readable ;) Jan 04 18:01:22 quickdev: I am currently recompiling everything and check Jan 04 18:02:07 morphis, thanks Jan 04 18:03:07 quickdev: the etk list is white with grey Jan 04 18:03:29 dolf1074, in the default theme...yes..but not in the custom theme..that's why in the custom theme the font is white Jan 04 18:03:47 dolf1074, try the default etk theme Jan 04 18:04:05 how can I change? Jan 04 18:04:31 have you an oe tree? compile the package locally Jan 04 18:04:54 http://shr-project.org/trac/attachment/wiki/Screenshots/contacts1.png : the background is white with grey? Jan 04 18:05:38 and the text is black, because that's specified in libframeworkd-phonegui-efl Jan 04 18:05:44 but the default text color is white Jan 04 18:06:40 So if the default text color is changed to black and the text color in libframeworkd-phonegui-efl is eliminated, I can theme with my packages Jan 04 18:07:06 Do you get my problem? Jan 04 18:07:50 dolf1074, sorry, you are right. Eliminate the text color in libframeworkd-phonegui-efl and get the etk default theme..then it should be ok? Jan 04 18:08:01 yes Jan 04 18:08:13 But how should I change the etk default theme? Jan 04 18:08:58 with a patch, till raster makes that change upstream? Jan 04 18:10:24 dolf1074, I still don't get why there's something wrong with the etk default theme. Have a look at etk test - things are displayed correctly? Jan 04 18:12:34 mickey|tv: Hi there. Imagine a following condition: someone's calling and then (for an unknown reason) gsm0710muxd dies. We relaunch it and now the state-machine is stuck forever in "incoming call" state. A real-life example. Jan 04 18:12:45 ... looking for the tests ... Jan 04 18:14:08 dolf1074, eliminate the font color in libframeworkd-phonegui-efl and everything is solved? Jan 04 18:14:28 not at the moment, because then all the text will be white Jan 04 18:15:05 mickey|tv: another question: What should be done if the user wants to suspend the phone before getting "sim ready". In this case we'll never get it and so will be unable to read the phonebook and smss. Jan 04 18:15:55 quickdev: but yeah, it's strange that the etk tests gives black labels Jan 04 18:15:58 PaulFertser: best solution would be to wait until sim ready Jan 04 18:16:09 dolf1074, and if we use elementary labels? then the font color is specified by the elm theme? Jan 04 18:16:23 bumbl: so we force the user to wait for the sim readiness even if she wants to suspend NOW? Jan 04 18:16:38 dolf1074, on your local machine? (etk_test) Jan 04 18:17:41 quickdev: I'm now looking if the default elm theme color is black. If that's okay, then we can switch to elementary labels Jan 04 18:18:44 the default elm theme color is black, so that might solve it Jan 04 18:19:30 PaulFertser: yes Jan 04 18:20:14 PaulFertser: sim ready does not take that long Jan 04 18:20:44 and we have a phone - what point is it to suspend when the gsm part is not up and running Jan 04 18:21:07 bumbl: Ha, and what if we have a broken modem that doesn't report sim ready before it registered to the network and we're underground and unable to register? Jan 04 18:24:39 quickdev: Okay, I found the root problem. If you don't specify a color on a TEXT block, edje takes white :( Jan 04 18:25:13 dolf1074, we should use something that is themed by elementary -> elementary labels? ;) Jan 04 18:25:20 yes ;) Jan 04 18:26:35 okay, we now have the solution of that problem :) But now I will learn some more for my examination tomorrow. Jan 04 18:27:34 ah quickdev: I found a name for the package that will hold all the extra widgets like the buttonbar Jan 04 18:27:46 the name: elementary_supplementary :) Jan 04 18:29:37 dolf1074, do we really want to create an own package for it? Maybe raster implements it before we need an extra package (extra package would only be need, if there's another library than lfp-efl) Jan 04 18:30:04 Will raster implement a buttonbar? Jan 04 18:30:57 but yeah, we can implement it into the lfp-efl library Jan 04 18:33:23 PaulFertser: implement a timeout Jan 04 18:33:56 morphis, any info? :) Jan 04 18:35:10 quickdev: what's more important to you in FSO? Good foundations that won't require redesign soon or more features and MS5 before february? Jan 04 18:37:05 bumbl: Sorry, what exactly do you mean? So, you try to suspend, but sim is not ready, so FSO emits a signal like "wait a moment for sim readiness", then Zhone (or whatever) presents an info window, then FSO time outs, suspends the phone then i go outside and sim becomes ready but the modem is suspended and we lose "sim ready" signal again? Jan 04 18:37:33 kind of Jan 04 18:37:57 PaulFertser, I'd say the former one, although I cannot judge if those issue may be delayed Jan 04 18:38:31 I don't know what it technically is Jan 04 18:39:29 suspend -> sim not ready -> signal; lock suspend -> a) sim ready -> unlock suspend -> manually suspend again Jan 04 18:39:33 quickdev: The reason i ask is that i suggested to the FSO team that they might want to improve stability (and that'll probably require redesign of some parts, in particular ogsmd) before it gone too far. And that it should be considered for the MS5. And that the opinion of SHR developers should be taken into account. Jan 04 18:40:13 b) sim not ready in a certain amount t -> unlock suspend Jan 04 18:40:56 so if sim gets not ready in a certain amount of time Jan 04 18:40:57 allow the user to suspend the phone Jan 04 18:41:11 bumbl: the step "sim ready -> resume" is ultra-problematic. I'm afraid it can't be implemented on most phones. Jan 04 18:42:07 bumbl: moreover "sim is ready" unsolicited response is non-standard and can't be counted on as it might not exist on other modems. Jan 04 18:45:38 PaulFertser: do you know how android solves this problem? as android has to solve the same problem with similar utilities on more or less the same plattform (linux kernel) Jan 04 18:46:27 hi, i'm new to openmoko development. i've just got my freerunner and wanted to start developing some apps. i have experience in c++ development with Qt (desktop apps) and I use kdevelop as my IDE. now i wanted to implement a text input method (MessagEaseST, http://www.exideas.com/ME/faq.html) and just don't know how to start. do i need any sources of the openmoko distribution or can i just start writing a qt application or how Jan 04 18:46:27 should i start? Jan 04 18:47:12 well - as the freerunner has an armv4 cpu Jan 04 18:47:30 i already have the toolchain Jan 04 18:47:34 (prebuilt) Jan 04 18:47:34 you need to crosscompile your code for the freerunner Jan 04 18:47:40 ah ok Jan 04 18:47:50 but what about some sources of the distro? Jan 04 18:48:05 dont i need to implement it "into" it? Jan 04 18:48:26 bumbl: i don't intend to even look at the android. And the reason i ask the questions about sim readiness etc is not to propose a solution, actually. I want to highlight that some certain parts of FSO should probably be re-thinked given the knowledge FSO team gained from the experience. And if it results in redesign and delay of MS's, well, that'd still be better than unstable racy system. Jan 04 18:48:37 sebastian_: http://shr-project.org/trac/wiki/Building%20SHR Jan 04 18:48:51 sebastian_: this will get you the sources of the shr distribution Jan 04 18:48:54 + buildchain Jan 04 18:49:08 + bitbake (which is used for packaging) Jan 04 18:49:16 okay Jan 04 18:49:19 sebastian_: there's no "one true distro" for the FR. Jan 04 18:49:41 paulfertser: i mean the Om2008 distro Jan 04 18:50:13 PaulFertser: i totally agree with you Jan 04 18:50:35 stability in front of features Jan 04 18:50:38 sebastian_: screw that ;) nobody'll use it in 2010. I hope ;) Jan 04 18:50:57 sebastian_: you don't want 2008 - believe me Jan 04 18:51:00 it is horrible Jan 04 18:51:17 bumbl: and what about other SHR developers? If they all agree, then it should mean something to the FSO team, shoudn't it? Jan 04 18:51:21 so how should i implement something like a text input method which can be used with multiple distros? Jan 04 18:52:19 i thought about a standalone app, just like a keyboard simulation... Jan 04 18:52:27 PaulFertser, I'd want to hear mickey's opinion about it Jan 04 18:52:41 dinner now :) Jan 04 18:52:45 sebastian_: it seems that the trend now is to use illume -- and e17 module for mobile devices. And you may probably want to look at it and implement your method as another one integrated in e17. Jan 04 18:53:24 s/-- and/-- an/ Jan 04 18:53:24 PaulFertser meant: sebastian_: it seems that the trend now is to use illume -- an e17 module for mobile devices. And you may probably want to look at it and implement your method as another one integrated in e17. Jan 04 18:53:46 ^^ Jan 04 18:54:45 ok i'll do some googling now... and just try it. thanks Jan 04 18:54:50 sebastian_: Everybody likes it, really. It'll soon be in Debian, it's already used by the SHR and FSO distros. It's mainline, really. Jan 04 18:55:13 PaulFertser: "it" = e17? Jan 04 18:55:20 sebastian_: illume, to be precise Jan 04 18:55:26 ok Jan 04 18:55:47 PaulFertser: what should be redesigned in fso? Jan 04 18:56:10 PaulFertser: well they are paid by openmoko in order to provide features Jan 04 18:57:31 sebastian_: afaik it is quite easy to tell illume to use a different keyboard than the internal Jan 04 18:57:52 bumbl: no, they are paid to build a stable framework (fundament) ;) Jan 04 18:58:38 fgau: i don't have a degree in CS, so i can't say for sure. But what the ogsmd part just doesn't feel "right". I read logs everyday and i see that there's quite a number of things that are not solved effectively with current design. One particular case is the "workaround" to feed init commands after the resume. And that "FIXME: cancel the previous timer" is what bothers me a lot. That's not a clean design, even if we had an ability to cancel the Jan 04 18:59:06 bumbl: how do you mean this? a different internal? or an external? should i now start developing an external application or implement my input method into illume? Jan 04 18:59:50 bumbl: sorry about that questions, but i'm really new to this topic :) Jan 04 19:01:34 sebastian_: well illume has an internal keyboard - applications can request a keyboard and according to the settings e/illume (illume is an e module) will call either the internal keyboard or an external one Jan 04 19:03:29 PaulFertser: thx for you explanation. you've already tested pyneo? Jan 04 19:03:48 bumbl: thanks so far, i will check this out. but now its time for dinner :) cu Jan 04 19:04:11 sebastian_: you might want to talk to raster Jan 04 19:04:48 as he is in Australia/Japan he sleeps at the moment Jan 04 19:06:08 fgau: of course they should provide a stable framework - but they need to provide certain features in a certain amount of time - if it works(tm) with some dirty hacks they won't change it soon (imo) Jan 04 19:06:17 and as gsm modems are picky Jan 04 19:06:28 it might be that even the best design does not help Jan 04 19:08:16 bumbl: They shouldn't make it ad-hoc. FSO should be a solid foundation for now and for the future. It should support many modems. And do it clean. We're waiting for the free phone for a long time. And i hope that we're ready to wait a little longer for a good framework. Too many dirty hacks, and you're screwed. :-/ Jan 04 19:09:25 i completley agree with you Jan 04 19:10:22 bumbl: now we need all the SHR developers to agree with me. And then all the FSO developers. :) Jan 04 19:11:25 * PaulFertser_ is trying to be a virus, it seems Jan 04 19:12:28 i hope a good one :D Jan 04 19:12:44 To be precise, it's not agreement with me, that i hope for. It's the agreement with the idea "Stability and clean design first, features next". Jan 04 19:14:28 i think everyone agrees with that Jan 04 19:14:43 muxer, daemons, apps ... in this sequence Jan 04 19:14:49 morphis: svn updat Jan 04 19:14:50 Not some FSO developers, i'm afraid. Jan 04 19:14:52 [e bindings] Jan 04 19:14:55 muxer si stable isn't it? Jan 04 19:15:01 bumbl: not Jan 04 19:15:02 morphis: i fixed the build.sh Jan 04 19:15:44 bumbl: have you seen the muxer's code actually? I'm afraid /that/ can't be stable ;) Jan 04 19:16:06 mickey: what did you fix? it worked to build for me Jan 04 19:16:08 mickey: ping. Have you seen my questions? Jan 04 19:16:24 bumbl: it doesn't provide the proper include statements Jan 04 19:16:35 hmm okay Jan 04 19:16:38 during cythonizing the evas.pxd wasn't found for me Jan 04 19:16:43 anyway it built today in the morning Jan 04 19:17:05 perhaps you have the staged files in the standard locatiosn Jan 04 19:17:15 anyways, it's now synced with all the other build.sh Jan 04 19:17:28 PaulFertser_: i have seen them, yes. I have no answers for you atm., Jan 04 19:17:36 mickey: Good evening btw :) Jan 04 19:17:36 please open bugs if applicable Jan 04 19:17:45 happy new year, btw. Jan 04 19:17:46 :) Jan 04 19:17:58 i'm aware of _some_ problems, but demanding a redesign is overthetop Jan 04 19:18:01 mickey: Do you agree with the idea "Stability and clean design first, features next"? Jan 04 19:18:07 sure i do Jan 04 19:19:14 morphis: i still get the SIGSEGV though Jan 04 19:19:25 with latest HEAD Jan 04 19:19:37 mickey: But do you agree that some problems are caused by the design that is not adequate to the real life? And that the longer you ignore it, the harder the fix gets? Jan 04 19:20:22 mickey: and i'm not demanding a redesign. I *suggest* that it might be necessary given the logs i saw. Jan 04 19:20:37 it depends on what you mean 'design' Jan 04 19:20:51 the design of the whole subsystem is pretty good, IMO Jan 04 19:21:01 some calypso-specific things are racy Jan 04 19:21:05 yet Jan 04 19:21:14 mickey, is elementary working for you in latest head? Jan 04 19:21:17 mickey: and alphaone says that the resource-allocation thing is busy. Jan 04 19:21:27 mickey, I mean..is the elementary test application showing fonts? Jan 04 19:21:29 s/busy/racy/ Jan 04 19:21:30 PaulFertser_ meant: mickey: and alphaone says that the resource-allocation thing is racy. Jan 04 19:21:30 quickdev: on x86, yes. Jan 04 19:21:40 mickey, compiled it on x86, too Jan 04 19:21:41 quickdev: py-elementary sigsegvs though Jan 04 19:21:51 quickdev: do you have fontconfig support enabled in evas? Jan 04 19:22:14 yes, resource as well Jan 04 19:22:43 mickey: and what about #31? You say that you care about stability and yet the pace of investigating it is amazingly slow. I see a little contradiction here, don't you think so? Jan 04 19:22:59 i don't see that no Jan 04 19:23:05 first, i need to switch between several roles Jan 04 19:23:09 i'm not fulltime ogsmd Jan 04 19:23:46 mickey: and who is? BTW, you see mwester almost everyday. And he's quite capable of reporting useful info, don't you think so? Jan 04 19:23:58 no one is, my team is small Jan 04 19:24:50 #31 is pretty convoluted Jan 04 19:24:52 But somebody should probably concentrate on ogsmd to make it stable and good and clean. Or else we get many features we can't use because of the instability. Jan 04 19:24:57 it doesn't seem any longer about flow control sysfs node Jan 04 19:25:03 which issue do you refer to now? Jan 04 19:25:06 btw. Jan 04 19:25:16 mickey: haven't you said that you need to hire new fso developers? any progress with that? Jan 04 19:25:22 i didn't answer because i don't wanted to get into a discussion now Jan 04 19:25:22 mickey: #31 and everything it highlights. Jan 04 19:25:26 now you dragged me in Jan 04 19:25:27 *sigh* Jan 04 19:25:35 bumbl: no progress, otherwise I would have reported it Jan 04 19:25:40 it was new year Jan 04 19:25:42 in case noone noticed Jan 04 19:25:44 mickey: ok, lets postpone it. Jan 04 19:26:17 trust me on it, i'm coming back to all that Jan 04 19:26:22 but i define the order of things i work on Jan 04 19:26:33 and it's hell of context changes Jan 04 19:26:36 mickey: You know, i don't want to push you or anybody too hard. I'm just afraid that the users won't get what they want with FSO. Jan 04 19:26:38 people want opimd asap Jan 04 19:26:42 people want stability on everythign Jan 04 19:26:47 and we're just 4 part timers Jan 04 19:27:17 mickey: opimd? Is it more important that ability to make and receive calls at all? Jan 04 19:27:30 answer that for yourself Jan 04 19:27:33 read the mailing lists Jan 04 19:27:37 it's the #1 demanded thing atm. Jan 04 19:27:40 PaulFertser_: you are talking as if you can't make and receive calls? Jan 04 19:28:00 again, people are using the Neo as a daily phone, so please don't make it sound worse than it is. Jan 04 19:28:10 anyways, need to run now Jan 04 19:28:51 bumbl: Having to restart frameworkd to be able to make a call is sometimes necessary. And it's not good. Jan 04 19:29:19 hmm never had to do that Jan 04 19:29:24 making and receiving calls is more or less stable for me Jan 04 19:29:44 bumbl: And it should be rock-solid. "Stability first". Jan 04 19:29:57 but the only thing which prevents me from using it as a daily phone is missing pim Jan 04 19:30:44 bumbl: i've already told you. Imagine a muxer dies while smbd's calling. And it should be handled gracefully. But framework restarts it and voila. You're stuck in "somebody's calling" state. Yet the modem was power-cycled. Jan 04 19:31:52 bumbl: look at #31, btw. Are you sure that something like that is acceptable in a "stable" system? Jan 04 19:34:17 Too bad mickey_away doesn't use "away log"... I wanted to say that i use it as a daily (and the only) phone too. And that i have already provided some logs and asked some questions that highlights some real problems, i don't imagine them. BTW, has anybody from the SHR team looked into the FSO internals? What do they think about the design? Jan 04 19:36:55 bumbl: have you seen numerous reports on the mailing lists that they need to restart Zhone to see new SMSs? And that means they restarted the whole ogsmd, actually. It seems if nobody's going to change it, we'll have the same level of stability in MS6. And it's quite depressing :( Jan 04 19:43:27 TAsn: hi Jan 04 19:43:50 hey. Jan 04 19:43:55 sup? Jan 04 19:45:13 I'm trying to bitbake an fso-image and it's failing on trying to install fso-gpsd because gpsd conflicts Jan 04 19:46:06 I've tried to define PREFERRED_PROVIDER_gpsd = "fso-gpsd" but it is still trying to install gpsd Jan 04 19:55:23 morphis, here? :) Jan 04 19:59:45 no, it is cooking with ainulindale Jan 04 20:00:03 we have lost another dev with the kitchen ... Jan 04 20:00:54 this makes me think how the life is awful Jan 04 20:10:47 Hire: everybody has to eat from time to time... even devs :p Jan 04 20:11:27 no, devs doesn't eat and sleep Jan 04 20:12:01 would like to have that... because you're an admin ;) Jan 04 20:14:46 :/ Jan 04 20:14:50 i am a sissy admin Jan 04 20:20:19 mwester: Hi there :) Do you know if any SHR dev has taken a look at the design and implementation of frameworkd in general and ogsmd in particular? And why don't you state your opinion about how and where FSO's going? I respect your opinion very much, as do many people. Why's everybody saying: "ask Mickey about that"? Is he the only one who knows what's going on inside FSO in general and ogsmd in particular? Do you feel tha Jan 04 20:22:34 well Jan 04 20:22:54 mickey is the big boss Jan 04 20:23:11 so it is natural if someone says "talk with him" Jan 04 20:24:16 Hire: It's not good when there's only one person that knows what's going on. Jan 04 20:24:35 him Jan 04 20:24:43 alphaone Jan 04 20:24:54 and other bad guys Jan 04 20:25:04 Hire: And that's not good when SHR people blindly trust him. Every man makes mistakes, you know. And i'm just asking questions. That nobody answers. Jan 04 20:26:17 Hire: alphaone is busy doing other things. Not ogsmd and good overall race-free fool-proof bad-stupid-FUCKING-TI-hardware-proof ogsmd. And stefan_schmidt_ is also not in charge here. Jan 04 20:26:17 we have other tasks Jan 04 20:26:35 well Jan 04 20:26:44 mickey is working on ogsmd Jan 04 20:26:49 and i find it pretty stable Jan 04 20:27:01 but please, don't stress him too much Jan 04 20:27:09 Hire: do you love him? ;) Jan 04 20:27:13 he is doing a good work Jan 04 20:27:26 sure and i was homosexaul i did sex with him Jan 04 20:27:31 but this is another story Jan 04 20:27:42 guys, youre crazy ^^ Jan 04 20:28:03 i am italian, so don't worry, don't listen to me Jan 04 20:28:12 :) Jan 04 20:28:16 i says always "bla bla bla" without sense Jan 04 20:28:20 Hire: seriously, look at the dates on #31. I'm pressing that much on #31 just because that's a perfect example of lack of communication and plenty of unsolved issues. And mickey's doing something other than solving them. That's what i don't understand. Jan 04 20:28:46 why mickey has to do the bug #31? Jan 04 20:29:03 Hire: Ainulindale should be jealous now, as you finally confessed and admitted your relatioship with mickey ;) Jan 04 20:29:21 Hire: because he's in charge of good and stable ogsmd. Jan 04 20:29:23 i am openmind Jan 04 20:29:33 ah Jan 04 20:29:38 that issue with the gta01 Jan 04 20:29:52 sorry dude but the gta02 is a *bit* more important than gta01 Jan 04 20:29:56 Hire: fucking no. It's daniel who thinks that it's only gta01! Jan 04 20:30:41 Hire: and he did the change too fast, not digging into the details. It stayed under another title for months. Read the whole story. And please notice the dates! Jan 04 20:30:42 Could we please fucking stop the fucking swearing?! Jan 04 20:30:47 Thank you Jan 04 20:30:51 alphaone: sorrpy Jan 04 20:30:51 fucking yes Jan 04 20:31:06 And it was not just yet, for the record. Jan 04 20:31:36 We had a meeting here in Braunschweig, Mickey, Stefan, Jan and me. Jan 04 20:31:52 PaulFertser_: ok but as mickey says before them, 4 guys, working on frameworkd Jan 04 20:31:54 alphaone: is swearing considered counter-productive here btw? I'll try to refrain then, but it seems not natural. Jan 04 20:31:57 We discussed the bug and it seemed to us it was the flow-control thing Jan 04 20:32:00 only 4 guys ... Jan 04 20:32:19 PaulFertser_: he is kidding Jan 04 20:32:31 PaulFertser_: At least I consider it counter-productive and slightly offending Jan 04 20:33:10 alphaone: i didn't intend to use it as a personal offence. Sorry. I promise to not hilight you and swear in the same message ;) Jan 04 20:33:28 PaulFertser_: That would be great, thanks Jan 04 20:33:29 alphaone: Don't you agree that proper flow-control matters no matter what device is used? Jan 04 20:33:30 morphis: ping Jan 04 20:34:31 PaulFertser_: If it affects the device, yes Jan 04 20:34:50 alphaone: don't you agree that faster communication between mwester and mickey was/is needed to find all the problems involved? And most of them are not GTA01-specific. The small buffer just provokes the problems more often. Jan 04 20:36:11 PaulFertser_: I agree that would be great Jan 04 20:36:15 alphaone: moreover, i'm afraid you haven't read the latest log mwester attached. It doesn't show any flow-control problems, or so it seems. Why haven't you closed the ticket at all? Jan 04 20:36:33 But I don't see how that could be achieved Jan 04 20:36:56 It's not mickey's main job to work on ogsmd Jan 04 20:39:02 PaulFertser_: I know the current situation sucks. Jan 04 20:39:04 alphaone: please look at the dates. mwester's responses are fast enough. He provides good logs and thoughtfull analisys. Somebody's gotta fix all the known issues in ogsmd. Not to work around it. Don't you agree? And mickey's the person to do it or to assign this task to somebody. ogsmd is important part of FSO. Jan 04 20:40:17 alphaone: I'm glad you agree. And please don't take my "pushing" as a personal offence or something. I'm just asking questions, trying to understand. And trying to help. I read the code myself and analise the logs. I'm trying to help. Jan 04 20:40:33 PaulFertser_: Yeah, so is answering and clarifying why we're not yet in a state you or other people think we should be. Jan 04 20:41:33 dos1: whats up? Jan 04 20:41:38 And for a great part having fun during work is what is pretty important to me as well. Jan 04 20:41:48 And unfortunately that's starting to fade Jan 04 20:42:21 morphis: hey, what's going on with python-elementary? :> Jan 04 20:42:24 Which is part of the reason I haven't worked more on fso lately Jan 04 20:42:25 alphaone: oi, that's bad :( Jan 04 20:42:30 alphaone: What surprises me most is that the FSO team is releasing milestones before they're sure that the design and implementation of core parts is good. Why work on connection-sharing when ogsmd is not stable? Who needs automated connection-sharing while ogsmd has some real problems? And yet mickey's doing connection-sharing. That's one of the cases highligthing the situation i can't understand. Jan 04 20:42:32 nothing? Jan 04 20:42:45 dos1: but quickdev also reported a problem Jan 04 20:42:49 alphaone: I'm really sorry to hear that. Jan 04 20:43:17 PaulFertser_: what's connection sharing? Jan 04 20:43:22 morphis, I have solved my problem. fontconfig wasn't compiled into evas. Jan 04 20:43:25 lindi-: conferance call Jan 04 20:43:27 blogtch! Jan 04 20:43:33 quickdev: ok Jan 04 20:43:34 morphis, but it's segfaulting here sometimes...when I try to start it Jan 04 20:43:34 lindi-: i guess it's some automated iptables configuration built in FSO. Jan 04 20:43:34 (14:00:45) morphis: I think this until this weekend I will have full support for all current elementary features Jan 04 20:43:37 PaulFertser_: for it is easy, there's one goal to achieve, one task and everything else should stand in line and wait until your most important issue is done once and for all. This is very unrealistic. Jan 04 20:43:37 this is starting to annoy me to no end Jan 04 20:43:37 :> Jan 04 20:43:38 lindi-: i think ... Jan 04 20:43:40 PaulFertser_: urgh Jan 04 20:43:51 PaulFertser_: good that it's modular so that i only can run the modules i need Jan 04 20:44:06 dos1: ok :) sorry I don't get so far as I think in the middle of the week Jan 04 20:44:13 morphis, do you need backtraces? Jan 04 20:44:22 lindi-: resource allocation is racy and should be rethinked. So, it doesn't work very well in this regard. Jan 04 20:44:39 quickdev: backtraces would be nice Jan 04 20:44:41 morphis: ok :D but we are waiting, don't forget about it ;> Jan 04 20:45:02 Kensan_: Someone should concentrate on good design and stable ogsmd. Without it the whole system can become useless, i'm afraid. Jan 04 20:45:37 dos1: I know, but currently I am a little bit under stress because of university Jan 04 20:45:58 PaulFertser_: The current design is very flexible and as mickey said and already showed he/they are willing to change the design if there's a need to do it. Jan 04 20:46:04 dos1: what do you currently need most? Jan 04 20:46:24 Kensan: anyone could have implemented connection-sharing or netdev led triggers. And it takes a real experience and clue to design and implement good core systems, like ogsmd. I hope mickey'll concentrate on that. Jan 04 20:46:40 PaulFertser_: all the people in the community want something else then there's management and other parties that have an interest. Jan 04 20:47:11 morphis: toolbar, and later hoversel Jan 04 20:47:29 PaulFertser_: there is no fulltime engineering team of 50 guys that have limitless ressources here... Jan 04 20:47:42 dos1: ok, then I will fix that two parts first Jan 04 20:48:15 morphis: ok, thanks :) Jan 04 20:49:39 Kensan: there's one manager that should decide how, when and what to implement. He's called System Architect. And it's mickey. The guy who knows how to do things well. Not clumsy and ad-hoc. How to make a stable system everybody'll love. I'm surprised he's doing something else. Jan 04 20:50:35 PaulFertser_: ok, that's just utter rubbish. You are basically saying all the FSO team has done in the last ~1 year is utter bulls/%& which simply IS NOT TRUE. Jan 04 20:50:57 Kensan: the only interested parties are: SHR team (very active) and paroli team (have never seen anybody communicating with FSO from them). Jan 04 20:51:04 morphis, I need to code a little programm for school. That's why I'm using your bindings atm :) Jan 04 20:51:08 Kensan: I'm not saying it. Jan 04 20:51:09 PaulFertser_: they need every man they can find, maybe dive into it and provide them patches instead of telling them they have to little persons in their team Jan 04 20:51:16 PaulFertser_: but you are! Jan 04 20:51:55 quickdev: for school? for desktop or the freerunner? Jan 04 20:52:32 PaulFertser_: shr and paroli team? How about Openmoko Inc. that pays the salaries? Jan 04 20:52:44 dolf1074: an ordinary man can find a fix a bug. But i'm afraid we're facing some design decisions here. Moreover, not everybody as experienced in modems as mickey. Jan 04 20:52:48 morphis, both - a learning application..that stores questions and it's answer - I can enter answers on my desktop and them query them on my phone...when I'm somewhering and I have nothing to do - to use time more effectively Jan 04 20:53:50 quickdev: hehe Jan 04 20:53:59 Kensan: i'm not saying they made rubbish. I'm saying there're some issues that needs attention of an experienced FSO developer. Jan 04 20:54:49 Kensan: don't OM who pays the salaries trust their engineers? If they do, they should trust mickey and let him do what he decides to be important, don't you think so? Jan 04 20:55:54 PaulFertser_: sorry, but all the things you write like quote: "Not Jan 04 20:55:59 clumsy and ad-hoc. How to make a stable system everybody'll love. I'm surprised he's doing something else" Jan 04 20:56:08 PaulFertser_: that's rather clear Jan 04 20:56:28 PaulFertser_: so don't say you are not seriously bitching about FSO when you are. Jan 04 20:58:37 Kensan: i'm not a native speaker, please take that into account. Second. I see some parts that _seem_ to _me_ clumsy and ad-hoc. And i _guess_ it affects stability of the whole system. And _i_ am afraid somewhere some design might need to be fixed. And that _to_me_ it seems that there's not enough communication between the SHR devs and the FSO team. That's what i'm saying. Jan 04 21:00:11 I: Why should there be communication between SHR and FSO? II: Even tough it isn't needed, why do you think they don't communicate with each other? Jan 04 21:00:46 PaulFertser_: well that sound very different from what you wrote before because your previous statements lead me, and I assume I am not alone in that assesment, to believe that you (strongly) believe the FSO-Team has made a crappy design wrt ogsmd and the software is not working at all and should be rewritten from scratch. Jan 04 21:01:01 Kensan: and one can't make a stable system in one move. It's a process of implementation and improvement. And improvement of critical parts shouldn't be stopped before they're stable. That's what i think. Jan 04 21:01:54 PaulFertser_: So what are these design issues then? Jan 04 21:02:08 PaulFertser_: Rome isn't build in one day Jan 04 21:02:18 dolf1074: SHR strongly depends on FSO, that's why. And i think that while the FSO team considers their goals they should take SHR opinion into account. Jan 04 21:02:32 they do, because we ask them opimd Jan 04 21:02:41 PaulFertser_: Why do you think the FSO team does not value the input of the SHR team? Jan 04 21:03:26 Kensan: I look at bug #31 and see how reports of very valuable developer that affects stability gets ignored for months, that's why. Jan 04 21:03:46 dolf1074: but don't you ask them to make a good ogsmd first? Jan 04 21:05:05 ogsmd is working (more or less) and it is still being worked on. But at the moment we also want opimd, so we can start making a full phone instead of one that can only phone reliable Jan 04 21:05:12 dolf1074: I've read about opimd... Can't say much about it, but to me it doesn't make sense to work on opimd before stable ogsmd. Jan 04 21:05:26 I think ogsmd is working enough for now Jan 04 21:05:51 dolf1074: does mwester agree? Jan 04 21:06:05 the kernel of linux wasn't perfect or stable before they started to make user apps Jan 04 21:06:16 PaulFertser_: why do you think they were ignored? Jan 04 21:06:25 dolf1074: GNU made user apps long before the linux kernel. Jan 04 21:06:51 Kensan: look at the dates... And the issues mentioned are still there. Jan 04 21:06:56 and on the first kernel release, all the apps worked reliable? Jan 04 21:06:58 no Jan 04 21:07:07 it is all work that is ongoing Jan 04 21:08:31 PaulFertser_: if they are older then x months and they are still there, rebumb them Jan 04 21:08:40 dolf1074: alphaone (i'm sorry he's left depressed, really) and stefan_shmidt said the communication with the SHR devs wasn't good. And you say it is. Whom should i trust? Jan 04 21:08:42 PaulFertser_: it's 6 weeks ago when the last log was attached and mickey commented on it plus obviously he did some work on it because there were commits for this issue in MS4.1 Jan 04 21:08:43 but now there are enough crap between the bugs Jan 04 21:09:06 Kensan: he did a half-working work-around. Not solved the problem in a proper way. Jan 04 21:09:10 PaulFertser_: and it's not just one bug. Jan 04 21:09:15 Kensan: sure. Jan 04 21:09:17 PaulFertser_: it's tied to a kernel bug. Jan 04 21:09:34 Kensan: And that is questionable. Jan 04 21:10:11 PaulFertser_: there are suspend resume issues in the current stable kernel and in the latest andy-tracking. Jan 04 21:10:52 Kensan: 5 weeks ago mickey was going to analise the logs. And it passed several months between the full mwesters description of the problems and mickey's response. Jan 04 21:11:07 PaulFertser_: aparently you know everything about the communication between SHR and FSO and you are well documented into the sources of framework to comment on them. So you're right. (But I still wonder why, if you are so documented into the sources of FSO, you can't help and make patches) Jan 04 21:11:30 Kensan: What suspend/resume issues are you seeing with andy-tracking? Honestly, i see none except not-working bluetooth. Jan 04 21:11:53 PaulFertser_: there's still Wsod reports. Jan 04 21:12:53 PaulFertser_: Which means he was busy? Jan 04 21:13:12 dolf1074: I don't know much about the communication. I'm just repeating what FSO devs told me. As to half-working fix... It's written in the commit message here: http://git.freesmartphone.org/?p=framework.git;a=commitdiff;h=52584bf1802590902a9c52b3a1188ccab0ad6669 Jan 04 21:13:12 PaulFertser_: in any case: where are the design issues? Jan 04 21:14:07 Kensan: WSOD, unfortunately, yes... But it's not related to the flow control issue. Jan 04 21:14:15 PaulFertser_: i never had WSoD with kernels other than andy-tracking 2.6.28 Jan 04 21:14:23 but with andy-tracking i had Jan 04 21:15:16 PaulFertser_: the comment even says, that it's going to be revisited and the bug was left open. Jan 04 21:16:01 PaulFertser_: so going from there to "FSO needs a serious redesign" is rather far fetched don't you think? Jan 04 21:16:42 Kensan: look at the link i pasted before. That's not a good design to cancel the timer. And to use it in first place too. IMO. Moreover, i just suspect the design issues. I'm not sure. But alphaone agrees there're some problems and stefan implies it. Jan 04 21:17:23 PaulFertser_: it's quite a lot of "think" "hear-say" to bring such allegations here don't you think? Jan 04 21:17:59 Kensan: in my guess the issue won't be workarounded like that in the first place. That good design would have provided a proper and easy way to solve the problem as soon as it was revealed. That's a guess. Jan 04 21:18:10 PaulFertser_: because in the end, and I am repeating myself, you basically told the FSO team their design and thus their work of the last year, is crap. Jan 04 21:20:31 PaulFertser_: obviously all three are acknowledging the problem and provided a workaround for now. Jan 04 21:20:35 Kensan: i'm just saying that some parts should be re-thinked. And probably redesigned. Stefan agrees that it might be the case. And alphaone too, as far as i understand them. And mickey's busy lately with other important tasks. That's what i see. Jan 04 21:20:45 PaulFertser_: I still don't see the design issues you keep bringing up all the time. Jan 04 21:21:56 Kensan: i think in a clean design there's no place for races. And we still have them. I don't know how to solve them properly in ogsmd. And i asked everybody. And nobody answered. Jan 04 21:21:57 PaulFertser_: your saying much more than that but let's leave it at that. Jan 04 21:22:34 PaulFertser_: the races are because of the hardware. Jan 04 21:23:09 Kensan: not my native language, please remember. I'm trying to state and express my thoughts as clearly and non-offensive as possible. Please forgive me if i don't always succeed in that. Jan 04 21:23:12 PaulFertser_: the calypso is broken and there's a ton of fixup/workaround code to make it usable. Jan 04 21:23:43 PaulFertser_: it's rather clear what you mean. Jan 04 21:24:26 Kensan: i doesn't seem that calypso is broken significantly more than other modems in the wild. So the fixups/workarounds should go cleanly and clearly in the design. Jan 04 21:24:36 PaulFertser_: oh but yes it is. Jan 04 21:24:50 PaulFertser_: it is very broken actually Jan 04 21:25:19 PaulFertser_: e.g. it's statemachine is acting on timeouts not on responses from the AP etc. Jan 04 21:25:30 PaulFertser_: in some cases but there's much more issues. Jan 04 21:26:24 Kensan: but one of the goals for the FSO is to provide a solid framework working with the calypso. Can they succeed without thinking about calypso's limitation while designing? Jan 04 21:27:30 PaulFertser_: IMHO they did a pretty good job so far. There's things that get dropped along the way and bugs all over the place but that's far from needing a redesign. Jan 04 21:27:32 Bonsoir à tous! hi their! Jan 04 21:29:08 Kensan: do you hack on ogsmd code? It looks cool and clean, yes. But why it fails real-life tests too often? Broken calypso? But we have to live with that, thanks to the TI. Jan 04 21:29:52 PaulFertser_: no I don't hack the code but I have looked at here and there. Jan 04 21:30:10 PaulFertser_: Software breaks and this is no different. Jan 04 21:31:40 PaulFertser_: the calypso has man short-comings and strange interactions. I am not saying it's the cause for all issues/problems. Jan 04 21:31:52 Kensan: i think the FSO team gained a lot of new knowledge during the actual development. And you know, sometimes some parts just need to be rewritten from scratch. I'm not saying it's what is needed right here right now. I'm just asking. And the only answer i get is "i'm not sure, ask mickey". Jan 04 21:31:58 it would be really interesting to see how calypso is used on other phones Jan 04 21:32:41 PaulFertser_: I am trying to give you a different answer here... Jan 04 21:33:00 Kensan: But you're not developing ogsmd, unfortunately. Jan 04 21:33:47 PaulFertser_: the API/design of the various FSO systems has been changed and adapted where needed. Don't think it's all done and fixed, but I think the team has thought about it hard and done a pretty good job. Jan 04 21:34:23 Kensan: i agree. But why don't they make properly fixing ogsmd the top priority? Jan 04 21:35:04 PaulFertser_: you want to make it the one and only priority which is simply not realistic. Jan 04 21:35:31 PaulFertser_: stability etc is important but quite frankly there's many people that think it's ok and rather want opimd Jan 04 21:36:01 Kensan: i want to make it top priority for Mickey, yes. As he's the only one actively hacking on ogsmd. Jan 04 21:36:56 PaulFertser_: You don't have the power to make him do anything. You can try to convince him but pushing every member of the fso team this hard is rather annoying I could imagine. Jan 04 21:37:57 Kensan: i better communicate with computers than with people, that's true :( Jan 04 21:39:42 PaulFertser_: everybody is wishing for something and wants the project to move in a certain direction. Each and everyone wants the project to go off in a different direction. Mickey has the delicate task to somehow come up with a plan how this can all fit together - which is obviously impossible. Jan 04 21:40:10 Kensan: what's surprising is that every other member of the fso team doesn't stay his opinion strong enough and says "ask Mickey" instead... Jan 04 21:40:44 Kensan: should the SHR devs opinion be prioritized for Mickey? Jan 04 21:41:06 PaulFertser_: well yes, because he has the responsibility. Jan 04 21:41:11 that's because all members in a team has different opinions and they want to give a unified opion to the world Jan 04 21:41:24 therefor they say 'ask Mickey' Jan 04 21:41:33 dolf1074: since when unified opinions are good in the Free Software world? Jan 04 21:41:42 PaulFertser_: I am sure mickey is taking the SHR devs opinions into account. Jan 04 21:42:03 PaulFertser_: it is a FOSS project but mickey is paid to do this work. Jan 04 21:42:09 PaulFertser_: the persons in the FSO will have meetings where they can spill out there different opinions Jan 04 21:42:12 PaulFertser_: it's not all black and white. Jan 04 21:42:49 dolf1074: I'm asking a person, not a machine. I think every member of a team should be able to state his own personal opinion no matter what. Jan 04 21:43:27 PaulFertser_: what if the team decides they discuss issues internally? Jan 04 21:43:29 not of his opinion gives other people toys for rants. Oh mickey, he also wants it, why don't you do it? Jan 04 21:43:42 PaulFertser_: it is their right to do that and you can not tell them how they should work. Jan 04 21:43:48 Kensan: the fact he's paid shouldn't matter that much, i hope. He should do whatever he thinks should be done. That's what he's paid for, i hope. Jan 04 21:44:01 PaulFertser_: exactly, and that's what he is doing. Jan 04 21:44:50 PaulFertser_: that's why he is not simply considering the opinion of "the loudest guy in the room" (so to speak ;) as the only opinion. Jan 04 21:45:10 Nobody wants me to develop software for the OM FR. Jan 04 21:45:15 dolf1074: I think it's a valid question. "Why don't you do it?" A good valid question. I've seen honorable cool devs explaining their decisions in details for everybody at LKML. Jan 04 21:46:10 PaulFertser_: yes, because otherwise the code does not get merged. Jan 04 21:46:28 The small different is that everybody in FSO is working hard on FSO and don't have time to do cool explaining in detail Jan 04 21:47:01 and especially not for everybody who finds this channel Jan 04 21:47:05 Kensan: and that's good. He should consider the opinion of those who does the real development, that is the SHR devs. I'm just trying to highlight to the SHR devs that something is broken and needs fixing. Jan 04 21:47:28 PaulFertser_, was your buffer fixing bug accepted/ Jan 04 21:47:43 PaulFertser_: the SHR devs are working on SHR and not on FSO Jan 04 21:47:45 Sargun: no. quickdev is still fixing it. Jan 04 21:47:49 PaulFertser_: SHR is just using the framework, FSO is doing the real work !! Jan 04 21:48:17 we are just making some nice application around it Jan 04 21:48:20 dolf1074: Exactly the reason why the SHR devs should be worried about the health of the FSO. Jan 04 21:49:03 are you now saying the SHR devs aren't worried about the health of FSO? Jan 04 21:49:25 PaulFertser_: you are constantly insinuating, that FSO is not healthy, the design is broken and should be rewritten. Please back that up because nothing you have told me so far has convinced me that FSO is actually in need of a redesign. Jan 04 21:49:26 dolf1074: i'm afraid (not sure) they aren't worried enough, yes... Jan 04 21:49:51 raster: hey there. happy 09 to your sir Jan 04 21:49:54 And why do you think that? Jan 04 21:50:09 * raster yawns Jan 04 21:50:14 morning! Jan 04 21:50:18 Kensan: yeah, i sound like a wierd clown, have to admit. Jan 04 21:50:19 evening :) Jan 04 21:50:25 Kensan: shanks! Jan 04 21:50:43 schame tew yew! Jan 04 21:50:46 :) Jan 04 21:50:51 raster: akimashite omedetou Jan 04 21:51:53 PaulFertser_: nobody is saying that but since you are formulating these "accusation" I think it would seem fair if you backed up these accusations with actual facts etc... Jan 04 21:52:02 Kensan: the reason of my "rants" is: i use my FR as a phone and look at the logs and at the code. And i see that the known problems with basic modem handling are there sitting unsolved for months. I guess that if the design was good enough, then the known problems would be solved faster than that. That's all. Jan 04 21:52:37 PaulFertser_: my impression is that the hardware indeed is buggy Jan 04 21:53:07 PaulFertser_: I still see some basic problems with my ubuntu, so the design of ubuntu is crappy? Jan 04 21:53:30 raster, any suggestions how to further investigate it? http://rafb.net/p/7nwSaM55.html Jan 04 21:53:48 Kensan: and that latest workaround of scheduling a timer with a delayed initialization after resume. And that work-around is still half-working as such... I hoped that mickey will fix it in a more robust way. And i'm afraid he couldn't have done it because it's the design issue. Jan 04 21:54:14 lindi-: yes, very buggy, indeed. And the design should allow all sort of necessary workarounds. Jan 04 21:55:10 PaulFertser_: yes Software is a kind of magic and can make all hardware issues go away... Jan 04 21:55:56 quickdev: I'man change so whole libframeworkd-phonegui-efl uses elementary labels, but can you do the Jan 04 21:56:02 Kensan: not all, but most known documented issues... Jan 04 21:56:27 raster, do you advise us to use elementary labels instead of edje text? To make it themable.. Jan 04 21:56:38 quickdev: i have never seen that. seems to me like the bindings are not initting elm right Jan 04 21:56:44 ie passing argv + argc Jan 04 21:56:46 OR Jan 04 21:56:52 quickdev: I'm busy with the changes of inserting elementary labels, but can't find a way to change the text of a row. Jan 04 21:56:56 argv/c are being changed after setting Jan 04 21:57:10 raster, ok, thx - please answer to the next question :) Jan 04 21:57:11 dolf1074: I think the management of ubuntu is crappy. And honestly, i'm afraid the user base of ubuntu is unhealthy. Look at their forums. They suggesting wild things and don't know how to even provide the devs with a backtrace. Jan 04 21:57:21 chances are it may be the 2nd Jan 04 21:57:29 PaulFertser_: given enough time that might be quite possible but there's other things that are more important and that is exactly your main issue all along: your priorities do not lign up with the priorities as mickey sees them. Jan 04 21:57:47 tho maybe u were passing null... Jan 04 21:57:49 not sure Jan 04 21:58:23 dolf1074: I've seen they highligted "fail-safe" x-server as one of the design goals lately. And it's crap, it just messes with the sane way of writing xorg.conf. Especially with several X-servers on one machine. And that's just one example. Jan 04 21:59:15 raster, do you advise us to use elementary labels instead of edje text to make things themable? Jan 04 21:59:35 quickdev: elm labels? um... yes. Jan 04 21:59:44 as sizing is handled for you in the widget tree Jan 04 21:59:56 ie label gets bigger - parent is told and tries to expand to fit etc. Jan 04 22:00:20 hello, i've some problems with the wifi in SHR : normally(in power saving mode) it has trobble: it is not connected 100% of the time...but if i do wmiconfig -i eth0 --power maxperf it eat the battery too fast(realy fast) Jan 04 22:00:20 Kensan: yes, exactly... I wish mwester commented on this topic :( Jan 04 22:00:26 raster, we don't need size handling - just a themable color / size so far :) Jan 04 22:00:54 well other than labels following the theme Jan 04 22:00:54 PaulFertser_: I know what he thinks. Jan 04 22:01:19 PaulFertser_: I have talked to him many many times and we agree on many things. Jan 04 22:01:26 PaulFertser_: and on some we disagree Jan 04 22:01:30 PaulFertser_: but that's life. Jan 04 22:01:46 quickdev: if we use edje text, the .edj files of lfw-efl will be themed. Else I only need to theme the different widgets in the different libraries (etk/elm) Jan 04 22:01:49 Kensan: what does he think about FSO's priorities then? Jan 04 22:02:21 PaulFertser_: if it's that important to you then there's only one way: try to fix it yourself or further pinpoint the issue(s). Jan 04 22:02:40 PaulFertser_: make it a low-hanging fruit for the FSO team to fix. Jan 04 22:03:17 dolf1074, yeah. let's use elm labels :) Jan 04 22:03:27 Kensan: a recent example: quickdev had an issue with gsm0710muxd. A real one. Reproducable, etc. And Mickey hadn't enough time to fix it. Isn't it a bit strange? Jan 04 22:03:41 PaulFertser_: why is that strange? Jan 04 22:03:51 quickdev: okay Jan 04 22:03:59 PaulFertser_: mickey is a very busy man. Jan 04 22:04:10 dolf1074: it's up to you Jan 04 22:04:18 you ask me - i asay - use labels Jan 04 22:04:22 but you are free not to Jan 04 22:04:25 Kensan: if he cared about stability of ogsmd really hard, he would have taken the opportunity to debug the issue (easy, reproducable) ASAP. That's how i see it. Jan 04 22:04:26 but there are consequences Jan 04 22:04:27 PaulFertser_: he's not waiting at his desk for bug-reports. He is doing many things and most of them we (the community) never hear about. Jan 04 22:04:46 raster: yeah? Jan 04 22:04:46 Kensan: And i read commit logs. I see what he's working on. Jan 04 22:05:19 PaulFertser_: well then, obviously you know he is a lazy bastard. Jan 04 22:05:29 PaulFertser_: seriously WTF Jan 04 22:06:14 PaulFertser_: you can't imagine he is doing other important work besides what you can read on the mls and in the repos? Jan 04 22:06:19 I would also go for labels, that's something we can fully theme Jan 04 22:06:37 dolf1074: yes. labels will not follow elementary theme Jan 04 22:06:46 they will be whatever your custom theme decides Jan 04 22:06:48 Kensan: important in general or important for the FSO project? If the former, then yes, i can hardly imagine it. Jan 04 22:07:12 s/former/latter/ Jan 04 22:07:12 PaulFertser_ meant: Kensan: important in general or important for the FSO project? If the latter, then yes, i can hardly imagine it. Jan 04 22:07:33 runytime scale changing (eg someone goes and changes scaling preferences while an app runs) likely wont work well Jan 04 22:08:05 PaulFertser_: as he said: he is working parttime on FSO. He has other work at the same time and god forbid he has to eat and sleep too. Jan 04 22:08:52 raster: what do you mean on runtime scaling? Jan 04 22:08:55 Kensan: i thought he's working full-time. Jan 04 22:09:02 i change the scale settings Jan 04 22:09:13 raster: Opening the keyboard is also scale change of the window? Jan 04 22:09:36 no Jan 04 22:09:39 20:26 < mickey> people want opimd asap Jan 04 22:09:39 20:26 < mickey> people want stability on everythign Jan 04 22:09:40 20:26 < mickey> and we're just 4 part timers Jan 04 22:09:40 scale as in dpi scaling Jan 04 22:09:51 where text is bigger on higher dpi screens Jan 04 22:09:55 ah okay, that's okay Jan 04 22:09:57 where u can set min/max scaling limits Jan 04 22:10:00 PaulFertser_: that statement is about part timers includes mickey Jan 04 22:10:06 that will likely not change Jan 04 22:10:06 thats a user settable value Jan 04 22:10:14 theres a dialog for that in e Jan 04 22:10:34 but if they restart app, it is okay? Jan 04 22:10:36 PaulFertser_: even then, you cannot expect him to prioritize the same things that you wish him to do. Jan 04 22:10:37 Kensan: ok, let's stop this useless discussion. I'm being a lazy annoying bastard here, and the SHR devs are happy with what they have and how FSO evolves, etc... Thanks for you time. Jan 04 22:11:43 PaulFertser_: I am not saying everything is happy and jolly but it's far from having a broken design. Stuff breaks, issues fall through the cracks that life but I am very confident that the fso team is working very hard. Jan 04 22:12:50 I am sure Ainulindale and quickdev make themselves heard when something stinks *heh* Jan 04 22:14:18 Kensan: i believe they're working hard. It's just that they don't care about stability as much as i do. And as it was stated clearly that the SHR devs are happy with what they have, well... Probably they'll face the issues later. Probably not. You're the experienced and cool developers, i hope you're right and i'm not. Jan 04 22:14:46 imho there are some design errors in fso Jan 04 22:14:53 at least in my optinion Jan 04 22:14:57 like idle handling Jan 04 22:15:07 reading the ts device directly Jan 04 22:15:09 for example Jan 04 22:15:19 PaulFertser_: trust me, they do care about stability but there's just a ton of work and not everything can be done at once. Jan 04 22:15:23 instead of just letting the ui message fso to say "ok - ui is idle Jan 04 22:16:49 raster: my pick would be the one-python-process issue but we talked about that Jan 04 22:16:56 raster: do you have any opinion on the ogsmd design? I suspect it's not exactly suitable for dealing with buggy gsm modems (read calypso). Jan 04 22:17:31 Kensan: yeah. and it's not design - but implementation-wise, it's a mem hog - and cpu. :( Jan 04 22:18:02 PaulFertser_: i dont have a take on that - i havent looked in detail beyond some of the dbus api Jan 04 22:18:33 raster: too sad nobody except Mickey has. And he's too busy with other things. Jan 04 22:18:37 other thnig at the moment i'm dubious on design-wise is putting all sms message storage handling and contacts handling behind a dbus api Jan 04 22:18:48 basically u're re-inventing a database Jan 04 22:18:53 or datastore in files Jan 04 22:18:56 via dbus Jan 04 22:19:18 at that point - i think the only thing should be the simple sim-card storage handled by fso Jan 04 22:19:25 anythgn else should be "someone elses business" Jan 04 22:19:27 raster: I think that's all "in the flow" since nobody has really done some serious thinking about opimd etc. Jan 04 22:19:55 Kensan: my thinking has been a "dont think thats a good idea" Jan 04 22:19:56 :) Jan 04 22:19:58 raster: And there was a message asking for opinions about this issue of dbus access to a database on the smartphones-standards. Obviously, everybody's too busy with other important tasks. Jan 04 22:20:00 thats my gut instinct Jan 04 22:20:03 raster: hehe Jan 04 22:20:29 PaulFertser_: i've commented on here several times Jan 04 22:20:30 :) Jan 04 22:21:10 Kensan: you see. SHR is so waiting for the opimd and yet you say that nobody has really done some serious thinking about it? Jan 04 22:21:21 but as such these are the 2 things i disagree with with fso design-wise Jan 04 22:21:24 and 1 with implementation Jan 04 22:21:30 i dont have anything else on my list Jan 04 22:21:36 whihc is pretty good for FSO actually Jan 04 22:21:36 :) Jan 04 22:22:04 PaulFertser_: yes because it has a lot todo with abraxa which may or may not be working on it finally Jan 04 22:22:49 ok, that's proof Jan 04 22:22:56 raster said it Jan 04 22:23:06 lol Jan 04 22:23:10 hahahahaha Jan 04 22:23:18 things have mistakes Jan 04 22:23:28 gobs of core fundamental ones are bad Jan 04 22:23:35 a few design errors here and there can be fixed Jan 04 22:23:39 or "ignored" Jan 04 22:23:53 eg - if u believe opimd is just a wrong way to go - i can choose to just not use its api at all Jan 04 22:24:13 the power management idle handling is a more serious flaw Jan 04 22:24:42 as it directly conflicts/competes with things like x's screenblanking and powersaving Jan 04 22:24:44 eg Jan 04 22:24:48 if u blank the screen Jan 04 22:24:59 x can (and should) do things like shut down the gfx unit Jan 04 22:25:05 (set its clock to 0) Jan 04 22:25:14 and this often also means losing video ram contents and refresh stops Jan 04 22:25:25 but before it does this it may need to copy data out of video ram and save it Jan 04 22:25:37 raster: and if all of the calypso's shortcomings really can't be handled in a robust a stable way, then what? Are we screwed? Should it be a development priority, what do you think? Jan 04 22:25:49 and fso has no clue how to do all this - except just fiddle with brightness/backlight values Jan 04 22:26:10 leave the screne dimming/power management handling and idle detection to the system handling the gfx subsystem and input system Jan 04 22:26:21 raster: well power-management is one of the areas to tread carefully.. Jan 04 22:26:43 raster: meaning there's lots room for improvement. Jan 04 22:26:47 PaulFertser_: dude. imho with calyopso... you're screwed anyway :) Jan 04 22:27:13 Kensan: i know. so i'm not really touching that area as i consider it "under debate" Jan 04 22:27:16 raster: same as with Glamo *shazam - double combo hi* Jan 04 22:27:21 haha Jan 04 22:27:45 i admit that x's simple screenblanking infra is also inadequate Jan 04 22:27:55 but the problem should be solved in x - not in fso Jan 04 22:28:09 ie fix xrandr to support baklight controls via output properties Jan 04 22:28:19 raster: yes, I think there's much that can be done on the kernel side so mickey is it focusing on other stuff. Jan 04 22:28:21 so now everyone goes THRU x to handle blanking/brightness Jan 04 22:28:24 raster, I think I found the root of the segfault. Now there's another bug. The background is always black - althougth elementarys default bg should be white. Jan 04 22:28:27 now its coordinated in 1 spot Jan 04 22:28:40 quickdev: did u add a bg widget? Jan 04 22:28:44 and show it Jan 04 22:28:52 and tell elm that that widget is a resize object Jan 04 22:28:57 (well tell the window widget) Jan 04 22:28:57 ? Jan 04 22:29:13 raster: yeah, true. Jan 04 22:30:08 mwester-laptop: bonsoir Jan 04 22:30:24 mwester-laptop: and a great 09 for you and your family Jan 04 22:30:41 raster, it's the elementary-python test app: http://rafb.net/p/GulWPJ79.html Jan 04 22:30:51 Thank you - same to you and your family! Jan 04 22:30:53 mwester-laptop: Happy hacking in the new year :) Jan 04 22:30:58 :) Jan 04 22:31:23 mwester-laptop: how's the new job? Jan 04 22:32:01 mwester-laptop: u got a new job? Jan 04 22:32:25 mwester: you got which new job? :) Jan 04 22:32:51 quickdev: seems to do the right things - if the bindings are right. Jan 04 22:33:04 other than setting the weight to 1.0 1.0 before adding as resize object Jan 04 22:33:10 raster, that's it. There's probably a problem with the bindings Jan 04 22:33:13 whihc is simply just a little nicer on callback storms Jan 04 22:33:54 also the c version of rhe test sets some other limits like a min/max size to the bg which in turn as its a resize object, limits the window too Jan 04 22:34:10 Kensan: new job is great, but busy - little time for play between the holiday activities and work. Jan 04 22:34:43 (as elm is inlike gtk/qt u have multiple objects that can be resize objects and thus u can stack widgets/objects and all of them play a role in limiting window sizing params - tho under illume this becoems much less relevant as illume will insist on maximising all windows except dialogs) Jan 04 22:35:12 mwester-laptop: quit old job voluntarily? or involuntary? Jan 04 22:35:15 mwester-laptop: I see, that's good news - well not the busy part ;) Jan 04 22:35:39 raster: his job had something to do with the us autoindustry... Jan 04 22:35:52 raster: involuntary (closely associated with the american auto industry, so there was no surprise about it). Jan 04 22:36:26 mwester-laptop: i'm being an annoying lazy bastard here and spent everybody's time implying that Mickey should have investigated #31 (flow-control) faster and that he should work on ogsmd more and that ogsmd might have design problems etc. What do you think about that? Jan 04 22:36:30 mwester-laptop: aaah. i remember you being a bit worried about keeping a job at all as your sales rhad prettymuch flatlines Jan 04 22:36:35 flatlined Jan 04 22:36:54 didnt know if u jumped ship or were tossed off :) Jan 04 22:37:23 raster: they threw him off the titanic Jan 04 22:37:31 scnr Jan 04 22:38:44 ok, that one was bad for the karma. Jan 04 22:39:23 ahhahaa Jan 04 22:41:03 well I'll be productive and... play some video games. Jan 04 22:41:21 * Kensan thinks vacation is awesome Jan 04 22:42:13 * ljp bought a house and moved during his holidays Jan 04 22:42:53 ljp: congratulations. December seems to be the month of moving in australia ;) Jan 04 22:43:00 PaulFertser_: #31 is closed as far as I can tell; closing it exposed a parser issue with ogsmd that needs fixing. Another thing that I overloaded 31 with is an architectural issue that needs more exploration. Jan 04 22:43:09 ljp: congrats! Jan 04 22:43:27 thanks Jan 04 22:43:29 ljp: bigger? better? faster? Jan 04 22:43:30 :) Jan 04 22:43:33 yep Jan 04 22:43:50 raster: http://images.icanhascheezburger.com/completestore/2009/1/4/128755826886637810.jpg Jan 04 22:44:05 yes, i don't have anything to do Jan 04 22:44:20 faster? :) We'll need to compare continental drift rates, I guess! Jan 04 22:44:36 hehe, these crazy aussies Jan 04 22:44:36 mwester-laptop: I think you have discovered some oddities in the flow control handling of calypso. Would you mind documenting them somewhere? Jan 04 22:44:55 Hire: HGAHAHAHAHAHAHAHAH Jan 04 22:45:23 leave malloc code eves :( Jan 04 22:45:25 coding pussy is currently hanging out at the mouse Jan 04 22:45:26 faster because it has tiles throughout and get very slick when wet Jan 04 22:45:28 he wants to help you Jan 04 22:45:45 ljp: tiles! good for spillages. :) Jan 04 22:45:55 Hire: malloc is my magic-8-ball Jan 04 22:45:55 PaulFertser_: they've been documented in the old bug OM bugtracker. But they have been pretty thoroughly worked around at this point. Jan 04 22:45:58 mwester-laptop: so, no comments on what should be more important for Mickey? Sad. Now i'm told that everyone wants opimd and that's why ogsmd is not worked on. Jan 04 22:46:04 "malloc - do i use a hash or a list?" Jan 04 22:46:05 yes. with two kids that like to go naked too Jan 04 22:46:09 malloc: "prrrrr" Jan 04 22:46:16 "ok - hash it is!" Jan 04 22:46:17 :) Jan 04 22:46:26 do you have to shake him for an answer? Jan 04 22:46:35 no Jan 04 22:46:38 just scratchies Jan 04 22:47:55 mwester-laptop: ok, i'll try to find the description in the old OM bugtracker and propose a patch to Mickey to include the info to his special "what's-wrong-with-the-calypso" file. This information might be useful for other programs. Jan 04 22:48:12 PaulFertser_: What FSO should work on is Mickey's decision, and opimd is an essential part of the framework that is necessary. I think that we need to have more community involvement, to free Mickey's time. Someone needs to step up to be a second ogsmd expert, someone who can invest time to "experiment" with the oddities of the FR. Jan 04 22:51:48 mwester-laptop: Thanks for the answer. At least you confirmed that ogsmd needs attention. :) Jan 04 22:53:45 The problem is that i see some oddities of the FR but i don't have a slightest idea how to fix them given the current ogsmd facilities. Jan 04 22:54:34 raster, I found the background issue. Another bug in the binding Jan 04 22:54:48 yay! bindings! Jan 04 22:55:13 Moreover the idea of "unsolicited responses" is flawed by design. It just messes too much the way the AT command set was designed. And how to overcome them is beyond my understanding. It really needs an expert. Jan 04 22:55:43 I disagree, actually -- an unsol response is the gsm equiv of an interrupt. Jan 04 22:56:01 And just like interrupt handling in the kernel, handling of unso resp. is tricky. Jan 04 22:56:32 bah Jan 04 22:56:33 its an event Jan 04 22:56:34 because while they *should* be statistically distributed evenly over time, Murphy ensures that they always arrive when you least desire them. Jan 04 22:56:36 deal with it :) Jan 04 22:56:40 (not hard) Jan 04 22:57:08 unless they do things like "well once u get a response X thats unsolicited u no longer can to commands X, Y, Z or the whole thng will barf" Jan 04 22:57:14 or "must be handled within 200ms" Jan 04 22:57:30 (and a request of X, Y or Z must be sent within this time or the chip explodes" Jan 04 22:57:33 raster: not hard, in theory. in practice, they are hard to sort out from other text streams on the same channel. Jan 04 22:57:41 then you just have rabidly stupid design in the modem Jan 04 22:57:46 Yes. Jan 04 22:58:07 That's why we need a very smart design in the ogsmd. ;) Jan 04 22:58:19 the gsm AT protocol is just stupid -- it's like an engineering class conducted with nothing but cave paintings. Jan 04 22:58:28 maybe u dont need smart design Jan 04 22:58:33 but just enough hackery to make it work Jan 04 22:58:37 That's it. Jan 04 22:58:41 and then hope for a gsm modem that doesnt suck in future Jan 04 22:58:53 i'd opt for the latter Jan 04 22:58:58 1. gta02 is a small-run device Jan 04 22:59:05 2. calypso is dead as of gta02 Jan 04 22:59:07 That's the current idea. Make it simple, add hackery. And hope for the better. Jan 04 22:59:10 IFF the modem was properly documented, and well designed, it would probably have some other protocol or customization to better handle the stuff. Jan 04 22:59:14 in fact it already was an end-of-line chip Jan 04 22:59:18 But we're stuck with the calypso. Jan 04 22:59:19 before the gta02 came out Jan 04 22:59:40 you're designing for a basket case Jan 04 22:59:45 Exactly.l Jan 04 22:59:48 not the "common case" Jan 04 22:59:50 :) Jan 04 23:00:10 So we need FSO to handle the common case, then we need the community to bastardize the Calypso driver to do what is necessary. Jan 04 23:00:15 raster: are you sure the new modem doesn't suck? Jan 04 23:00:23 no Jan 04 23:00:30 but knowing what i do about the calypso Jan 04 23:00:40 i'd bet that pretty much anything is better Jan 04 23:00:40 Mickey has access to the new modem; I'm sure that if there are similar issues with the calypso, he'll flush them out. Jan 04 23:00:42 :) Jan 04 23:01:26 What we need to do is to open tickets on all the individual Calypso issues that are exposed by FSO, so that someone can evaluate the new GSM against those issues. Jan 04 23:01:29 raster: do you think i should propose to Sean to issue a press-release with bashing of TI and other companies that broke promises? I'm so frustrated with the calypso. Jan 04 23:04:02 PaulFertser_: ti broke no promises Jan 04 23:04:26 there are always issues with modems Jan 04 23:04:28 PaulFertser_: doing so would be a great way to ensure your company is blacklisted by many suppliers and never will be able to do business again Jan 04 23:04:49 PaulFertser_: calypso is 100% om's problem Jan 04 23:04:52 raster: didn't they promised to provide a working hardware? #666 was a clear indication they broke this promise. As #1024 is. Jan 04 23:04:56 If they even notice, of course -- Om is so utterly unimportant to TI or any other vendor in terms of volume. Jan 04 23:05:13 PaulFertser_: calypso was end-of-lifed long before om shipped it in gta02 Jan 04 23:05:27 ti said so and said there would be no support forthcoming as it was end-of-lifed Jan 04 23:05:31 om shipped it anwyay Jan 04 23:05:34 begged for help Jan 04 23:05:36 and got some Jan 04 23:05:45 so ti - out of the goodness of their hearts went beyond what they agreed to Jan 04 23:06:12 not to mention calypso was used purely because there was a pile of stock of the chips Jan 04 23:06:17 that had been sitting around for years Jan 04 23:06:22 raster: why did it take so long to communicate with TI to allow reflashing with fluid? Is it a good relation to customers? Jan 04 23:06:29 and needed to be used up Jan 04 23:06:37 raster: and why don't they provide enough firmware sources? Jan 04 23:06:48 and theres other background to this that i can't talk about as its sensitive internals - but the result woudl be Jan 04 23:07:10 "my god - i am amazed ti would even answer and email or phone call at all from om" Jan 04 23:07:22 dude Jan 04 23:07:27 its an END OF LIFE chip Jan 04 23:07:32 before it went into the gta02 Jan 04 23:07:36 vendors were told that Jan 04 23:07:42 om included Jan 04 23:07:45 and that support wouldnt happen Jan 04 23:08:07 om didnt have a source code license agreements to begin with so they knew what they had Jan 04 23:08:21 do not blame TI for calypso Jan 04 23:08:38 when there is blame to be had - let it be had appropriately Jan 04 23:08:58 in this case it's not ti's fault Jan 04 23:09:11 raster: ok, now i see... so calypso is shit, but TI is not to blame because if it weren't EOL, TI would have helped with all the issues... Jan 04 23:09:23 actually no Jan 04 23:09:35 there are other reasosn i cant mention Jan 04 23:09:45 that make it amazing ti even would talk with om Jan 04 23:09:54 irrespective of anything else Jan 04 23:10:01 ti went above and beyond in all ways Jan 04 23:10:04 raster: when gta01 was shipped by Om, calypso was supported by TI? Jan 04 23:10:12 maybe not as far aas you'd like by dumping all the sources on om Jan 04 23:10:26 dos1: yes - i think so Jan 04 23:10:31 though it was still marked for oel then Jan 04 23:10:36 but it wasnt eol'd yet Jan 04 23:10:46 but the other fact still remains Jan 04 23:10:51 that i'm amazed ti helped at ALL Jan 04 23:10:58 they went above and beyond in all ways Jan 04 23:11:06 raster: I trust you. Ok, now i know that TI is not guilty. Thanks a lot for the clarification. Jan 04 23:11:12 it was TI that got screwed Jan 04 23:11:25 not OM Jan 04 23:11:25 just trust me Jan 04 23:11:29 i cant mention the details Jan 04 23:11:35 its now water under the bridge Jan 04 23:11:50 I trust you, yes. Jan 04 23:11:53 om is doing many very stupid decisions... Jan 04 23:12:29 om did go with glamo on the agreement that the docs would be open and just needed review by om Jan 04 23:12:31 om reviewd Jan 04 23:12:36 and asked for them to be opened Jan 04 23:12:46 even just named specific chapeters to open - the ones that are relevant to the programmng of it Jan 04 23:12:51 and smedia said no Jan 04 23:12:56 they went back on an agreement Jan 04 23:13:17 in that case you can blame the supplier of the chips for breaking an agreement Jan 04 23:13:29 though they did provide all the programming docs to om to do it themsleves Jan 04 23:13:30 and om did Jan 04 23:13:34 x is accelerated Jan 04 23:13:41 raster: so maybe OM should issue a press-release bashing S-media then? ;) Jan 04 23:13:47 no Jan 04 23:14:05 unopenned glamo was smedia fault, i know Jan 04 23:14:07 if om wants to stay in business Jan 04 23:14:21 it'd better not make a habit of airing dirty laundry in public Jan 04 23:14:25 as once it dfoes so Jan 04 23:14:44 but whole ASU is mistake for me Jan 04 23:14:52 every other supplier will go "fuck that - i'm not sellign anything to you - if i do the slightest thing wrong or we just happen to disagree you'll go giving me bad press" Jan 04 23:15:27 the way you do business is you simply cease doing business with suppliers that dont supply you with what you want and need Jan 04 23:15:33 you find one that does Jan 04 23:15:38 they lose sales Jan 04 23:15:50 admittedly om's buying power is so tiny that it invariably doesnt hurt them Jan 04 23:16:06 theey likely consider it a positive as a picky pain-in-the-butt customer is gone Jan 04 23:16:16 and u can focus ont he cusotmers that buy 10x or 100x the volume Jan 04 23:16:17 :) Jan 04 23:16:57 so, every other supplier doesn't want to be open and honest and reserve a way to back up their promises and so on and that is business and that is life and that's why we'll face broken promises in the future and there's no way around it and that's why my life sucks. ;) Jan 04 23:17:20 thats why you have contracts Jan 04 23:17:30 and contracts have these thngs in black and white Jan 04 23:17:34 and you have penalty clauses Jan 04 23:17:43 raster: small question, elm labels aren't aligned in the middle of a edje Swallow part? Jan 04 23:17:46 and you take them to court and get your pound of flesh Jan 04 23:18:20 dolf1074: that depends on the swallow Jan 04 23:18:45 but as such if the label is expanded in size bigger than its "minimum size" it will be left-aligned test Jan 04 23:18:47 like in any document Jan 04 23:18:55 thats just how the theme style has it Jan 04 23:19:10 raster: And it doesn't work as to take them to court you need plenty of money and a small company just can't afford to sue a huge supplier and that may result in the same thing you mentioned earlier - one will be considered a pain in the butt and avoided by other suppliers? Jan 04 23:19:27 raster: and how can you say to the swallow part that it may not stretch the label? Jan 04 23:19:51 PaulFertser_: the difference is - one is the mature way to do things. the others is like being a small child whining about not having their icrecream Jan 04 23:20:09 generally court cases arent press releases being publicsed all over Jan 04 23:20:34 PaulFertser_: but if you wish to run your own phone manufacturing company and run it that way Jan 04 23:20:35 go for it Jan 04 23:20:42 its your money and your company and your business Jan 04 23:20:43 raster: i respect small children and the way they do things. At least they usually don't lie, don't play under the cover and they're honest and open. Jan 04 23:20:54 until then what om does is their decision Jan 04 23:21:09 dolf1074: set a max size on it of 0 0 Jan 04 23:21:13 (the swallow) Jan 04 23:21:26 the child will increase that max size by its min size Jan 04 23:21:41 raster: thanks, I will try Jan 04 23:21:53 kinds Jan 04 23:21:55 honest and open Jan 04 23:21:57 HAHAHAHAHHAHA Jan 04 23:22:20 raster: but... some OT, i just want to know: is slow bus from cpu to glamo determined by glamo chip? could there be faster? Jan 04 23:23:03 dos1: yes. glamo will only accept external reads/writes at a given rate reserviing the rest of access cycles to its internal vidoe refresh and accelerator Jan 04 23:23:19 and its about as fast as it will get Jan 04 23:24:57 raster: i'll never be able to run a business. I hope to stay immature enough for the rest of my life ;) Jan 04 23:26:04 raster: thx. i wonder why smedia is selling it as vga cappable, when it's working fast enogth only with qvga Jan 04 23:26:16 dos1: it is vga capable Jan 04 23:26:17 JUST Jan 04 23:26:26 its like anything with specs Jan 04 23:26:46 enough* (? ;D) Jan 04 23:26:47 "yes - it does vga, while going downhill, with a tailwind, and a teflon roadsurface" Jan 04 23:27:04 if u READ the specs - not just the checkbox featuresheet Jan 04 23:27:11 but the actual programing specs Jan 04 23:27:15 the register map and so on Jan 04 23:27:25 it becoems apparent that it was NOT designed for vga Jan 04 23:27:27 it CAN do it Jan 04 23:27:30 just - at a stretch Jan 04 23:27:40 but it was meant for qvga level resolutions Jan 04 23:27:52 vga is a total "outer limit" thing Jan 04 23:28:09 raster: had om known it before they decide to use it in gta02? Jan 04 23:29:12 its like trynig to drive in a formula-1 race with a vw beetle Jan 04 23:29:14 anyway, all of those bad hardware choices will be gone for the GTAO3 no? Jan 04 23:29:15 no more glamo and good opened gsm chip. Jan 04 23:29:17 or take your vw to lemans Jan 04 23:29:17 (I don't remember where i read that (perhaps in forseign openmoko)the gsm chip for gta03 is a benediction compared to TI's one.) Jan 04 23:29:18 NO? Jan 04 23:29:23 and wonder why - it may complete the race Jan 04 23:29:32 it does so prettymuch far behind everyone else Jan 04 23:29:33 :) Jan 04 23:30:01 or attach a 2tonne trailer to your vwm and wonder why it doesnt quite handle going uphill anymore Jan 04 23:30:01 maybe i'm asking stupid questions, but i just want to understand situation ;x Jan 04 23:30:06 (but will go ok on the flat) Jan 04 23:30:07 :) Jan 04 23:30:17 glamo was chosen before i arrived Jan 04 23:30:27 i dont know if someone sat down and read the full programming docs Jan 04 23:30:31 but i did when i started Jan 04 23:31:27 and my conclusion was "vga is pushing this - it was realyl a qvga chip - and you can go write lots of accel for it and u'll likely spend a lot of effort going nowhere. a dub fb like gta01 will get you about as much "Speed" with 0 work. glamo will get you the "same" with a tonne of work - if you implement everything. if u are lucky" Jan 04 23:31:30 with 2 exceptions Jan 04 23:31:40 1. video playeback (yuv->rgb + scaling) Jan 04 23:31:42 ie xvideo Jan 04 23:31:47 glamo will help more than it hinders Jan 04 23:32:19 all of those bad hardware choices will be gone for the GTAO3 no? Jan 04 23:32:33 <[Rui]> raster: is glamo the reason efl apps seem so slow to adapt to a screen rotation? Jan 04 23:32:33 and 2. opengl (but again lots of caveats and limitations and alooooot of work - and can only really be used for simple 3d games at low res. cant be re-used for 2d accel eg for drawign webpages, maps, widgets, windows, blah blah) Jan 04 23:32:38 (if we can call theme "bad hadware choice") Jan 04 23:32:59 [Rui]: no - rotation isnt it Jan 04 23:33:02 its just general redraw Jan 04 23:33:05 <[Rui]> raster: or is it just bad design of those EFL aps? Jan 04 23:33:14 likely not Jan 04 23:33:28 evas is limited mostly by the cpu speed and bus bandiwdth to upload pixels Jan 04 23:33:34 it has "accelerated rendering" Jan 04 23:33:35 <[Rui]> raster: zhone in particular is a complete PITA if I turn my phone during a call Jan 04 23:33:40 youc an use opengl or xrender Jan 04 23:33:40 BUT Jan 04 23:33:42 <[Rui]> it becomes utterly unusable Jan 04 23:33:55 xrender basically cannto be accelerated sufficinelty on the glamo to make it worth it Jan 04 23:34:02 u likely wont beat the software engihne with the glamo Jan 04 23:34:06 <[Rui]> so during a call bandwidth tends to zero? could that be it? Jan 04 23:34:08 considering the gaps it has in the pipeline Jan 04 23:34:14 ie just doesnt implement operations Jan 04 23:34:18 raster, I've got a horizontal box. I'd like to place the left widget at the left border. Do I need hint_align for that? Jan 04 23:34:42 <[Rui]> raster: I'm just asking this because I'd like to understand if it's something I can work around to improve the experience Jan 04 23:34:43 gl is useless as u couldnt do it at vga res and it also has a texture size limit that makes it useless as well a sno render-to-texture for future changes Jan 04 23:35:14 <[Rui]> raster: yeah, all the glamo rants should be collected into a page to point to everyone :) Jan 04 23:35:43 the gta02 is an excpetion in pretty much every embedded device i've played with Jan 04 23:35:58 it has an inappropriate screen resolution for the processing power it has Jan 04 23:36:08 given its chipset qvga would be appropriate Jan 04 23:36:18 or u need something with 4x the grunt basically Jan 04 23:36:50 no matter what - ui performance is pretty closely related to @ of pixels Jan 04 23:36:55 err # of pixels Jan 04 23:37:01 u have 4x as many Jan 04 23:37:04 expect 1/4 the speed Jan 04 23:37:13 even if its accelerated Jan 04 23:37:32 gfx accel also is limited by memory bandwidth and it can only process so many pixels/sec in a given operation Jan 04 23:37:40 <[Rui]> well, to me it's spilled milk, not worth crying about, but all the problems with it should be publicy documented to improve things for GTA03 and beyond Jan 04 23:37:44 efl of course is fairly ambitious Jan 04 23:37:52 and uses scaling of images and blending all over Jan 04 23:37:57 but as such this has always worked well Jan 04 23:38:04 as targest were appropriately designed Jan 04 23:38:10 targets Jan 04 23:38:19 they have enough grunt to drive that many pixels Jan 04 23:38:23 <[Rui]> raster: so it would probably be smart that omnewrotate pays attention to call status, and contain it's actions to outside an incoming/active call? Jan 04 23:38:36 monochrome: the future of the glamo on gta02. Jan 04 23:38:49 hahahaha Jan 04 23:39:04 quickdev: use align Jan 04 23:39:11 quickdev: 0.0 -1.0 Jan 04 23:39:17 (if u want it to fill vertically) Jan 04 23:39:23 or 0.0 0.5 Jan 04 23:39:26 or whatever u like Jan 04 23:39:32 also u want weight to be 1.0 1.0 Jan 04 23:39:36 so it expands Jan 04 23:39:40 but that depends on other thigns in the box Jan 04 23:39:53 [Rui]: no - i'd say it should rotate all the time Jan 04 23:40:00 problem is that on rotate u get a root window resize Jan 04 23:40:05 this ends up a storm of activity Jan 04 23:40:17 x now needs to go redraw screen on rotate anyway Jan 04 23:40:20 <[Rui]> raster: but it's intolerable with zhone during a call Jan 04 23:40:25 and now all clients get mesages they windows change size Jan 04 23:40:33 eas e goes and resizes windows etc. to fit Jan 04 23:40:39 and everyone eakes up to redraw at once Jan 04 23:40:46 <[Rui]> raster: so I fear it may also be horrible with paroli Jan 04 23:41:04 so u have e redrawing the bg behind windows (the app launcher) as its held in a pixmap and needs a redraw Jan 04 23:41:13 <[Rui]> in hackable:1 redraw seems to act up better Jan 04 23:41:29 (the pixmap can be disabled and thus the redraw but this emans a higher cost one xposing the bg going home as it needs a full redraw then) Jan 04 23:41:42 * [Rui] nods Jan 04 23:42:00 its also possibly just zhones' ui than just is using things that are slow to draw Jan 04 23:42:04 raster: and another thing: why software_x16 is much faster on gta02 than software_x in illume? is that bus speed issue? or cpu? Jan 04 23:42:08 like smooth scaling on big images Jan 04 23:42:11 and lots of them Jan 04 23:42:13 layered Jan 04 23:42:22 raster, still centered...both: http://rafb.net/p/nZIs4I60.html Jan 04 23:42:24 dos1: memory bus Jan 04 23:42:29 dos1: it renders in 16bpp internalyl Jan 04 23:42:34 software_x11 is 32bpp Jan 04 23:42:41 also it doesnt allwo smooth scalign at all Jan 04 23:42:44 so even if asked for Jan 04 23:42:48 its disabled forcibly Jan 04 23:42:53 thus quality degrades rapidly Jan 04 23:43:15 quickdev: is the box itself expanding? Jan 04 23:44:02 dos1: as such software_x16 skips a 32->16bit+dither conversion on display Jan 04 23:44:19 it also does all operations in 16bpp space - which is basically half the memory bandwidth of 32bpp Jan 04 23:44:27 of course alpha channel is an extra 8bit mask plane Jan 04 23:44:31 so not quite 1/2 Jan 04 23:44:50 so u'd expect about double speedup just from that Jan 04 23:44:52 but it has bugs Jan 04 23:44:54 lots of them Jan 04 23:44:54 <[Rui]> software_x16 and software_x correspond to what in the engine dialog? Jan 04 23:45:06 it really only implements a subset of stuff Jan 04 23:45:09 <[Rui]> software checked == software_x ? Jan 04 23:45:14 raster, now I did: box1.size_hint_weight_set(1.0, 0.0) <- no change - that sets it to expandable, right? Jan 04 23:45:21 it is good if u really pay attention to designing a ui just for that resolution and setup Jan 04 23:45:31 specifically doing the gfx just for the 16bit engine case Jan 04 23:45:42 and keepiong your code within that envelope Jan 04 23:46:28 but... in the end you pay a price of bugs, drawing quality issues and an engine people dont pay much attention to Jan 04 23:46:56 software == software x11 (the default engine and pretty much best maintained) Jan 04 23:47:12 software 16 = software 16 x11 (the 16bit rendering engine) Jan 04 23:47:19 <[Rui]> raster: I don't have it checked in FSO M4.1 does tha mean I should? Jan 04 23:47:32 quickdev: yes. but that depends if the box has expanded too Jan 04 23:47:35 it may not have Jan 04 23:47:44 [Rui]: what is checked? Jan 04 23:47:52 <[Rui]> raster: I only see [ ] enable composite and ( ) software ; ( ) xrender Jan 04 23:47:55 raster, the box1 or the parent box? Jan 04 23:48:02 <[Rui]> raster: that's the weird thing, to me Jan 04 23:48:04 aaah u have a bug issue Jan 04 23:48:13 basically its set to software-16 in config Jan 04 23:48:18 <[Rui]> two radio buttons and not one unchecked? Jan 04 23:48:18 but that engine isnt available runtime Jan 04 23:48:29 raster, http://rafb.net/p/ORCTmU62.html Jan 04 23:48:31 so the option is disabled (raido just not there) Jan 04 23:48:47 and e is falling back to the normal software engine as the one asked for isnt available Jan 04 23:49:31 quickdev: set align for box1 to -1.0 -1.0 Jan 04 23:49:38 box1 isnt filling the allocated area Jan 04 23:50:35 raster, working, great - now I understand align / weight things Jan 04 23:50:50 align DOUBLEs for fill Jan 04 23:50:59 as slign makes sense only if u dont fill Jan 04 23:51:02 err align Jan 04 23:51:03 <[Rui]> well, bed for me. good night all Jan 04 23:51:06 thus -1 == fill Jan 04 23:51:12 <[Rui]> raster: thanks for clearing that up for me :) Jan 04 23:51:16 0.0->1.0 == align Jan 04 23:56:03 raster, I've got a label and an entry. Label is not leftmost. entry is in the center. When inserting text into the label, the text moves left. How to make text only expand to the right? Jan 04 23:58:27 the label Jan 04 23:58:30 or entry text? Jan 05 00:01:14 the label should stay leftmost. the entry should have some space to the label. the entry should only expand to the right, not expanding to two directions (because it's centered?) Jan 05 00:01:50 label Jan 05 00:01:59 set weight to 0.0 1.0 Jan 05 00:02:05 u dont want the label region "Expanding" Jan 05 00:02:17 but u wont get a gap between label and entry Jan 05 00:02:25 yeah - already have that - but I want to have that gap Jan 05 00:02:31 they will be flush next to eachother Jan 05 00:02:33 that's not possible? Jan 05 00:02:42 well dont have any spacer widget Jan 05 00:03:06 ok..planned? :) Jan 05 00:03:15 not really Jan 05 00:03:20 tho was planning a separator Jan 05 00:04:31 a "blank" separator style would be the right thnig here Jan 05 00:04:59 raster, a different thing. There's no background for an entry. A workaround is the scrollable widget? Jan 05 00:05:08 yup Jan 05 00:05:14 tho it kind of doesnt always play nice Jan 05 00:05:20 but yes - i stick it in a scrollable Jan 05 00:09:48 raster, imagine I've got two buttons in a vertical box. I'd like to make each use half width - possible? already tried weight(0.5 Jan 05 00:10:57 the buttons have different text lengths - thus they are bigger / smaller Jan 05 00:12:33 http://www.pcworld.com/businesscenter/article/156305/memo_to_vendors_heres_how_to_build_a_winner.html <----- a must read for ALL developers. Jan 05 00:13:08 This explains the *REAL* issue with a lot of the Om software/kernel issues.... Jan 05 00:13:52 ...and offers a reasonable way to make things *feel* better to the end user, even while the problems are still being fixed. Jan 05 00:17:32 The amazon kindle is not clunky Jan 05 00:17:54 And because it's made by amazon, and it has CDMA, and not some crappy GSM stuff. Jan 05 00:21:44 quickdev: u want the box to be homogenous Jan 05 00:21:48 ie all items the same size Jan 05 00:21:49 :) Jan 05 00:22:10 ah, yeah - that's what I want! :) Jan 05 00:22:12 0.5 means "expand 50% as much as you can" Jan 05 00:22:28 in the end everyonje is expanded to their desired size Jan 05 00:22:37 (or less depending on space available) Jan 05 00:22:42 and any left over space if there is more Jan 05 00:22:49 as soon as I set entry.single_line_set(False) it does not display any text anymore Jan 05 00:22:50 is then divided up between thpse that can expand Jan 05 00:22:55 based on weight Jan 05 00:23:36 hm. Jan 05 00:29:56 raster, last question: http://rafb.net/p/B59Hhe71.html <- Buttons should be at the top, not at the middle Jan 05 00:31:09 mwester-laptop: I am mentioned in the 6th paragraph of that article Jan 05 00:31:48 raster, got it Jan 05 00:32:09 raster, there's a typo in elementary's test.c Jan 05 00:32:11 /* set weight to 1.0 x 1.0 == expand in x and y) */ Jan 05 00:32:11 evas_object_size_hint_weight_set(bx, 1.0, 0.0); Jan 05 00:32:15 do you see it? :) Jan 05 00:32:42 0 = 1? Jan 05 00:33:18 yes Jan 05 00:33:25 quickdev: what did I win= Jan 05 00:33:26 ? Jan 05 00:33:52 oooh Jan 05 00:33:56 bad bindinjg design Jan 05 00:34:08 one question you may throw at raster (if he does not hide as soon as he realizes that he made a serious fault :) ) Jan 05 00:34:08 what happens when a signla happens to be the same name as an api call Jan 05 00:34:11 like label_set Jan 05 00:34:15 or whatever Jan 05 00:34:19 :) Jan 05 00:34:36 aaah comment not matchng code Jan 05 00:34:37 :) Jan 05 00:34:40 yeah your questions and explanations are all fine but what did I win? Jan 05 00:34:44 (why i hate comments) Jan 05 00:35:06 raster: well if your code does not speak for itself... Jan 05 00:35:09 *mwahaha* Jan 05 00:35:20 wow, I am pounding my karma Jan 05 00:35:35 ~karma Kensan Jan 05 00:35:35 kensan has neutral karma Jan 05 00:36:20 how much does OM make off each FR Jan 05 00:36:38 aah Jan 05 00:36:40 mwester-laptop: phew... Jan 05 00:36:41 ~karma PaulFertser_ Jan 05 00:36:41 paulfertser_ has neutral karma Jan 05 00:36:50 box1 - aling -1.0 0.0 Jan 05 00:36:55 not -1.0 Jan 05 00:37:02 mwester-laptop: good article Jan 05 00:37:28 mwester-laptop: an older version of that is the apple way whihc is "do whatever is more fun for the user" Jan 05 00:37:34 ie keep them happy Jan 05 00:37:35 :) Jan 05 00:38:15 mwester-laptop: Quote: "The other half is the human, that irrational, impulsive, impatient, power-hungry gratification machine." Jan 05 00:38:18 yes thats me Jan 05 00:38:22 What I took from that was that even if it's broken, if you give the user something to click, push, or touch to try to fix it, they will be happier than if it just locks up or hangs ;) Jan 05 00:38:49 We don't do enough of that. Jan 05 00:38:54 so we should change the WSOD to White Touch Screen of Death Jan 05 00:39:08 So the user can still tap the screen Jan 05 00:39:11 We really, really do need to create a "restart the whole **** userspace" for SHR. Jan 05 00:39:11 hrr Jan 05 00:39:15 What is the "official" FSO phone? Jan 05 00:39:23 mwester-laptop: yes Jan 05 00:39:25 do work in the bg Jan 05 00:39:33 give the user a workable ui that does stuff asap Jan 05 00:39:36 mwester-laptop: we need a CTRL-ALT-DEL for Fn/Sys Rq equal Jan 05 00:39:42 Yep Jan 05 00:39:52 any FSO devs here? Jan 05 00:39:57 one example in asu Jan 05 00:40:08 and in illume is the faded out black box while launching an app Jan 05 00:40:12 it remvoes control from a user Jan 05 00:40:22 yep Jan 05 00:40:29 mwester-laptop: casemod for a button, that stops the battery from providing power. Jan 05 00:40:31 i originalyl just had a little box slide up from the bottom of the screen to let u know app is starting Jan 05 00:40:36 so u can go on and launch other apps Jan 05 00:40:41 if u want Jan 05 00:40:52 but om's gerat ui designers disagreed Jan 05 00:40:56 and wanted the black box Jan 05 00:41:07 mwester-laptop: ok, that's not just for userspace *haha* Jan 05 00:41:19 whihc is the opposite of what should be done Jan 05 00:41:20 :) Jan 05 00:41:35 Kensan: ;) IBM had that on their first RISC-based workstations -- a bit yellow "RESET" button on the front panel. We used to joke about it when I worked for a competitor of IBM. But it worked -- it was something the users had that gave them "power", even if they never used it. Jan 05 00:42:05 mwester-laptop: but seriously, could we map Sysrq to e.g. when the user presses all buttons at once? Jan 05 00:42:15 Kensan, there are two buttons... Jan 05 00:42:23 Sargun: yes, both buttons Jan 05 00:42:36 Kensan, how about the user open the back cover, and take out the battery? Jan 05 00:42:49 Kensan: I think we can look into it. Or maybe combine it with a screen tap? Jan 05 00:42:55 Sargun: too much work Jan 05 00:43:05 Kensan, uh... for who? Jan 05 00:43:12 mwester-laptop: well we have many things Jan 05 00:43:16 Kensan, it takes me about 45 seconds to take out the battery Jan 05 00:43:17 mwester-laptop: frantically shaking the phone Jan 05 00:43:18 :) Jan 05 00:43:23 hehe! Jan 05 00:43:31 Sargun: it takes 1 sec tops to press both buttons Jan 05 00:43:34 Throwing it against the wall. Jan 05 00:43:39 I like that idea mwester Jan 05 00:43:59 mwester-laptop: yeah but seriously combining events accel+both buttons? Jan 05 00:44:20 mwester-laptop: so it would look like the user is trying to strangulate the phone Jan 05 00:44:29 That would be tough with the current hardware -- easier if Om had gone with the external MCU Jan 05 00:44:43 mwester-laptop: pressing both buttons is too common I think... Jan 05 00:45:48 http://www.jensroesner.de/wgetgui/#screen < We should make out guis like this! Jan 05 00:46:17 mwester-laptop: hm so whatever event would trigger that, this would give the user to put the phone in a well defined state Jan 05 00:46:29 i'm only pressing both buttons at once when i'm trying to get u-boot's menu ;p Jan 05 00:46:51 so this is good idea for me Jan 05 00:46:55 would give the user the power Jan 05 00:47:42 mwester-laptop: consider userspace gone totaly haywire and reset everything. Jan 05 00:47:57 Kensan: Exactly. But it should be like Shrek (like onions) -- layers of control. If FSO or SHR seems to be misbehaving, but we still have a touchscreen that works and X works, then at least a button that triggers a restart of just FSO/SHR would be nice to offer. Jan 05 00:47:57 mwester-laptop: without rebooting. Jan 05 00:48:58 well written software should have the ability to bring itself back to a sane state already Jan 05 00:49:09 or at least make a damn good attempt at it Jan 05 00:49:27 raster: but somebody still has to tell it that it (or something it controls) is no longer acting sanely. Jan 05 00:49:50 yes Jan 05 00:49:50 mwester-laptop: hm... ok. So just like sysrq we need a way to differentiate Jan 05 00:50:03 well u have a known way to do it Jan 05 00:50:11 if it segvs's (sigbusfpe etc.) Jan 05 00:50:15 it can restart itself Jan 05 00:50:27 That's the least of my worries. Jan 05 00:50:27 mwester-laptop: hm ok, like a master daemon that restarts the daemons it is watching Jan 05 00:50:27 as opposed to just myseteriously vanishing from the face of the planet Jan 05 00:50:57 No, no no -- the issue is not segv's or hangs or any other software-determinable issue. Jan 05 00:50:57 the problem is.. how do u detect a misbehavior Jan 05 00:51:06 it is when the USER says "it's all wrong!" Jan 05 00:51:09 raster: that's when the user say so Jan 05 00:51:13 other than giving the user the ability to trigger a restart when the user things its gone nuts Jan 05 00:51:23 raster: give the magic handshake to the kernel and voilà Jan 05 00:51:28 at least in theory Jan 05 00:51:29 hah Jan 05 00:51:34 the problem is - u have a very limited set of controls Jan 05 00:51:40 Kensan, what if the laster daemon fails? Jan 05 00:51:46 er, master. Jan 05 00:52:08 Sargun: that's the sysrq stuff - signal from kernel to init itself. Jan 05 00:52:10 Sargun: since it is small you can audit it better and also let it get respawned by init Jan 05 00:52:47 mwester-laptop: djb has done somethink like that in djbdns Jan 05 00:52:54 something Jan 05 00:53:17 mwester-laptop: I tried to kill that stupid daemon but I couldn't. So that's a pretty robust implementation Jan 05 00:53:21 imho Jan 05 00:53:21 that is Jan 05 00:53:21 heh Jan 05 00:54:14 We should build something like that for SHR/FSO. It could be a community-written system, with the first goal being to offer the user a "restart all userspace" menu item. Jan 05 00:54:15 mwester-laptop: and the kernel would simply propagate the sysrq to that daemon. Jan 05 00:54:29 Once that works, we can wire in the sysrq. Jan 05 00:54:36 mwester-laptop: yes, that sounds reasonable. Jan 05 00:54:50 Anyway - gotta run now (dinner time) -- later! Jan 05 00:54:57 mwester-laptop: how much later? Jan 05 00:55:04 mwester-laptop: cause it's 2 am here... Jan 05 00:55:15 mwester-laptop: but if you are back we can discuss this Jan 05 00:55:22 :) see you in the morning, I think! Jan 05 00:55:38 mwester-laptop: my morning or your morning? ;) Jan 05 00:55:43 mwester-laptop: well I'll stick around Jan 05 00:55:51 mwester-laptop: just ping me when you're back Jan 05 01:00:03 Any FSO users want to write a standards proposal on function decorators Jan 05 01:13:11 mwester-laptop: that's what I was talking about: http://cr.yp.to/daemontools.html Jan 05 01:20:18 raster, still here for a little question? Jan 05 01:24:27 Kensan jap... basically just one proccess started by init Jan 05 01:24:55 roh: oh hey there :) Happy 09 to you too Jan 05 01:24:57 its a bit bad documented i think, but there are patches for adding atleast manpages Jan 05 01:25:12 yeah.. right... there was something ;) happy 09 you too ;)) Jan 05 01:25:32 roh: I assume you were at 25c3 as everybody else but me... Jan 05 01:25:49 jap Jan 05 01:25:57 and some parties after that Jan 05 01:26:10 roh: cool. Seems like there was a huge crowd there. I follow some of the live streams Jan 05 01:26:14 followed Jan 05 01:26:19 roh: waiting for the recordings. Jan 05 01:26:28 actually i also were there much earlier and quite late too.. did layer1 cat5 patching again this year Jan 05 01:26:32 roh: hehe good parties I hope! Jan 05 01:26:52 roh: layer1 cat5 patching? Jan 05 01:27:04 Kensan hehe.. yeh.. the usual fsck.... videos in good quality take some time.. but there are streamrips of about anything i looked for as wmv *shiver* .. but its there Jan 05 01:27:13 jap. layer1 .. copper :) Jan 05 01:27:23 if it links, its not my problem anymore Jan 05 01:27:33 roh: haha have to remember that Jan 05 01:27:50 roh: ah ok at the hackcenter? Jan 05 01:28:11 the bcc (the location the ccc rented again) has 6 patchrooms we access Jan 05 01:28:30 roh: I only see a couple mp4 sets on the ftp server. I'll just wait Jan 05 01:28:33 one has >200 copper ports to 'the field' in one rack which also holds the fibre links and the switches Jan 05 01:28:46 roh: ok, lots to patch :) Jan 05 01:28:58 roh: nice for making tasty kabelsalat Jan 05 01:29:34 yeah Jan 05 01:30:19 roh: hm I hope I can drag my ass to Berlin next year... I've been wanting to go there for years... Jan 05 01:31:28 roh: haven't seen the md5-ssl talk yet Jan 05 01:31:55 *g* .. was a nice colletion of fail this year Jan 05 01:32:13 gsm fail, dect fail, nfc fail, ssl certs fail... etc Jan 05 01:32:16 roh: yeah, DECT was interesting too Jan 05 01:32:55 roh: mifare Jan 05 01:32:58 *g* Jan 05 01:33:12 oh and Kaminsky Jan 05 01:35:19 Stereoscope was entertaining too Jan 05 01:36:38 quickdev: ja Jan 05 01:38:01 raster, I already worked around it. But let me ask you: I have a several rows in a box...on the left side there's a label and on the right, there's an "Edit" button. Now I'd like to register a callback on the button...which gets the text as parameter...how do I do that? Jan 05 01:38:54 the text in the label? Jan 05 01:39:05 or the text in the entry? Jan 05 01:40:10 I'm not dealing with entries right now....just a label and a button per row Jan 05 01:40:16 the text of the label Jan 05 01:43:31 I'd like to have an elementary list..hehe ;) Jan 05 01:54:03 well thats very python specific Jan 05 01:54:15 in c all callbacks can be passed a data pointer Jan 05 01:54:24 u can pass in a const char * string to that Jan 05 01:54:35 as longas it is validly pointing to the stuff for the life of the callback Jan 05 01:54:38 u're fine Jan 05 01:54:46 and actualyl list is next on.. my list Jan 05 01:54:57 i'm now at the "i need it" Jan 05 01:54:57 stage Jan 05 02:23:37 raster, solved it. Have a good day! :) Jan 05 02:48:27 does anybody have a ublox agps account? how does one get one? **** ENDING LOGGING AT Mon Jan 05 02:59:58 2009