Subject: ideas about future frame layout?

From: Dominik Vogt <[email-masked]>
Date: Mon, 11 Mar 2002 11:35:04 +0100

In the next days I'll start to restructure the layout of the fvwm
frames.  Specifically, the decor_w (decor window) will go away.
But I'm not yet sure what the correct new layout is.  This is the
current situation:

The frame window has two children, the decor window and the parent
window:

              +--------------------+
              |                    |
              |                    |
              |                    |
              |       frame        |
              |                    |
              |                    |
              |                    |
              +--------------------+

  +--------------------+   ......................
  |                    |   .                    .
  |                    |   +--------------------+
  |                    |   |                    |
  |       decor_w      |   |                    |
  |                    |   |       Parent       |
  |                    |   |                    |
  |                    |   |                    |
  +--------------------+   +--------------------+

The parent window has the client window as its single child (same
size).  The decor window has nine children:  the eight handles and
the title window (title_w).  This is a zoom into the top left edge
of the decor window:

  o...........o+---------------------
  :top left   :|    top handle
  :handle     :|
  :    +-------+---------------------
  :    |      :
  :    |      :   title window
  :    |      :
  o....|......o
  |    +----------------------------
  |    |
  |    |  Parent/client window
  |    |
  |    |
    ^
    |
  right handle

The title window is raised above the handles and thus covers part
of the corer handle windows.

There are several problems with the decor window:

 - Since the border is drawn on the foreground of the frame
   itself, it is often necessary to redraw borders.  Borders
   flicker heavily during opaque resize.
 - The title buttons don't stick to their corners when the frame
   is resized.  This flickers too.

Now the draft of a solution I have come up with.  The decor window
is removed, and the title window and button windows become
children of the frame.  The border is drawn into the handle
windows by setting a backgorund pixmap.  Thus, a simple
XClearWindow() would redraw any exposed parts of the borders
without flickering.  To further reduce flickering, the cornes
handles stay invisible, and four tiny "corner pieces" are added in
the corners:

corner
piece
  o....o+----------------------------
  :    :|    top handle
  :    :|
  o....o+----------------------------
  +----+o......o
  |    |:button:
  |    |:  1   :
  |    |:      :
  |    |o......o
  |    |
  |    |
  |    |
  |    |
  |    |
  |    |
    ^
    |
 right handle

(The top left handle is not drawn for clarity.  It is a square
window that begins at the top left of the corner piece and ends at
the bottom right of button 1.)

So far, we removed one window (decor_w) and added four new ones
(the corner pieces).  However, there's no place to draw the bevels
for the handles yet.  Since they should stick to the corners, they
shouldn't be drawn into the side handles.  They would be outside
the corner pieces, and the corner handles are invisible.  I see
two solutions:

 - Draw them on the foreground of the side handles.  In this case,
   they would either flicker during opaque resize/shading or have
   to been deleted.

 - Introduce 8 (eight) new windows, each two pixels thick and as
   long as the border is thick.  Although they'd sum up to only a
   few pixels, there certainly is a memory penalty for eight
   additional windows for each frame.  On the other hand, window
   shading and opaque resizing will become absolutely prefect (not
   counting what the application does with its own windows).

I prefer the second solution, but I'm unsure about the memory
penalty.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
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-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Mon, 11 Mar 2002 16:29:50 +0000

> The frame window has two children, the decor window and the parent

An important attribute of the frame and parent windows is that they use 
the root visual, the decor window uses the fvwm visual which may not be 
the same.  The root visual is necessary to allow transparent clients 
(like rxvt) to work. If we remove the decor window the frame window will 
  have to change to the fvwm visual. I think this may upset some users 
with old software that assumes the root visual is pseudocolor but maybe 
it's time to move on and make them use something like VNC to handle 
their old apps.

> I prefer the second solution, but I'm unsure about the memory

I'm not sure of the point either, applications flicker like mad during 
opaque resizing and unshading. How about filling the border with the 
XorPixmap? There doesn't seem to be any usability in having 3D looking 
borders during a resize, you can't press the border. Having the 
XorPixmap/XorColor in the border would give a similar look to non-opaque 
resizes.

If you are going to rewrite the border stuff could we have colorsets 
supported?

Cheers,
Tim.

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 11 Mar 2002 17:00:55 +0000

I can only agree with your analize, Dominik, you are doing a nice work.

But you asked for more ideas, so here is a try. This is something similar
to what Tim once suggested, it may work well if there is a big penalty for
additional windows.

Titlebar is not discussed here, only borders.

The division to windows may be like this:

  o...+------++-----
  :l-t|  top || handle
  +---+------++-----
  | l |corner::
  | e |window::
  | f |      ::
  +-t-+......o:
  +---+.......o
  | h |
  | a |
  | n |
  | d |
    l
    e

Top and right handles are fully drawn using pixmap tiles.
Left-top tiny corner piece may be drawn using a pixmap, it is constant.

Corner window starts from the very left-top and includes both bevels
(inner 2 pixels and outer 2 pixels) on both ends.

Now the only problem is a wrong cursor in the central bevels.
This may be solved by adding one invisible corner2 window that is a bit
smaller than corner1 window and defines a different cursor.

In this solution there are only 4 additional windows, not 8.
Also I am not sure left-top corner piece is needed, it's drawing pixmap
probably may be included into corner1 window without flickering. If this
is possible, there are no additional windows at all.

So to sum it up, corner2 is invisible, corner1 has 3 unbound parts.

And while you are at it. Please add boolean NoBorder/Border style option
that is similar to NoHandle/Handle. I want to add this for some time now,
this enables to temporarily remove borders without reseting BorderWidth.

This also raises a question of disabling only parts of a border, for
example only side borders suggested by Olivier in another thread.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 12 Mar 2002 11:20:15 +0100

> But I'm not yet sure what the correct new layout is.  This is the

[snip]

> Now the draft of a solution I have come up with.

[snip]

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).  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

Without pixmap background:

 8 handles (4 side handles are drawn into, 4 corners invisible)
 4 corner pieces
 8 windows for the bevels
 ----------------------------------------------------
 = 20 windows

:-P

Bye

Dominik ^_^  ^_^

---

From: Tim Phipps <[email-masked]>
Date: Tue, 12 Mar 2002 16:11:40 +0000

[email-masked] wrote:
 > 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,

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. 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.  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
    create a pixmap for it
    draw the background into the pixmap (XFillArea with a tiling GC)
    draw the reliefs into the pixmap
    set the frame window background from the pixmap
    do the mapping

When resizing/shading
    resize the extra windows
    create backround pixmaps for each and set
    reparent the extra windows in to the frame window
    restack the extra windows
    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)
    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
    reparent them back to the root (optional I think)

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.

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.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 12 Mar 2002 17:56:43 +0100

On Tue, Mar 12, 2002 at 04:11:40PM +0000, Tim Phipps wrote:
> 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
 
> 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

  == current decor_w

>    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.

>    set the frame window background from the pixmap

 == decor_w background.  Otherwise, transparency doesn't work.

>    do the mapping

Okay.

>    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.

>    set the new pixmap to the frame window (no need to refresh)

 frame == decor_w again

>    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.

> 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.

> background set should also not give any visible sign that the extra

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 ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 12 Mar 2002 19:18:48 +0000

>  8 windows for the inner relief

I think this may be a good opportunity to discontinue this functionality.
Tiled pixmap borders as they are now just don't work. I would guess noone
likes the fact that the top and left borders look constantly, while the
bottom and right borders look randomly for different windows. It is pretty
impossible to find a good pixmap to use for tiling as it is now.

I would like to hear from anyone who uses tiled pixmaps whether he agrees
with a different approach to tiling. I personaly don't think a border look
should be dependent on the window size. I think it is better to add a
functionality to define 1, 2 or 4 tiles that are used (after a possible
manipulation) for different border sides, so they are always look constant
independently from the window size. It is ok for me that there will be 4
crossing points at corner pieces, in the future this may be configurable.

Just to illustrate, if this ascii-art pixmap is given

  +-------+
  | ooooo |
  |  o o  |
  |   o   |
  +-------+

the window with tiled borders may look like this

  +-------------------------------------------+
  | ...  ooooo  ooooo  ooooo  ooooo  ooo  ... |
  | ...   o o    o o    o o    o o    o   ... |
  | ...    o      o      o      o      o  ... |
  |     +-------------------------------+     |
  | o   |                               |  oo |
  | oo  |                               | o o |
  | o o |                               |  oo |
  | oo  |                               |   o |
  | o   |                               |     |
  |     |                               |   o |
  | o   |                               |  oo |
  | oo  |                               | o o |
  | o o |                               |  oo |
  | oo  |                               |   o |
  | o   |                               |     |
  |     |                               |   o |
  | o   |                               |  oo |
  | oo  |                               | o o |
  | o o |                               |  oo |
  | oo  |                               |   o |
  |     +-------------------------------+     |
  | ...  o      o      o      o      o    ... |
  | ...   o    o o    o o    o o    o o   ... |
  | ...  ooo  ooooo  ooooo  ooooo  ooooo  ... |
  +-------------------------------------------+

I don't warry what is drawn in the corner pieces, they may be empty.
Compare with the current ugly (IMO) look depending on the window size.

Thus the window partitioning for both tile pixmap borders and normal
window borders should be the same, similarly to what is described below.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Tue, 12 Mar 2002 14:41:09 -0500

> crossing points at corner pieces, in the future this may be configurable.

I don't disagree with your main point except to say that I think
that there are some pixmaps that look fine for borders:

http://www.fvwm.org/screenshots/Dan-desk-1280x1024.gif

There is no up or down to that texture.

> Just to illustrate, if this ascii-art pixmap is given
...
> window borders should be the same, similarly to what is described below.

Refering to  my screenshot, I've decided the  handles detract from the
overall  appearance and dispensed with  them, so I wouldn't like empty
corner pieces.

-- 
Dan Espen                           E-mail: [email-masked]
444 Hoes Lane  Room RRC 1C-214      Phone: (732) 699-5570
Piscataway, NJ 08854
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 12 Mar 2002 19:56:04 +0000

On 12 Mar 2002 16:11:40 +0000, Tim Phipps wrote:
>  > We forgot to

It will sometimes look _very_ bad (may I say unusable?) if we implement
one continuation border colorset like this.

Instead, I suggest to have 4 colorsets (one per border side) or one
colorset used 4 times (with a possible rotation). See my another message.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 11 Mar 2002 21:05:49 +0100

> The division to windows may be like this:

Let's ignore that fact, one pixel to the right or left can be
safely ignored in terms of usability.

> In this solution there are only 4 additional windows, not 8.

Mine requires 12 additional small ones minus one big window.

> is possible, there are no additional windows at all.

The corner piece and the additional bevel windows make it easy to
shade a window without flickering.  Let's assume a window with top
title is shaded.  As the window shrinks, the bevels on the left or
right are kept in the correct place.  Right before the animation
step that would cause them to cross paths their gravity is set to
UnmapGravity so that they are unmapped automatically when they
come too close together.

The same can't be done if the bevels are drawn into the corner
handles:  the handles are moved by resizing the frame, but they
cant be resized to not overlap each other in the same operation.
You'll always see one of the bevels in the wrong place before it
can be hidden:

  +---+---------
  |tl |
  |   |
  ----- <- bevel
  +---+-------- 
   br

tl = top left handle, br = bottom right handle

> this enables to temporarily remove borders without reseting BorderWidth.

Please remind me of that in a few weeks :-)

> example only side borders suggested by Olivier in another thread.

dito

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 11 Mar 2002 20:27:10 +0100

On Mon, Mar 11, 2002 at 04:29:50PM +0000, Tim Phipps wrote:
> (like rxvt) to work.

> If we remove the decor window the frame window will 
> have to change to the fvwm visual.

Why?  I don't intend to draw into the frame window, only to
reparent the individual sub windows of the decor_w to the frame.
First experiments with rxvt indicate that transparency works fine.
All I did was reparenting the windows as described and selecting
Enter/LeaveNotify on the frame instead of the decor_w.

> I think this may upset some users 
> XorPixmap?

> There doesn't seem to be any usability in having 3D looking 
> borders during a resize, you can't press the border.

It's only the looks.  If the new approach with the additional 11
windows per frame is implemented, the frame won't flicker at all,
except perhaps the title window.

> Having the 

I think thats just confusing.

> If you are going to rewrite the border stuff could we have colorsets 

Sure, if someone codes it ;-)  No, I have no reasons against it,
but if someone else doesn't do it I don't know when I can finde
the time.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 11 Mar 2002 20:27:10 +0100

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 11 Mar 2002 21:05:49 +0100

+---+---------
  |tl |
  |   |
  ----- <- bevel
  +---+-------- 
   br

dito

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 12 Mar 2002 22:56:24 +0000

> There is no up or down to that texture.

Yes, it may work well if:

  * large monotonous "random noise" tile is used
  * wide border width is specified (wider than the average noice size?)
  * a user likes such kind of "flying" borders (with no up and down)

For all other cases it does not seem to produce a good result. With a new
approach any pixmap may be used.

I think the pixmaps with no up and down should work well in a new approach
too. The benefits are: less random look and almost perfect opaque resize
and shading (because almost no parts of the border are changed).

The only problem I see is how to nicely fill the tiny corner pieces...
I would like to solve this to the everyone's satisfaction if possible.

In the end it will be up to Dominik to decide whether to implement one or
another tiling aproach or both. I think the previous try at border tiling
was not successful to be a general solution and thus may be replaced.

Regards,
Mikhael.

---

From: Tim Phipps <[email-masked]>
Date: Wed, 13 Mar 2002 16:02:43 +0000

> reparent the individual sub windows of the decor_w to the frame.

Sorry, I misunderstood. I thought your comment on pixmap borders meant 
that the pixmap would be drawn in the frame window and the sub windows 
would only be used for the 3d reliefs (so only 1 or 2 pixels wide/high).

Cheers,
Tim.