Re: What should a community manager do?
Excellent posting!! This is a very good job description for someone like a community manager. Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Temporary testing and development feeds for ASU
On Thu, 2008-08-14 at 14:26 +0200, Holger Freyther wrote: On Thursday 14 August 2008 05:25:54 Robert William Hutton wrote: Holger Freyther wrote: testing feeds: http://people.openmoko.org/~zecke/om2008.8-testing/all http://people.openmoko.org/~zecke/om2008.8-testing/armv4t http://people.openmoko.org/~zecke/om2008.8-testing/i686 http://people.openmoko.org/~zecke/om2008.8-testing/neo1973 http://people.openmoko.org/~zecke/om2008.8-testing/om-gta02 Holy moley, I just updated to testing and it looks like just about every package on the system got upgraded! aeh? If one looks at the diff between .stable and .testing it is Qtopia and EFL/illume that got upgraded. But yeah that might look like a lot. Went fine apart from an error about a truncated libwebkit file, here's a snippet of the upgrade output: eeh? disk full? I can confirm that a lot of packages have been upgraded but there ware no complaints from opkg in my case. Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alpha 2 Release of Accelerometer-based Gestures, and Screen Orientation
Excellent!! Two things in one go :) I have trained a bit. But I have problems to train z and some of the others. shake-shake is very prominent in detection :) I noticed also that gesd is running on 17% cpu permanently. Could this be a reason for the problems in detecting or the delay until the notification is shown? Norbert On Thu, 2008-08-14 at 19:01 +0200, Paul-Valentin Borza wrote: I'm proud to announce that the new release of accelerometer-based gestures, and screen orientation is now available for download. What you've seen in the video from http://www.youtube.com/watch?v=K2S2rQUETwc is now available. This release includes: An application with user interface that allows the user to train the gestures for himself/herself; A listener daemon that sends a notification on the screen of the recognized gesture; Automatically switch of screen orientation for the four possible modes (2xportrait, and 2xlandscape). Here's the direct link for the release: http://accelges.googlecode.com/files/accelges_0.1.0-svnr204-r2_armv4t.ipk You can find documentation, installation instructions, screenshots etc. on the Wiki: http://wiki.openmoko.org/wiki/Gestures There's a quick way to install it, and a more detailed way... Read http://wiki.openmoko.org/wiki/Gestures I would suggest carefully reading the instructions, and running the gesture listener as soon as you install the package (i.e. before training). Of course, the gestures were not trained for you (unfortunately I had a limited set of training data - only myself), so you'll have to train them for yourself. Have fun with it! Thanks, Paul -- http://www.borza.ro ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
On Wed, 2008-08-13 at 11:02 +0200, Holger Freyther wrote: On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote: 2. Better communication between the development community and the end user community. I have yet to see anyone say they're pleased as punch with the keyboard. When almost everyone is unhappy, closing bugs as 'working as intended' is pigheaded. Hey, as this action is misunderstood a couple of small words. What is the bugtracker for? The way we have used docs.openmoko.org so far is to make it an engineering tool. The assigned/owned tickets tells/informs engineers what to work on, when to get it done (milestone) and how important that is. Don't forget the problem reports which are a valuable source of feedback for those developers. So the bugtracker is also for reporting bugs and enhancement wishes. The benefit of having as precise tasks as possible is that they are small, can be assigned to a single person, one can set the severity and the milestone. After this small task was done, the engineer can set it to in_testing and QA can test that single fix. In an ideal world it would something like this. Now we have bugreports like the SIM PIN Dialog or the Keyboard. No doubt that there is a real issue but they are the exact the opposite of the above workflow. We can not assign a single engineer to take care of them. This means they will never be addressed as no one is responsible and not many people are capable of touching everything that would be needed to resolve the bug. So how to get out of that? Look at the issues presented and file tickets for each single issue. These can be assigned to developers, these can have a milestone set, these can have a severity, these fixes can actually be tested and verified. With my limited resources, internet connectivity (GPRS through the neo), my available time and my main tasks in mind, I have simply no time to create the tickets for each and every issue. So I name the issues I see in the report (and yes the list can be incomplete) and rely on people/interest holders to file a new precise bug report. This is to make it possible for engineers actually being able to do a bugfix which is in the interest of the community... Is that bad faith? How do others see that? No, it is just a gap. Users expect that developer understand their concerns (you should know what it in it is broken means) and developer expect that users understand their concerns (they should report e.g. that component X makes wrong assumption and produces a race condition). In between there is a huge gap. While the sentence improve the communication is complete non-sense it indicates at least the helpless- ness how to bridge the gap. In my opinion bridging the gap means translation of the language from the consumer to the engineer. I know only two things that can bridge this gap: - if problem reports are written as reproducable misbehaviour one can report it and developer can reproduce the same thing to find his own words/ the real issue behind it. Then the engineer should translate the ticket (subject) to the real thing - community workers can leverage this manually by trying to understand the customer and having enough knowledge to know how the engineer needs the information in order to be able to work. As this is a boring job you have to be paid for it (hello moko). That is nothing you can expect from people to do in their spare time. It is difficult and I could write pages with all those aspects of community vs. paid workers, product vs. development platform, widget set A vs. widget set B and so on. But it would be even more boring than this mail. So I let it go :) My experience is that working with a ticket system takes a lot of time. Don't take tickets statically. Change them as you would change code when you recognize that it doesn't work. That way a unspecific user complaint could be turned into something valuable. And workarounds are workarounds and they are useful until real issues have been fixed. Regarding the No SIM pin dialog where I was involved the ticket isn't that bad. There is an issue recognized no sim pin dialog while qpe is eating your device. And there is a workaround. So why not open a ticket qpe does not detect media files on the SD card which is blocked by the no sim pin ticket? In the sim pin ticket you can announce the work- around and in the second ticket you can complain about the shitty workaround. But then it is clear. The workaround isn't good and has to be removed as soon as the first issue is solved. In the meantime it does something good. My proposal for the ticket system would be to define rules. As soon as you have a page which describes when a ticket is useful and when it is not you can reject tickets from users pointing to that page. That sounds harsh at first but becomes useful really quick because this is a restriction where the community benefits. The
Re: What could be done to improve the OM development process?
On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote: 2. Better communication between the development community and the end user community. I have yet to see anyone say they're pleased as punch with the keyboard. When almost everyone is unhappy, closing bugs as 'working as intended' is pigheaded. You shouldn't understand a community as the incarnation of a collective dictatorship. There is still a company that may have other ideas than everybody in the community. That is ok. It is rather that people have problems in understanding the openness in those things. You are not forced by anyone to use the keyboard. You can change it any time. If you don't like much more things you can even fork the whole thing and make like you expect it. No intellectual property hassle, you are free to do it. That sounds like the same dumb answers before? Yes, it reads like a big excuse for everything from the community members. But there is one thing why this is the way to answer such things. Projects like openmoko survive from people that do anything for it. It is starving through simple complaints, tons of enhancement wishes and the public management of sensitivities . So for me it is the ultimate justice that the people that do decide what to do. If a company pays people to do the work that nobody likes to do than everything is perfect :) hmm, there are a lot of cents in my pocket today :) Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ahah: and you released anyway ? - Re: [ Software Testing Report : 2008.08.07 ]
On Wed, 2008-08-13 at 12:25 +0200, Sébastien Lorquet wrote: It's easy to blame an announcement. +10 Openmoko NEVER said any software realeased as now was 100% ready for daily customer use. I don't think that counts. This no excuse because people automatically expect things. So you don't have to announce it as 100%. You have to do it if it is not 100% to lower expectations and this would have been a good idea if the post about the test results came before the release announcement. Little strategic failure :) So -100 When it will become, be sure the announcement and publicity will be far greater than anyone we had up to now. Keeping hope is good, but expecting what was never promised is disappointing, yes. For my part I will always encourage the GREAT team work that comes out from this community/open company association. Keep up the intense work, Openmoko! +1000 still some cents left Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [ Software Testing Report : 2008.08.07 ]
On Wed, 2008-08-13 at 20:20 +1000, Dale Maggee wrote: Wendy, I'd really like to be notified when these bugs are fixed, specifically: - Some of the testing phone can not make phone calls but can receive/send SMS??? (With alert messageno network) - Two of our phone can not wake up from suspend time. These are the two major issues which made me go back to 2007.2. Is there a way I can be notified of this? will there be an announcement on the list? Also, while I disagree with the 'aha, and you released anyway' comment and don't necessarily see anything wrong with releasing in an unstable state, I do think that it should have been made clear(er) in the announcement that OM's QA team had said Not stable enough to release our Om 2008.8 I think that the talk of debian style stable/testing/unstable branches is a good idea. You can subscribe to the ticket. Just enter your username in the CC field of the ticket and you get a mail when ever the ticket changes. Norbert Thanks, -Dale Wendy wrote: Dear community, here is the QA report which has been created before Om 2008.8 was released. We simply forgot to send this report to a public list because we were too busy with the release preparations. Sorry. More details about our bugs can be found in our bug tracker [http://docs.openmoko.org/trac/], and also check our wiki page [http://wiki.openmoko.org/wiki/Test_Cases] to understand our work and to contact us. Currently we are working on a bugfix release which addresses the major issues you experienced. Stay tuned and thanks for you support, Wendy Subject: [ Software Testing Report : 2008.08.07 ] From: Wendy [EMAIL PROTECTED] Date: Thu, 7 Aug 2008 20:54:41 +0800 To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi All, here are the major bugs from our latest image of Om 2008.8, - Out going call can not really disconnect by End Call if the other one did not pick up the call. - Some of the testing phone can not make phone calls but can receive/send SMS??? (With alert messageno network) - qpe crashed all the time in one of our testing phone. - Two of our phone can not wake up from suspend time. - WiFi can not work (show up unknown all the time) - Can't take GSM signal right away after on the device - [#1661] Unable to send saved tags by entering number (Locations) - [#1635] After x hours the call active will become unstable. Can't receive or make a phone call normally. Due to all these critical major bugs, from our testing team point of view: Not stable enough to release our Om 2008.8. Best Regards, Wendy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenEinstein Newton emulator - Working?
On Wed, 2008-08-13 at 12:52 +0200, Tilman Baumann wrote: Who wrote: Is there any interest? The large screen seems perfectly suited to a Newton Emulator and the Newton UI really is awesome to behold - just so intuitive! I always wonder why no one ever tried to build a modern newton like runtime. Not necessarily smalltalk, but maybe OpenStep/GNUStep... Not necessarily but... :) My plans are to bring squeak/pharo to the device. In squeak there is a handwriting recognition called genie. I doubt the performance will be good enough but it is worth testing. Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What could be done to improve the OM development process?
On Wed, 2008-08-13 at 14:09 +0200, Olivier Berger wrote: Holger Freyther [EMAIL PROTECTED] writes: On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote: 2. Better communication between the development community and the end user community. I have yet to see anyone say they're pleased as punch with the keyboard. When almost everyone is unhappy, closing bugs as 'working as intended' is pigheaded. Hey, as this action is misunderstood a couple of small words. What is the bugtracker for? The way we have used docs.openmoko.org so far is to make it an engineering tool. The assigned/owned tickets tells/informs engineers what to work on, when to get it done (milestone) and how important that is. Whereas us users have been assuming that it was an open bugtracker for en-users... Maybe there would be a need for some other Bug-tracking tool, which would clearly support the separation between support-oriented bugtracker (external) and engineering-oriented one (internal maybe) ? Having two different tools raises complexity and lowers collaborative work. And what do you get from it? I don't think trac's is powerful enough to play both roles without much frustration from either side (but I may be wrong). In my opinion it is never the tool that prevents organized work. Not having the right tool is just the simplest excuse for being organized ;) In any case, a policy should be drafted and announced widely. And mailing-lists for users vs bugtracker for engineering is not satisfactory for any open project, of course. Also, maybe you would need to rely on an organisational tool like a todo manager to assign work to people, whereas bugtrackers may only be there as a repository of knowledge and a communication tool ? Wow, I think it is exactly the opposite. What a bugtracker does best is keeping things that have to be done. What it doesn't do so good is serve as a knowledge base or communication tool. We are communicating over a mailing list. For the rest (ticketing, wiki, source repository) trac tries to be a good integration of those systems. Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPRS working (somewhat) with T-Mobile and Freerunner
I gave it a try, too! I have a t-mobile flat rate which I use from my laptop. I just copied the file to the freerunner altered /etc/group as you supposed. My files look like this: /etc/ppp/peers/t-mobile --- user tm connect /usr/sbin/chat -v -f /etc/ppp/connect-t-mobile /dev/ttySAC0 persist modem noipdefault usepeerdns defaultroute ipcp-accept-local ipcp-accept-remote lock crtscts /etc/ppp/connect-t-mobile - ABORT 'BUSY' ABORT 'NO CARRIER' ABORT 'ERROR' '' AT OK AT+CGATT=1 OK AT+CGDCONT=1,IP,internet.t-mobile OK ATDT*99***1# /etc/ppp/pap-secrets # Secrets for authentication using PAP # clientserver secret IP addresses * * * tm* tm* That's all. I connected it yesterday and it worked. I used tangogps along with it and it downloaded the tiles automatically without having a usb cable connected. This is great! Gprs indeed feels slow and sluggish. The user tm in my files is arbitrarily chosen. It is said it's just better to connect with supplying a user and password. Norbert 08-09 at 14:51 -0700, Nathan Kinkade wrote: I just wanted to share with the community that I have somewhat got GPRS working T-Mobile on a Freerunner (GTA02) with the August 8 release of Om2008.8. I'm going to paste a bunch of stuff in here, so sorry if this email is pretty confused and long. I need to say up front that I don't have any data plan with T-Mobile. I just went to a T-Mobile store yesterday and bought a SIM chip (US$10) and a pre-paid plan. The guy behind the counter asked me what the phone was that I had. I explained a little, and then he mentioned something about me being able to get free data service, that T-Mobile didn't advertise it, and that it wasn't worth their time to track down who was using it ... I don't know. He just wrote on my receipt wap.voicestream.com. I should also note that I didn't have to modify /sys/bus/platform/devices/neo1973-pm-gsm.0/power_on, or chown /dev/ttySAC0, or even do stty -F /dev/ttySAC0 crtscts. However, in relation to chowning /dev/ttySAC0, I *did* modify /etc/group and add the users uucp and ppp to the group dialout, which by default has write permissions on /dev/ttySAC0. It seems to connect, bring up the ppp0 interface, and get and configure a number of TCP/IP settings. Only DNS name resolution seems to work, but this is probably just because I don't have a data plan, or haven't figured out what ports are open to the outside world or what proxy may need to be used. Any input, or suggestions would be great. What I've done required very little modification from this wiki article: http://wiki.openmoko.org/wiki/GPRS. The only files I edited or created were the ones you see below. Get ready for a cut-n-paste fest: - [EMAIL PROTECTED]:~# cat /etc/ppp/peers/tmobile lock /dev/ttySAC0 115200 crtscts connect /etc/ppp/tmobile-connect disconnect /etc/ppp/tmobile-disconnect hide-password usepeerdns ipcp-accept-local noauth noipdefault novj novjccomp defaultroute replacedefaultroute # Reopen the connection if it fails, pausing for a while. persist holdoff 15 # Check the line every 20 seconds and presume # the peer is gone if no reply for 4 times. lcp-echo-interval 20 lcp-echo-failure 4 - [EMAIL PROTECTED]:~# cat /etc/ppp/tmobile-connect #!/bin/sh -e exec chat -v -S -s\ TIMEOUT 15\ \K\K\K\d+++ATH\ OK-AT-OK ATZ\ OK ATE1\ ABORT BUSY\ ABORT DELAYED\ ABORT NO ANSWER\ ABORT NO DIALTONE\ ABORT VOICE\ ABORT ERROR\ ABORT RINGING\ TIMEOUT 60\ OK AT+CFUN=1\ OK AT+COPS\ OK AT+CGDCONT=1,\IP\,\wap.voicestream.com\\ OK ATD*99***1# CONNECT /n/d - [EMAIL PROTECTED]:~# cat /etc/ppp/tmobile-disconnect #!/bin/sh -e /usr/sbin/chat -v\ ABORT OK\ ABORT BUSY\ ABORT DELAYED\ ABORT NO ANSWER\ ABORT NO CARRIER\ ABORT NO DIALTONE\ ABORT VOICE\ ABORT ERROR\ ABORT RINGING\ TIMEOUT 12\ \K\K\K\d+++ATH\ NO CARRIER-AT-OK \c - [EMAIL PROTECTED]:~# cat /etc/ppp/pap-secrets # Secrets for authentication using PAP # client server secret IP addresses * * * - [EMAIL PROTECTED]:~# pon tmobile [EMAIL PROTECTED]:~# logread -f Aug 9 21:40:52 om-gta02 daemon.notice pppd[1521]: pppd 2.4.3 started
http://wiki.openmoko.org/wiki/Om_2008.8
Hi, I read the post about the new review for the freeunner on golem. While reading I wondered what screenshots they used in a text announcing the new firmware. A few moments later I followed the link to the wiki page for Om2008.8. I think the screenshots on the page should show what you get after installing the new firmware. The second one is just counter productive. With a fresh install you get not only fewer icons, all icons are assigned different applications. That maximizes confusion for new users. Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
No pin dialog/ qpe
What is qpe exactly doing? I noticed a lot of problems other people reporting like the no pin dialog. Looking at the device qpe uses 100% CPU for a long time. I don't understand it but the CPU usage of qpe is capable to slow down other things extremely. The SIM Pin dialog is working with the new firmware but delayed through qpe. Holger Freyther gave me the hint that it is looking for media on the SD card. In /opt/Qtopia/etc/default/Trolltech/Storage.conf there is a section where qpe is configured for the media it should search. For the SD card every media type is activated. So the qpe searches the SD card after booting blocking a lot of other things. There are two issues for me: - it is discussable if these settings are useful as default to search for media on the SD card. While being troublesome I would be against it - furthermore the SD card is configured as being removable forcing the qpe to do the search every time being activated. Removable can be interpret as two things. The card is removable at runtime or it is removable at all. In the second case this would be true for hard disks as well :) If this is meant as something sensible at runtime this is a misinterpretation. You have to shut down the freeunner to remove the card so it is not really removable Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No pin dialog/ qpe
On Mon, 2008-08-11 at 21:01 +1000, Lorn Potter wrote: Norbert Hartl wrote: What is qpe exactly doing? I noticed a lot of problems other people reporting like the no pin dialog. Looking at the device qpe uses 100% CPU for a long time. I don't understand it but the CPU usage of qpe is capable to slow down other things extremely. The SIM Pin dialog is working with the new firmware but delayed through qpe. Holger Freyther gave me the hint that it is looking for media on the SD card. In /opt/Qtopia/etc/default/Trolltech/Storage.conf That is one possible thing it is doing at startup. The idea is that it is a phone, and you only startup in rare instances. If we take a stable phone than you are right. But at the moment people need to start often and that leads to a situation where these settings confuse a lot of people. It is even there if you start your phone the first time. To raise user experience this search should be delayed and it should be assured that this search is happening on a very low priority so it does not block anything. There could be even an indicator that is visually announcing the search. But let us be realistic :) there is a section where qpe is configured for the media it should search. For the SD card every media type is activated. So the qpe searches the SD card after booting blocking a lot of other things. There are two issues for me: - it is discussable if these settings are useful as default to search for media on the SD card. While being troublesome I would be against it If Qtopia is not allowed to search the SD card, it will not be able to see/use files on it, so then why have it at all? Because there is always something in between black and white. There could be some intelligent way to detect when it is necessary to refresh. And users are quite used to know that software is stupid and they praise the existence of a manual trigger for such actions. - furthermore the SD card is configured as being removable forcing the qpe to do the search every time being activated. Removable can be interpret as two things. The card is removable at runtime or it is removable at all. In the second case this would be true for hard disks as well :) If this is meant as something sensible at runtime this is a misinterpretation. You have to shut down the freeunner to remove the card so it is not really removable But it _IS_ removable, losable and optional. The flash chip is not. As well, you might have added files to it while you had it out. see above. Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No pin dialog/ qpe
Thanks! But your proposal is a bit harsh for me :) You just need to put 0 to the config items in section SD Card. That solves it as well. Norbert On Mon, 2008-08-11 at 13:35 +0200, Rorschach wrote: Thanks Norbert very much for finally finding the real problem with the pin dialog not appearing! Removing this makes the pin-dialog appear for me with !!every boot!! now ca. 15-20 sec after x started. Before this patch the pin-dialog just appeared 1 out of 40 boots! This is a big improvment. So if this is really needed to do by qpe, this process should be forked away from qpe in order to not block other things and it should be given a low priority with nice not to consume so much cpu and blocking other processes with this. # diff /opt/Qtopia/etc/default/Trolltech/Storage.conf.bak /opt/Qtopia/etc/default/Trolltech/Storage.conf --- /opt/Qtopia/etc/default/Trolltech/Storage.conf.bakMon Aug 11 11:19:26 2008 +++ /opt/Qtopia/etc/default/Trolltech/Storage.confMon Aug 11 11:20:02 2008 @@ -2,19 +2,8 @@ File=QtopiaDefaults Context=Storage -[MountTable] -MountPoints=MountPoint0 - [HOME] Name[] = HOME Documents = 1 Applications = 0 ContentDatabase=1 - -[MountPoint0] -Name[] = SD Card -Path=/dev/mmcblk0p1 -Removable = 1 -Applications = 1 -Documents = 1 -ContentDatabase = 1 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No pin dialog/ qpe
On Mon, 2008-08-11 at 13:41 +0200, arne anka wrote: If Qtopia is not allowed to search the SD card, it will not be able to see/use files on it, so then why have it at all? wouldn't it be sensible to have some flag or checksum indicating that the card and it's content are unchanged, thus preventing unnecessary searching? i do not use qtopia, so if it's already done that way, ignore me ... The flag you mean could be the modification date of the filesystem. Placing an extra flag does not help. A copy of mp3 files with an other program does not honor your flag but the filesystem stamps do. A registry of media cards and modification dates could solve this. If there is an id on the filesystem (like the uuid from an ext3) use this. Otherwise the freerunner could create one and write it on the media. If the freerunner then would check the id and the timestamp asking the user to do some actions on change that would be heaven :) my 2 cents Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Feed updates
Since the release of Om2008.8 there were IMHO no further updates over the feeds. Is this caused by the hard-earned rest of the exhausted developers or has development switched to a dev branch/feed? Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No pin dialog/ qpe
On Mon, 2008-08-11 at 15:01 +0200, arne anka wrote: wouldn't it be sensible to have some flag or checksum indicating that the card and it's content are unchanged inotify does inotify tell you if the card was manipulated outside the fr? No, inotify is an observer at runtime. http://en.wikipedia.org/wiki/Inotify It is exactly the opposite I talked about and non working version of the same :) Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Video demo: Openmoko Neo Freerunner Features Accelerometer-based Gestures, and Screen Orientation
Wow, that is great!!! How fine grained is the resolution of the movements? I mean how detailed you could draw a shape on the screen from the figure you painted in the air? Or even better. Do you think it would be possible to do something like palms grafiti without knocking your neighbor out? :) Norbert On Mon, 2008-08-11 at 09:35 +0200, Paul-Valentin Borza wrote: Hi, As Google Summer of Code 2008 is almost at its end, here's a video showing what you should expect out of the accelerometer-based gestures project: http://digg.com/gadgets/Openmoko_Neo_Freerunner_Motion_Gestures_Screen_Orientation_2 There still are some things that need to be worked on for the GUI, but I will release another package on Thursday/Friday with everything you've just seen in the YouTube video. Again, big thanks to Daniel for helping me out with the problems I have encountered on the way. Thanks Daniel! This doesn't mean that I'll stop working on the project; on the contrary, I will continue to improve it, and I'll use the Neo for my primary development target. More on http://gestures.borza.ro Thanks, Paul -- http://www.borza.ro ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No pin dialog/ qpe
On Tue, 2008-08-12 at 03:26 +1000, Lorn Potter wrote: Norbert Hartl wrote: On Mon, 2008-08-11 at 21:01 +1000, Lorn Potter wrote: Norbert Hartl wrote: What is qpe exactly doing? I noticed a lot of problems other people reporting like the no pin dialog. Looking at the device qpe uses 100% CPU for a long time. I don't understand it but the CPU usage of qpe is capable to slow down other things extremely. The SIM Pin dialog is working with the new firmware but delayed through qpe. Holger Freyther gave me the hint that it is looking for media on the SD card. In /opt/Qtopia/etc/default/Trolltech/Storage.conf That is one possible thing it is doing at startup. The idea is that it is a phone, and you only startup in rare instances. If we take a stable phone than you are right. If you develop a phone for only developers, then thats what you get. A phone that only a small niche of developers are going to want to use. Are you serious? It is no end-user device right now. The behaviour at the moment prevents a lot of people to work with the freerunner (use it as a phone) and therefor prevents acceptance. This change is so easy to revert if the situation changes that I can't understand what you are saying. In my understanding you are forcing a situation which you state you want to avoid. But at the moment people need to start often and that leads to a situation where these settings confuse a lot of people. Then take the SD card entry out of the conf file. I have fixed it already on my freerunner. I just like to give feedback to the community. In my opinion discussions make sense. I find something, some discuss it and if it is a good idea than maybe a few take responsibility and change the code base. If it doesn't work that way I don't understand the whole thing. There is no need trying to teach me, thank you. It is even there if you start your phone the first time. To raise user experience this search should be delayed and it should be assured that this search is happening on a very low priority so it does not block anything. There could be even an indicator that is visually announcing the search. But let us be realistic :) there is a section where qpe is configured for the media it should search. For the SD card every media type is activated. So the qpe searches the SD card after booting blocking a lot of other things. There are two issues for me: - it is discussable if these settings are useful as default to search for media on the SD card. While being troublesome I would be against it If Qtopia is not allowed to search the SD card, it will not be able to see/use files on it, so then why have it at all? Because there is always something in between black and white. There could be some intelligent way to detect when it is necessary to refresh. And users are quite used to know that software is stupid and they praise the existence of a manual trigger for such actions. The trigger is someone booting up, or inserting the SD card. Then you know exactly what it does. What happens if a file is downloaded from the internet and stored on the SD card? Does qpe recognizes this as well? No matter what the answer is the current situation is not optimal. And I would like to hear rather a proposal how to treat that instead of getting an explanation about how _it_ works [tm]. Thanks again! regards, Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Feed updates
On Tue, 2008-08-12 at 02:36 +0200, Holger Freyther wrote: On Monday 11 August 2008 14:15:20 Norbert Hartl wrote: Since the release of Om2008.8 there were IMHO no further updates over the feeds. Is this caused by the hard-earned rest of the exhausted developers or has development switched to a dev branch/feed? Hey ruediger, Psst, you are not supposed to tell anyone that other name ;) there will be an testing feed. It will be public, it is supposed to be used by QA to upgrade from stable images to test bugfixes. These things will move into stable. Oh yes, I saw the update in the git repo. Very promising way to go into the direction of something real stable. So it might take a week or so for new updates to appear? That's ok. Go for it!!! Once we have it I'm going to write another mail. Things scheduled for testing are these [1]. I think I'm going to buy a Nokia wireless keyboard and take the freerunner with me on my holidays. (God, she will hate me!) Norbert z. [1] http://git.openmoko.org/?p=openmoko.git;a=shortlog;h=org.openmoko.asu.testing ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.8 Goes to sleep too fast!
On Sun, 2008-08-10 at 09:32 +0200, Anton Persson wrote: Hi, I have a problem, my FreeRunner goes to sleep to fast when I'm running the 2008.8 release. If I connect it to the USB socket of my computer I can hardly manage to login via SSH before it goes into hibernation, quite unuseful. How do I disable/configure the auto-hibernate feature? Go to Home. Press the Settings icon...wait. On the upcoming screen there is an option suspend. Press it until it displays off. Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FR at golem.de
On Wed, 2008-08-06 at 14:35 +0200, Tobias Kündig wrote: This is the worst review I ever read from Golem. So many mistakes. They bought their Freerunner and wrote the review. I bet they haven't tested it for more than 1 day. Fow how long do you think you should check a device before writing a review? I find the review ok. It is very clear that the tester doesn't has to be an expert in this domain. And I found most points to be true. What are the big mistakes in it that makes this review so horrible? The conclusion is that you get a linux computer with many possibilities from which the most are not made available , yet. And it is quite unusable as phone. All true for me. I can't use it as my daily phone and I know how to tweak the device. And that is the same openmoko says about their own product. So where is the problem? Norbert The funniest thing: They say the icons are bad. i.e. the «gears»-Tab is not for Settings, it's for the favorites menu. Never heard from a task manager, haven't they... 2008/8/6 Christian Weßel [EMAIL PROTECTED]: Googles English is horrible. :-) Am Mittwoch, den 06.08.2008, 07:29 -0400 schrieb Charles Pax: 2008/8/6 Christian Weßel [EMAIL PROTECTED] Hi folks, the german online news golem reports about our FR (unfortunaly just in german language) http://www.golem.de/0808/61507.html Google translate: http://translate.google.com/translate?u=http%3A%2F% 2Fwww.golem.de%2F0808%2F61507.htmlhl=enie=UTF8sl=detl=en -Charles ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- mfg/br, christian weßel Flurstraße 14 29640 Schneverdingen Germany E-Mail: [EMAIL PROTECTED] Telefon: +49 5193 97 14 95 Mobile: +49 171 357 59 57 http://wesselch.homelinux.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Navit?
On Wed, 2008-08-06 at 19:05 +1000, Dale Maggee wrote: Michael Sheldon wrote: Dale Maggee wrote: do you have an ipkg? did you get gpsd support to compile? I've tried compiling the svn version, but I get the following during 'make': /usr/local/openmoko/arm/lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/../../../../arm-angstrom-linux-gnueabi/bin/ld: cannot find -lpq collect2: ld returned 1 exit status make[2]: *** [osm2navit] Error 1 om-conf seems to work, although it still isn't enabling gpsd. You shouldn't need to use the separate openmoko buildchain, there's a navit recipe in openembedded which should build navit and all the required dependencies. Just setup the MokoMakefile: http://wiki.openmoko.org/wiki/MokoMakefile Then run: make build-package-navit This'll probably take a long time, since it'll first have to build the tool chain and all dependencies. If I get time later I'll see about doing a build of it and making it available. Cheers, Mike. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I had a read through the MokoMakeFile wiki page, but it looks to me like it has to build other stuff (also mentioned in your message). This mentions requiring about 12Gb of free HDD space, which I don't have... am I missing something? can I just build navit using the MokoMakeFile? will it really need 12Gb? :O No, you will need this space only if you are building the complete image. For navit it will be much less. I'm trying to build it at the moment but being stuck with a portaudio issue. Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FR at golem.de
On Wed, 2008-08-06 at 15:19 +0200, Michele Renda wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Norbert Hartl wrote: On Wed, 2008-08-06 at 14:35 +0200, Tobias Kündig wrote: This is the worst review I ever read from Golem. So many mistakes. They bought their Freerunner and wrote the review. I bet they haven't tested it for more than 1 day. Fow how long do you think you should check a device before writing a review? I find the review ok. It is very clear that the tester doesn't has to be an expert in this domain. And I found most points to be true. What are the big mistakes in it that makes this review so horrible? The conclusion is that you get a linux computer with many possibilities from which the most are not made available , yet. And it is quite unusable as phone. All true for me. I can't use it as my daily phone and I know how to tweak the device. And that is the same openmoko says about their own product. So where is the problem? I think that before to test something you must to know what are you testing. You can not to test a phone and than to say: Oh... it is stupid, it is not able to prepare me a coffee :) Nobody expected from a mobile phone that it should be able to make coffee. But you can expect from a mobile phone to make phone calls, can't you? From a PDA you can even expect to have a addressbook where you can store and find addresses, can't you? To be extremely biased towards this device does not help anyone. From the view point of a mobile phone the freerunner is the second worst device (nokia communicator 9100 was much worse :)) I ever saw. From the perspective of an open mobile platform it is coolest thing invented since sliced bread. my 2 cents, Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FR at golem.de
On Wed, 2008-08-06 at 09:36 -0400, Daniel Benoy wrote: Yeah, someone who is reviewing this device from the mindset of an end user is someone who's producing a useless review. It says 'Not for end users' all over its site long before you try to buy one. Are they writing a review for people who don't read? If you ask me, FIC should have shipped these with no rootfs, so that it would really drive home the point about how you should approach this device at this early stage. In the review you read what you can expect from the device. The conclusion is exactly what you say about what is written all over their site (Can you point me to any place on openmoko.com site where it says Not for end users?) So this is a review for people to know what it is without having to buy it first. And the conclusion says Not for end users. Norbert On Wednesday 06 August 2008 09:19:32 Michele Renda wrote: Norbert Hartl wrote: On Wed, 2008-08-06 at 14:35 +0200, Tobias Kündig wrote: This is the worst review I ever read from Golem. So many mistakes. They bought their Freerunner and wrote the review. I bet they haven't tested it for more than 1 day. Fow how long do you think you should check a device before writing a review? I find the review ok. It is very clear that the tester doesn't has to be an expert in this domain. And I found most points to be true. What are the big mistakes in it that makes this review so horrible? The conclusion is that you get a linux computer with many possibilities from which the most are not made available , yet. And it is quite unusable as phone. All true for me. I can't use it as my daily phone and I know how to tweak the device. And that is the same openmoko says about their own product. So where is the problem? I think that before to test something you must to know what are you testing. You can not to test a phone and than to say: Oh... it is stupid, it is not able to prepare me a coffee :) Michele ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ASU - desktop theme instead of ASU theme in X?
On Sun, 2008-08-03 at 14:05 +0200, Torfinn Ingolfsen wrote:
More info:
todays upgrade ('opkg update', then 'opkg upgrade') didn't solve the
problem with the desktop theme or screen or whatever.
If anybody knows how to get back the standard ASU look and feel on
the screen, I will be very happy.
I hope I don't need to reflash my FR to get it fixed.
I had a e desktop as well after applying the fix of Bug #1678. In
my case I had to reinstall illume and do a
rm -rf /home/root/.e
hope this helps,
Norbert
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
