Subject: FVWM: Key binding to raise specific window?

From: "Jed S. Baer" <[email-masked]>
Date: Sun, 7 Jul 2002 11:40:05 -0600

Greetings.

First off, taking a queue from Maddog Hall, many thanks to the Fvwm
developers. I try other WMs from time to time, and keep coming back.

I'm using v 2.2.5

What I would like to be able to do is bind a key to a function which would
raise my fvwmbuttons. For the sake of having as much usable screen area as
possible, I have it set so that it can be obscured by other windows. (no
autoraise going on, and sometimes I completely obscure it anyway)

Style "FvwmButtons"	NoTitle, NoHandles, StaysPut, Sticky, \
			CirculateSkip, BorderWidth 0, \
			WindowListHit

So, I can warp to it from the window list, or edge-flip and get to it that
way, but I'm hoping for a faster method. But looking through the man page,
the closest I can come to this is `WindowId 0x34567890 Raise' (or warpto),
except that I don't have the window ID. Is there a function I've missed
which will return the window ID so that I can use it in a key binding? Or
maybe a SendToModule command to tell it to raise itself?

I'm starting it up this way:

AddToFunc InitFunction     "I" Module FvwmButtons
AddToFunc RestartFunction  "I" Module FvwmButtons

I realize that a GetWindowID("string") would suffer from the issue of
possibly matching multiple windows, but I could give FvwmButtons a unique
title at startup, and find it that way, I think.

Advice appreciated.
jed
-- 
We're frogs who are getting boiled in a pot full of single-character
morphemes, and we don't notice. - Larry Wall; Perl6, Apocalypse 5
--
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: Mon, 8 Jul 2002 00:15:28 +0200

> developers. I try other WMs from time to time, and keep coming back.

You should consider upgrading to 2.4.8, the latest stable release.
It has a lot of fancy new stuff - and maybe equally important -
the 2.4.x series are the only supported stable releases.  Now to
your question:

> raise my fvwmbuttons.

Bind this command to a key:

  Next (CirculateHit, FvwmButtons) Raise

> For the sake of having as much usable screen area as

The WindowId command is mainly used with modules like FvwmEvent or
FvwmAuto.  They have an option to append the window id to the
commands they send to fvwm.  Also, you can reference the window id
with the '$w' variable in commands, for example:

  Mouse 1 5 n Echo $w

Prints the window id when title button 5 is pressed.  It's usually
only needed in complicated setups.

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" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 8 Jul 2002 11:52:36 +0200

On Sun, Jul 07, 2002 at 11:33:28PM -0600, Jed S. Baer wrote:
> On Mon, 8 Jul 2002 00:15:28 +0200
> Dominik Vogt <[email-masked]> wrote:
> 
> > > I'm using v 2.2.5
> > 
> I actually installed 2.4.7 from the Sourceforge RPM. I encountered some
> minor problems with it, and went back (this was just this morning, after I
> posted my question). I guess it would be inconsiderate of me to mention
> that, without mentioning what they were, so here goes.
> 
> I was somewhat disappointed that I couldn't install the RPM without first
> obtaining libstroke. I know a lot of people consider it to be really
> nifty, but at some point I just get tired of having to intall yet another
> piece of software I'll never use on my system, to be able to get something
> else I do use. I don't mean that to sound like a criticism, and I hope
> that should I decide to build from source, that --disable=libstroke, or
> it's equivalent, is an option. But at the moment, I'm not going to
> download the tarball for the sake of making that discovery - I have very
> limited network bandwidth. I have to admit though, that it's pretty
> unlikely that I'll build from source.

Then you unfortunately have to live with the options that were
compiled into the rpm.  We can't supply one rpm for each
combination of options (millions).

> There is a difference in the way menus are drawn. I don't know if it's a
> bug. I looked through the 2.4.7 NEWS file for any mentions of menu changes
> that sounded like what I was seeing, and didn't see any.
> 
> MenuStyle * FVWM
> MenuStyle * Foreground seashell, Background DarkSlateGrey
> MenuStyle * Greyed DarkSlateBlue
> MenuStyle * Font -adobe-utopia-medium-r-*-*-19-*-100-100-*-*-iso8859-*
> MenuStyle * MenuFace DGradient 128 4 \
> 	DarkSlateGrey 10 \
> 	DarkSlateGrey 58 \
> 	SlateBlue 22 \
> 	DarkSlateGrey 10 black
> MenuStyle * SidePic /home/jbaer/images/sideflash.xpm
> 
> MenuStyle msmaug FVWM
> MenuStyle msmaug Foreground seashell, Background DarkSlateGrey
> MenuStyle msmaug Greyed DarkSlateBlue
> MenuStyle msmaug Font
> -adobe-utopia-medium-r-*-*-19-*-100-100-*-*-iso8859-* MenuStyle msmaug
> MenuFace DGradient 128 4 \	DarkSlateGrey 10 \
> 	DarkSlateGrey 58 \
> 	SlateBlue 22 \
> 	DarkSlateGrey 10 black
> MenuStyle msmaug SidePic /home/jbaer/images/dgreen_grad.xpm
> 
> A menu of style msmaug has a vertical bar, the width of the pixmap, the
> color DarkSlateGrey, running along the left side, while other menus don't.
> I realize my responsibility as a user is to provide good bug reports, but
> please understand that at the moment, there are very good reasons why I'm
> not able to do so. My apologies. dgreen_grad.xpm is transparent, except
> for some greek letters running vertically. I don't imagine it matters that
> they're greek - any 5 letter word would do, or any arrangement of
> non-transparent pixels for that matter. At any rate, I like the way this
> looks in 2.2, but not in 2.4. I should be able to easily reproduce it at a
> later time. How much later, I can't say just now.

I tested this with the latest development code, and there is
definitely a bug somewhere.  Sometimes the msmaug MenuStyle is
applied to the wrong menus, sometimes it's not applied to the
correct menus.  It seems completely random.  When I scroll through
my RootMenu, sometimes the submenus get the menustyle and
sometimes they don't.  It's clearly a bug.  I'll look into it when
I have the time.

> And, 2.4.7 apparently has problems with swallowing xdaliclock:
> 
> *FvwmButtons(2x1 Swallow xdaliclock 'Exec /usr/local/bin/xclock')
> 
>  -- /usr/local/bin/xclock --
> 
>   xdaliclock -24 -noseconds -visual best \
>     -memory low -bg deepolive -fg palegold \
>     -font -*-lucidatypewriter-medium-r-normal-*-15-*-100-100-*-*-*-* \
>     -geometry 60x20 &

That command is not correct:

  $ xdaliclock -24 -noseconds -visual best -memory low \
    -bg deepolive -fg palegold -font \
    -*-lucidatypewriter-medium-r-normal-*-15-*-100-100-*-*-*-* \
    -geometry 60x20
  zsh: no matches found:
  -*-lucidatypewriter-medium-r-normal-*-15-*-100-100-*-*-*-*

Since the font name contains wildcards, you have to quote it:

  $ xdaliclock -24 -noseconds -visual best -memory low \
    -bg deepolive -fg palegold -font \
    "-*-lucidatypewriter-medium-r-normal-*-15-*-100-100-*-*-*-*" \
    -geometry 60x20

Bye

Dominik ^_^  ^_^

P.S.: Pleasse always reply to the mailing list, not to my private
address.  I usually bounce any such messages to the list anyway.

 --
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: Dominik Vogt <[email-masked]>
Date: Tue, 9 Jul 2002 11:16:23 +0200

On Mon, Jul 08, 2002 at 12:11:03PM -0600, Jed S. Baer wrote:
> Well, bash doesn't mind. Maybe bash doesn't do wildcard expansion on
> command qualifiers? Whether it's a problem would also depend partly on how
> Fvwm invokes the shell process.

As /bin/sh unless told otherwise.  You're right, /bin/sh should
run this command, but quoting is a good idea anyway.

> I know, but unfortunately can't find the
> reference at the moment, that it's possible to invoke a shell (at least
> bash, anyway) in manner which disables various normal shell processing.
> Also, a quick read of the bash manpage indicates that * is expanded only
> when it is introduced by '$', i.e. '$*', making it a parameter, or as part
> of pathname expansion or pattern expansion. So, I'm concluding that bash
> doesn't see the * as being in any context it uses for expansion or
> substitution.
> 
> Regardless, it works fine without quoting in 2.2.5, but not reliably in
> 2.4.7.

> Is there a difference in the way the Exec function is implemented?

No.  Swallowing works very reliable if two conditions are met:

  (a) The application starts up fine.
  (b) The window has the title/class/resource specified in the
      hangon string.
  (c) The window is not swallowed by someone else.

If it does not work, make sure each of these conditions are met.

> I'm tempted to re-install 2.4.7 (what I have handy) and run it
> with -debug.

Forget -debug it's not useful for anybody, including us
decvelopers.  

> Later,

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 9 Jul 2002 10:39:24 +0000

> If it does not work, make sure each of these conditions are met.

Actually there is one more condition (a feature or a bug).

If you have the following line (without UseOld):

  *FvwmButtons: (Swallow "xload"   `Exec xload -fn fixed`)

and a window matching "xload" already exists when you start FvwmButtons,
you end up with 2 xload windows, none is swallowed. The only relable
way currently to swallow something new is:

  *FvwmButtons: (Swallow "xload"   `StartApp "xload" "xload -fn fixed"`)

  AddToFunc StartApp
  + I All ("$0") Close
  + I Exec $1

Regards,
Mikhael.