Quoting Stephen Perez <[EMAIL PROTECTED]>:
> I need to add something to DFB for a little project I am working on, and I
> wanted you all's opinion (since the features maybe generally beneficial).
>
> I need to be able to add decorations to windows in a fairly flexible manner.
> The idea is to modify the core window object so that it not only has a
> primary surface, but decorative surfaces as well. Somewthing like (psuedo
> code):
>
> DFBRegion r = {0,-20,100,20}; // x,y,w,h
> window->AddDecorativeRegion(r, DSPF_ARGB, MY_DECORE_ID); // r is relative to
> upper left corner of the "window proper"
>
>
> The above code illustrates the basic idea: being able to have arbitrary
> decorative regions with arbtrary pixel formats. For my needs, these
> decorative surface don't even need to have physical backing stores (although
> they could). I was looking more to having a callback that could be
> implemented by the consumer (called by DFB when it updates the window
> stack). When DFB called the callback it would send me a temp surface and the
> id (MY_DECORE_ID) of my decorative region so I could draw into the region.
> It would then take the surface and composite it along with the other window
> surfaces. Also for my purposes, I am going to need to be able to route
> decoration events to seperate event buffers than those that handle the main
> window (window proper, primary window, or whatever you want to call it :).
> I've benchmarked something similar and there doesn't appear to be much of a
> slow down having to call out to the consumers callback. Of course you could
> just turn decorations off, in which case there's no slowdown.
>
> I have read the list archives and I think providing these sort of decoration
> hooks will provide far more power then reparenting or just using four
> standard windows wrapped around a primary to provide decoration.
>
> I would really appreciate some feedback...good?....bad?....hacky (perhaps:)?
If window reparenting doesn't allow the decorations to have a different
pixel format than the main window, I think your solution is probably better.
(I want ARGB for most decorations...)
How about some more generic feature such as grouping together windows? calling
Move() on one window would also move the others. Perhaps other functions should be
inflicted by the grouping as well?
Hallvar
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-dev" as subject.
