On Sun, Aug 22, 2010 at 10:03, Simon Busch <[email protected]> wrote: > Hm, I though already about this a while ago and I don't think it's the > right way to go. We don't have the pressure like companies named Google > or Apple to provide a API everybody likes to use. We are some small > projects working together to fullfill a dream of an open and free > smartphone. And part of this openeness and freedom is heterogeneity. So > you will have people wanting to write there application in GTK+, QT or E > (maybe some other unimportant tooltkits). Yes, we can provide a simple > API for creating unique looking applications but people should have the > freedom to decided which toolkit is right for them. For a first start we > could create a API for E and provide only this but our focus should be > more something like a general application handling and inter application > communication (see Android Intents). FOSS toolkits we have enough out > there, but no environment which handels applications in the right way. >
Sounds reasonable :-) I really miss those things in Freerunner development. That's what we should focus on, all the SHR guys too ;-) > My plan would be: Separate mokowm from the other code and implement > something like org.freesmartphone.Lifecycle, > org.freesmartphone.Launcher, org.freesmartphone.Application which do all > the application handling within the wm, so the wm knows when a new > application is started via org.freesmartphone.Launcher and can tell the > currently visible application via org.freesmartphone.Lifecycle to > suspend and resume when the other application gets closed. > > I already have written some notes on a sheet of paper. Will write them > down later when I have a little bit more time. > Mokowm is already a standalone app (doesn't even depend on libmokosuite as for now). But integrating those DBus interfaces into the WM would be a great thing :-) Just make public those writings you made, we will arrange something. > regards, > morphis > > thank you simon, -- daniele_athome _______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
