On 16.05.2011 23:22, Neil Jerram wrote: > I'm afraid I don't understand. Why not just have SHR as your > reference set of applications? If you don't think they are using the > FSO APIs in the pattern that you would recommend, presumably you could > work with them to correct that? Or, if they are missing applications > or features to showcase some of the latest FSO API features, > presumably you could help them to add those?
SHR is a great thing, but it's too complex to be the first showcase for new features. The main problem we have is time and man-power. We are currentl two people doing most of the FSO work. With two people it's even hard to get only the basics done. SHR is based on the traditional design pattern of a window mananger which runs some application you can work with. The work to integrate new features like network (wireless, gprs, bluetooth pan) in a usable we needs a lot of work (you need a new E Gadget, you need a application to choose the network, you to adjust shr-settings, ...) to do. I worked for now 2 two to get SHR running on the Palm Pre and it's so much work that I will never finish it on my own. You invest a lot of time to debug things, see how things work and never get your work finished in a reasonable time frame. >> At the top of every application stack is the user. Pleasing him or her >> is the topmost priority. > > Speaking as a user, I would be pleased not to see more unnecessary > fragmentation of front-end efforts; also for the FSO2 middleware to be > rock-solid, with things fixed like RequestResource('bluetooth') > starting bluetoothd. Aurora is not about fragmentation. Zhone was already there before SHR and Aurora will continue Zhone. We will take aurora as our new reference application as it is quite simple and let us integrate new features very fast. > To be fair, it may be that FSO2 already is rock-solid now. I haven't > reviewed the situation recently, but I can't immediately think of any > known and clear issues, about from the bluetoothd one. But in that > case I'd still prefer focus on the SHR front end, over some new UI. As you may know we are working hand-in-hand with all the SHR developers and we are loving SHR too. But at some point we need to concentrate us on FSO and FSO as framework only to be successfull in the future and not only on the Openmoko devices. There are a lot of devices out which are suitable to be driven by FSO but needs time to be integrated into the framework. If we do everytime to full work for SHR and FSO we will never do anything else with this phones in their lifetime. If you work for a long time very hard on such a project you want to see something working and usable to have. But currently with doing the doubled work for SHR and FSO does not let us come the this point. > If you strongly favour Qt, you could take QtMoko as your reference set > of applications. That would be especially helpful right now, as Radek > is just looking at converting QtMoko to use FSO. With QtMoko it's the same as I said above. We need some simple stupid thing we can change within an hour to support a new feature like network management. We cannot archive this with QtMoko or SHR. > I'm almost lost for words here. Starting from scratch seems so > obviously the wrong thing to do, when there are mature projects that > you could contribute to... We are not starting from scratch with a completely new platform. We are just reordering the reponsibility of the FreeSmartphone team which is to develop the middleware and concentrate of integrating new devices and get new features like network management in. > I must be misunderstanding what you mean - please do explain more! Don't thing about aurora as something big, it's a very simple thing for simple needs. You will see all new features even in SHR, but not done by the core FSO team. regards, morphis _______________________________________________ Openmoko community mailing list email@example.com http://lists.openmoko.org/mailman/listinfo/community