Subject: CVS domivogt: * Refresh and RefreshWindow functions flush style updates.

From: CVS <[email-masked]>
Date: Tue, 2 May 2000 21:42:01 -0500 (CDT)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	domivogt	00/05/02 21:42:00

Modified files:
	.              : ChangeLog NEWS 
	docs           : ChangeLog FAQ 
	fvwm           : builtins.c conditional.c functions.c 
	                 functions.h fvwm.h fvwm2.1 move_resize.c 
	                 move_resize.h window_flags.h 
	libs           : Parse.c Parse.h 
	modules        : ChangeLog 
	modules/FvwmAuto: FvwmAuto.c 
	modules/FvwmWinList: FvwmWinList.1 FvwmWinList.c 

Log message:
* Refresh and RefreshWindow functions flush style updates.
* Some enhancements and new options to Move and Resize commands (see NEWS and
ChangeLog).
* New command MoveResize.
* New condition MovedButton3.
* Removed latest FvwmAuto hack (Mikhael, please look at the comment in the code).
* Fixed FvwmWinList placement w/ TitleAtBottom and negative y geometry.

--
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: Fri, 5 May 2000 02:03:43 +0300

> * Refresh and RefreshWindow functions flush style updates.

Very good. It is now possible to implement the original MaximizeFullScreen
example without RecaptureWindow. Still there is an unrelated problem when
restoring the original title/border/handle style settings, which is
currently impossible to do without hardcoding. Probably this can be
solved later together with individual window styles.

> * New condition MovedButton3.

All good enhancements. Does any other WM have such flexibility? :)

> * Removed latest FvwmAuto hack (Mikhael, please look at the comment in the code).

Actually this is not quite a hack, but a fix of a broken behavior, when
non raise/lower actions are ignored for already raised/lowered windows.
I cleaned up comments and enabled this fix with your correction.
I think, the current detection in FvwmAuto is acceptably good, it works as
expected in most cases, and can be reversed by specifying another name.

> * Fixed FvwmWinList placement w/ TitleAtBottom and negative y geometry.

Yes, it works correctly now.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 5 May 2000 01:24:36 +0200

> solved later together with individual window styles.

What is the problem?

> All good enhancements. Does any other WM have such flexibility? :)

Hardly.  That what fvwm is all about, right? :-)

> expected in most cases, and can be reversed by specifying another name.

Ugh, of course.  Can you please *document* this behaviour in
the man page?

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: Mikhael Goikhman <[email-masked]>
Date: Fri, 5 May 2000 03:27:15 +0300

> > solved later together with individual window styles.

I believe, this problem is not for 2.4. Here it is since you ask.

# -------------------------------------------------------------
Key F11 W SC MaximizeFullScreen
Key F12 W SC UnMaximizeFullScreen

DestroyFunc MaximizeFullScreen
AddToFunc   MaximizeFullScreen
+ I Style $n NoTitle, NoHandles, BorderWidth 0
+ I WindowId "$w" RefreshWindow
+ I WindowId "$w" Maximize true

DestroyFunc UnMaximizeFullScreen
AddToFunc   UnMaximizeFullScreen
+ I WindowId "$w" Maximize false
+ I Style $n Title, Handles, BorderWidth 5
# =============================================================

As you can see, the last line is hard-coded, you can't just restore the
previous state for title/handle/border. Possible solution: to add UnStyle
command (or DestroyStyleOptions), undoing last style entries having
specified style options. But giving the current merging, this can work
only for Style on individual windows, i.e. [Un]Style (WindowId $w) ...

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 5 May 2000 07:29:20 +0200

> I believe, this problem is not for 2.4. Here it is since you ask.

Gack! Um, why would you want to do that?  I guess that's the
case for each and every style that does not simply toggle a
flag.

Bye

Dominik ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 5 May 2000 23:30:18 +0300

> case for each and every style that does not simply toggle a

These functions implement Alt-Enter in some known OS (this was a request
from someone). But unlike this OS, where all windows have the same decors,
fvwm can have windows with and without titlebar/handle/border. After
S-C-F11 & S-C-F12 you should get the original decors (not toggle, undo).

Do you have a better solution? Actually, I think, an idea with undo-able
Style commands (using UndoableStyle, disallowing merging, and UndoStyle)
is good by itself. It can be used, for example, by a simple interface for
applying individual window styles with a possibility to try and cancel.
An alternative implementation of UndoStyle can be StoreStyle, RestoreStyle.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 6 May 2000 09:02:19 +0200

> An alternative implementation of UndoStyle can be StoreStyle, RestoreStyle.

The style code was no written to be undo-able, you know.  You are right,
we don't want to think about this before 2.4 :-)

Bye

Dominik ^_^