Only whats on the website. review the files in src/core should give you a good idea how its works fairly quickly.
On 1/16/07, Rahaman Md Mustafizur-A19072 <[EMAIL PROTECTED]> wrote: > Hi, > > Does any one have any architecture level document of DFB?i have only gor the > one available in DFB website, which only talks on a very high level? > > If anyone of you have any doc on this, please share.It would be very much > helpful for me. > > > ************************************** > Regs, > Rahaman. > Ph(Off): 91-40-2347-4165 > ************************************** > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Emmel > Sent: Tuesday, January 16, 2007 10:25 PM > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [directfb-dev] Want To Help: Window Manager > > On 1/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Seems you know more about the DirectFB architecture than I. > > I will try to read up on that, if I can find any documentation. > > Today I have tried to look a bit on other Window Managers and also > > found and read the "Extended Window Manager Hints" specs, which both > > KWin(KDE), Metacity(Gnome), AfterStep and a lot of other WM's more or less > > adhere to. > > > > It also helped me understanding where the line is between the WM and eg. > > the Desktop. So perhaps we need to make a Desktop also? The WM in > > itself seems to be more of a base on which to build a desktop. > > > The line is quite blurry generally the last part of a wm that makes the > desktop is a plugin framework for applets that run on the desktop or root > window. > Most modern X11 wm seem to be basically full desktops outside of these > applets. > > > I will continue to read about the existing WM's and looking a their > > code in order to see if it would be possible to use any of them as a > > base, converting all X-related functions to DirectFB calls. Ofcourse > > if we want to use an existing I suppose we better stick to those using > > LGPL or less restrictive licences.... > > > > I went down this path already with metacity my conclusion is we needed to > open up the design of directfb to create the wm foundation toolkit I've > described to handle pretty much any wm design. > > My current approach is to first open the directfb api to allow X11 to work > well i.e allow X11 wm etc to function and manage all windows including dfb > windows. > For a non X11 wm I'd like to instead take a different approach and make > WebKit the wm. > > The cool thing would be the whole desktop would be xml programmable. > Its basically one > big web page/ xul app. So directfb have a cooler desktop than anyone else :) > A shared XML doc makes it much easier to do the detailed interoperability > needed to pose as a X11 wm. > > > > -Martin L > > > > > On 1/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > >> 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? > > >> > > > > > > My plan was to extract the current directfb wm out of the core and > > > make it load as a plugin module. > > > > > > Currently the directfb wm is semi embedded in the core and half > > > plugin. The problem is this means a lot of design decisions on the > > > WM side are present in the core library. > > > > > > Instead the core should only be a composite manager responsible for > > > showing the windows when needed. > > > > > > Right now the windows draw routine would be hooked to the buffer > > > flipping but after the first set of changes is in it could be made > > > into a generic draw list handler. > > > > > > On the interface side directfb exposes locking a assumed backing > > > store for direct drawing but this is already a bit broken for sub > > > windows since they can lock a parent buffer and draw through any > > > sibling subwindows that overlap and of course it hands back the > > > buffer pointer for the main window forcing you to figure out where > > > you are on the root before you can draw. > > > > > > In anycase the window interface for directfb in my opinion needs > > > more work and needs to be made more flexible but we can address this > > > when we get to it. > > > > > > But the first steps are to simplify the core and ensure that the > > > current api is supported as a module. > > > > > > My next step would be to alter my kdrive X11 server to be both full > > > screen and defer to this new core composite manager when creating > > > windows so that I can prove the new api can handle a alternative > > > approach. Right now I plan to do this by building in the X11 > > > composite manager and making it defer to directfb or at least the guts of > > > one. > > > This would mean of course for X11 under directfb you can't use any > > > X11 composite manager but this should be the only difference between > > > standard X11 and X11/directfb. > > > > > > The above is useful of course but more important it shows that we > > > have created the right core composite manager support to run any > > > windowing api on directfb with a good simple core api. > > > > > > The fun part is building out directfb window mangers customized to > > > different types of devices and desktop styles. Done correctly any > > > window management design should work. > > > > > > I did check in a branch that explored these concepts and more but > > > its not useful more of a R&D project on my part to make sure its possible. > > > On that branch I refactored a lot of code to show that its possible > > > to rip various parts of the current core into libraries. I went way > > > to far but I'm comfortable that we can do what we need to do. > > > > > > From that experience my suggestion is we start with the screen layer > > > and add a new type that represents this composited object backing > > > the window managers. > > > > > > We have used most of the english concept words such as layer and > > > window for other stuff so the best I have now is CoreComposite. > > > Other names for this are welcome. We may need to save CoreWindow for > > > advanced wm interaction so we should keep the concept of this z > > > ordered composited drawing area different. > > > > > > It should have the following. > > > > > > Z order position. > > > A draw routine thats replaceable i.e accessed via a function pointer. > > > > > > The concept of bounds this could be complex i.e non rectangular or a > > > alpha image along with a rectangular bounding box. So we probably > > > need a new CoreBounds object that represents the region owned by the > > > Composite. The composite manager just needs to know the rectangular > > > bounds and if the composite is opaque for optimizing the rendering > > > but we I think should store a complex object that can be provided by > > > the wm along with a good default implementation. > > > > > > > > > A mouse hit test routine that replaceable or better generic event > > > handler concept. > > > I'd like to defer as much event handling to the wm as possible but > > > the core system should be able to find out who has focus etc. The > > > important part is you should be able to find out which composite is > > > active and also get enter/leave events from each composite. > > > > > > > > > My plan for doing this was to introduce the CoreComposite and just > > > default the rendering to fill a rectangle for testing. Also > > > CoreComposites should nest without changes to the api or programming > > > model. The drawlist concept could and I think should be built into > > > the core as the default drawing routine with fillrect and the > > > current buffer flipping as the basic routines supported in general > > > all the core graphics ops could then be added. > > > > > > > > > Then move the current CoreWindow api out into a module on top of the > > > new CoreComposite. > > > It would then simply register the buffer flipping as its drawing op > > > and its current event handling as the event handler. At this point > > > the current directfb api should be fully supported. > > > > > > > > > > > > So the core composite built into directfb would handle most > > > programing styles for wm's and it is pluggable to allow the wm to > > > replace objects and api's and still keep the correct CoreComposite api. > > > > > > > > >> -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 > > >> > > > > > > > > > _______________________________________________ > 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
