**** BEGIN LOGGING AT Tue Apr 19 02:59:58 2011 Apr 19 05:02:21 pespin: http://permalink.gmane.org/gmane.comp.handhelds.openembedded/44704 Apr 19 06:46:22 hi Apr 19 06:57:36 mrmoku: hehe, now we have swap on buildhost again :) hope this helps :) at least webkit-efl wont be killed by oom killer Apr 19 06:58:18 * JaMa was never happy from swap before... Apr 19 07:02:52 JaMa: is there some place I can read up on your plans to move shr to oe-core + layer ? Apr 19 07:05:31 something on shr-devel ML (in future plan thread) Apr 19 07:06:33 ok thanks Apr 19 07:06:41 JaMa: is it save to use org.oe.dev for now ? Apr 19 07:16:17 save yes.. but to spend much time on adding stuff to it is better to spend on meta-shr Apr 19 07:17:04 what's the state about meta-shr right now ? Apr 19 07:17:24 JaMa: can I creage a usable shr-image for htcleo with it ? Apr 19 07:17:25 shr-lite images works for om-gta02 and n900 Apr 19 07:17:48 you need to add htcleo to it Apr 19 07:18:30 I don't know if there's much htcleo specifics in the shr related oe metadata Apr 19 07:18:46 rather in cornucopia.git and global oe machine configuration Apr 19 07:19:07 you can see that I'm using meta-shr repo also for bsp stuff atm Apr 19 07:19:19 bsp ? Apr 19 07:19:23 that should be moved to separate layers later.. but for now it's easier for me Apr 19 07:19:54 Board Support Packages Apr 19 07:20:36 http://www.yoctoproject.org/docs/bsp-guide/bsp-guide.html Apr 19 07:20:42 what do you think is missing right now for htcleo in meta-shr ? (need to figure if I can handle adding that) Apr 19 07:21:13 by the way it is great that somebody makes the effort to keep up .. I also see the use of being 'yocto compatible' Apr 19 07:21:25 ah rpuride :) Apr 19 07:22:02 machine configs, maybe kernel etc (don't remember how many machine specific packages are needed for htcleo) Apr 19 07:22:23 ah ok so _everything_ in OE Apr 19 07:22:34 I didn't know these things were dropped (and moved to bsp?) Apr 19 07:22:55 OE != meta-oe Apr 19 07:23:17 meta-oe contains only stuff added mostly by me and koen Apr 19 07:23:27 no machine/distro configs Apr 19 07:24:06 for each missing part maintaner needs to step up and move it to meta-oe or some bsp layer and start maintaining it Apr 19 07:24:15 stuff without maintainer will die with oe Apr 19 07:24:19 old oe Apr 19 07:24:48 if I keep up with shr there would be no problem to maintain htcleo machine Apr 19 07:24:55 also it's nothing that changes too often Apr 19 07:27:44 JaMa: is there a 'yocto getting started' ? Apr 19 07:27:56 JaMa: I need to know where to download the metadata from Apr 19 07:28:17 make setup-shr-core Apr 19 07:28:23 or read what Makefile does Apr 19 07:28:27 if you don't like Makefile Apr 19 07:28:53 I sure like the idea but I would like to understand everything so it would be better to do it manually Apr 19 07:29:19 ~setup-shr-core Apr 19 07:30:00 then read it Apr 19 07:30:19 http://shr.bearstech.com/Makefile ? Apr 19 07:31:23 http://build.shr-project.org/Makefile should be the sam Apr 19 07:31:25 e Apr 19 07:31:30 it seems very complex Apr 19 07:31:30 http://wiki.shr-project.org/trac/wiki/Building%20SHR Apr 19 07:31:39 it's not so simple Apr 19 07:32:06 _I thought I'd like do git clone twice and be set Apr 19 07:33:14 that's at least 3 repos and you need to create ie conf/bblayers.conf right etc.. Apr 19 07:33:40 or just use makefile and then repeat same steps manually as you want :) Apr 19 07:33:49 but you'll see how it should look like in the end Apr 19 07:34:46 pespin: http://permalink.gmane.org/gmane.comp.handhelds.openembedded/44704 Apr 19 07:36:48 JaMa, yay thanks :) Apr 19 07:37:00 JaMa, is that applied already? Apr 19 07:37:05 no Apr 19 07:37:40 pespin: read whole thread.. you can workaround it by building different orc Apr 19 07:37:43 version Apr 19 07:38:01 ok Apr 19 07:38:26 JaMa: ok maybe it will really be best to use shr makefile as a first step. but for now I will stick with org.oe.dev Apr 19 07:38:59 dcordes: that's why we have makefile :) Apr 19 07:39:29 JaMa: maybe at some point we should add an overview of the metadata archtiecture in buildingshr Apr 19 07:39:33 * JaMa doesn't use it on his desktop, only on shr buildhost.. but that's because my setup is much more complicated :) Apr 19 07:39:50 dcordes: what do you mean by that? Apr 19 07:40:13 just adding the makefile and how to use it will leave many people with the same questions as I ahve Apr 19 07:40:13 dcordes: which layers are used? Apr 19 07:40:19 things like that, yeah Apr 19 07:40:20 dcordes, I need newer version of FSO to test the gprs code. Apr 19 07:40:51 pespin: I'm using what org.oe.dev shr-image is giving me: cornucopia.git I guess ? Apr 19 07:41:02 is it too old ? Apr 19 07:41:06 dcordes: but that's information which is expected to change a lot for few more weeks Apr 19 07:41:28 and then I'll be offline for maybe 2 months ;/ Apr 19 07:41:48 JaMa: ok. once I tried it myself and reconstructed it and understood it I can take care of such thing Apr 19 07:41:54 hehe because of burnout ? Apr 19 07:42:04 dcordes: http://git.shr-project.org/git/?p=shr-makefile.git;a=blob;f=conf/shr-core/bblayers.conf;h=c0b107d816df77384939abff2ffaca6e069f73c9;hb=HEAD Apr 19 07:42:06 dcordes, nop, we aren't using autorev in shr feeds Apr 19 07:42:34 dcordes: because of moving to new flat and 4 weeks road trip Apr 19 07:43:35 nice. you're in germany, right ? Apr 19 07:43:45 no, czech republic Apr 19 07:43:59 ok Apr 19 07:44:41 pespin: hm but I always get the cornucopia.git changes compiled from fresh bitbake shr-image Apr 19 07:45:48 pespin: just fix your patches :) Apr 19 07:45:58 dcordes, you are maybe using autorev in your buildhost Apr 19 07:46:13 yes Apr 19 07:46:16 JaMa, I'm leaving in about 20 min and I won't return till tomorroow night hehe Apr 19 07:46:20 beach is waiting for me :D Apr 19 07:46:22 shr-u is using shr-autorev, but not fso-autorev Apr 19 07:46:32 pespin: good for you :) Apr 19 07:46:39 * pespin still burnt from 2 days ago u.u Apr 19 07:47:02 *_* Apr 19 07:47:02 sun burnt? :) Apr 19 07:47:09 yes Apr 19 07:47:37 I'll try to resend the patches once I arrive Apr 19 07:47:57 pespin: if you have anything to test don't hesitate. I have my shr-image ready again in the late CET evening Apr 19 07:48:18 (gprs) Apr 19 07:48:23 hmm well I can pass you the diff of shr_gprs.py I have Apr 19 07:48:26 NOTE: Running task 10986 of 11011 (ID: 35, /OE/shr-unstable/openembedded/recipes/images/shr-image.bb, do_rootfs) Apr 19 07:48:47 NOTE: Running task 142 of 8224 (ID: 6585, /media/croisette/openembedded/recipes/gcc/gcc-cross-initial_4.5.bb, do_unpack) Apr 19 07:48:51 :> Apr 19 07:49:04 dcordes, I changed some of the code apart from adding some error handling Apr 19 07:49:23 pespin: I have seen one commit with lots of files moved Apr 19 07:49:27 but as the error thing has changed, I prefer to wait and try with the new status before pushing Apr 19 07:49:38 alright Apr 19 07:49:39 dcordes, nop, that's another one :) Apr 19 07:49:44 ^^ ok Apr 19 07:51:14 dcordes, http://paste.pocoo.org/show/374310/ Apr 19 07:51:25 JaMa: regarding documentation. I have seen on the ml some mentions of shr-u . I have no clue what that is. any documentation on these things ? Apr 19 07:51:44 the file is in /usr/lib/python2.6/site-packages/shr_settings_modules/ afair Apr 19 07:51:53 blabla firefox is already running.. Apr 19 07:52:16 run it from terminal and you will get some extra prints with a bit of info. Apr 19 07:52:28 dcordes: shr-u? Apr 19 07:52:40 yes and the other shr-x Apr 19 07:52:46 shr user manual :) Apr 19 07:52:49 shr-u is shr-unstable Apr 19 07:52:53 shr-t shr-testing Apr 19 07:53:11 and shr-core is workname for shr based on oe-core/meta-oe/meta-efl/meta-shr layers Apr 19 07:53:46 maybe we can drop shr-u shr-t once shr-core is established and then we can make stable versions with srcrev freezes Apr 19 07:53:49 ? Apr 19 07:54:34 srcrev freezes wont work very well for shr-t Apr 19 07:54:53 as there are usually small fixes good for users.. that's why I expect shr-t branches Apr 19 07:55:07 at least for meta-shr repo Apr 19 07:55:25 meta-shr-testing Apr 19 07:55:33 and yes I don't plan to build shr-u once we're happy with shr-core state Apr 19 07:55:48 I hope I will be able to improve that state soon Apr 19 07:55:49 I don't care about oe.dev already Apr 19 07:56:02 at least need to add and test leo well Apr 19 07:56:04 because I hate doing things twice Apr 19 07:59:42 dcordes, btw, how's the port of the htcleo going? :) Apr 19 08:00:19 pespin: most important thing is still audio routing and alsa Apr 19 08:00:29 which are defunct currently Apr 19 08:01:06 dcordes, sms are working? Apr 19 08:01:13 then there are things like standby.. Apr 19 08:01:16 pespin: yep Apr 19 08:01:36 ok :) Apr 19 08:04:07 * pespin leaving to the train station, bye! Apr 19 09:13:22 heyho Apr 19 09:13:29 mickey|office: ping Apr 19 09:29:34 mornign Apr 19 09:29:37 pöng Apr 19 09:39:24 mickey|office: good morning Apr 19 09:39:36 mickey|office: you mentioned you got qdbusxml2cpp working? Apr 19 09:40:31 yes, it's actually quite simple Apr 19 09:40:38 two steps Apr 19 09:40:46 1) add the interfaces to DBUS_INTERFACES Apr 19 09:40:59 2) actually use them (by including the header file from at least one cpp file in your project) Apr 19 09:41:03 nothing more to do Apr 19 09:41:09 DBUS_INTERFACES? Apr 19 09:41:17 yes Apr 19 09:41:22 a env variable? Apr 19 09:41:29 no, .pro Apr 19 09:41:45 ok Apr 19 09:42:23 and it even solves the problem with the variants? Apr 19 09:42:59 no Apr 19 09:43:11 the xml files have to be annotated Apr 19 09:43:24 i did it for the Usage, but did not commit yet Apr 19 09:44:09 qdbusxml2cpp will tell you the exact line it's missing Apr 19 09:44:28 (just substitute with VariantMap) Apr 19 09:44:35 i'll commit the usage file when I'm back home Apr 19 09:45:58 ok Apr 19 09:56:50 the one direction seems to be relatively simple Apr 19 09:57:28 shouldn't we create a libfso-glib? Apr 19 09:57:34 äh a libfso-qt? Apr 19 09:58:20 i'm still rather thinking about the vala bridge, but yes, libfso-qt will make sense anyways Apr 19 10:00:31 wrt bridging: for every Q_INVOKABLE, we need to create a C++ method that calls a corresponding C function. We need to generate some marshalling helpers that will be called from the 'mediators' Apr 19 10:01:09 the other way round is emitting signals when the C code says so Apr 19 10:01:23 so we need to create C stubs that call the respective C++ functions that actually emit the signal Apr 19 10:01:29 sounds reasonable Apr 19 10:02:08 i think the first plan of attack is writing a small proof-of-concept manually Apr 19 10:02:24 where we have a QML file with a button and a text field Apr 19 10:02:40 we hit the button, Vala gets called and sends somethign to the text filed Apr 19 10:02:51 in the 2nd step we can try to create the glue code by a script Apr 19 10:02:58 I took a closer look at all the QML stuff yesterday and after clicking through their presentations ... wow it's quite hot shit, a lot better than Edje will ever be Apr 19 10:02:58 sounds like a cool project to me :) Apr 19 10:03:20 morphis: *nod* that's what i was thinking as well. "This is what I would have liked edje to be" Apr 19 10:03:22 yeah but we will have extra qml components Apr 19 10:03:27 jepp Apr 19 10:03:37 glad you understand my excitement Apr 19 10:03:39 I started yesterday to create some qml playground Apr 19 10:03:50 I was a little bit confused the last days .. Apr 19 10:03:52 did you take a look at the 'photoviewer' example? that's amazing Apr 19 10:04:02 thinking around what to do, commited stuf Apr 19 10:04:06 jepp Apr 19 10:04:14 you should even take a look at the meego stuff Apr 19 10:04:18 cool. so after all we can work togehter on that :) Apr 19 10:04:18 it's quite amazing Apr 19 10:04:32 ok, perhaps we can steal some of their UI stuff Apr 19 10:05:12 their license managing is very curious, apache license here, lgpl there and some own too Apr 19 10:06:23 ok Apr 19 10:06:47 the one thing that i loved when looking at the photoviewer was the inherent scalability of the components Apr 19 10:06:56 jepp Apr 19 10:07:03 it looked nice both on the n900 (albeit dog slow) and on the pre Apr 19 10:07:14 and currently i'm targetting QVGA *phew* Apr 19 10:07:25 without a touchscreen, so we have to work on joystick Apr 19 10:07:30 it's nice that you can write your own components, delegates and so own and put them together to something very nice Apr 19 10:07:33 *nod* Apr 19 10:07:34 ieee :) Apr 19 10:07:44 ya, back to the roots... Apr 19 10:08:09 will stay at the Palm Pre/Pre Plus/Pre 2 Apr 19 10:08:15 good. Apr 19 10:08:24 then we have two variants Apr 19 10:08:32 that are pretty extreme Apr 19 10:09:06 and you can even use X, and i can use fb :) Apr 19 10:09:12 right Apr 19 10:09:17 but the components are the same Apr 19 10:09:48 you already have some code for the bridge thing? Apr 19 10:10:00 no, just wet dreams Apr 19 10:10:23 was busy to get my new device up Apr 19 10:10:24 ok, but a idea how to do it, thats even a good start Apr 19 10:10:29 yep Apr 19 10:10:34 the EZX one? Apr 19 10:10:36 ya Apr 19 10:10:42 ok Apr 19 10:11:25 we need even a way to compile vala and Qt stuff in parallel Apr 19 10:11:34 and I am thinking about using cmake here Apr 19 10:12:26 ok, worth a shot. I'm quite confident with qmake and never looked into cmake, but apparantly it's the new KDE hotness Apr 19 10:13:03 jepp and there are already cmake macro for vala: https://github.com/jakobwesthoff/Vala_CMake Apr 19 10:13:19 ah, good Apr 19 10:13:20 I want to port the aurora thing I wrote yesterday to port to cmake Apr 19 10:13:27 to have vala and qt in parallel Apr 19 10:13:30 excellent Apr 19 10:13:36 you know qt is using GLib internally on unix? Apr 19 10:14:18 i did know that there were plans to do that Apr 19 10:14:29 i dno't know whether they actually carry it out in production these days Apr 19 10:14:40 on ubuntu ti's the case Apr 19 10:14:47 if so, then mainloop integration is... _done_ . Apr 19 10:14:48 ) Apr 19 10:14:50 :) Apr 19 10:15:00 just started a QApplication yesterday and called g_idle_add(...) and it works :) Apr 19 10:15:06 awesome Apr 19 10:15:09 one problem solved Apr 19 10:15:13 there is a --enable-glib switch in Qt Apr 19 10:15:24 information about this are very rare Apr 19 10:15:31 ok, will have to see whether we use that in OE by default Apr 19 10:15:36 we definitely want that Apr 19 10:15:55 btw should we maybe create our own distro for FSO basic stuff? Apr 19 10:16:25 with some preferred versions? Apr 19 10:16:26 ya, why not. i can commit what i have on aurora Apr 19 10:16:34 (which is my distro config) Apr 19 10:16:39 (based on minimal) Apr 19 10:16:58 ok, whats currently in it? Apr 19 10:17:04 see foroyurself Apr 19 10:17:09 it's on the server Apr 19 10:17:20 aurora.conf and include/aurora-preferred.inc Apr 19 10:19:26 ok, some parts we should rework like IMAGE_DEV_MANAGER = "" Apr 19 10:19:32 which is not the case for palmpre* Apr 19 10:19:58 and even the KERNEL_HEADERS are wrong for palmpre Apr 19 10:20:19 but it's a start torwarding a stable subset for FSO Apr 19 10:20:27 right Apr 19 10:21:03 another thing is, we should write down our plans Apr 19 10:21:07 make a little roadmap Apr 19 10:21:24 so we have steps we can work on and finish some day Apr 19 10:21:43 ok Apr 19 10:21:58 it's even better to have a milestone we can reach than working without anything Apr 19 10:22:05 for sure Apr 19 10:22:33 and maybe a name for the project like "Aurora Project" Apr 19 10:22:47 yep Apr 19 10:22:49 but still within FSO Apr 19 10:24:00 I start a wikipage about it Apr 19 10:24:14 first steps should be: Apr 19 10:24:19 * aurora distribution in OE Apr 19 10:24:24 * vala qt bridge Apr 19 10:24:30 * cmake vala/qt environment Apr 19 10:24:55 ok, i'll add up then Apr 19 10:25:44 i will also lay out my plans for tefosa Apr 19 10:25:50 btw. what do you think about borad-support-packages for FSO? Apr 19 10:26:07 what would be the contents of such a package? Apr 19 10:26:10 bbiab, bathroo Apr 19 10:26:11 so put everything needed for getting FSO running on another board is in this package Apr 19 10:26:11 m Apr 19 10:26:19 fsodeviced/fsogsmd modules Apr 19 10:26:26 configuration Apr 19 10:26:32 so we have them separated from fso core Apr 19 10:44:45 hmm Apr 19 10:45:31 that's complicated Apr 19 10:45:36 configs are easy, modules are not Apr 19 10:45:50 at least if splitting is concerned Apr 19 10:45:56 what we could do is virtual packages Apr 19 10:46:01 (if you have that on mind) Apr 19 10:46:14 e.g. in OE, recipes that include the config and depend on the modules they need Apr 19 10:47:34 i'm not too satisfied with the way we split the modules in OE atm. Apr 19 10:48:03 i would have expected split_packages to be used rather than manual specification Apr 19 11:04:00 re Apr 19 11:06:42 mickey|office: I used manual, because with split_packages I would get many "shared" modules Apr 19 11:07:06 mickey|office: and still the need to put them in rdepends of right subpackage pulling them to image/device Apr 19 11:07:26 but you're right I'm also not too satisfied from it Apr 19 11:11:31 JaMa: ok, perhaps we can improve this a bit in different directions. the RDEPENDS for the devices we need to maintain manually anyways, however we could perhaps add some more information in FSO itself, e.g. specify whether a module is devicee independent or not (e.g. by prefixing it with shared-), and then have the packaging move everything shared- into the base package Apr 19 11:11:48 and have split_package emit the rest automatically per-plugin Apr 19 11:13:49 good idea Apr 19 11:15:41 i wanted to unify the module naming anyways Apr 19 11:15:46 so that may be a chance to do both in one run Apr 19 11:21:42 sounds nice, then we can even put all device-specific modules in a _quirks module like I did it in fsodeviced for palmpre Apr 19 11:38:34 bbiab, lunch Apr 19 12:38:29 morphis: jama told me you and mickey are working on some qt ui thing? Apr 19 12:51:00 darkh: yes Apr 19 12:51:37 ok cause i'm working on getting kde on the freerunner Apr 19 12:52:01 kde4? Apr 19 12:52:06 yes Apr 19 12:52:10 4.6.x Apr 19 12:52:27 currently im switching to shr-core meta stuff Apr 19 12:52:49 kde is not usable on the freerunner way to slow Apr 19 12:53:21 but if you have some time... you can take screenshots with ksnapshot XD Apr 19 12:54:01 KDE support in OE would be nice Apr 19 12:54:15 I saw plasma active recently Apr 19 12:54:29 im working on it... i hope i don't reinvent the wheel Apr 19 12:54:30 looks interesting but always depends on some accelerated gfx card Apr 19 12:55:02 don't think so as I don't from anyone tried to run kde on a OE supported platform Apr 19 12:55:03 im workin on meta-kde not kde-active Apr 19 12:55:11 plsma-active Apr 19 12:55:20 yeah but it would be the start to have plasma-active later on Apr 19 12:55:54 mickey|office's and my approach is really simple: we want some tiny UI to handle most Smartphone things in a simple way Apr 19 12:56:01 nothing complex we can't handle as little team Apr 19 12:56:10 just something that works and is portable very easily Apr 19 12:56:31 as mickey|office targets framebuffer with the EZX devices and I want it to run on the Palm Pre phones Apr 19 12:57:13 so in the end it will be a qml application which uses several components written for it which makes it very easily to implement more features Apr 19 12:57:29 sounds good Apr 19 12:57:43 think of a better zhone2 Apr 19 12:57:49 with better UI and more features Apr 19 12:57:59 and it should feel like a real Smartphone UI Apr 19 12:58:11 so with something like a launcher Apr 19 12:58:28 in the end it will be the development frontend for FSO Apr 19 12:58:48 as we need to get FSO in a better shape, create a roadmap, implement most needed features and so Apr 19 12:58:49 should plasma-mobile also do... but on top of heavy kdelibs... Apr 19 12:58:54 jepp Apr 19 12:59:08 it is a little bit more complex than one binary running some qml stuff Apr 19 13:00:03 as an addendum: FSO has been too much developed for its own sake. We need to change the development model more towards driven-by-the-clients. And for that we need to work on clients in tandem with FSO, otherwise we are too much detached from the API consumers' needs. Apr 19 13:00:22 correct Apr 19 13:00:43 and SHR is quite some more complex as we think of a little client which leads us in development Apr 19 13:00:48 you mean you need users who actually use the features fso provides? Apr 19 13:01:08 yes, and no Apr 19 13:01:10 on the one side yes Apr 19 13:01:20 no in the sense of... the users of FSO are the client developers Apr 19 13:01:26 we already have clients who uses FSO Apr 19 13:01:34 yes in the sense of... people should actually be able to use the apps written on top of FSO Apr 19 13:02:00 ok, mickey|office gaves the answer :) Apr 19 13:02:07 :) Apr 19 13:02:31 i have a very concrete use case now Apr 19 13:02:31 SHR is not bad, it's quite amazing what people have done and actually doing Apr 19 13:03:05 * radekp is interested in QT FSO frontend too :) Apr 19 13:03:17 but I am now working on the Pre phones for about 1,5 years and there is much work to do with SHR and thats would not be the case if we have some little UI targeting FSO only Apr 19 13:03:30 my wife needs a new phone as her old one is falling apart. I want her to use the software we write. So I have the very concrete needs of a simple self-contained telephony app. Apr 19 13:03:50 which is quite stable ... Apr 19 13:04:22 and if you look at EFL and Qt/QML both are great Apr 19 13:04:31 EFL is very easily to use, fast and portable Apr 19 13:05:07 but Qt/QML is quite more powerful than EFL/Edje will be in the next years and it has the better tools Apr 19 13:06:21 so don't get me wrong, I love the idea of having a fully working X11 Smartphone Environment with EFL running on the UI layer, but it's is quite too much work to get it in a state ready for daily needs (web browser, mail, music, ...) Apr 19 13:06:44 so we're switching down to a simpler approach Apr 19 13:10:38 has anyone already started something? Apr 19 13:14:14 who was making emtooth2? Apr 19 13:14:19 pespin? Apr 19 13:14:34 es Apr 19 13:14:36 y Apr 19 13:14:51 radekp: yes Apr 19 13:15:10 look at the aurora git repository on git.freesmartphone.org Apr 19 13:15:16 only some initial steps Apr 19 13:15:20 nothing visible Apr 19 13:15:25 just a playgroud for further work Apr 19 13:15:39 as we've been just few days into this new plan, we are laying out our ideas and doing some technology tests first Apr 19 13:15:49 so I have to leave Apr 19 13:15:52 bye Apr 19 13:15:54 cu soon Apr 19 13:17:06 ok Apr 19 13:46:41 mrmoku, hi Apr 19 13:46:47 any news? Apr 19 14:12:04 anybody could comment on http://shr-project.org/trac/ticket/1434 I'm not sure if it's the best way to solve the problem Apr 19 18:01:06 hi ho Apr 19 18:02:10 GNUtoo: what metadata are you using for shr ? Apr 19 18:05:16 freesmartphone.org: 03mickey 07aurora * r1641ec92bca9 10/tefosa/mcp/ (7 files in 2 dirs): tefosa/mcp: calling cpp from qml Apr 19 18:05:18 freesmartphone.org: 03mickey 07aurora * re584867658b8 10/.gitignore: gitignore-- Apr 19 18:05:19 freesmartphone.org: 03mickey 07aurora * r681013097870 10/tefosa/.gitignore: .gitignore++ Apr 19 18:09:35 dcordes, metadata? Apr 19 18:10:12 recipes... Apr 19 18:11:45 usually it means oe Apr 19 18:11:55 but it could mean something else in dcordes's head Apr 19 18:11:59 that's why I ask Apr 19 18:12:15 heh, ok, i don't know how it looks in dcordes' head, but i think oe is what he means Apr 19 18:12:32 hi mrmoku Apr 19 18:12:53 hmmm where is pespin? Apr 19 18:14:52 hmmm maybe I should use something else than emtooth2 Apr 19 18:15:03 the author keep saying that it's bluetoothd's fault Apr 19 18:15:15 about the reason why it works so badly Apr 19 18:15:26 but on my desktop the gnome bluetooth applet works really great Apr 19 18:15:35 I wonder why Apr 19 18:15:46 maybe emtooth2 could be improved Apr 19 18:15:46 GNUtoo: i had moderate success using bluetoothd dbus api directly with dbus-send. Apr 19 18:15:46 ? Apr 19 18:15:53 ok Apr 19 18:16:07 I want to associate with a keyboard Apr 19 18:16:10 For some operations i needed a small python app though. Apr 19 18:16:14 *pair a keyboard Apr 19 18:16:15 ok Apr 19 18:16:28 GNUtoo: to pair you can use simple-agent, it should be packaged with bluetoothd. Apr 19 18:16:33 ok Apr 19 18:16:40 I know how to do it Apr 19 18:16:42 but.... Apr 19 18:16:45 I had that error: Apr 19 18:17:49 can't open HIDP control socket: protocol not supported Apr 19 18:18:19 GNUtoo: hidp??? What are you using? Apr 19 18:18:28 GNUtoo: hidp was an old daemon from bluez3 days. Apr 19 18:19:17 hidd Apr 19 18:19:24 Same Apr 19 18:19:29 Ah Apr 19 18:19:41 I think it's a wrapper nowadays Apr 19 18:19:54 GNUtoo: anyway, bluetoothd is not using and not needing any additional control sockets, it uses dbus api :) Apr 19 18:20:08 strange then Apr 19 18:20:11 GNUtoo: and pairing with a keyboard has nothing to do with HID. Apr 19 18:20:17 It's the regular pairing thing. Apr 19 18:20:34 ok Apr 19 18:20:39 I'll investigate then Apr 19 18:20:44 on how to do it the dbus way Apr 19 18:23:58 GNUtoo: http://wiki.openmoko.org/wiki/Manually_using_Bluetooth is where i put on my bluetooth-related experience. Please ask if anything's unclear or incorrect. Apr 19 18:24:36 ok thanks a lot Apr 19 18:24:55 mine was here: http://bugcommunity.com/wiki/index.php/BluetoothHowto Apr 19 18:26:24 :) Apr 19 18:35:20 # hcitool scan => Scanning ... => Inquiry failed: Connection timed out Apr 19 18:35:59 Probably your device turned off or hit pairing timeout or something like that. Apr 19 18:36:29 it's on and in discovery mode Apr 19 18:36:33 (the keyboard) Apr 19 18:36:42 let me look again on the nokia900 side Apr 19 18:37:09 GNUtoo: btw, the maemo version of bluez4 is crippled. Apr 19 18:37:21 I've SHR version Apr 19 18:38:21 GNUtoo: hcitool scan should work, it's not emtooth fault :) Apr 19 18:39:41 ok Apr 19 18:39:52 the griefs against emtooth are rather something else Apr 19 18:40:02 mainly it doesn't reconnect Apr 19 18:57:14 GNUtoo: no news Apr 19 18:57:22 ok Apr 19 18:57:26 I bet you didn't try then Apr 19 18:59:12 I tried once the start ofono and then kill it thing Apr 19 18:59:15 and it did not work for me Apr 19 18:59:24 had no more time then Apr 19 19:05:12 ok Apr 19 19:05:20 did you try like it was in the spreadsheet? Apr 19 19:06:07 did not try the ofono modifications Apr 19 19:06:16 and neither the old fsogsmd rev Apr 19 19:08:02 no Apr 19 19:08:04 mickeyl: GNUtoo: yep, recipes is what's in my head when I'm talking about metadata. and configuration etc ! Apr 19 19:08:08 :) Apr 19 19:08:08 you should try without the modifications Apr 19 19:08:25 * GNUtoo is nervous again with bluetooth Apr 19 19:08:33 GNUtoo: I am wondering if you migrated to meta-shr on top of oe-core Apr 19 19:08:35 freesmartphone.org: 03mickey 07aurora * re14a8d411ab1 10/tefosa/mcp/ (SomeAPI.cpp foo.vala mcp.pro vala.prf): tefosa/mcp: call vala from qml Apr 19 19:08:41 ah ok Apr 19 19:08:44 ask JaMa|Off Apr 19 19:08:49 I'm still on oe.dev Apr 19 19:09:13 GNUtoo: me too. I was just wondering for you personally. JaMa|Off was so kind to give me an insight on his plans already Apr 19 19:09:34 hmm... mickeyl is comitting cpp files... that is a first step ;-) Apr 19 19:09:35 for me I didn't switch Apr 19 19:09:44 mrmoku: ;) Apr 19 19:09:45 I'm waiting for the swtich signal Apr 19 19:09:49 from the mailing list Apr 19 19:09:59 no games at all are on oe-core yet Apr 19 19:10:04 so...no switch for me Apr 19 19:10:15 what's stefosa ? Apr 19 19:10:23 tefosa Apr 19 19:11:00 Looks like elementary is no longer "the thing"? Apr 19 19:11:21 just some random technology playground which if we are lucky leads to a feature phone telephony system... Apr 19 19:11:34 based on qt ? Apr 19 19:11:39 yes Apr 19 19:11:41 are you crazy :) Apr 19 19:11:44 yes Apr 19 19:11:46 but that's nothing new... Apr 19 19:11:48 hi captaini1loo Apr 19 19:11:53 hi Apr 19 19:12:28 PaulFertser: qml is lightyears ahead, in all but two areas, I'm afraid Apr 19 19:12:47 Apr 18 15:07:37 JaMa|Work, hmm libschroedinger is failing when building an shr-lite image here Apr 19 19:12:57 ^^^ I'm getting the same problem but in org.oe.dev Apr 19 19:13:03 mickeyl: raster was always saying that qml can't compete with efl. Apr 19 19:13:35 PaulFertser: likely he was referring to performance Apr 19 19:13:38 which is one of those areas Apr 19 19:13:43 where EFL beats. Apr 19 19:14:05 captaini1loo: couldn't try keyboard yet due to build problems Apr 19 19:14:16 mickeyl: lua-scriptable themes sound cool as well. Apr 19 19:14:52 ah there is a keyboard to try? Apr 19 19:14:55 And iirc edje and his rich theams concept appeared before qml. Apr 19 19:14:58 the software keyboard? Apr 19 19:15:16 PaulFertser: absolutely. qml is a copycat. Apr 19 19:15:19 just 6 years before Apr 19 19:15:22 captaini1loo, I'm for efl, since it's faster and do not require 3d Apr 19 19:15:33 captaini1loo: btw. you installed libphone-ui-shr... if you need access to the repo just send me your key :) Apr 19 19:15:47 but some copycats can beat the original... Apr 19 19:16:36 last time i benchmark both, qml was way slower than evas/edje Apr 19 19:16:45 basically I eared people that switched from EFL to QT at fosdem Apr 19 19:16:46 correct Apr 19 19:16:57 they said the only differences were speed and documentation Apr 19 19:17:00 worse speed Apr 19 19:17:04 and better documentation Apr 19 19:17:06 So, what makes Qt more attractive then? Apr 19 19:17:11 GNUtoo: yes with extra huge buttons for capacitive devices like leo etc Apr 19 19:17:13 documentation Apr 19 19:17:18 qml works well when you have one window with everything created Apr 19 19:17:22 dcordes, can I try it? Apr 19 19:17:33 GNUtoo: captaini1loo posted link yesterday Apr 19 19:17:34 Nah, aren't e sources understandable enough. Apr 19 19:17:44 dcordes, do you have the link? Apr 19 19:18:12 but maybe with opengl-es stuff qml is better Apr 19 19:18:12 GNUtoo: I will look it up for you. one moment please Apr 19 19:18:16 PaulFertser, documentation means for app writers Apr 19 19:18:24 dcordes, thanks a lot!!!! Apr 19 19:18:30 captaini1loo, that's non-free Apr 19 19:18:34 PaulFertser: QML is edje done right. The concept is reaching much further, it's component-based, great architecture, calling out of and into the QML descriptions are much more versatile than edje. Apr 19 19:18:34 for now Apr 19 19:18:34 Apr 18 16:58:09 dcordes: http://82.227.130.131/files/Minimal.kbd Apr 19 19:18:35 GNUtoo: i understand, but when there's no documentation you just skim the code and get it. Apr 19 19:18:37 Apr 18 16:58:47 but it's usable only if it's the only one installed on the machine .... Apr 19 19:18:43 GNUtoo: voila Apr 19 19:18:59 GNUtoo: note the above line. you must save it as only keyboard map. Apr 19 19:19:04 dcordes, thanks a lot Apr 19 19:19:05 lindi-: congratulations, dude! Apr 19 19:19:05 PaulFertser: and I can READ it. in contrast to edje where i never got the hang out of it Apr 19 19:19:19 GNUtoo: and afaik captaini1loo uses same wvga display as me .... Apr 19 19:19:28 ok Apr 19 19:19:48 GNUtoo: it will be sexy on the nexus ! Apr 19 19:19:53 i have been fascinated from day 1 when they introduced it some years ago. seeing what they now have and how good it looks and works on the devices put me over. Apr 19 19:19:54 dcordes, indeed Apr 19 19:20:18 mickeyl, nokia won't make any newer devices and android have no GNU/Linux 3d Apr 19 19:20:25 GNUtoo: [Rui] is also working on it. he implements a new alternative key function in E Apr 19 19:20:31 GNUtoo: upstream Apr 19 19:20:33 dcordes, nice Apr 19 19:20:44 let me try the keyboard Apr 19 19:20:49 GNUtoo: so captaini1loo can put all the keys needed Apr 19 19:21:06 mickeyl: i hope that nokia will continue working on it Apr 19 19:21:19 GNUtoo: can't wait for it to mature as I really think it will boost usability on capcitivte devices a lot ! :) Apr 19 19:21:20 GNUtoo: what's with your 3d? Apr 19 19:21:25 captaini1loo: me too Apr 19 19:21:27 as I use it at work Apr 19 19:21:32 captaini1loo: but even if they'd stop now, it'll be enough for us Apr 19 19:21:38 but i'm a bit sceptic Apr 19 19:21:43 mickeyl, will your qml thing depend on 3d? Apr 19 19:21:48 GNUtoo: no Apr 19 19:21:50 like beeing slow enough to require 3d Apr 19 19:21:51 ahh ok Apr 19 19:22:19 one of my target platforms is the EZX ROKR E2 Apr 19 19:22:28 :) Apr 19 19:22:33 shr-e-gadgets_git.bb' failed Apr 19 19:22:38 no 3d, no touchscreen Apr 19 19:22:43 32MB RAM Apr 19 19:22:49 hugh Apr 19 19:22:54 48 in fact, but 32 for userland Apr 19 19:22:59 without X ? Apr 19 19:23:38 of course. i won't use X on such a tiny system Apr 19 19:23:51 (tiny by today's measurements) Apr 19 19:25:08 ok Apr 19 19:25:17 so it's nice Apr 19 19:25:30 I'll be using it on top of Qt/Embedded, but anyone is free to use it w/ Qt/X11 Apr 19 19:25:35 ok Apr 19 19:28:40 ok I tried the keyboard Apr 19 19:28:45 it looks nice Apr 19 19:28:51 the concept is great Apr 19 19:28:55 but it lack an alt Apr 19 19:29:01 unusable on shell Apr 19 19:29:04 so go on Apr 19 19:29:06 thanks a lot Apr 19 19:38:48 dcordes, did cotulla publish something already? Apr 19 19:39:24 dcordes, for srhodinger there is a thread on oe ml Apr 19 19:45:14 GNUtoo: no. ok. Apr 19 19:45:19 GNUtoo: tried the kbd ? Apr 19 19:46:24 yes Apr 19 19:47:05 http://scap.linuxtogo.org/ Apr 19 19:47:09 oops I made a type Apr 19 19:47:17 *typo Apr 19 19:47:20 sorry Apr 19 19:47:25 should I correct? Apr 19 19:55:55 freesmartphone.org: 03morphis 07aurora * r202d3fda348b 10/aurora/aurora-daemon/ (aurora-daemon.pro main.cpp rootwindow.cpp): aurora-daemon: require the full path for the application to run Apr 19 19:55:57 freesmartphone.org: 03morphis 07aurora * r9cf15ab5d2ab 10/aurora/aurora-components/ (24 files in 4 dirs): aurora-components: import some stuff from meego-ux-components Apr 19 19:55:58 freesmartphone.org: 03morphis 07aurora * r1846684cd700 10/aurora/ROADMAP: aurora: add draft for something called a ROADMAP torwards a 1.0 release Apr 19 20:08:08 GNUtoo: nice Apr 19 20:09:44 mrmoku, do you have time for beeing helped to help us with modem? Apr 19 20:24:18 dcordes: libschroedinger see ML and try newer orc Apr 19 20:30:19 GNUtoo: right now? Apr 19 20:30:30 when you want Apr 19 20:31:21 for sure I will still find lots of time to spend on the modem Apr 19 20:31:28 and help is very much appreciated :-) Apr 19 20:37:45 GNUtoo: one thing I wanted to try for some days (and did not) is to add a logger in the netlink handler of ofono Apr 19 20:37:55 ok Apr 19 20:38:09 I want to know if it might be 'normal' the link goes down Apr 19 20:38:15 and we just react wrong Apr 19 20:38:15 ok Apr 19 20:38:34 mrmoku, should I try to work on xrandr -o 1 ? Apr 19 20:38:40 that would be awsome for games Apr 19 20:38:55 and for music/browsing Apr 19 20:39:00 yeah, xrandr would be very interesting Apr 19 20:39:28 but I don't want to do it in vain Apr 19 20:39:33 (I need modem) Apr 19 20:39:51 ok Apr 19 20:40:41 I hopefully will have some time tomorrow afternoon to continue with the modem Apr 19 20:41:04 from friday to monday I'll be camping with the family though Apr 19 20:41:09 ok Apr 19 20:41:19 I hope the modem will be camping the network too Apr 19 20:41:34 hehe :) Apr 19 20:43:55 ~curse htcdream for the nervousity Apr 19 20:47:07 eeks. Qt Apr 19 20:47:40 a.k.a. fatty **** ENDING LOGGING AT Wed Apr 20 02:59:58 2011