I will read the XCB documentation and see if I can play around a bit with Fusion. However I will be away from friday and rest of week 5, so I won't be online too much untill after that!
-Martin Lütken > Hi Mike, > > I've been reading doc and code, too. > There are still things not completely clear, but I think I could > start doing something useful. > > As you said, we can start with the CoreDrawable. > After reading your previous emails and other doc (like xcb) I got a better > idea of your proposal, but I still have several questions. > I start with the what I understand (see attached diagram), that if it's > correct could be useful for others. > You have much more experience in this subject, so please correct me if I'm > wrong and don't get upset if you read awful things :) > > (1) DirectFB with the CoreDrawable > As you said, this is DirectFB plus this Core that only does a couple of > things: > - List of z-ordered regions: circular double-linked list? It could be > useful for ordering the regions in a fast way. > - List of instructions for drawing a region: normal DFB rects for now. > > DirectFB should remain without a wm, since the later would be a shared > library. > Thus, when a new window is added (through a request done by X11, a DFB WM > or directly from a DFB app), a DFBWindow would be created on top of the > CoreDrawable that will handle how this DFBWindow is drawn and it's > z-order. This should be done having in mind backwards compatibility with > current > DFB apps. > > (2) The communication between a DFB WM or an X11 server with the > CoreDrawable would be that the CoreDrawable: > - sends input events and msgs (such as windows id and properties) > - receives drawing requests and msgs. > This is similar to xcb, does the CoreDrawable need to send/receive > something else? > > For all the X11-based apps and wm, the kdrive could be used, at least > initially, as a hook for passing the real drawing work to DirectFB. > > (3) The DFB wm decides what to do with the windows. The chain of > primitives for drawing (that could include cairo) could be created here, > although the real drawing is passed to the CoreDrawable. Is this correct? > > (4) Could you explain a bit more about the interoperability in cases like > an X11 wm running DFB windows or the other way around? (my simple diagram > doesn't show it)and the XML programmable desktop? > > Thanks and sorry the list of questions. > > I will start playing with Fusion! > > Pedro Aguilar > >> On 1/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >>> 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. >>> >> I went off the deep end a bit on that one :) >> Consider it notes. >> >>> 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. >>> >> Correct I asked on the list about moving away from cvs and svn seemed to >> be >> acceptable I'd like to see us use svn for this type of work. >> >> Dennis any chance of a move to SVN in the near future ? >> >> If not I'll make another branch in CVS. >> >>> 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! >>> >> >> Great. The first step is to create a new core data type like >> CoreWindow and CoreLayer >> that will represent our Z ordered surface. For now it can just draw a >> rectangle as its opp. >> >> I have to give a demo on Wed but after that I'll have some free time >> to start working a little. >> If you have not done any internal dfb programing the first thing you >> need to do is work through how the fusion calls work between the >> interface and the core object. >> >> So your homework is to play with fusion a bit so you see how it works >> in multi and single mode. Probably it would be best to create our own >> Fusion world for this also. >> The best approach I think is to set up your own master slave sample >> server you can use the one in DirectFB/tests as a example. >> >> >> I can add the base data type after Wed on a branch. I think I'll call >> the new data type CoreDrawable since thats easier to spell than >> CoreComposite and its main purpose in life is a place to draw. The >> constructor takes a surface and we need to have the ability to change >> the surface to a new one. The software cursor will become a sprite >> CoreDrawable so the first real test would be to show we have a cursor >> working correctly. This means we probably need to support z order >> layer conceptual grouping in the CoreDrawable so its easier to keep >> groups above and below other groups. >> >> Initially it will be a z ordered tree of rectangles with only a fill >> rect supported. >> >> The WM will attach to the screen get events and is full responsible >> for user events. >> First of course we have it just drag windows around and click to raise >> lower. >> >> >> To finish I hope to get some feedback from Dennis on this and I'll cut >> a branch off after next Wed and add the new CoreDrawable data type and >> we can then work on filling in the details. >> You play with fusion for a few days until your comfortable with it >> thats the only part of directfb that is different once you grok fusion >> its basically regular C programming. >> >> The first goal is a z ordered list of drawable that support fill rect >> operator and a soft cursor >> along with a simple wm using CoreDrawable. >> >> The next goal will be to add Surface blit/flip support as a operator >> from CoreWindow and add more drawing operators. >> >> At this point we can look at splitting CoreWindow between the new WM >> module and CoreDrawable. This means need one more new datatype >> interface DFBWindowManager. >> >> >> >> >> >> >> >> >>> -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 >> >> > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
