Forwarding message forgot by Simon ;-) ---------- Forwarded message ---------- From: Simon Busch <[email protected]> Date: Sun, Aug 22, 2010 at 10:03 Subject: Re: [Shr-Devel] [RECIPE] Mokosuite2/Mokowm IM To: Daniele Ricci <[email protected]>
Am 22.08.2010 09:33, schrieb Daniele Ricci: > On Sun, Aug 22, 2010 at 09:22, Simon Busch <[email protected]> wrote: >> That sounds interesting. What's your pimary goal in writing a new window >> manager especially for mobile devices? What are it's primary features? >> The opkg.org page does not tell me the details about this project. Do >> append you work on a already available window manager? Is it written in >> plain c with xlib/xcb or do you use ecore_x for handling all the X11 >> stuff? You are the only one working on this project? Is there somewhere >> a real project page (not the one on opkg.org). >> > > Actually, my wm is really a basic one. It is based on Ecore_X API and > it serves just the basic window types. > I am the only one for now working on this project, and there isn't any > official site yet, sorry. I will open one as soon as I have a little > time (today my holidays begin :-). Ok, go and enjoy your holidays! > My primary goal would be to create a unified UI system, but is of > course a huge project. Therefore, for now i'm developing a WM for > getting rid of the weight of illume, and a set of basic apps. The > library that every app is using (libmokosuite) has some "extended" > elementary objects, that's a start for having unified windowing and UI > systems. > > The problem is, of course: no one wants to have a new API; but this is > actually what I want to do; every phone has its own consistent API: no > multiple toolkits, a few programming languages, much documentation. I > think that if people is provided a unique and consistent API, they > will begin to write applications much more willingly. 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. > >> The idea is really interesting as I though about writing something like >> this for a long time now. I though a little more in the direction about >> a window manager handling application life cycles and provide a simple >> management API over DBus. >> > > I was thinking about that, besides, as I said before, an API must be > defined before starting to write code, so everyone must stick to it. > Or we may find some existing API such as the Maemo one... or we could > extend the FSO API... it's just a matter of choosing. 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. regards, morphis -- daniele_athome _______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
