On 5/30/06, Ville Syrjälä <[EMAIL PROTECTED]> wrote: > On Mon, May 29, 2006 at 10:18:43PM -0700, Mike Emmel wrote: > > On 5/29/06, Ville Syrjälä <[EMAIL PROTECTED]> wrote: > > > On Mon, May 29, 2006 at 04:55:15PM -0700, Mike Emmel wrote: > > > > I was looking at the implementation of this function and was surprised > > > > to see it creates a window. Explanation ? > > > > > > It creates an IDirectFBWindow object but it doesn't actully create a new > > > window (CoreWindow). > > > > > Yes I realized that its not clear that its created with the right > > properties either. > > I don't see anything wrong with it. It first check if the core window > exits and then constructs the object. > > > Why are we not saving a back pointer when we create the interface ? > > That's not how it's supposed to work. It is quite possible you didn't > even create the window but someone else did. > > > This function is a leak waiting to happen. > > Why exactly? If you don't release it you leak it. That's how things work > in DirectFB. > > > Create should allocate Get should return and existing interface or null. > > You can have multiple interfaces to the same core object. >
I don't disagree with a function that does this it should be called Attach or better CreateInterface and the docs should be explicit that its a new interface Get implies returning and existing value thats interned. You should have ... 1.) Attach creates a new interface for a core window given and id used for sharing a core window between multiple processes. 2.) Get which returns a existing interface or null in the same process given and id. Without the second the app is forced to maintain the list and if a core window is withdrawn or destroyed we don't have access to the interfaces to disable them. At the minimum Retrieve an interface to an existing window. Is highly misleading documentation it should say Create and interface to an existing window. The user does not realize that when they use id's in the same process there are allocation and multiple interfaces created so there responsible for maintaing a mapping table. I understand that its common in directfb for the application to maintin its own state and mappings not a problem but we need to document it. So in the case a usage note that if you use the window id in the same process you should maintain a list of id->interface mappings to prevent allocation. Agian I'm not arguing what the function does it just the documentation and function name are misleading at best. > -- > Ville Syrjälä > [EMAIL PROTECTED] > http://www.sci.fi/~syrjala/ > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
