Okay I wan't to write out my concerns here in a generic manner. First Directfb is cool it can be used for lots of different purposes.
Next as it becomes more widely used all of us want to add our favorite function and there are a lot that are valid and useful but stuffing all this in the core is going to result in and increasingly bloated toolkit thats less and less useful for any particular use case since you pick up baggage from other peoples needs. How do we stop this. 1.) Core directfb my analysis is that core directfb is just the main surface mgt. Windows should have not gotten entangled in it they should be optional. The only real tie is the software cursor this can and should be fixed. 2.) Subclassing vs annotation of a object. This is pretty basic we don't have a generic method to add fields to a object at runtime we need a Get/Set mechanism so we have a choice of subclassing/wrapping. And it needs to be public. Right now private data is allowed but its via a internal mechanism. Generic annotation via a get/set property makes things very clean. 3.) Surfaces SubSurfaces and buffering. We need a mechanism to allow surface sub surfaces and buffer strategies. We need a call back to allow child surfaces to resize when a parent changes. 4.) The software cursor should be implemented using the core api. -------------------------------- END CORE API ------------------------------------------------ Now higher up there should be not dependencies of the core on any of this. The Window api should exist but the implementation should be moved out of the core. We should be able to create a window for any surface ! I did this with the Inset calls so its doable. With this we now allow windows to be nested which is fine since were not spilling the needs for widgets into our basic surface support. Now higher up. Above surfaces and below windows there is a needs for a region based api to deal with decorations and non window drawing on screen we can provide a generic but optional api by cleaning up StRet. Top of the stack --------------------------------------- The WM should own the windows and create them and control there blitting. Its hooked into the surface resize via a property that sets the window owner. So we can get our real window class back out of surfaces as needed. Windows would hook the surface resize calls to pass them on to the window resize callbacks to layout children. If we split directfb along these lines we can server everyones needs and keep the core library small and usable. Before we go 1.0 the big change would be to pull IDirectFBWindow out of the core api and move it over to a new directory preferably to allow windowing to develop on its own track. We may want to offer several different window implementations depending on the needs of the device. StRet would be a optional but required package depending on the windowing strategies. Api's may be subsets depending on the complexity. I believe that this won't happen if we make all optional stuff a property. In anycase the point is it will evovle on its own without gunking up the core api. _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
