On Tue, Mar 12, 2002 at 04:11:40PM +0000, Tim Phipps wrote: > fvwm-workers@fvwm.org wrote: > > Actually, neither my solution nor Mikhael's work. We forgot to > > consider tiled pixmap borders. These have to be drawn in a single > > window in order to prevent seams between the pixmaps of the > > different windows (when resizing). > > This would make it easier to implement colorset support for borders. I > know it wouldn't look all that good when resizing. > > > To further complicate things, > > pixmap borders even may have an inner and outer relief. The clean > > way to solve this requires > > > > With pixmap background: > > > > 8 invisible handles for the cursor shape > > 1 big window with the pixmap background > > 8 windows for the outer relief (4 sides + 4 corners) > > 8 windows for the inner relief > > 8 windows for the bevels > > ---------------------------------------------------- > > = 33 windows > > I don't think this will do it, the DepressableBorder style makes the > corner reliefs be inverted so the bit from the bevel to the corner can't > use the side reliefs.
But that are already the windows listed under "inner relief" and "outer relief". Every visible part has its own window: the four sides (*2 for inner and outer relief), the four corner pieces (*2 again), the eight bevels, the eight input only handles and the pixmap window. > I think you need an extra four windows per corner > to get this right and still have a smooth background pixmap. > > Total: 49 windows! > There may be a way to reduce the total number of windows given that fvwm > only ever resizes or shades one window at a time. All the other windows > only need the frame window with a pixmap background (everything drawn in > it including bevels) and the 8 invisible cursor windows. We need at lease four additional windows to draw the borders. If we use a pixmap border, it will consume a lot of memory on the server because it has the dimensions of the frame. Reparenting the decorations to the window being resized is a good idea though, at least if they can be added or removed without disturbing the looks of their old or new parent. > The window > being resized/shaded can have the extra windows necessary to do smooth > resizing > > I think a working scheme might look like this: > > At startup: > create the extra windows, don't map them > 8 outer relief > 8 inner relief > 8 bevels > 4 depressed corner relief (only one corner is pressed at a time) > these can be used to un-depress the corners if a side is > depressed. > > When adding a window > create the frame window == current decor_w > create a pixmap for it > draw the background into the pixmap (XFillArea with a tiling GC) See above. Use tiled GC only for tiled pixmaps, otherwise use at least four windows along the sides. > draw the reliefs into the pixmap > set the frame window background from the pixmap == decor_w background. Otherwise, transparency doesn't work. > do the mapping Okay. > When resizing/shading > resize the extra windows > create backround pixmaps for each and set > reparent the extra windows in to the frame window Okay. > restack the extra windows Not a good idea since this would flicker. Instead, the windows have to be added in the correct order or in the correct stacking position. > create the frame background pixmap from the colorset/tiled-pixmap > without any frame marks > set the new pixmap to the frame window (no need to refresh) frame == decor_w again > perform the resize/shade loop > create the frame background pixmap from the colorset/tiled-pixmap > and include the relief marks for the new size > unmap the 40 extra windows Okay (except the count). > reparent them back to the root (optional I think) Necessary. Otherwise they might die when a window is killed and have to be created again, and - worse - they make Enter/LeaveNotify handling and the GetContext() function a lot more complicated. > I think you can restack windows before mapping them, hopefully this > means that a careful restack followed by mapping in the right order > would result in no visible sign that the extra windows had mapped over > the frame window reliefs and marks (it's going to be laborious to check). > > I don't think you can use XMapSubWindows of the frame window since that > may map subwindows of the client (someone correct me please), if you > keep the decor window then it's OK and might make the restacking easier. I don't think XMapSubwindows recursively maps sub windows of its children. I have to look that up in the O'Reilly book. The man page doesn't say anything about it. > Unmapping the extra windows after the frame window has it's new > background set should also not give any visible sign that the extra > windows have gone away. That should work. The only disadvantage I see is that during opaque resizing, the extra windows are reparented twice for each animation step (not to speak of all the creation and destruction of pixmaps). But some pice of clever logic might prevent that. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
