Thomas Zimmermann wrote: > Am Freitag 17 September 2010, 12:27:48 schrieb Arigead: >> At present all the core phone apps are in one repo and in one bitbake >> recipe. It'd be nice, from my point of view, if these could be separated >> into different repos and recipes so that each app was more stand alone. > > In reallity there is just one app with different user interfaces. This app > is: > phoneuid > > The phoneui-apps don't really do anything they just say phoneuid that it has > to show a specific view. > > The advantage of this ist, that phoneuid can share the contactlist, > messagelist, and so on among the different views. That's not possible if one > uses distinct apps. But it's need to speed up the phone apps, as opimd is > slow > ;)
OK All thanks for a very informative discussion. I'm feeling a bit more educated. OK so speed is an issue and we're using "Dirty tricks" to circumvent the problems with speed. I'm not sure I'd agree with the solution in the ideal world but we're stuck with this one. So opimd is slow is there any chance that this could be speeded up. At the risk of revealing my naivety is it not a sort of a Database thingy. I'm not sure I agree with the comment that phoneuid can share contactlist and messagelist etc. with various views. Ideally opimd should enable all info to be shared between all the apps. opimd is the base layer that feeds info to anything that needs and perhaps has access to that info. Fundamentally this arch seems to boil down to limitations in opimd. Is speeding that up a possibility, without wanting to offend opimd, I'd be lost without it? I started looking at mokosuite2 just out of curiosity and I really like the desktop and the GUI's. It is having issues with connecting to the GSM network on my FR but apart from all that does it replace the one layer of the libphone-ui-shr stack or a few of them. Now that I've gotten the answers to many of my questions I should go back to looking at the code with what I've learned. _______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
