Subject: FVWM: Changing titlebar buttons based on window state?

From: Len Philpot <[email-masked]>
Date: Thu, 5 Sep 2002 21:28:39 -0500

I have the following defined in my .fvwm2rc :

Mouse   0       1               A       Menu Window-Ops2 Close
Mouse   0       2               A       Close
Mouse   0       4               A       Maximize
Mouse   0       6               A       Iconify

# lightning bolt - system menu
ButtonStyle 1 8 35x15@1 20x50@1 40x50@0 30x80@1 75x40@0 50x40@1 75x15@0 35x15@1
# x - Close
ButtonStyle 2 17 20x20@1 30x20@1 50x40@1 70x20@1 80x20@1 80x30@0 60x50@0 80x70@1 80x80@0 70x80@0 50x60@0 30x80@0 20x80@0 20x70@0 40x50@1 20x30@0 20x20@1
# downward triangle - minimize
ButtonStyle 6 4 50x75@1 25x25@1 75x25@1 50x75@0
# large square - maximize
ButtonStyle 4 5 25x25@1 25x75@1 75x75@0 75x25@0 25x25@1
# small square - restore
#ButtonStyle 4 5 40x40@1 60x40@1 60x60@0 40x60@0 40x40@1

(swiped straight from the website and sample files, obviously)

What I want to do is use the small square for button 4 if the window is
fullscreen and the large square if it's neither fullscreen nor
iconified. I feel certain this is in the man pages somewhere, but I've
yet to come across it. I have no idea how to approach this.

I'd still like to work on (which may or may not be doable) :

* How to make windows resizable by dragging on the borders, in
  addition to the corner handles (and disabling moving via borders)

* How to make a window truly maximize, rather than stop a few pixels
  short of fullscreen; a nice touch would be to make it _really_
  maximize, with no border showing and no movement possible while
  maximized

* How to either get FvwmTaskBar to swallow FvwmPager, or remove the
  border from FvwmPager (there is also some difficulty in getting focus
  to return to a window after using the pager)

* How to remove the biff applet and clock from FvwmTaskBar

* How to remove the title and geometry info from the WindowList menu but
  still have it pop up centered on the screen

* How to prevent the menu selection from automatically following the
  mouse pointer and vice-versa

* How to get vector buttons to appear in a different color than the
  titlebar

* How to make the handles thicker than the border

...but I'll work on these personal preferences as time allows. :)

Thanks for any advice on my first (real) question. Any input on the
subsequent wish list is appreciated (particularly if something is known
not possible).

-- 
+-----------------------------------------------------+
|  Len Philpot       ><>         http://philpot.org/  |
|  [email-masked]     [email-masked] (alt)  |
+-----------------------------------------------------+
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 6 Sep 2002 10:41:38 +0200

> yet to come across it. I have no idea how to approach this.

It's the default on button 2.  If you want the same on another
button you have to tell fvwm about it.  Try this:

  ButtonStyle 4 - MWMDecorMax
  AddButtonStyle 4 5 25x25@1 25x75@1 75x75@0 75x25@0 25x25@1

>   addition to the corner handles (and disabling moving via borders)

Find the function in your config files that defines the action on
the window borders.  You should have something like

  Mouse 1 F N <resize command>
  Mouse 1 S N <move command>

Change this to

  Mouse 1 FS N <resize command>

>   short of fullscreen;

Not at all.  Windows often define their font size and want to be
resized in multiples of it.  The gap is there when the screen size
isn't a multiple of the font size.  Just get used to it.

>   a nice touch would be to make it _really_

There are some commands and styles in 2.5.x that make it possible,
but I don't have the time to check it right now.  I think Mikhael
already wrote a setup for this.

> * How to either get FvwmTaskBar to swallow FvwmPager,

The taskbar can't swallow anything.

>   or remove the

  Style FvwmTaskBar HandleWidth 0, BorderWidth 0
 
> * How to remove the biff applet and clock from FvwmTaskBar

The clock can't really be switched off, but can be made to just
print an empty string:

  *FvwmTaskBar: ClockFormat
  *FvwmTaskBar: UpdateInterval 1000000

The second line prevents that the clock is ever updates, saving
some CPU cycles.  To turn off the mail indicator:

  *FvwmTaskBar: MailBox None

>   still have it pop up centered on the screen

Find the WindowList command in your config file.  Add the
"NoGeometry" option.  You may be using the default Alt-Tab
binding.  In this case just put this in your config file:

  Key Tab A M WindowList Root c c NoDeskSort NoGeometry

>   mouse pointer and vice-versa

Use a different window manager ;-)  Like it or not, fvwm's menu
handling is tightly coupled with the position of the pointer.
Unless you'd like to spend about a month to change that you can't
do anything about it.

> * How to get vector buttons to appear in a different color than the

This should be possible with colour sets, but I'm not sure if
they work in title buttons.  Mikhael?

> * How to make the handles thicker than the border

Not with fvwm.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 6 Sep 2002 09:39:47 +0000

>   AddButtonStyle 4 5 25x25@1 25x75@1 75x75@0 75x25@0 25x25@1

Actually, Len wanted to have different vectors for toggled states.

Here is how to add a new button number 3 that shades a window and looks
differently when shaded or not:

  Style "*" MWMButtons  # button relief follows the state

  Style * Button 3  # Button 1, Button 2, Button 3, Button 4, Button 6

  ButtonStyle 3 ActiveUp          Vector 8 40x80@1 40x50@1 20x50@1 50x20@1 80x50@0 60x50@0 60x80@0 40x80@0
  ButtonStyle 3 ActiveDown        Vector 8 40x80@1 40x50@1 20x50@1 50x20@1 80x50@0 60x50@0 60x80@0 40x80@0
  ButtonStyle 3 Inactive          Vector 8 40x80@1 40x50@1 20x50@1 50x20@1 80x50@0 60x50@0 60x80@0 40x80@0
  ButtonStyle 3 ToggledActiveUp   Vector 8 40x20@1 40x50@1 20x50@1 50x80@1 80x50@0 60x50@0 60x20@0 40x20@1
  ButtonStyle 3 ToggledActiveDown Vector 8 40x20@1 40x50@1 20x50@1 50x80@1 80x50@0 60x50@0 60x20@0 40x20@1
  ButtonStyle 3 ToggledInactive   Vector 8 40x20@1 40x50@1 20x50@1 50x80@1 80x50@0 60x50@0 60x20@0 40x20@1

# I plan to add "Normal" and "Toggled" shortcuts for window states, so it
# would be possible to reduce these 6 lines above to just two in 2.5.4+.
# It is already possible to reduce this to 4 lines in cvs.

  ButtonStyle 3 - MWMDecorShade  # MWMDecorMax for the maximizing button

  Mouse 1     3     A       WindowShade toggle
  Mouse 2     3     A       WindowShade true
  Mouse 3     3     A       WindowShade false

>   Mouse 1 FS N <resize command>

Actually this default is in our ConfigFvwmDefaults. I really think this is
a bad default, not very consistent and not very functional. Something like
this would be more consistent and functional:

  Mouse 1 FS A SomeComplexFunctionDoingResize
  Mouse 2 FS A SomeComplexFunctionDoingMove

Try to use "A" instead of "N" whenever is possible, otherwise you end up
with FAQ #0.1.

> isn't a multiple of the font size.  Just get used to it.

Maybe it is possible to have an option to keep 2 geometries for a window,
one is the real one and another for decorations, the gap may be filled
with some colorset. But this is complex and probably not very intuitive.

> already wrote a setup for this.

It is possible to do with 2.4.x too, but the if-else is tricky in 2.4.x
and additionally BorderWidth should be hadcoded and handles are forced:

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

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

2.5.x has no such problems (except that individual styles would not hurt):

  DestroyFunc MaximizeFullScreen
  AddToFunc   MaximizeFullScreen
  + I ThisWindow (Maximized) Style $n Title, Border
  + I CondCase (NoMatch) Style $n NoTitle, NoBorder
  + I CondCase (NoMatch) Raise
  + I CondCase (NoMatch) UpdateStyles
  + I Maximize

> they work in title buttons.  Mikhael?

This is tricky. There is no separate colorset for buttons for now.
In 2.4.1+ vector buttons may use 4 colors, but they are not different than
the ones titlebar uses. These colors are @0, @1, @2, @3 for sh, hi, bg, fg
and they are taken from "Style <pattern> Colorset <c>" if it is defined.

It is possible however to combine several tactics to separate colors of
button vectors from anything else by defining separate BorderColorset (to
let vectors and buttons to use separate colorsets) and define TitleStyle
to use different colors than colorset <c>. This colorset <c> is also used
by default in pager, so depending on the needs this may be changed too.

Another solution is to use images for decorations.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 6 Sep 2002 12:49:49 +0200

> with some colorset. But this is complex and probably not very intuitive.

And it won't work reliably either.  By the way, the reason why
this usually works with windoze is that windoze applications
usually don't specify a font size.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 6 Sep 2002 12:38:40 +0200

> Unless you'd like to spend about a month to change that you can't

I am afraid that I do not understand the question and the answer.
But, the following behavior is interesting: popup a menu A with an
entry _e which popup a sub-menu B. Popup the menu B, then click on the
entry _e. Then the menu selection does not follow the pointer on the
menu A and its parents neither on the submenus that B can popup (to
activate an entry in these menus just click on it).  The mouse pointer
is followed only in menu B.  To "dynamically" restore the default
behavior just re-click on the entry _e.
Something like "MenuStyle * PopupOffset -6 100" may help. There are
also others "popup" options to MenuStyle that you would like to use.

Regards, Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 6 Sep 2002 12:12:46 +0200

> with some colorset. But this is complex and probably not very intuitive.

Maybe we can add a FullyScreen command or option to Maximize in 2.5.x:
The cmd will remove the title and the borders, maximize the window,
and add flat borders so that it seems "fullscreen". Of course there is
an 1 pixel out of visible screen small pbs. Indeed, we can save the
original title/borders parameter as the original geometries are saved
with maximize.

I suggest a [email-masked] follow up.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 6 Sep 2002 13:22:18 +0200

> I am afraid that I do not understand the question and the answer.

Len refers to fvwm's habit to warp the pointer to the selected
menu item when using the keyboard.

> behavior just re-click on the entry _e.

That's a feature.  Clicking on a submenu entry locks the selection
in that submenu until you click somewhere else.  The patch was
inspired by the way menus worked in netscape 4.x.

Bye

Dominik ^_^  ^_^

---

From: Len Philpot <[email-masked]>
Date: Fri, 6 Sep 2002 06:58:18 -0500

> isn't a multiple of the font size.  Just get used to it.

I'll take a closer look at all of your recommendations once I get home
from work this afternoon - Thanks for all the input.

By the way, please understand - By posting such questions, I'm not
criticizing nor complaining... just asking about little details that are
mostly my personal preferences. I'm sure others feel differently and
have different ideas about such things. That's fine with me. I've read
through all the man pages at this point, but I'm sure I'm yet to really
recognize and associate the capabilities of one module when used against
another, etc., etc.

Thanks again.