Hello, I think these all together will be fine. The only thing I have in my mind beside these is something I ever wanted to try but never did: redirecting sound (e.g. a sound file with pause melody or answerphone) to the call input. But just an idea, thanks! Kai
Am 21.07.2012 21:44, schrieb Thamos: > Hi all. > I've never seen someone using the conference-feature. I think selecting > the provider is more important. (this one really annoys me, since i am > near an border and simply can't phone until i get out auf alien range, > if the phone switched one time, even reboot doesn't help...). I also > miss the possibility to choose loudness of the ringtone reasonably. Most > other phones are even able to choose a ringtone based of the caller! > > Apart from that i comply with you. > > kind regards, > Thamos > > > > Am 21.07.2012 20:45, schrieb Simon Busch: >> Hey everybody, >> >> as a lot of you may have noticed we did two releases in the past months >> of the FSO stack. Both were related to bring stability and consistence >> to the stack. Now I want to talk with you about the future of the stack. >> In the past we were only concentrating on getting new hardware supported >> and lost our real focus on creating a middleware suitable for >> embedded/specific-purpose devices. This is where I want to go back to >> and get into development again. >> >> In the last weeks I looked over several parts we have in our stack and >> tried to find out where we can improve and get into development of new >> features again. A lot of you have stability in mind as you want to use >> something with FSO on your daily phone. Thats the second peace which >> should be part of the core development focus of the Freesmartphone.org >> middleware. >> >> Getting new features is fast said but I have several things on my list >> where I want to improve FSO in the next weeks and months. Everything is >> focused on the core stack which is formed by our framework libraries and >> the three daemons fsodeviced, fsogsmd and fsousaged. We have other >> daemons like fsotdld as well but that will be not on my focus. If >> someone wants to step up with further development of these just go on >> and get in contact. But please don't get me wrong: I will support all >> other daemons like fsoaudiod and fsotdld in the next releases too but >> just not doing any development related work for them. >> >> For fsogsmd there are the following things on my list: >> >> 1. Get the last peaces of not implemented things in like conference or >> emergency calls >> 2. Several API cleanups >> 3. Get several bugs fixed >> 4. Do integration testing with a remote controlled phonesim so we can >> simulate incoming calls etc. This will also included integration testing >> with a remote controlled fsogsmd on another device >> 5. Multi device support: While working in HFP HF support in fsogsmd I >> discovered that things would be easier if we can control more than one >> modem with the same daemon at the same time. Think about phone with >> support for more than one SIM card. Work has already started for this in >> the morphis/multi-device branch of the cornucopia repository. >> 6. Cleanup of the modem status handling: right now the modem status and >> SIM/network status are too much tight together. We have cleanly separate >> them. >> 7. Internally we don't separate a modem from a AT based modem; that >> needs to be fixed >> 8. A lock-down mechanism to keep anyone out when doing a firmware >> upgrade. When doing a firmware upgrade of a modem we have the problem >> that nobody should access the modem while this is in progress. The idea >> is now to implement a dbus API to lock the modem by requesting a lock >> and only the requesting program can unlock the modem again. While the >> modem is locked nobody else can access the modem via fsogsmd. >> >> fsousaged: >> - nothing right now >> >> fsodeviced: >> - nothing right now >> >> lib*: >> - I am thinking about grouping all libraries together so just have one >> single framework library and don't need to maintain several small >> libraries which increases the complexity of release testing, ABI >> refinements, etc. Just one libfsoframework; this is only a thought in my >> head right and nothing concrete. >> >> That are some of my toughs were I want to go with FSO in the next >> months. So no focus on concrete devices but getting the stack itself >> forward to be ready for every kind of a device. >> >> I would be really happy to hear what other people are thinking about the >> idea behind FSO since it was started back in 2008. What are your missing >> features? What do you like and what not? >> >> regards, >> Simon >> > > _______________________________________________ > 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