Hi Mike I think I have a least a conceptual understanding of how WM's traditionally work, what we need to do, and of how you propose to do it.
I suggest that at least in the beginning you could delegate the work to me and others, since you seem to have the best overview. I tried checking out the "mike_surface" branch but that did not compile. The work you have allready done! Is that in cvs, in a branch or not ? I suppose we would need to create a branch at least untill we have factored out the WM so it loads a a module. So if you could take charge at least here in the beginning and give me something to work on. If there is a not too complex and lengthy thing we need done that would probably be the best! -Martin L > I guess I should say where I'm at on this project. > > On the X11 side I've written a kdrive based directfb X11 server that > runs full screen > on the display layer. So we have X11 now in full control of the screen. > > The next step is to rip the WM or probably more correct ignore the > current Directfb wm code > and write the simple region manager with a basic drawing list. This > can reuse a good bit of the current wm code and simply have the > structures renamed I call them CoreComposite right now since we have > used all the good words ( I'm open to suggestions ) > > Then we need to move back to X11 and hook the creation functions to > defer back to the dfb composite manager the rootless and composite > api's can be used to guide how to preform this hook. > > Then back to directfb you can now rip the remaining CoreWindow code > out and let it defer to our CoreComposite manager. Done correctly when > a DFBWindow is added it adds a CoreComposite the X11 WM picks up this > request and wraps it in the X11 api creating a X11 window that can now > be hooked by current X11 wm's. Yes this means that X11 is running on > directfb and directfb windows are emulated under X11 but thats by > design honest :) > > Once we have good directfb wm's the reverse would be true with the X11 > wm api rerouted to and simulated by directfb via a compatibility > library. > > This is a lot of work but now DFB can be running on the desktop and it > works via integration with the existing X11 code base we have plenty > of time to develop new cool desktops DFB core can be adopted and > deployed using the existing technology via the above hooks. > When compelling "pure" DFB desktop are available that support > applications expecting a X11 WM the X wm can be replaced. > > My opinion is that we can offer a saner and easier api for WM > development from directfb so I think that in time people will prefer > the DFB api if its widely deployed. The migration route solves this > problem. The WM/App interaction can then be hidden via a wrapper > programming interface so your not doing X programming directly. In any > case the options for evolution/revolution are open so it really up to > what gets adopted technically there are no limitations. Overtime I > think that direct X11 programming will fade and a agnostic api will > develop. This is already common with libraries like Gdk/QT but they > add a lot of other junk to the wraps. I'm talking about a saner > Xlib/DFB style simple api that hides the window impl without adding a > widget toolkit. > > > > > > > > > On 1/17/07, Mike Emmel <[EMAIL PROTECTED]> wrote: >> On 1/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> > I am still reading up on WMs. Just tried to compile and run metacity >> in an >> > Xnest, and reading their HACKING document. >> > >> > Still a lot of questions and things I need to get familiar with, but >> for >> > now just one question: >> > What exactly do you mean by: >> > "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." >> > >> > Do you wan't existing X Window Managers to actually compile "out of >> the >> > box" under DirectFB. >> > >> > Perhaps it's just me which still havent figured out how exactly th WM >> > interacts between the server and the client program showing windows. >> By >> > messages? Or by hooking in directly on Xserver functions? >> > >> > Hope these questions are not too stupid :-) .. but's the only way to >> learn... >> > >> > -Martin >> > >> >> No these are fine questions you would need to know the guts of a wm to >> understand. >> >> All wm work by capturing events and drawing commands and configuration >> changes >> such as resizes and re-directing them through the wm for pre-processing. >> >> Directfb default and running X11 with no wm ( really the internal one) >> are the simplest. >> They draw no borders and process events as documented in the application >> api. >> >> Anything more than this and you need a shadow window or a way to draw >> a border and capture events in this border for resize etc. And of >> course other events like creation need to be captured to allow the wm >> to create the right border for the window. I think your finding that >> wm are actually fairly complex. >> >> What I mean by opening up the directfb API is that both X11 and >> Directfb assume a certain design for the wm built in. What people >> generally consider WM are actually privileged applications that hook >> various wm functions and redirect them to do further processing before >> generally calling back into the real wm and preforming the default >> action. >> >> The core design is written in stone so to speak in both however the >> hooks exported are fixed. For X11 this resulted in a new manager the >> composite manager which adds additional hooks to support alpha >> blending of window on screen. DFB by design already allows the wm to >> control compositing. My point is not who has the better design ( DFB >> :) but that maybe the whole concept needs to be rethought. Why do we >> have too fix the design of the wm in the core architecture there are a >> lot of ways to build wm and design tradeoffs etc esp when your looking >> at embedded devices. >> >> X11's composite manager shows in a sense that you can go with a more >> primitive public api in the core and move most of what is hardcoded >> now in both X11 and directfb out as a variable design. What you >> really need at the core is actually quite simple. >> >> 1.) A unified list of all z order regions >> 2.) A hook when compositing is needed to callback to show these regions. >> 3.) A way to specify how these regions are drawn so the composite can >> happen without blocking on another process. >> >> Directfb is actually pretty close to right but it exports these z >> ordered regions as a application accesible api DFBWindows and it >> assumes all top level windows are buffered. >> >> So the changes on the directfb side are to recognize two things. >> >> 1.) All you need in the core is a unified list of these z ordered >> regions to run you composite >> manager. This is required. >> 2.) The composite manager really just needs a list of instructions for >> drawing a region when >> it composites blitting a buffer is simply one operation thats really a >> subset of a list of graphics primitives that could be performed in the >> simplest case you could have either fill rect or blit etc. The key is >> that at composite time the drawing instructions are fixed but they can >> be a complex list. >> >> Event handling is simply forwarded to the wm and no events are >> generated in the core. >> We don't even need to do hit detection in the core although helper >> routines can be provided see below. >> >> With this design how a wm works is no longer defined all that is >> defined the shared list of regions and a way to specify draw ops when >> you run the real composite algorithm. >> >> The WM also intercepts all request to create a "real" window and >> provides the hook for this. >> >> >> Now with all these changes the reason that its possible to embedded >> the wm in the core in the first place is generally you have a limited >> way to actually write a real wm so all this code can be moved out into >> a optional helper library or toolkit library for someone who wants to >> write a wm. This library in the case of directfb could create a >> default implementation of a DFBWindow and could have hooks to allow a >> alternative WM to wrap the default >> or of course the wm can do a custom version and simply reuse the code >> it needs from the library since its open source. >> >> With this design and some small changes to the X11 server which can >> now run full screen >> existing X11 wm can be used to manage directfb apps and new dfb >> centric wm can be developed that manage X11 windows. Since we have a >> wealth of X11 wm getting dfb embedded in the traditional desktop >> cleanly is my first priority. >> >> What this means is that on the X11 side you need to divert the hooks >> created for the composite manager extension to run back into dfb to >> create these regions. >> >> And if your creating a native dfb window it needs to defer to the X11 >> server/wm to allow X11 to create a X window proxy for each region. >> >> You can see that by moving the wm implementation out of the core and >> just leaving the bare minimum you can now write a wm using any api you >> want and if you have the hooks any other api works as a "child" or >> slave wm to your chosen one. The interaction is cooperative between >> the supporting api's with the core providing the base level of >> cooperation which is the z order list and a way to declare the drawing >> commands. >> >> The ability of one wm to emulate another say the X11 wm api can in >> time probably be extracted as a simple library with a basic backside >> api. So if I write a pure dfb wm I should not have to do that much >> work to allow it to pose as a X11 wm. The directfb api is simple >> enough that the reverse allowing current X11 wm to create dfb windows >> is fairly easy. >> But again this can be moved into a support library. The exciting thing >> is this opens the door for custom embedded wm that export their own >> windowing api and support whatever current api they choose. A open gl >> dfb/desktop need only support managing these 2D z ordered surfaces for >> example and provide its own window api while still allowing DFB and >> X111 windows to function. In this case all of these 2D windows would >> be embedded in OpenGL surfaces. >> >> I'm interested for example in making all the windows part of a browser >> running full screen so in my case all windows would also show as tags >> in a dynamic full screen document. >> >> Thus the sky is the limit on how you actually write the WM and what it >> capabilities are and you have access eventually to simple libraries >> that allow existing apis such as X11 and DFB and others to run on your >> new "cool" desktop. All we need to do is make some small changes to >> directfb to remove some assumptions and expose basically the >> CoreWindow api to the WM and let it create the DFBWindow interface. >> >> >> >> >> >> >> >> >> > >> > > 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
