On 1/14/07, Pedro Aguilar <[EMAIL PROTECTED]> wrote: > 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. >
Yep thats pretty much the design I've proposed. Also I'm working on seemless compatibility with X11 not rootless mode. In this case and for other reasons you want a core window server thats really simple X11 would register and so would the directfb window manager this allows mutiple api's to be pretty much first class citizens on device. For X11 I've written a kdrive server thats fullscreen and runs on the display layer. After I extract out the concept of a core manager I'll have it register its windows and defer to the core as stated above. But note if you have X11 and are not running any other wm its could run in "pure" direct mode if you wanted. Only when other wm like directfb windows are shown would you need to move to deferred drawing mode. I'll need to dig a bit into how X11 buffering and composite mangers works since they have solved the problem for x11. In any case if your intrested in a real decent wm for directfb I really think going back and revisiting the way it works and extracting this composite manager/ draw list concept will make further development a lot cleaner and easier. As I get time I'll work through how to do this but for now if you take a hard look at the way CoreWindow works and the wm composites and just add a CoreWindow that registers something as simple as a fill rect for for drawing. A lot of the concepts are actually up in unique also. What I'm really saying is the way unique works should be refactored to be the core wm and we should build on top of that. Next look at Evas Canvas it has exactly the design I'm proposing and you can pretty much use the same design and a lot of the documentation. I've not dug deeply in the code but its pretty big and we have cairo etc for drawing so I'm not sure how much code could actually be reused. In any case I owe the whole concept to Rasterman and Evas canvas. Finally on another point for supporting gdk one of the approaches I'm very interested in once we have the above is porting the xcb library to run "native" on the new directfb. The nice thing about this approach is it also supports xlib so you would be able to run all xlib based X11 programs local without running the X server. Next of course if you wanted the X server could then be gutted to call back into the new api if its worth it. Finally a bit of history I started work porting the MetaCity window manager and realized that trying to support a lot of the concepts in the WM on top of the current directfb api would be really hard if not impossible. This lead me to consider if we could offer a more flexible api under directfb which would make it a lot easier to support complex wm's. The composite manager/draw list approach seems to meet this goal and other goals such as seamless X11 support I added later. Mike > 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 > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
