On 7/15/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > Mike Emmel wrote: > > This allows us to do tons of things. > > It gives use the equivalent of XNest since you can run a wm in another > > window. > > It allows rootless mode with special root surfaces i.e now I can write > > a x11 driver > > where the main display is not accessible by default. MDI works. > > Note that getting the directfb api to run on other OS and WM is > > important for wide adoption. > > > > > > If you don't want windows you don't carry the baggage the windowing > > api can now evolve at its own pace. And most important Core Directfb > > is defined it provides surfaces input and multiapplication support for > > surfaces period. > > I like the ideas in general, had something similar a while back when > doing StReT, but I think we should leave DirectFB as it is before 1.0 > and start flipping top and bottom in 1.1 :) > I think it would be 2.0. But get/set prop should go into 1.0 for sure IMHO. Doing it now.
Next the surface changes I suggested should go in I think. Adding shared and unshared buffering is not hard. If we make the constructor or loader for the wm public I can write the new code on the side without impacting the current implementation. Its easy enough to ignore or not start the current wm. So. 1.) Your doing a non window cursor. 2.) I can add props. 3.) Next I can add the buffering options to surfaces 4.) Also add exposing the surface tree. 5.) The new wm create function. Then I can go off and write the new api with no impact on the core. In 2.0 I highly suggest we can the old api but the 2.x series would be compatible with 1.X. Its not hard for me to do this I just need a dir to work in wm/2.0 ? If we do a few things its compatible with 1.X. I just need the hooks and the buffering. For subsurfaces the tree logic is there already. Also most if not all of the logic for subsurface buffering exists. The group thats intrested in things like SetTitle etc etc can work in the 2.0 wm dir. We leave the existing code alone except in 2.0 you can get a Window from the new WM interface. I'll add a few ifdefs and make file conditionals to kill the old code and prepare it for removal. The impact on current directfb is really adding optional bufferes for subsurfaces and exposing the subsurface tree and changing the cursor but your doing that now and its optional. Adding optional backing bufferes for subsurfaces is a good thing tm. The wm load function is already there just not public. We just expose one wrapper around dfb_wm_initialize. I can ifdef it for 2.0 wm or we can add a stub WM class that just calls back into the existing api. My point is I can make these changes with small impacts on the current code base. Mike > > Short term we can just push the software cursor which is a window now > > up into the wm. > > Later it should work without one but its tied now anyway. > > I'm working on a software cursor implementation which uses a surface > instead of a window. A big advantage will be that you can't reveal > changes within windows that are not yet commited, i.e. Flip()ed. That's > because I'm going to implement a backing store for the region under the > cursor. The cursor can be handled in the core completely, but I'm not > sure yet if that's the best option. > Well if a wm is running it can take over the cursor implementation maybe. For example do what we do today. I think the core should have a cursor implementation but it should be replaceable. Right now we don't have hardware cursor support as far as I know. This mean we prob need a real cursor object. > -- > Best regards, > Denis Oliver Kropp > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
