Subject: Patch submissions for fvwm-2.2.2

From: Mark Rainford <[email-masked]>
Date: Thu, 01 Jul 1999 11:33:14 +0100

Hi fvwm workers,

Attached please find two fvwm-2.2.2 patches which may be of interest.

Our site recently made a wholesale transition from Motif MWM-1.1.4 (yup,
that's old) to fvwm. The users love it: the config we devised presents
an almost identical look and feel to their old WM environment, while
opening up the glorious possibilities of fvwm - plus we avoid the cost
of new licenses, and too great a culture shift for the poor users (CDE).

*BUT* applications which relied on specific Motif behaviour suffered,
hence these two patches.

Patch:    MWMConstrainSize
Aim:      Limit maximum window size to that of the screen
Why:      Lazy programmer made his app. full screen on all sizes of
glass
          by configuring a huge window - Motif would clip to size of
screen.
Wibn:     I'd really like to make this a window style option, but it
looks
          like all the "name_list_struct" flags have been grabbed,
          or am I missing something?
Wibn2:    Style option to govern round up/down for windows with size
increment,
          but same flag famine.

Patch:    MWMTransients
Aim:      Transients always above their main window; all Raise/Lower
together 
          as a group (possibly tree) of main+transients. OnTop stacking
order
          handled as part of the same deal.
Why:      Full screen app. should not be allowed to hide secondary
windows,
          esp. warning boxes.

Applying the patches:
=====================
Recursive diff used as >1 file per patch.

	cd fvwm-2.2.2
	patch -p1 < patch_file

Apologies
=========

1) Sorry about the context diff: mah diff don't do -u.
2) Sorry about the handwritten ChangeLog entry: me no emacs
Ctrl+Shift+_+Speak
3) I'm no WM or X expert, just the sucker who got landed with pacifying
the users.
-- 

Regards,  Mark.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 1 Jul 1999 13:17:38 +0200

> of new licenses, and too great a culture shift for the poor users (CDE).

8-)

Would you be willing to contribute the customized config file(s) to
the fvwm project?

> *BUT* applications which relied on specific Motif behaviour suffered,

Did you see any bugs with such applications? We are always interested
in making fvwm just a little better.

Now to the patches:

The bad news is: the development code of fvwm has undergone massive
changes since 2.2, especially regarding style and flag code. So the
chance of applying your patch with little effort is about zero. The
good news: the 'out of flags' thing has been addressed and is no
longer a problem. Furthermore in the development code most of what
your patch does is already implemented.

>           by configuring a huge window - Motif would clip to size of

The MaxWindowSize command showed up around fvwm-2.3.3 or so. Currently
we are working on 2.3.5, but this is considered *alpha* code. We are
closing in on 2.4, the next stable release however (within two month
I hope).

> Wibn2:    Style option to govern round up/down for windows with size

Are these styles really needed?

>           handled as part of the same deal.

Can you elaborate what the patch does? Stacking order and OnTop handling
has been modified heavily since 2.2. I think the 'RaiseTransient' style
that will be in the 2.3.5 release does what you want (with a bit of
improvement). It doesn't affect lowering transients, but if wouldn't
be too much work to implement this too.

Would you update the patch for 2.3.5 to implement a LowerTransient
style? (Hint: you will have to touch the files style.c, stack.c,
style.h, window_style.h, fvwm.h, fvwm2.1, possibly ConfigFvwmDefaults)

> Why:      Full screen app. should not be allowed to hide secondary

Some users see this very differently. Try out the RaiseTransient style
once 2.3.5 is available (remeber: *alpha* code).

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-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: Mark Rainford <[email-masked]>
Date: Fri, 02 Jul 1999 19:24:14 +0100

Dominik 

> > ... The users love it: the config we devised presents
> > an almost identical look and feel to their old WM environment ...
> 

No problem: config attached (somewhat lagging behind fvwm abilities).
I'm afraid it does not correspond strictly to Motif defaults owing to
inexperienced twiddling when we first moved to X11 many years ago. You
won't want the JET_applications stuff, but it illustrates our usage.
User's get to override this system-wide config from a file in their
home, and they have exclusive use of mouse btn 2 on the root window.
We've adopted Ctrl+Alt+some_key for things like viewport and desk
navigation.

> in making fvwm just a little better.

No bugs, just the behaviour differences addressed by the patches. Oh,
and one thing I don't quite understand to do with a client call to
XMapRaised() going unnoticed by fvwm - but I haven't firmed up the
details yet.

> .... fvwmm has undergone massive changes since 2.2
> ... chance of applying your patch with little effort is about zero

OK

> > Wibn:     I'd really like to make [constraint] a window style option ...

No, but now that more flags are available (thank you) I can patch away
here if necessary. Just to explain, though

Wibn: we don't need to constrain *all* apps to the screen size - a style
option seems to offer maximum flexibility for choosing which do and
which don't.

Wibn2: I boobed having chosen to round up - on the grounds my maximised
xterm pushed just a couple of pixels outside the root window, and the
next smaller increment size looked silly. Unfortunately, a local emacs
user found his command buffer was rounded off the bottom of the screen.

> > Patch:    MWMTransients
> 
> Can you elaborate what the patch does?

1) A transient (subwindow) always appears above its transientfor (main)
window.

2) Transient siblings can move above each other, but are always above
main.

3) Since a transientfor (main) window can itself be a transient of
another window, we may have a tree of transient windows + one
non-transient main.

4) Raise/Lower on any window in the tree moves all windows in the tree
as a group (the Motif behaviour we seek), somewhat similar in essence to
the (de)iconfiy behaviour already in fwvm.

5) A window which is not "ONTOP" never appears above an ONTOP window -
done in the patched Raise/LowerWindow() rather than in KeepOnTop().

6) The presence of an ONTOP window in a tree of main-plus-transients
makes the whole tree of windows behave as if they are ONTOP (but without
changing their ONTOP flag) - possibly overkill, but arguably correct. I
bet you're yawning now.

> Would you update the patch for 2.3.5 to implement a LowerTransient style?

I'm happy have a go.

> Some users see this very differently.

Point taken. I'm all for flexibility.

Thanks for answering. I look forward to trying out 2.3.5 .

-- 

Regards,  Mark.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 3 Jul 1999 15:51:09 +0200

> XMapRaised() going unnoticed by fvwm - but I haven't firmed up the

That would happen if the client declares its window to 'override redirect'.
The window manager is not notified about such windows.

> Wibn:
  ^^^^^

What does that mean?

> we don't need to constrain *all* apps to the screen size - a style

Hm, yes. It would be better to constrain only certain windows. A style
won't hurt. It's no more difficult than a style.

> user found his command buffer was rounded off the bottom of the screen.

That depends on if you resize the window interactively (ronded up) or
with the 'Resize x y' command (rounded down). I'm not sure if the patch
for this was in 2.2 already. I'd rather not touch this because there is
to satisfying solution anyway.

> 2) Transient siblings can move above each other, but are always above

Hm, you should have a look at 2.3.5 when it's out and compare its
possibilities whith what you want. I guess most of the work is already
done.

> another window, we may have a tree of transient windows + one

Ooh, sounds ugly. Does this ever happen? I had thought of this as
a theoretical possibility.

> the (de)iconfiy behaviour already in fwvm.

Raising already works this way (with the RaiseTransient style). Lowering
would require a similar 'LowerTransient' style. But I don't understand
how you can fulfill (2) and (4) at the same time. Either lowering a
transient lowers it below its fellow transients (2) or it lowers the
complete tree (4). How can it do both at the same time?

> changing their ONTOP flag) - possibly overkill, but arguably correct.

The 'StaysOnTop' style is obsolete with 2.3.x. There are now so called
'layers' on which to arrange your windows. A window on a higher layer
is always above windows on lower layers. 

> > Would you update the patch for 2.3.5 to implement a LowerTransient style?

I'd like to have raising/lowering of transients straight in 2.4. Perhaps
we can work together to find a smooth solution before 2.4. I will build
2.3.5 this weekend so you can inspect the code and see what is needed
(but be warned, there is a bug in the RaiseLower function that prevents
windows from being lowered when they are not fully on the screen).

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]