What disk space size is needed to run make openmoko-devel-image?
I have used a 15G disk to run make openmoko-devel-image, but it has been out of disk space. I have no idea of what disk size is OK to run make openmoko-devel-image. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
Absolutely agrree. GPS was one of my main points for buying the phone. I dont really care about the source for the driver as long as I can get the co-ordinates. Count me in the 'me too' crowd .. I'm really looking forward to having working GPS functionality on my GTA01, from the perspective of a user as well as that of a developer, who would like to integrate GPS into the game currently being worked on exclusively for OpenMoko .. j. ; -- Jay Vaughan ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What disk space size is needed to run make openmoko-devel-image?
Wave Zhang wrote: I have used a 15G disk to run make openmoko-devel-image, but it has been out of disk space. I have no idea of what disk size is OK to run make openmoko-devel-image. Add INHERIT += rm_work to build/conf/local.conf and you shouldn't need more than about 5.5GB -Gordon ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What disk space size is needed to run make openmoko-devel-image?
But I already have that in my local.conf. I past my moko/build/conf/local.conf as following: MACHINE = fic-gta01 DISTRO = openmoko BUILD_ARCH = i686 INHERIT += rm_work -Bo On 10/15/07, Gordon Syme [EMAIL PROTECTED] wrote: Wave Zhang wrote: I have used a 15G disk to run make openmoko-devel-image, but it has been out of disk space. I have no idea of what disk size is OK to run make openmoko-devel-image. Add INHERIT += rm_work to build/conf/local.conf and you shouldn't need more than about 5.5GB -Gordon ___ 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: Some feedback from using the neo as a phone for a day
Hi Igor, It would be very useful if you could file your issues on the OpenMoko bug tracker at http://bugzilla.openmoko.org. This would ensure your issues are dealt with and you receive proper feedback from the developers. Regards, Thomas On Sun, 2007-10-14 at 22:38 -0400, Igor Foox wrote: Yesterday (and today) I used the neo as a phone for the first time, after gsm started mostly working out of the box. I'm really excited about this development and I think that it marks a huge milestone for the project. So congratulations to everyone who worked so hard on this project! I've got a lot of feedback about my usage of the phone. Both minor points as well as bigger design issues. I'm going to post them here for discussion, in no particular order. But if there are better places where specific points should be redirected, I'll be happy to do that. A lot of the issues I'm going to raise are negative, but it's just constructive criticism from a user's point of view. :-) Voice/Talking: - There is a very strong amplification of background noise when in a voice call. If you are in a quiet room the sound is pretty good (and the volume is nice and loud). But when there is even mild background noise in your location it gets amplified, and both you and the other party barely hear anything. - I tried playing with sidetone in alsamixer but that didn't help, so I don't think that that's the problem. - I'm not sure in which component of the software stack this happens, but it seems to me that we might need to investigate some noise cancellation algorithms and apply those to the incoming sound when in a voice call. Does anyone have any experience with this, or does anyone at least know whether this is a common thing to do with cell phones? UI: - The current keyboard is highly unusable. I know it's intended to be used with a stylus, and it's fine for that, but it's completely unreasonable to expect a user to have a stylus for activities like SMS, or entering a new contact. And even with pretty small fingers it's pretty hard for me to type on the keyboard. - In the Contacts application, it's impossible to enter a phone number (and maybe an email address) for a contact when the phone is not connected to the GSM network. - In the dialer application there's apparently a 'cursor' that you can move by clicking somewhere on the textfield displaying the current phone number. But there is no visual feedback for the cursor so if you accidentally place it in the middle of a number you're left thinking you will be very confused. - The scrolling is very cool, but it's often difficult to scroll when the items you're scrolling are clickable, because it incorrectly gets recognized as a click. - The dialer does not always pop up on an incoming call. So when the phone starts ringing you need to open the dialer application and then answer the call. - The dialer application has the hangup button on the top right of the screen when in a call. When you actually talk on the phone it's _really_ easy to touch that part of the screen with your face, which results in 3-4 accidental hangups per call. Oops. :-) - The status icons on the top tend to disappear once in a while. Sometimes a reboot gets them back. Sometimes it doesn't. But usually two or three reboots get them back. Very perplexing. :) I'm going to continue using the phone for the next few days and try to identify more issues. I think that the only major issue here is the background noise problem. If that is resolved we would be well on our way to having a phone ready to be tested by some real consumers. Igor -- OpenedHand Ltd. Unit R Homesdale Business Center / 216-218 Homesdale Road / Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559 Expert Open Source For Consumer Devices - http://o-hand.com/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What disk space size is needed to run make openmoko-devel-image?
On 10/15/07, Wave Zhang [EMAIL PROTECTED] wrote: But I already have that in my local.conf. I past my moko/build/conf/local.conf as following: MACHINE = fic-gta01 DISTRO = openmoko BUILD_ARCH = i686 INHERIT += rm_work -Bo On 10/15/07, Gordon Syme [EMAIL PROTECTED] wrote: Wave Zhang wrote: I have used a 15G disk to run make openmoko-devel-image, but it has been out of disk space. I have no idea of what disk size is OK to run make openmoko-devel-image. Add INHERIT += rm_work to build/conf/local.conf and you shouldn't need more than about 5.5GB -Gordon I have noticed that disk usage drops in a late part of the building process of openmoko-devel-image. I have seen several gigabytes being freed after doing the do_stage phase of packages which happened unexpectedly late. If you have disk space problem try manually doing make build-package-pkgname for those packages who needs lot of disk space. This should force (I think) the stage and rm_work phase for those packages. Hope this helps, Alessandro ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some ideas for the accelerometer
I like the idea - especially because I always have full pockets and it takes hours to fish the phone out ;) Imho it should be possible to implement, a knock should give a peak you can't reach while walking and even if it happens, it shouldn't be that worse. 2007/10/14, Ortwin Regel [EMAIL PROTECTED]: This doesn't work well because the screen moves with the phone. So if you want to scroll right fast, you'll have trouble to see what's going on on the screen. Scrolling should rather be done on the touchscreen because that works really well. However, dragging the map/website as if it was physical is too slow in most cases. Increasing scrolling velocity by the distance from the initial touchpoint would probably be a good idea but adjustable scrolling speed would be great already. Instead of scrolling one screen far when I move my finger once across the screen, I want to scroll four screens so that I get where I want quicker. Someone else might only want to scroll one screen. Kinetic scrolling can extend this and look/feel awesome but also be very annoying so it should probably be optional. Now what do we do with the accelerometer? I like the zooming idea. It shouldn't require a hardware button press because those are kind of hard to press. Touching the screen should be enough and it would mean that you can zoom and scroll at the same time and pretty intuitively. About the initial idea: Judging from my DS accelerometer (which is different hardware but should be relatively similar), the sampling frequency will probably be pretty high. I still doubt that you can reliably differentiate between walking and hitting the phone. However, it might be possible to shake it two or three times with a frequency faster than any form of running and it should be possible to detect this. This probably won't help you if the phone is hidden in a huge backpack. It's also important to remember that the motion of picking up your phone should not lead to denial of the call... ;) Ortwin On 10/12/07, David Pottage [EMAIL PROTECTED] wrote: On Friday 12 October 2007, Oliver wrote: I've had similar ideas, but haven't posted them yet. Here's one: Imagine you're surfing the internet, or checking a map, or something like that. We don't have a multi-touch screen, so we can't zoom out with our fingers like iPhone users. Zooming out, though, is something we really should be able to do. So just hold a hardware button and bring the phone closer to your face! The site/image should be shrunk in such a way that you'll think it is stationary behind the phone, and the phone screen is a window through which you can view this image/site! When you've spotted something you want to focus on, somewhere else on the page, don't scroll, just keep holding the button bringing the phone/window down to that place. If you stop holding the button, the image can either stay where it is, or go to it's original zoom-level. Just imagine, if you think of the screen as a window, what incredibly fun games you could develop for the phone! I think a better idea would be to think of the screen as a mirror that you are using to view a much larger page behind you. That way you can intuitively scroll both vertically and horizontally a large page or map by tilting the screen, and without using the touchscreen. (Which can be reserved for other functions). A lot of UI ideas here are coppied from other touch screen devices. That's fine where appropriate, but the Neo 1973 is the only phone with built in accelerometers, and I think we should make use of them where we can. We should not just copy the iPhone or whatever, that only uses it's accelerometer as a tilt sensor to make the display image the right way up. -- David Pottage ___ 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: Bi-weekly OpenMoko community update
On Mon, 15 Oct 2007 11:18:55 +0200, Jay Vaughan [EMAIL PROTECTED] wrote: so no, we do want and require the source code to everything Change your government then. Of course. This is but a small first step on the road to world domination ;o) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some ideas for the accelerometer
On Sun, 14 Oct 2007 21:57:52 +0200, Ortwin Regel [EMAIL PROTECTED] wrote: It's also important to remember that the motion of picking up your phone should not lead to denial of the call... ;) The initial proposal mentioned muting the ringer, not denying the phone. It's perfectly OK to mute the ringer if you're already taking the phone to your ear. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Data Calls] over [Wifi Mesh network]
In my work group we need two phones GTA02v3. They say in the wiki that it can be available in october to qualified developers. How is the way to be classified qualified developers? Who to ask for? Francesco Pistillo Computer science department Bari University Italy ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some ideas for the accelerometer
I think the idea is great... I've designed a few control systems using accelerometers to time the ejection of parachutes on MPRs/HPRs (Medium/High Power Rockets). The biggest issue is how to interpret the data. One of the largest problems we've had to overcome with accelerometers is averaging the input data over the right time interval. Too short of an interval and the jitter effect drowns out any useful data. Too long, and detecting any useful pulses is attenuated. An algorithm that varied that time interval would probably prove most useful. I am particularly interested in the scrolling function, possibly using a [tap]. You could [tap] right above the top of the lcd module or right below it, and depending on the program, it would scroll up or down. This could easily be picked up using the accelerometers since the phone is so light, an acceleration peak is easily attained (and I'm only thinking 2D here, there's a huge amount of information coming in with 2x3D accelerometers). This would even work while walking or running, because those would register as curves more than a specific peak. (The algorithm could use the GPS data to detect walking and attenuate accordingly.) Do we know the exact accelerometer being used in GTA02 yet? I could do a comparison using the accelerometers I have lying around. @Dean Collins, The IBM Hard Drive knock application is an excellent example of using this type of input. -Kyle On 10/15/07, Alexey Feldgendler [EMAIL PROTECTED] wrote: On Sun, 14 Oct 2007 21:57:52 +0200, Ortwin Regel [EMAIL PROTECTED] wrote: It's also important to remember that the motion of picking up your phone should not lead to denial of the call... ;) The initial proposal mentioned muting the ringer, not denying the phone. It's perfectly OK to mute the ringer if you're already taking the phone to your ear. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com ___ 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: Usability team?
I'll do that! Thanks Thomas. Carla - Original Message From: Thomas Wood [EMAIL PROTECTED] To: List for OpenMoko community discussion community@lists.openmoko.org Cc: london cowgirl [EMAIL PROTECTED] Sent: Sunday, October 14, 2007 10:21:29 AM Subject: Re: Usability team? On Fri, 2007-10-12 at 07:14 -0700, london cowgirl wrote: Hi Justin Thomas I think the investment made into the UI is extremely important and valuable (well done, Thomas). Shall we put together a usability team so these user centered design efforts continue? I'm a usability expert and would love to get engaged on a mobile device project. We could do personas, interviews, usability tests, etc... Any takers? Sounds like a great idea. I would love to get some usability feedback from proper usability analysis on the current design. Perhaps we can start a discussion on the openmoko-apps mailing list? That is the mailing list for the official applications. Perhaps you could post a mail suggesting some starting points and some basic things everyone could try? Regards, Thomas -- OpenedHand Ltd. Unit R Homesdale Business Center / 216-218 Homesdale Road / Bromley / BR1 2QZ / UK Tel: +44 (0)20 8819 6559 Expert Open Source For Consumer Devices - http://o-hand.com/ Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: interface design suggestions
Dani We're attempting to put together a usability team and a user centered design process. Would you be interested in working with us and our findings? You have a good eye and I like the input you've provided. Carla White On 9/23/07, Dani Anon [EMAIL PROTECTED] wrote: Hi I was thinking on getting an openmoko when it's done and probably developing a couple of apps but before that I think there is a big problem with the current graphic design so I thought I'd contribute a mockup and some thoughts. If such contributions are welcome I'd be willing to mockup the remaining interface elements under CC free for any usage. Note that I don't have an openmoko yet so I just took an screenshot of the website (the one I found to be more complete widget-wise) and remade it. You can see both here in this png I've uploaded to imageshack: It's work in progress, I didn't bother to do the full reflection treatment to the icons, and the little ideograms are pretty poorly done, a lot of other things also need to be fixed, but it's enough to get us started: http://img442.imageshack.us/img442/4728/ommockupexportaf2.png Now some comments about the differences: - The current design has too many different styles all over the interface, there are a lot of different backgrounds, styles of buttons, sliders, etc. In my proposal there's only one background (that gray gradient bitmap) that is used in every input area. For background as the content area I use simply white, and the only exception is the black status area on top with the notification icons. Using less bitmaps not only gives you a better looking design but it simplifies development and theming, this is very important. - You are using non-white colors for background of the content areas, which gives you a text contrast of 80%. This is no good, as a mobile device is commonly used outside and visibility (contrast) is no good to start with, so we shouldn't have anything less than 100% contrast for variable content, i.e: black over white or white over black. Things that the user is familiar with like symbols and titles of programs and headers are ok not having 100% contrast since the user already knows the captions. - I understand that you are using the same non-gray color through the interface (orange) to get some coherence. This can be a good idea to avoid making bad color choices but we can do better and get: a) better usability. using different colors for different categories of things is a universal and accepted way of improving usability (think of traffic lights and signals). You shouldn't avoid this resource. b) better experience. The same color all over the interface can get boring quickly! - Keyboard layout. You are wasting space right know, the same keyboard can be arranged to take advantage of 100% of the width of the screen. The new layout gives you 20% more horizontal space resulting in more accuracy. I'm not sure at all about having backspace and enter in that place, that particular detail is just the first thing I came up with. - You have a lot of padding and margin where you don't need it. As a result of removing those unnecessary details I have saved a lot of space. Yes, padding and margin is good wherever we have an interactive button that would need to be pushed, to avoid errors, but we really don't need it for non interactive items if we design properly. - My key buttons are now language agnostic, del has been replaced by just the backspace symbol and enter has been replaced by the enter symbol. The color of the buttons provide another clue about the function. This way the same bitmaps can be used in any language configuration. - (strictly design problem) I didn't like the horizontal gradient on top, really took my attention toward the left, I felt it was a problem. - The proposed layout of the keyboard is more similar to a real keyboard, in the current design Z is right on top of S for example. There is space at the right of L that could be used for an ntilde (Ñ) for spanish speakers or a cedilla (Ç) for french speakers depending on the configuration. - You didn't need to surround the clock on top by a border, the format XX:XX is easily recognizable already as an independent item, and by removing the border you can have a bigger font size that makes it easy to read. - Speaking of font sizes notice how by removing unnecessary elements now I have bigger font sizes everywhere that make everything easier to read. - The orange glow to indicate selection of an item: it's a cool idea, but unfortunately there's little contrast between orange and white (remember this is a cellphone so we need a lot of contrast). Contrast between yellow and black is 65%, contrast between the current orange and white is 43%. Contrast between a selected cell and the cells above and below also helps, that's why I've removed the glow. A plus about yellow is that it is intuitively recognized as the most used color to highlight stuff. Contrast
Re: Some ideas for the accelerometer
But not while walking... Differentiating between motions and situations will be a big challenge. Once my Neo knows how I walk, it can detect that I am walking and subtract the walking pattern from the accelero data. Remaining data contains noise from walking (hopefully noisy enough to go undetected) and other signals (including signals with lower amplitude than the walking pattern). Should be workable, though there may be funny effects when I start or stop walking :) Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some feedback from using the neo as a phone for a day
- The dialer application has the hangup button on the top right of the screen when in a call. When you actually talk on the phone it's _really_ easy to touch that part of the screen with your face, which results in 3-4 accidental hangups per call. Oops. :-) - The status icons on the top tend to disappear once in a while. Sometimes a reboot gets them back. Sometimes it doesn't. But usually two or three reboots get them back. Very perplexing. :) I noticed that too. Maybe the panel applets process needs to run under a supervisor that will restart it? Nah, they (or one of them, since I think it's one application) should simply not crash. Supervisors add complexity that I do not desire. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: interface design suggestions
To be honest, I understand the concepts of better contrast etc, but the proposed interface is very blockish and not nearly as nice looking as the fades and the use of Orange in the current. I do understand that it is a quick mockup, and that I myself have had no suggestions (nor do I claim to know about usability), but I really like the current look quite a bit more than the proposed. I dislike the white fields in the proposed, and the large number of colours; there is much to like in the current: the circular keys, the rounded edges everywhere, the slight boarders to the various frames and fields, all make for a nicer looking interface (IMHO). At the resolution the phone provides, I don't think that the phone should look like it has a lot less by removing these stylistic details. Again, I am just one person with the desire to help influence this great project, and the overall goal is to make a great phone. I appreciate the work of all in this endever, as I really am only a buystander. The usability team will really know best, and I am hoping it is all themeable anyway. Dani, you've put more thought into this than I, and you seem to know. I just like the current so much, orange and grey looks great. Jeffrey ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bi-weekly OpenMoko community update
On 10/14/07, Robin Paulson [EMAIL PROTECTED] wrote: On 15/10/2007, Pranav Desai [EMAIL PROTECTED] wrote: Absolutely agrree. GPS was one of my main points for buying the phone. I dont really care about the source for the driver as long as I can get the co-ordinates. hmm. this an open phone with open hardware and (where legal) open drivers. not having the source code to something would defeat the whole purpose of what sean et al are doing, and not attract any of the community that's here - the neo would be just another smartphone/pda and we'd be back to square one. so no, we do want and require the source code to everything Even I would love to get the source, but if not getting the src is causing the device to be non-functional, then I would prefer to get it without the source as long as I can get the device to work, since I have paid for it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- -- http://pd.dnsalias.org ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Usability team?
Sorry for the slow reply, it's been a long week. As I stated in my previous email, I'm currently in university and am taking some courses in HCI. I'm interested in this as well and will join the openmoko-apps mailing list. Thanks, Justin On 10/12/07, Jeremy G [EMAIL PROTECTED] wrote: I could also be interested in this. I'm finishing up a master's degree in Information Science with a focus in Information Architecture and HCI, so I have a lot of interest in OpenMoko usability. Jeremy On 10/12/07, london cowgirl [EMAIL PROTECTED] wrote: Hi Justin Thomas I think the investment made into the UI is extremely important and valuable (well done, Thomas). Shall we put together a usability team so these user centered design efforts continue? I'm a usability expert and would love to get engaged on a mobile device project. We could do personas, interviews, usability tests, etc... Any takers? Carla White - Original Message From: Thomas Wood [EMAIL PROTECTED] To: List for OpenMoko community discussion community@lists.openmoko.org Sent: Tuesday, October 9, 2007 1:38:46 AM Subject: Re: Usability team? On Mon, 2007-10-08 at 23:31 -0700, Justin Wong wrote: Hello! I've been really interested in interface usability and design since I've been taking this HCI course at my university. I've been interested in and following OpenMoko development a little. I'd love to know if and how I can get involved with the OpenMoko project with respect to interface usability and design. Is there a specific team that does this sort of work? Hi Justin, The current (2007.2) GUI was designed at OpenedHand by myself and a few others. I wrote about some of the design decisions here: http://blogs.gnome.org/thos/2007/08/21/openmoko-20072/ If you have any specific questions though, please let me know. Regards, Thomas -- OpenedHand Ltd. Unit R Homesdale Business Center / 216-218 Homesdale Road / Bromley / BR1 2QZ / UKTel: +44 (0)20 8819 6559 Expert Open Source For Consumer Devices - http://o-hand.com/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. ___ 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: Some feedback from using the neo as a phone for a day
On 10/15/07, Kero van Gelder [EMAIL PROTECTED] wrote: - The dialer application has the hangup button on the top right of the screen when in a call. When you actually talk on the phone it's _really_ easy to touch that part of the screen with your face, which results in 3-4 accidental hangups per call. Oops. :-) - The status icons on the top tend to disappear once in a while. Sometimes a reboot gets them back. Sometimes it doesn't. But usually two or three reboots get them back. Very perplexing. :) I noticed that too. Maybe the panel applets process needs to run under a supervisor that will restart it? Nah, they (or one of them, since I think it's one application) should simply not crash. Supervisors add complexity that I do not desire. Yes, not crashing would be good. :) Can I restart the status app(s) from the command if it crashes? Igor ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some ideas for the accelerometer
The GPS should help with that... On 10/15/07, Kero van Gelder [EMAIL PROTECTED] wrote: But not while walking... Differentiating between motions and situations will be a big challenge. Once my Neo knows how I walk, it can detect that I am walking and subtract the walking pattern from the accelero data. Remaining data contains noise from walking (hopefully noisy enough to go undetected) and other signals (including signals with lower amplitude than the walking pattern). Should be workable, though there may be funny effects when I start or stop walking :) Bye, Kero. ___ 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: [Data Calls] over [Wifi Mesh network]
They're not available to anyone yet. -Steven On 10/15/07, Francesco Pistillo [EMAIL PROTECTED] wrote: In my work group we need two phones GTA02v3. They say in the wiki that it can be available in october to qualified developers. How is the way to be classified qualified developers? Who to ask for? Francesco Pistillo Computer science department Bari University Italy ___ 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: interface design suggestions
On Mon, 15 Oct 2007 12:19:57 -0500, Jeffrey Thomas [EMAIL PROTECTED] wrote: To be honest, I understand the concepts of better contrast etc, but the proposed interface is very blockish and not nearly as nice looking as the fades and the use of Orange in the current. I do understand that it is a quick mockup, and that I myself have had no suggestions (nor do I claim to know about usability), but I really like the current look quite a bit more than the proposed. I dislike the white fields in the proposed, and the large number of colours; there is much to like in the current: the circular keys, the rounded edges everywhere, the slight boarders to the various frames and fields, all make for a nicer looking interface (IMHO). At the resolution the phone provides, I don't think that the phone should look like it has a lot less by removing these stylistic details. Again, I am just one person with the desire to help influence this great project, and the overall goal is to make a great phone. I appreciate the work of all in this endever, as I really am only a buystander. The usability team will really know best, and I am hoping it is all themeable anyway. Dani, you've put more thought into this than I, and you seem to know. I just like the current so much, orange and grey looks great. Hi Jeffrey, all valid points, but I personally can't stand the orange and grey theme. the basic design is fine (curved buttons, etc), but the colors should be _easily_ skinnable without having to entirely rewrite a theme. Ideally, just set somewhere in a preferences file, like ~/.openmoko This should not reflect a philosophy of all of these things are orange and so they are all equivalent, but rather a functional characterization of the UI element and association with base color. For gradients where a color shift is used for shadow/highlight, ideally this would be calculated from base color, although allowing the specification of multiple colors to form the gradient is an acceptable (if slightly more cumbersome) alternative. I know Thomas was doing work on converting away from a pixmap-based theme, so this flexibility should be possible, the gradients just weren't quite as pretty using GD. Of course, if run-time customization is not possible, then a multitude of nearly identical skins will spring up - workable, but less than ideal. Regards, joshua ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Data Calls] over [Wifi Mesh network]
On Mon, 15 Oct 2007 12:57:55 -0500, Steven ** [EMAIL PROTECTED] wrote: They're not available to anyone yet. -Steven I don't believe that is entirely true, given that they are on the third revision of GTA02 and I believe Thomas Wood has posted about working on both a GTA01 and a GTA02. now, 'anyone' may be a _very_ small group of select people, but I think some people have access to it. rgds, j. On 10/15/07, Francesco Pistillo [EMAIL PROTECTED] wrote: In my work group we need two phones GTA02v3. They say in the wiki that it can be available in october to qualified developers. How is the way to be classified qualified developers? Who to ask for? Francesco Pistillo Computer science department Bari University Italy ___ 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: [Data Calls] over [Wifi Mesh network]
Hi Francesco, 1. OpenMoko never intends to qualify developers - anyone is welcome to participate. If you find a place on the wiki or website or anywhere else that mentions qualification, please let me know and I will fix it. 2. GTA02V3 was a fabrication prototype. We produced an extremely small quantity to verify things like layout, manufacturing process, and chip selection, and in order to further driver development. These were distributed to an extremely small number of engineers in order to make this evaluation, and are not available. We expect GTA02 to be ready by year's end. I presume from your subject that you want to use Wifi. If you want to get started before the end of the year, can your group start with GTA01 and and use Bluetooth as a temporary solution? 3. For questions and requests of this sort I'm a good place to start. Michael Shiloh Francesco Pistillo wrote: In my work group we need two phones GTA02v3. They say in the wiki that it can be available in october to qualified developers. How is the way to be classified qualified developers? Who to ask for? Francesco Pistillo Computer science department Bari University Italy ___ 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
Server Downtime 2007/10/25
Hello Community, there is a USV (power system) related downtime planed at our hosting location in Nuernberg Germany. It is scheduled for: * 25th of October - 4:30AM MET. Two of our OpenVZ Hosts are concerned so there is a whole bunch of VMs/services that will be unavailable for about 2 hours. DS 7000 #20192 (88.198.58.17) - bhavani.openmoko.org VZs: * projects.openmoko.org 88.198.93.218 * gforge * shakti.openmoko.org 88.198.93.219 * downloads.openmoko.org * varaha.openmoko.org 88.198.93.220 * openmoko * buildhosttest (bitbake) 88.198.93.221 * catursana.mc.fic.com.tw 88.198.93.222 DS 9000 #20715 (88.198.62.104) - mahavidya.openmoko.org secondary IPs: 88.198.84.234 88.198.84.235 Services: * buildhost-new * www.openmoko.com I will be online after the systems recover. So tell me if you notice anything over the IRC Channel or by mail. gismo signature.asc Description: OpenPGP digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: interface design suggestions
I really like the mockup by Dani, I don't think the colours/blockish look are important as these can be changed by a theme engine but the use of screen space is excellent. The mockup is far more readable and the extra borders in the current theme are a waste of screen space. I think these concepts should be incorporated into the current OpenMoko release. Cheers, Tim On 10/16/07, Joshua Layne [EMAIL PROTECTED] wrote: On Mon, 15 Oct 2007 12:19:57 -0500, Jeffrey Thomas [EMAIL PROTECTED] wrote: To be honest, I understand the concepts of better contrast etc, but the proposed interface is very blockish and not nearly as nice looking as the fades and the use of Orange in the current. I do understand that it is a quick mockup, and that I myself have had no suggestions (nor do I claim to know about usability), but I really like the current look quite a bit more than the proposed. I dislike the white fields in the proposed, and the large number of colours; there is much to like in the current: the circular keys, the rounded edges everywhere, the slight boarders to the various frames and fields, all make for a nicer looking interface (IMHO). At the resolution the phone provides, I don't think that the phone should look like it has a lot less by removing these stylistic details. Again, I am just one person with the desire to help influence this great project, and the overall goal is to make a great phone. I appreciate the work of all in this endever, as I really am only a buystander. The usability team will really know best, and I am hoping it is all themeable anyway. Dani, you've put more thought into this than I, and you seem to know. I just like the current so much, orange and grey looks great. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
