Quoting Denis Oliver Kropp ([EMAIL PROTECTED]): > > First, it could be nice if an app could find a window at (x,y), or could use > > some window-manager like policies about size, etc ... > > Some time ago someone was speaking about a window manager, isn't it? > > You may want to read the todo section on the web site.
Adding an IDirectFBDisplayLayer::GetWindowAt(x,y) could be easily added. It would return the ID of the window. Or would you prefer to create and return an interface to it already? This will require some thoughts about security soon. > > Third, it could be nice that a window with alpha channel could decide of not > > receiving mouse event where alpha = 0, with this shaped window can be > > implemented in Qt and receive selected events. Al that can be realized with > > the attached patch, that add the "DWOP_SHAPED" flag (to be used with > > DWOP_ALPHACHANNEL) > > I was thinking of that some time ago. Unfortunately the locking to read one > pixel for each mouse movement may be too much overhead and a faster solution > should be thought about. > > I will apply the patch now. However, DWOP_SHAPED has to be implemented for > color keyed windows, too. You should think about using the primary pixelformat > (pixel format of the layer, i.e. no DWCAPS_ALPHACHANNEL). You can implement > shaped windows via color keying then which is way faster and consumes less > video memory. XDirectFB uses color keying for shaped windows. Your patch is in CVS now. I made some fixes and improved readability ;) I also added a pre-check if the window surface's pixel format has alpha at all. If not (common case) we can skip the locking. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
