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
