Could someone enumerate through the reasons why Hallvar's idea of arbitrary window groups is not so good? It is kinda growing on me. I think it goes a long way to keeping the DFB interfaces simple.
Actually, the more I think about it, maybe they shouldn't be "arbitrary". Maybe we should of predefined postions like DECOR_TOP, DECOR_BOTTOM, DECOR_LEFT, and DECOR_RIGHT. This would allow the window stack to adjust them automatically when the window is resized. Also, I've seen it asked on these lists several times: "what's next for DFB?" How is this decided? On this list? Just curious. Here's my two cents. I hope DFB stays small and light, providing hooks for others to implement anything they might want on top of it. I hope DFB doesn't become a full-fledged windowing system, although I certainly hope there are plenty of windowing systems built on DFB. Put another way, I would hate to see DFB (the low-level graphics stuff and window stack) become tightly coupled to any particular mechanism for managing windows, cut-n-paste, etc. I'm just wondering what a road map for DFB looks like. Does Convergence have long term requirements? Ok, enough babbling... Stephen -----Original Message----- From: [EMAIL PROTECTED] [mailto:directfb-dev-bounce@;directfb.org]On Behalf Of Hallvar Helleseth Sent: Friday, October 25, 2002 7:32 AM To: [EMAIL PROTECTED] Subject: [directfb-dev] Re: Window Decorations 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. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
