Back to the basics: improving user experience

[Xavier Bestel]

On Thu, 2008-10-16 at 15:47 +0800, John Lee wrote:

> Hi,
>
> Like Wolfgang said in
> http://n2.nabble.com/Weekly-Engineering-News-41-2008-td1336450.html
>
> We assembled a team to focus on improving the user experience.  Here
> is our todo list at the moment:
>
> * Reduce boot time.
>
> * Optimize the touch screen driver on freerunner for finger usage.
>
> * A generic python loader to enhance the start up time of python
>   scripts.
>
> * Work with system team to improve suspend/resume user experience.
>
>
> I would like to ask the community:
>
> What do you want us to work on?

Definately a working WiFi driver (the current one is half-working only,
just have a look at opened bug reports).

Generally more working low-level stuff.

Thanks,
        Xav



_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[dant]

I was wondering about one thing:
When we talk about FR as phone every one wants it to by light speed fast (instant calls, sms and so one), but when you think about FR as ultramobile PC capable of playing games, movies and so one our response time expectations are much lower. So maybe we could make one big(ger) app (remember that there is quite big amount of ram there) responsible for calling, contacts, sms and all that phonny stuff and keep it all the time in memory with all needed library (static build?) and maybe even higher priority - result: no loading, no waiting = instant phone functionality. you want to play some games? sorry you have to wait (which is acceptable).

ps. this approach could also apply to some basic settings.

[joakim]

"Neil Jerram" <[hidden email]>
writes:

> 2008/10/16  <[hidden email]>:
>>
>> Here are my desired clients I want to develop:
>> - Emacs phone services on top of dbus
>
> Hey, me too!  Can we share / help each other out?

Cool! Clearly we should work together.
Here are some ideas of mine:
- get emacs23 working, so one can use the dbus support of emacs 23.
- make a dialer compatible with bbdb, and later addressbook.el
- make a gnus backend for sms
- a symbol chooser keyboard, much like you hinted at below.
  Heres my take on the idea:
  - start the "keyboard"(an emacs app) in a particular context(lets say
  m-x now, but its the same for adresses or whatever)
  - (1) show all unique prefixes in this context
  - (2) choose a prefix
  - (3) repeat from (1) with the chosen prefix, exit on a terminal symbol

I really think Emacs could be a superiour telephone application plattform!
 

>
> That said, all I have so far is an attempt at an Emacs soft keyboard
> (attached).  It's very clunky and basic right now, but I think there
> are lots of possibilities down this road, such as "predictive"
> keyboards (like the Qtopia one), keyboards that are optimized for
> specific applications, etc.
>
> Regards,
>        Neil
>
> _______________________________________________
> Openmoko community mailing list
> [hidden email]
> http://lists.openmoko.org/mailman/listinfo/community

--
Joakim Verona


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[William Kenworthy]

Cant agree with this.  They are bugs, but none are urgent issues and few
affect a users basic needs - to be able to make phone calls and SMS's

This is where OM lost the plot - it looks pretty, but doesnt work.

Standing joke where I work (there are two of us neo owners - the other
was thinking of selling though) "Whats the difference between an iphone
and a neo - one looks pretty and works, one looks pretty and doesnt
work ..."

qtopia is what people are using NOW, and will for many months yet as far
as I can see. There seem to be only a few issues with its basic
functionality- fix them so its at least usable - please!

BillK



On Thu, 2008-10-16 at 04:49 -0700, Alasal wrote:

> I agree, we don't have to spend developer time on things that are going away.
> (So please don't fix qtopia)
>
> And here are the bugs that should be solved (My opinion):
>
> LANSCAPE
> http://docs.openmoko.org/trac/ticket/1244: Landscape mode must work good,
> also for glamo
> http://docs.openmoko.org/trac/ticket/1961: Going into landscape mode must be
> smooth
> http://docs.openmoko.org/trac/ticket/1336: Landscape mode shouldn't shift
> the screen by 160px
> http://docs.openmoko.org/trac/ticket/1381: Let libsdl spit out the correct
> mouse coordinations
>
> WIFI
> http://docs.openmoko.org/trac/ticket/1860: Give the wifi driver more love
> http://docs.openmoko.org/trac/ticket/1902: Make the wifi work with
> one-character long ESSID
> http://docs.openmoko.org/trac/ticket/2030: Let the wifi also connect with
> WEP networks
>
> VARIA
> http://docs.openmoko.org/trac/ticket/1158: Charger shouldn't stop charging
> when it's still connected
> http://docs.openmoko.org/trac/ticket/1024: Fix the gsm reregistering issue.
> (Only if it's not qtopia related)
> http://docs.openmoko.org/trac/ticket/1718: Finally fix the python-pygtk
> program
> http://docs.openmoko.org/trac/ticket/1267: Fix the echo problem
> http://docs.openmoko.org/trac/ticket/1802: Don't let the partition table of
> the sd card be corrupted
> http://docs.openmoko.org/trac/ticket/1597: Don't let cpu do nothing and
> still eating 30%
> http://docs.openmoko.org/trac/ticket/1315: Keep xglamo at the same
> performance
> http://docs.openmoko.org/trac/ticket/1841: Solve the WSOD, so openmoko isn't
> the next windows
>
>
>
> Neil Jerram wrote:
> >
> > I agree that you should not spend time on Qtopia.  Even though I use
> > Qtopia most of the time, I would prefer you to focus all your efforts
> > on the lower levels (up to and including the FSO dbus interfaces)
> > until they are rock solid.
> >
> >        Neil
> >
> >
>

--
William Kenworthy <[hidden email]>
Home in Perth!


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[William Kenworthy]

Nope, thats a furphy - made the alterations, two boots so far and no pin
dialog ...

Took the SD card out and the pin popped up - twice

Put the SD card back in and no PIN dialog.

I have an 8G card as 2 partitions.  On p1 I have a single file while on
p2 I have tangogps maps - but p2 isnt indexed as far as I can see, so
they should not affect it and qpe doesnt show as being busy in task
list.  The alterations suggested below had been done.

Could it be an issue related to SD cards rather than QPE?

BillK




On Thu, 2008-10-16 at 11:39 +0100, Vasco Névoa wrote:

> An important note to the people who are experiencing all-round instability:
> I haven't had many problems with phone calls or SMS. I believe the  
> critical point was to disable QPE's file search upon bootup [1].
> Before I did that, I had all kinds of mysterious problems (including  
> PIN), derived from the fact that the Neo's CPU was starving for  
> cycles. To make matters worse, it would suspend before the indexing  
> job was done, and so the Neo would not have enough CPU power to  
> correctly process incoming calls and messages when it resumed. After  
> disabling that QPE stuff, it basically works.
> [1]: http://n2.nabble.com/No-pin-dialog--qpe-tp685679p685679.html
>
> Citando John Lee <[hidden email]>:

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Didier Raboud]

Vasco Névoa wrote:

>
> I agree with you partly; the main efforts should go into getting the
> new framework out - *as long as it runs on a rock-solid core system*.
> So I support the idea of accelerating the FSO integration... but in
> the meantime people have to use the sucking Qtopia ware in their
> everyday life, because there is no realistic alternative. FSO is still
> very incomplete at the user level.
>
> Today, the "complete" system is not reliable and the reliable system
> is not complete at all.
>
> If you fix the core and qtopia now, everybody gets a working phone,
> and FSO gets a more reliable development core. You favor the users,
> which are the noisier people. ;)
> If you jump start FSO into main distro, there will still not exist a
> complete system that can be used everyday. You favor the developers,
> who could wait a little more (but not long!) and ARE ALSO USERS.
>
> So please just make it work solidly, and then integrate FSO. :)

Well... I would rather let a bit more freedom to the team :

if you (as in "the team which will make the iFoan obsolete") think that
breaking useability or functionality or anything else could serve the
cause : do it !

Please decide your roadmap and make it public !

I (personnally) don't care if I am not able to use my Neo as a phone (and
anything else possible) for 2-3-4-5 months : I have a working phone. BUT,
what I would like to know is _when_  I will get _what_ functionality.

I you think that breaking the whole stuff for a moment will serve a precise
goal, please do it !

Regards,

OdyX
--
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[David Samblas-3]

El jue, 16-10-2008 a las 15:47 +0800, John Lee escribió:
> Hi,
>
> Like Wolfgang said in
> http://n2.nabble.com/Weekly-Engineering-News-41-2008-td1336450.html
>
> We assembled a team to focus on improving the user experience.  Here
> is our todo list at the moment:
>
> * Reduce boot time.
ok
>
> * Optimize the touch screen driver on freerunner for finger usage.
>
for me is quite good right now but any improvement are welcome
> * A generic python loader to enhance the start up time of python
>   scripts.
YES PLEASE :) this will allow script kiddies like me to help in high
level development and utilities on the phone
>
> * Work with system team to improve suspend/resume user experience.
yes,

>
>
> I would like to ask the community:
>
> What do you want us to work on?
>
>
> The idea is
>
> * We improve the current stack, not creating new features.

ok, there a lot of thirparty apps out there than can provide new
features, but they need a rock solid base to be totally cool
>
> * Prefer stuffs which could be brought over to gta03 instead of
>   gta02/om2008 specific.
Not totally agree here, some(a lot of) effort must be done in current
specific gta02 , a clear example is the "famous" glamo chipset, you are
the only ones who can improve it due NDA as some one else has pointed,
you must struggle(even more) this chipset to extract until the last drop
of it juice.  
>
> * won't work on om2007 stack.
Better make efforts on FSO
>
>
> So, tell us what you want, then the coding monkeys will start working!
> :)
just work on the basics as you have pointed, and the basic is all
hardware must work without any blocking bug(alas stability) and inside
this stability do it as fast as phisicaly posible.
Fancy apps will come from the community and porting from other distros,
thats the magic on free source :)
>
>
> Regards,
> John
>
> _______________________________________________
> Openmoko community mailing list
> [hidden email]
> http://lists.openmoko.org/mailman/listinfo/community


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Al Iasid]

As a user that switches between Debian, Qtopia, and om2008, I urge you to focus on improving areas that could benefit all "distributions".  I don't understand the technical dependencies, but I get the impression that Lorn and the Debian folks rely on some form of Openmoko development. Just as an example, suspend/resume continues to be a problem for me across all three distros. Also, the point someone made about working on stuff that's restricted under NDA seems valid.

Thank you for your continued work It is appreciated,

Aliasid

On Thu, Oct 16, 2008 at 3:47 AM, John Lee <[hidden email]> wrote:

Hi,

Like Wolfgang said in
http://n2.nabble.com/Weekly-Engineering-News-41-2008-td1336450.html

We assembled a team to focus on improving the user experience.  Here
is our todo list at the moment:

* Reduce boot time.

* Optimize the touch screen driver on freerunner for finger usage.

* A generic python loader to enhance the start up time of python
 scripts.

* Work with system team to improve suspend/resume user experience.


I would like to ask the community:

What do you want us to work on?


The idea is

* We improve the current stack, not creating new features.

* Prefer stuffs which could be brought over to gta03 instead of
 gta02/om2008 specific.

* won't work on om2007 stack.


So, tell us what you want, then the coding monkeys will start working!
:)


Regards,
John

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Vasco Névoa]

I can see there are at least 2 distinct types of user of OM:
A - "I need a working phone now, the uber-cool PDA stuff can wait";
B - "OM is a groundbreaking project, I don't care about telephony,  
let's press the revolution!"
As much as I am divided among the two views, I think OM must oblige to  
its responsibility towards the users who have paid for their hardware,  
and keep its promise of a working phone.

I don't think that making the core system work (including a little  
hacking of the Qtopia stuff) is a waste of time; any insight that is  
gained here can immediately be applied to FSO. OM2008.x will simply  
serve as a real-world testbed (one that is everyday usable!). When FSO  
comes along, it will already have the necessary corrections...


Citando Didier Raboud <[hidden email]>:

> Vasco Névoa wrote:
>
>>
>> I agree with you partly; the main efforts should go into getting the
>> new framework out - *as long as it runs on a rock-solid core system*.
>> So I support the idea of accelerating the FSO integration... but in
>> the meantime people have to use the sucking Qtopia ware in their
>> everyday life, because there is no realistic alternative. FSO is still
>> very incomplete at the user level.
>>
>> Today, the "complete" system is not reliable and the reliable system
>> is not complete at all.
>>
>> If you fix the core and qtopia now, everybody gets a working phone,
>> and FSO gets a more reliable development core. You favor the users,
>> which are the noisier people. ;)
>> If you jump start FSO into main distro, there will still not exist a
>> complete system that can be used everyday. You favor the developers,
>> who could wait a little more (but not long!) and ARE ALSO USERS.
>>
>> So please just make it work solidly, and then integrate FSO. :)
>
> Well... I would rather let a bit more freedom to the team :
>
> if you (as in "the team which will make the iFoan obsolete") think that
> breaking useability or functionality or anything else could serve the
> cause : do it !
>
> Please decide your roadmap and make it public !
>
> I (personnally) don't care if I am not able to use my Neo as a phone (and
> anything else possible) for 2-3-4-5 months : I have a working phone. BUT,
> what I would like to know is _when_  I will get _what_ functionality.
>
> I you think that breaking the whole stuff for a moment will serve a precise
> goal, please do it !
>
> Regards,
>
> OdyX
> --
> Swisslinux.org - Le carrefour GNU/Linux en Suisse -
> http://www.swisslinux.org
>
>
> _______________________________________________
> Openmoko community mailing list
> [hidden email]
> http://lists.openmoko.org/mailman/listinfo/community
>

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Paul-8]

Vasco Névoa wrote:
> I can see there are at least 2 distinct types of user of OM:
> A - "I need a working phone now, the uber-cool PDA stuff can wait";
> B - "OM is a groundbreaking project, I don't care about telephony,  
> let's press the revolution!"
> As much as I am divided among the two views, I think OM must oblige to  
> its responsibility towards the users who have paid for their hardware,  
> and keep its promise of a working phone.
>  

I agree. Having a solid functional phone is the prime objective.
Paul

--
My advice to you is not to inquire why or whither but just
enjoy your ice cream while it's on your plate - that's my philosophy.
-Thornton Wilder (from The Skin of Our Teeth)

http://www.nlpagan.net
Running on Mandriva Linux 2008 and Ubuntu 8.04


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[SCarlson]

  I would love to see the rotation/scaling bugs finished up Bug #1244. It has evolved as far as symptoms,
both scaling to low res 320x240 and rotation yield incorrect x,y coordinates. (Although going through tslib directly works fine, showing that it is glamo issue)

Would be nice to have this year + issue laid to rest, that would open the doors to some of our game developers and add to the overall functionality of the gui interfaces being created.

There have been two patches made available, one that fixes rotation and one that independantly fixes scaling, but I havnt seen an overall solution, or at least havn't seen the solution show up in the repo.

Scott

John Lee wrote:

Hi,

Like Wolfgang said in
http://n2.nabble.com/Weekly-Engineering-News-41-2008-td1336450.html

We assembled a team to focus on improving the user experience.  Here
is our todo list at the moment:

* Reduce boot time.

* Optimize the touch screen driver on freerunner for finger usage.

* A generic python loader to enhance the start up time of python
  scripts.

* Work with system team to improve suspend/resume user experience.


I would like to ask the community:

What do you want us to work on?


The idea is

* We improve the current stack, not creating new features.

* Prefer stuffs which could be brought over to gta03 instead of
  gta02/om2008 specific.

* won't work on om2007 stack.


So, tell us what you want, then the coding monkeys will start working!
:)


Regards,
John

_______________________________________________
Openmoko community mailing list
[e-mail]
http://lists.openmoko.org/mailman/listinfo/community

[Jason Cawood]

I agree to this point.  I would rather wait a few months to have a rock
solid core functioning device than one that works now with something that
isn't going to be used long term.

<quote who="Didier Raboud">

> Vasco Névoa wrote:
>
>>
>> I agree with you partly; the main efforts should go into getting the
>> new framework out - *as long as it runs on a rock-solid core system*.
>> So I support the idea of accelerating the FSO integration... but in
>> the meantime people have to use the sucking Qtopia ware in their
>> everyday life, because there is no realistic alternative. FSO is still
>> very incomplete at the user level.
>>
>> Today, the "complete" system is not reliable and the reliable system
>> is not complete at all.
>>
>> If you fix the core and qtopia now, everybody gets a working phone,
>> and FSO gets a more reliable development core. You favor the users,
>> which are the noisier people. ;)
>> If you jump start FSO into main distro, there will still not exist a
>> complete system that can be used everyday. You favor the developers,
>> who could wait a little more (but not long!) and ARE ALSO USERS.
>>
>> So please just make it work solidly, and then integrate FSO. :)
>
> Well... I would rather let a bit more freedom to the team :
>
> if you (as in "the team which will make the iFoan obsolete") think that
> breaking useability or functionality or anything else could serve the
> cause : do it !
>
> Please decide your roadmap and make it public !
>
> I (personnally) don't care if I am not able to use my Neo as a phone (and
> anything else possible) for 2-3-4-5 months : I have a working phone. BUT,
> what I would like to know is _when_  I will get _what_ functionality.
>
> I you think that breaking the whole stuff for a moment will serve a
> precise
> goal, please do it !
>
> Regards,
>
> OdyX
> --
> Swisslinux.org − Le carrefour GNU/Linux en Suisse −
> http://www.swisslinux.org
>
>
>
>

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Christian Weßel]

Am Donnerstag, den 16.10.2008, 18:20 +0200 schrieb Paul:

> Vasco Névoa wrote:
> > I can see there are at least 2 distinct types of user of OM:
> > A - "I need a working phone now, the uber-cool PDA stuff can wait";
> > B - "OM is a groundbreaking project, I don't care about telephony,  
> > let's press the revolution!"
> > As much as I am divided among the two views, I think OM must oblige to  
> > its responsibility towards the users who have paid for their hardware,  
> > and keep its promise of a working phone.
> >  
>
> I agree. Having a solid functional phone is the prime objective.
> Paul
>

I agree too. With high priority the phone/sms functinality should fixed

and maybe enhanced and afterwards the PC functions could be performed.

But the terminal appl. should be availible all time, because FR is still
a computer with a GSM module and sometimes I need the terminal to
check/fix/calibrate the phone/PC.
--

mfg/br, christian

Flurstraße 14
29640 Schneverdingen
Germany

E-Mail: [hidden email]
Telefon: [phone]
Mobile:  [phone]
http://wesselch.homelinux.org


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Sebastian Billaudelle]

Some javascript/style in this post has been disabled (why?)

Am Donnerstag, den 16.10.2008, 10:13 -0700 schrieb SCarlson:

  I would love to see the rotation/scaling bugs finished up Bug #1244. It
has evolved as far as symptoms,
both scaling to low res 320x240 and rotation yield incorrect x,y
coordinates. (Although going through tslib directly works fine, showing that
it is glamo issue)

Would be nice to have this year + issue laid to rest, that would open the
doors to some of our game developers and add to the overall functionality of
the gui interfaces being created.

There have been two patches made available, one that fixes rotation and one
that independantly fixes scaling, but I havnt seen an overall solution, or
at least havn't seen the solution show up in the repo.

Scott


John Lee wrote:
> 
> Hi,
> 
> Like Wolfgang said in
> http://n2.nabble.com/Weekly-Engineering-News-41-2008-td1336450.html
> 
> We assembled a team to focus on improving the user experience.  Here
> is our todo list at the moment:
> 
> * Reduce boot time.
> 
> * Optimize the touch screen driver on freerunner for finger usage.
> 
> * A generic python loader to enhance the start up time of python
>   scripts.
> 
> * Work with system team to improve suspend/resume user experience.
> 
> 
> I would like to ask the community:
> 
> What do you want us to work on?
> 
> 
> The idea is
> 
> * We improve the current stack, not creating new features.
> 
> * Prefer stuffs which could be brought over to gta03 instead of
>   gta02/om2008 specific.
> 
> * won't work on om2007 stack.
> 
> 
> So, tell us what you want, then the coding monkeys will start working!
> :)
> 
> 
> Regards,
> John
> 
> _______________________________________________
> Openmoko community mailing list
> [hidden email]
> http://lists.openmoko.org/mailman/listinfo/community
> 
> 

+1

I think this will help us to improve (X) performance for every image...

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Stefan Monnier]

> Suspend is quite good at the moment, but when the display is 'blanked'
> and the system is not in suspend, maybe pressing the 'power' button
> could wake up the screen instead. Now it wakes up and immediately
> suspends.

100% agreement.  The "suspend on power button" is completely useless
for me.  The machine suspends automatically anyway, so I don't need to
waste the precious few buttons we have on rare operations like
"explicitly request the machine to go to sleep".

It would have been good to put more buttons on the FR, but at the very
least we should make better use of the 2 we have.


        Stefan


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Boris Wong]

On Thu, 2008-10-16 at 16:58 +0100, Vasco Névoa wrote:
> I can see there are at least 2 distinct types of user of OM:
> A - "I need a working phone now, the uber-cool PDA stuff can wait";
> B - "OM is a groundbreaking project, I don't care about telephony,  
> let's press the revolution!"
> As much as I am divided among the two views, I think OM must oblige to  
> its responsibility towards the users who have paid for their hardware,  
> and keep its promise of a working phone.

There has been a lot of talk about a working phone, and I agree
(mostly). When I bought the FR I used it to replace my old phone
(non-PDA style regular flip phone). Other than just telephony services,
I found the Calendar/Alarm service very important. Currently accessing
the clock and accessing the alarm is difficult, not to mention there is
only one alarm time slot per day. I couldn't say much about the
stability, I have two other alarm clocks next to it to wake up, although
neither of those are stable either (I use a Cowon A3 player... DO NOT
use it to wake you up.. it won't go off half the time). Apart from this
digression, I would just like to say that a regular phone is expected to
have extensible utilities such as stable SMS, calendars, contacts, and
alarm clocks.
In my opinion, it's not just a phone. It's a day-planner.

-Boris


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Ben Hussey-2]

> Citando John Lee <[hidden email]>:
>> What do you want us to work on?
>>
>
> Prioritized:
> 1 - Solve the call quality problems (echo, buzzing, volume) for 99% of  
> the users.
> 2 - Solve the illume resume problems. They have been talked about over  
> and over, but unfortunately the information is scattered and  
> imprecise. the tickets themselves have misleading info (I should know,  
> I helped confuse you...), so maybe this deserves a new single ticket,  
> where everyone contributes with more exact information;
> 3 - Get the wifi driver corrected, so that it does not create link  
> association and stability and problems;
> 4 - Finish/validate implementation of the networking stack (all the  
> way up to resolv.conf and friends);
> 5 - Merge the GPRS muxer into the stable distro, so that it works out  
> of the box;
> 6 - Integrate the main applications with the power management: if QPE  
> wants to index the whole friggin' filesystem right after boot, then  
> give it time to do so before going into suspend; if you don't, it just  
> bogs down the CPU for many suspend/resume cycles, creating all sorts  
> of problems, and we don't know what is going on...
> 7 - Accelerate Qt applications - they respond so slowly that a normal  
> user will shoot itself in the foot everyday (i.e. pushing the "Answer"  
> button twice because it didn't appear to respond, effectively killing  
> the call; or taking the phone to the ear after pushing "Answer" and  
> having it rind loudly one last time in the ear);
> 8 - Work with the people of FDOM to integrate the best workarounds and  
> hacks - they did the work already, just use it.
> 9 - Get all the bluetooth support organized out-of-the-box. I haven't  
> played with it in a long time, but it looked like black voodoo to get  
> a simple pairing and OBEX exchange going... forget about PAN!...
> 10 - Put a "speaker" button on the dialer app. This is my only GUI  
> desire for now...
>
> Vasco.

Yes to the call quality(#1)!  Please fix this, I hate talking to people
on my Freerunner since they can't hear me well, and I can't hear them.
I used a friends phone the other day and was blown away by how good the
people on the other end sounded....This should be a non-issue.

I wholly agree with this list, in this order. +10!

-Ben


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Leonti]

       Personally I would like to see stopping development of ASU and 2007 stack and concentrate on FSO and developing some standards.
The reason for this is that so much time and effort are spent on something that we won't use in the future. If the official distro is going to be based on FSO, than a lot of work will be just thrown away. Example - suspend/resume issue - some people work to get it done on ASU, spending time, and some are working on the same problem on FSO. Than, when FSO will be merged with the main distro - we won't need suspend thing from ASU - a lot of time and effort for nothing. It's just an example.
      About standards - FSO is good from this point. I can develop for it using different languages and it's awesome. But what about PIM stack? There is a project from GSOC, but it's either dead or just being developed really slow. What if some time OM is spending on ASU get to develop PIM stack for FSO? Or even make a 0.9 release of FSO even earlier as planned?

In short I would like to see:
1. Abandonment of ASU and 2007.
2. More effort fo FSO.
3. Some fixes for Qtopia (for people who needs working phone), instead of working on ASU.
4. Hardware - some fixes. Personally I have GSM re-registering problem. Some people have others. A lot of them are fixed, but it still needs some work.

Leonti

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[t m]

On Thu, Oct 16, 2008 at 10:15 AM, W.Kenworthy <[hidden email]> wrote:

2008.9 + updates

A phone that works:
       reliably make and receive calls
       reliably make and receive sms's

At the moment, totally losing sms messages (phone sometimes
hangs/crashes when one comes in) or not waking up if suspended  when one
comes in means that its almost unusable as a phone.

It often takes several boots before the pin dialog comes up. If you
forget while waiting and it does come up but its awhile until you get to
it, it will hang so you have to reboot anyway.  Sometimes restarting X
helps, but not always


Stability:
My average in normal usage is at least two boots a day due to crashes,
and often extra rebooting to check if an sms comes in (sometimes they
will only show on fresh re-registration.  Leaving the phone on and
registered for hours doesnt seem to help - not sure how vodafone
australia takes to retry messages but surely its less that 12 hours.
The only way to stop crashes is not to use the thing! No GPS, no
wireless, no phone calls, and definitely never send/receive an sms :)

I suspect the event/0 thread is at the root of a lot of this so I am
waiting a fix for that.

I dont think I am alone in this - hopefully the new focus means that
these issues can be dealt with.

I am a little concerned though that you think things like boot time is
important enough to mention, but not basic issues like being able to
reliably make a phone call.  Though a faster boot means less time wasted
going through multiple bootups to get the thing registered. :)

I should mention that 2007.2 seemed more stable and mature than 2008
anything still is up until work stopped on it.

BillK

Totally, totally agree!
Who cares a <beep>  about wifi , speed, gps, accelerometer, booting time when the phone itself doesn't work.

Please fix this issues first, use the precious developing time for these priorities , so whe can finally use the phone for daily use.
The fun and fancy stuff can come later.

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Marco Trevisan (Treviño)]

Leonti Bielski wrote:
> But what about PIM stack?
> There is a project from GSOC, but it's either dead or just being
> developed really slow. What if some time OM is spending on ASU get to
> develop PIM stack for FSO? Or even make a 0.9 release of FSO even
> earlier as planned?

This is what I'd like to write. But there's a think I'd like to remark
here too (I've already said on the devel list), imho we should move to a
PIM stack that is compatible with the Qtopia one not to break
compatibility and support for multi-boot also from an high level
application point of view.
That PIM stack is quite good and accessible with easy instruments
(practically all is done with a sqlite3 database, and the same can be
easily doable with new python stack too).

Imho this should be a key point. It's quite obvious that a good PIM
stack is vital for a portable device.

--
Treviño's World - Life and Linux
http://www.3v1n0.net/


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community