I wan't to add to Object Sets the property and returns and id on any dfb object.
DFBResult SetProperty( char *name,void *data, int replace, int * id); Return the property id or error if does not exist DFBResult GetPropertyID(char *name,int *id); DFBResult GetProperty(int id,void **data); Needed but not sure on syntax if id's are null then its app props. DFBResult AddPropertyListener( int *id, int id_count,PropertyChange *callback); void PropertyChange( int id , void *data); I'm ready to start on this now. On 7/14/06, Claudio Ciccani <[EMAIL PROTECTED]> wrote: > If we want to realease the 1.0.0 on September, probably we should start > discussing what there should be in the "final" DirectFB API. > > Here ara some changes I'd like to discuss. > > IDirectFBDisplayLayer > --------------------- > - IDirectFBDisplayLayer::EnumWindows( DFBWindowCallback callback, > void *ctx ) > DFBEnumerationResult (*DFBWindowCallback) ( DFBWindowID id, > DFBWindowDescription dsc, void *ctx ) > Get an enumeration of existing windows. > Usefull for desktop pagers and similar applications. > > IDirectFBWindow > --------------- This would be a wrapper for my Prop stuff. > - IDirectFBWindow::SetTitle( const char *title ) > What are these ? Embedding ? Shouldn't use the ID ? > - IDirectFBWindow::Bind( IDirectFBWindow *window, int x, int y ) > > - IDirectFBWindow::Unbind( IDirectFBWindow *window ) > > (Quite intuitive) > > IDirectFBSurface > ---------------- These can be properties also since the wm can do this. The real answer may be to allow windows to have window children that are subsurfaces then these properties would be on the child window. Having two very different types for children and toplevels is problematic. The difference between child and toplevel is if they share a surface. In general you want. 1.) TopLevel ( Buffered or shared buffer with core layer) 2.) Child ( Share buffer with toplevel or buffered itself ) Right now were using types surfaces or windows to actually determine the buffer strategy. I think thats a flaw. Finally these are layout strategies and just a small set of layouts since in general you want to reflow your widgets on layout. I don't see them being part of the core surfaces. Its better to go with a real layout higher up which we can do if we make windows fixed and allow them to have children. What should happen here is that on a window resize before the backing buffer is blitted we have a callback to layout the children in the callback you do what ever you want. the properties I mention above can contain layout hints or they can be in a wrapper object. I don't disagree that these are common layout decisions but its a dynamic problem. > - IDirectFBSurface::SetSubSurfaceMode( DFBSubSurfaceMode mode ) > Set how a subsurface must behave when the parent surface gets resized. > enum DFBSubSurfaceMode: DSSM_FIXED, /* keep original rectangle > (default) */ > DSSM_PROPORTIONAL, /* keep proportions */ > DSSM_BORDERS. /* keep distance > from borders */ > Particularly usefull for widgets libraries (like LiTe) because it > avoids reallocation of subsurfaces. > > > > It could be also a good idea releasing some RCs (Release Candidate) > before the stable 1.0.0. > > -- > Regards, > Claudio Ciccani > > [EMAIL PROTECTED] > http://directfb.org > http://sf.net/projects/php-directfb > > _______________________________________________ > 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
