Hi again Sounds like very reasonable and good considerations. I actually started making a window manager which to some extend was intendedn to be platform independent, but really in the first shot was intended for SDL (and perhaps then later make a OpenGL backend).
However SDL does not have a Window concept and neither a multi app possiblitity, so when I started to look into the latter I checked how DirectFB was doing it and concluded that DirectFB would be a better choice. The only thing I have programmed for DirectFB is trying to make an X11 system, but it's only partly working. But making a WM for DirectFB seems like a real good project. Would it make sense to try to refine the design goals and after that perhaps firsk make all header files and definitions before moving onto actual implementation? -Martin L > Hi, > > I'm not a DirectFB hacker neither, but I would be interested too. There > have been some emails during November/December discussing this issue. > > I think starting from scracth could be a good idea. "Unique" could be > useful just for having some ideas at the beginning of development. > > I think that a good starting point could be having a kind of wish-list of > the things we want the DFB WM to do and how it will do it. > > A first draft could be the this list (points 4 and 5 were taken from Mike > Emmel emails). > These are only some fuzzy ideas that need a lot of work to make them real: > > 1. Provide a light, fast and reliable windowing system for DirectFB. > > 2. Provide transparently the benefits of DirectFB > - It's fast > - It's light > - It's stable > - It has a small size > > 3. Capable to be used in embedded devices: > - Reduced resources usage, specially memory and processor > - Small foot-print > - Support of small resolutions > - Support of a full-screen windowing system > > 4. Refactor the code so all of the current wm is loaded as a shared > library. Once this is done its up to the WM to provide the DFBWindow > interface implementation. > > 5. Consider expanding the concept of a window to be two parts: > First a region for events. > Next consider the current back buffer flip only one operation that can > be performed to show a window. > The operator is a chain of primitives that is executed to show a window. > The default operator is to flip a back buffer but other operations are > possbile. The only restriction is that any needed resources such as images > would need to allocated in shared memory. The base set of operators would > be all the core drawing ops of directfb. > > For "secure" apps one operator would be a custom callback that exists > in a shared library loaded into the root process. > > Libraries like cairo could be used to generate advanced drawing/blitting > chains. > > 6. Support for GTK+ > If Cairo is the graphics rendering engine and the other GTK+ libs > are available (Glib, ATK, ...) support can be provided for GTK+ > taskbars, statusbar, panels, icons and potentially Gnome apps > > 7. Support of virtual desktops > In embedded devices it could become a full-screen windowing system > > > I hope in the following days to start working on it (as time and my > real-job allow). > > Pedro Aguilar > >> Hi >> >> I would like to give a WindowManager for DirectFB a shot. >> Could anyone give me a few pointers or things I should be aware of. >> Have a little experience with DirectFB, but not too much. >> Should I use the "default" or "unique" WM as stating point or none? >> >> How does DirectFB select a WM? >> What kind of functions/API must the WM facilitate ? >> >> Regards Martin Lütken >> >> >> >> _______________________________________________ >> directfb-dev mailing list >> [email protected] >> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev >> >> > > > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
