On 1/18/07, Pedro Aguilar <[EMAIL PROTECTED]> wrote: > 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. > Cool !! The diagram looks about what I had in mind. You get sort of a E like dependency with reroute points depending on who is control basically how you implement a WM. Since the WM itself will generally use some sort of toolkit for its own implementation. I'll work on a pretty version later next week. As I mentioned I'm stacked until after next wed.
> 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. > It really just a tree you generally don't need something fancy. We will mainly run a optimized painter algorithm. Their are some indexing tricks to get the minimum paint set without walking the whole tree. Google for the painter algorithm. Directfb runs a simple version right now. http://en.wikipedia.org/wiki/Painter's_algorithm You can obviously get more complex and since we are asserting that all operations are known via the paint lists optimizations can be employed. KISS is the initial idea but we have all needed information so compiler concepts will work. Thats the real reason for the paint lists in the first place :) > 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? > Its very similar to XCB :) But we don't need to adhere to the X11 spec once done we should be able to map all the XCB relevent requests directly viola no Xserver for X. The Xserver code could be gutted to support all the legacy X junk. On the XCB side it would message three ways via a small extension to fusion. direct single app mode fusion local multi wire i.e fallback to the way it works now. Possible 4th (fast wire ) X replacement with better wire protocol. > 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. > Done I have a kdrive dfb X11 server written. > (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? > Right cairo would need a new backend that interacts with the CoreDrawable primitives it would be very similar to our current DFB backend but would instead generate the new drawlist. I expect using Cairo would be the easiest approach. For X11 the primitives would be created in the X GC and for Directfb its a new api similar to the current direct api. The WM provides the Window which provides the pseudo direct drawish api for backwards compat. For us a primitive opcode asm like api and cairo make sense. Hopefully cairo with maybe a few extensions will work for all the api's except dfb which would do the hard bytecode api directly. In any case we new two a primitive and cairo backend. > (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? > In the case of a DFB app running under a X11 wm. you have the following. DFBWindow created sends msg to dfbwm. DFBwm is really X11 wm so it creates a X11window and decorates it and creates the CoreDrawable. The CoreDrawable is then bound to the DFBWindow and handed back to the app. All wm work via sharing core drawables but they will be wrapped mutiple times depending on the wm impl in this case it shows as both a X11 window and a DFBWindow. Same for the XML programable desktop. A request causes a XML window defintion CoreDrawable and DFBWindow to be created. If your running X11 also a X11 window wrap would be created. So its one core drawable and N api's. Even if you don't expose the window in the other apis they all share the same core drawable list so theoretically any api could attach to a core drawable. Only one of the apis is Master and is responsible for creating the core drawable and wrapping it with its internal api at a time. So you always get wrapped with the WM impl api. This can be a simple custom api. This means for example I need to make another modification to the kdrive Xserver once this is up so it messages dfb everytime a X11 window is created. In the case of a X11 wm the following occurs. X11 app creates X Window X server defers to X WM X WM really creates Xwindow wrapped with bounds calls back to do real X window Xserver finally creates a CoreDrawable and wraps the X window api the various xid's are send back to the callers. So you see the Xserver defers to dfb for each window. If you did a dfb app the DFBWindow creation would go like this. CreateDFBWindow defers to the window server In this case its a X11Window server. The X WM would then act like a app on behalf of the DFB app and create A X window finally the CoreDrawable is unwrapped and sent back to DFB. In reality this redirection can be hidden in the Xserver and done as a pesudo X client we don't need to mod the X11WM themselves. Just deal with messages from them and Directfb correctly. The CoreDrawable is actually created in the master shared mem region via fusion so all these process really don't matter. And yes we reallly need a picture. > 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
