Subject: handlewidth help request

From: Dominik Vogt <[email-masked]>
Date: Mon, 8 Nov 1999 18:32:24 +0100

Yesterday I tried to understand how a window is placed
depending on the handle width and the decorations.  What
I want to do is to be able to change the handle/border
width without a recapture.  Bob (W.) or anybody else who
knows the code better than me, can you help me out here?
In the end I would need a new function that does the
following:

  - take a style and an existing, decorated FvwmWindow as input
  - returns the new geometry of the FvwmWindow
  - takes changed border/handle width into account
  - takes into account that the title may have been (de)activated
  - honours the initial gravity (perhaps with the modification
    that a window that has been moved will always have NW
    gravity)

I'd be very, *very* grateful if someone came up with such a
function.  The biggest problem is that the frame must be
resized, it cannot be destroyed.  Thus much of the work in
add_window.c has to be duplicated.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [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: Bob Woodside <[email-masked]>
Date: Tue, 09 Nov 1999 10:02:59 -0500

Dominik Vogt wrote:
> depending on the handle width and the decorations.

	I'm sorry....  :-)

>                                                     What

	I'd like to help here. Unfortunately, my system is, ah, rather unstable
at the moment. I'm in the middle of a long-overdue libc5 -> Glibc2
conversion, and there are more than a few things that are still
broken...and probably a few yet to be broken.

	If anyone else would be willing to take a look at this, *please* do so.
If not, I'll look into it as time permits, once I have a stable
system...but I can't predict how long that will be. :-(

> following....

	Erm...not to pick nits, but I assume that the other thing this function
does is the actual resizing of the window.

	Could you give us an hypothetical function prototype, as you envision
the function's being called?

Cheers,
Bob

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 9 Nov 1999 15:42:00 +0100

> system...but I can't predict how long that will be. :-(

Good luck. You will need it :(

> does is the actual resizing of the window.

No, not necessarily.  I'm in the process of modularizing the
code in add_window.c and some relating stuff from various
files.  It might me more flexible if I can choose when to
actually resize the window.

> the function's being called?

E.g.:

  void change_decoration_dimensions(
    FvwmWindow *tmp_win, window_style *pstyle,
    int *x, int *y, int *width, int *height);

Where x, y, width and height are the return values.  The function would
go into add_window.c.  I want to put all function necessary to create,
delete and redecorate into add_window.c in the long run.

I think the current FvwmWindow structure does not hold enough
information to write such a function.  For example the initial
gravity is overwritten as soon as the window as been placed.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Wed, 10 Nov 1999 11:23:25 +0000

> In the end I would need a new function that does the
 
How about modifying add_window() so that if given an existing window it
would resize and move the decorations rather than create windows? It
would be simpler and less bug prone than duplicating the function.

>   - takes into account that the title may have been (de)activated
This might be tricky (four cases to test)

>     that a window that has been moved will always have NW

FvwmWinList moves itself but it is important that it's original gravity
is preserved. I would vote for preserving gravity and worry about
changing to NW if anyone complains. I would expect that if someone has
specified a 200x200-0-0 geometry they would expect that changing the
border width would move the window up and left even if they moved the
window. I guess you could be clever and adjust the gravity depending on
how close to each edge the window is when it is moved.

> add_window.c has to be duplicated.

I'm happy to hack add_window so that it can resize/move the subwindows
if they exist. Let me know if I should do this, I'll make sure that the
existing use of add_window doesn't break and you can try putting it into
your style stuff.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 Nov 1999 12:44:34 +0100

> would be simpler and less bug prone than duplicating the function.

At the moment I'm following a different approach. I'm moving
all functionality of add_window() into separate functions that
can be called separately. I doubt that we could integrate even
more functionality into add_window() itself - it's already *so*
complicated.

> how close to each edge the window is when it is moved.

Yes. This would probably be the better solution.

> if they exist.

Resize/move subwindows? I don't understand what you mean.

> Let me know if I should do this, I'll make sure that the

If you wanted to say that you would write what I need: *yes*
please do it, but try not to touch the add_window() function
if possible. I want to make it simpler and more modular. I have
some uncommitted and idsruptive modifications on my disk at home
that won't merge in if we modify add_window.c now. So perhaps you
should wait until Thursday before doing anything.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Wed, 10 Nov 1999 12:08:56 +0000

> Resize/move subwindows? I don't understand what you mean.
I mean the titlebar, buttons and resize handle windows.

> should wait until Thursday before doing anything.

I'll wait.

Cheers,
Tim.