Okay I'm hacking on adding get/set props now I'll send a proposed patch as soon as I have it.
Also as you know I need to get gdkdirectfb fixed but right now I cant replicate the bug. Next as far as my overall proposal can we look at pulling IDirectFBWindow out of the core most of the code can go into the wm. So for me the next steps are. 1.) Add get/set props. 2.) Add ability to set a buffer for sub-surfaces and api //add flag on CreateSubSurface to ask for a private buffer ( format ?) IsBufferOwner Tree api plus call back mentions in previous email to enumerate ? GetParent GetFirstChild GetNextSibling 3.) Allow Window to be create for any surface fails if no wm associated. Since windows are then now nestable There also a tree add these plus prob the enum callback ? GetParent GetFirstChild GetNextSibling Disconnect window mgt from layers and surface api. We need a WM object The Window methods on IDirectFBDisplayLayer move to this new object. The Window Manager is created with a new Top level entry this allows us to split windows off into there own shared lib and makes the divorce from core directfb final :) DFBResult CreateWindowManager(IDirectFBSurface wmroot, char *wmimpl,IDirectfbWM **wm); The second arg can be null but if non null it loads the shared lib. Maybe instead of the char we pass some config structs. If we want to find a wm for a surface it can be set as a property easily enough and props don't know the api of there values. So the only tie back is this prop. Its easy enough to walk a surface tree to find the wm prop. 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. Sorry to bring all these changes up now but I learned that we needed to do this as I worked on the X11 implementation and porting MetaCity the complexity of a modern desktop WM is scary and I don't want DirectFB to be trashed to support it. 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. Mike Founder of the Society for Prevention of API Explosions DirectFB chapter. On 7/15/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > Claudio Ciccani wrote: > > Ben Combee wrote: > >> 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. > >>> IDirectFBWindow > >>> --------------- > >>> - IDirectFBWindow::SetTitle( const char *title ) > >> I don't think windows should have titles -- that seems like something > >> that's more appropriate at the toolkit or window manager level. LiTE > >> implements titles as part of its LiteWindow wrapper. > > > > I think that if the window manager can display window's decoration, it > > should be also capable of displaying a window's title on the decoration. > > Yes, that should move from LiTE to the WM, or at least have it like > now where LiTE can provide decorations if the WM doesn't support them. > > >> Also, what > >> character set is the title? How do you get it out of the window? > > > > The charset should be UTF8, of course. > > Default at least :) > > >> Rather than do this, title could just be one of the properties that > >> could be associated wth a window using the API that Mike proposes. > > Yes, that's what I'd like instead of SetTitle() etc. have properties > with content itself, content's encoding, timestamp, setter(?), > owner(?)... what else? > > -- > 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 > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
