Subject: FVWM: [fvwm-2.0.42] FvwmButtons and swallowed apps / styles

From: Mark Borges <[email-masked]>
Date: 22 Apr 1996 12:02:28 -0600

In fvwm-2.0.41, this style line:

  Style "xbuffy" NoTitle,NoHandles,Sticky,WindowListSkip,RandomPlacement

and this resource:

  *FvwmButtons(2x2) - NULL Swallow "xbuffy" Exec xbuffy -priority 16

would make the transient pop-up windows (i.e., those created by xbuffy
when a mailbox button is pushed) come up undecorated. This fails in
fvwm-2.0.42, i.e., they come up with a titlebar.

Anyone know what could have changed? How can I get the old
(undecorated transient pop-ups) behavior back? 

-- 
  -mb-
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: <[email-masked]> (Charles Hines)
Date: Mon, 22 Apr 1996 14:10:29 -0400

>>>>> "Mark" == Mark Borges <[email-masked]> writes:

Mark> In fvwm-2.0.41, this style line:
Mark>   Style "xbuffy" NoTitle,NoHandles,Sticky,WindowListSkip,RandomPlacement

Mark> and this resource:

Mark>   *FvwmButtons(2x2) - NULL Swallow "xbuffy" Exec xbuffy -priority 16

Mark> would make the transient pop-up windows (i.e., those created by xbuffy
Mark> when a mailbox button is pushed) come up undecorated. This fails in
Mark> fvwm-2.0.42, i.e., they come up with a titlebar.

Mark> Anyone know what could have changed? How can I get the old
Mark> (undecorated transient pop-ups) behavior back?

Do you have 'Style "*" DecorateTransients' in your .fvwm2rc by any
chance?  I just checked to make sure I wasn't putting that in as a
default, and I'm not, so I'm not sure what could have caused this
change in behavior.

You could try adding 'Style "xbuffy" NakedTransients' and see if it
helps.

Chuck

*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

IBM Internal email:                        "Go back to sleep, Chuck.  You're
  [email-masked],              just havin' a nightmare--of course,
  HINESC at FISHKILL, HINESC at FSHVMFK1    we are still in Hell." Gary Larson
*******************************************************************************
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Mark Borges <[email-masked]>
Date: 22 Apr 1996 12:45:47 -0600

>> On Mon, 22 Apr 1996 14:10:29 -0400,
>> Charles Hines(ch) wrote:

Mark> and this resource:

ch> Do you have 'Style "*" DecorateTransients' in your .fvwm2rc

Yes, but I always have. I want transients to be decorated by default,
but this specific instance not to be. So I thought the specific would
over-ride the general wildcard. It did in fvwm-2.0.41.

ch> You could try adding 'Style "xbuffy" NakedTransients' and see if it
ch> helps.
I just tried doing that via FvwmTalk, and it didn't help. Unless it
needs a full restart for it to take effect, that is.

---

From: <[email-masked]> (Charles Hines)
Date: Mon, 22 Apr 1996 14:56:18 -0400

Mark> and this resource:

Mark> Yes, but I always have. I want transients to be decorated by default,
Mark> but this specific instance not to be. So I thought the specific would
Mark> over-ride the general wildcard. It did in fvwm-2.0.41.

Mark> I just tried doing that via FvwmTalk, and it didn't help. Unless it
Mark> needs a full restart for it to take effect, that is.

No, but to affect windows that are already up you would need to do a
Recapture.  New windows should use that new value.

I don't recall changing anything that should have affected this...

Just for grins, try invoking it OUTSIDE of the new FvwmButtons and see
how it behaves.

Chuck

---

From: Mark Borges <[email-masked]>
Date: 22 Apr 1996 13:24:40 -0600

>> On Mon, 22 Apr 1996 14:56:18 -0400,
>> Charles Hines(ch) wrote:

ch> No, but to affect windows that are already up you would need to do
ch> a Recapture.  New windows should use that new value.

ch> Just for grins, try invoking it OUTSIDE of the new FvwmButtons and
ch> see how it behaves.

I just started xbuffy from the command line, after FvwmTalk supposedly
read the new style attribute (how can I confirm what the style flags
for a particular window are, BTW?) and got the same behavior. The
change doesn't appear to be related to the new FvwmButtons.

Oh, I forgot something potentially very important that I should have
mentioned from the start. This is *not* the baseline fvwm-2.0.42, but
rather fvwm-2.0.42+Henrique's jumbo patch:

------------------------------
  The patch adds to 2.0.42 a few of the changes/patches I've posted
  to this list, and that didn't make it into 2.0.42:

    - a patch to make the windows in the pager move in "real time"
    - a patch to allow Focus to place the mouse anywhere in the window.
    - a small fix to paging on the corners
    - a small fix to paging while moving, if the scroll amount is less than
      screen height/width.

  Also included is a fix to a #undef in modules/FvwmButtons/misc.c which
  looks like:

    #undef makemult(a,b)

  and that my ANSI-C compiler doesn't like, and needs to be replaced with

    #undef makemult

  Files affected are:

    fvwm/builtins.c
    fvwm/events.c
    fvwm/icons.c
    fvwm/misc.h
    fvwm/module.h
    fvwm/move.c
    fvwm/virtual.c
    modules/FvwmButtons/misc.c
    modules/FvwmDebug/FvwmDebug.c
    modules/FvwmDebug/FvwmDebug.h
    modules/FvwmPager/FvwmPager.c
    modules/FvwmPager/FvwmPager.h

  -- Henrique ([email-masked])
------------------------------

The patch applied cleanly, though, and I don't see any explicit style
flags mentioned above.

---

From: Dave Goldberg <[email-masked]>
Date: Mon, 22 Apr 1996 16:58:43 -0400

For what it's worth, I also run xbuffy swallowed in the buttons, have
Style "*" DecorateTransients set, run with Henrique's patch (and some
others), but do not see the problem behavior.  My xbuffy popups still
come up undecorated, as they should.  The relevant lines (AFAICT) from
.fvwm2rc:

Style "XBuffy" NoHandles, NoTitle
Style "XBuffy" Sticky, StickyIcon # leftover from before I started
				  # using FvwmButtons
Style "XBuffy" CirculateSkip

*FvwmButtons(26x1, Frame 0, Padding 0 0, Container(Frame 1, Padding 0 0 Rows 1))
*FvwmButtons(Swallow(Kill) XBuffy "Exec xcmd xbuffy")

---

From: Mark Borges <[email-masked]>
Date: 22 Apr 1996 15:41:14 -0600

>> On Mon, 22 Apr 1996 16:58:43 -0400,
>> Dave Goldberg(dg) wrote:
dg> For what it's worth, I also run xbuffy swallowed in the buttons, have
dg> Style "*" DecorateTransients set, run with Henrique's patch (and some
dg> others), but do not see the problem behavior.  My xbuffy popups still
dg> come up undecorated, as they should.

dg> Style "XBuffy" NoHandles, NoTitle

aye, there's the rub. Thanks for jumping in Dave.

Identify reports the Name, Icon Name, and Resource as "xbuffy", but
the Class as "XBuffy". When I made the change to use the Class name,
as you do, it works for me, too. Although the man page says,

          windowname can be a window's name, class,  or  resource
          string.

it appears to only work if the class is used for the windowname. Can
anyone else confirm this?

I was only able to duplicate the breakage from a fresh start of fvwm
using "xbuffy" as a windowname; I wasn't quite sure how to clear a
style using FvwmTalk.

If someone else can confirm this, is this change intentional? It
doesn't really matter as far as I'm concerned -- I just need to be
clear as to what the rules of the game are.

dg> *FvwmButtons(26x1, Frame 0, Padding 0 0, Container(Frame 1, Padding 0 0 Rows 1))
dg> *FvwmButtons(Swallow(Kill) XBuffy "Exec xcmd xbuffy")

I've just been using the old syntax; I'll have to try this newfangled
Container stuff soon.

---

From: Kai Grossjohann <[email-masked]>
Date: 23 Apr 1996 09:12:10 +0200

>>>>> On 22 Apr 1996 15:41:14 -0600, Mark Borges <[email-masked]>
>>>>> said:

  Mark> Identify reports the Name, Icon Name, and Resource as
  Mark> "xbuffy", but the Class as "XBuffy". When I made the change to
  Mark> use the Class name, as you do, it works for me, too. Although
  Mark> the man page says,

  Mark>           windowname can be a window's name, class, or
  Mark>           resource string.

  Mark> it appears to only work if the class is used for the
  Mark> windowname. Can anyone else confirm this?

You might want to check, using FvwmIdentify, what `name' xbuffy passes
to the popup windows.  xpostit, for example, creates popup windows
whose name is NOT `xpostit'.

kai
--
There ain't no cure for the summertime blues.

---

From: <[email-masked]> (Charles Hines)
Date: Tue, 23 Apr 1996 09:45:50 -0400

>>>>> "Mark" == Mark Borges <[email-masked]> writes:

Mark> Identify reports the Name, Icon Name, and Resource as "xbuffy", but
Mark> the Class as "XBuffy". When I made the change to use the Class name,
Mark> as you do, it works for me, too. Although the man page says,

Mark>           windowname can be a window's name, class,  or  resource
Mark>           string.

Mark> it appears to only work if the class is used for the windowname. Can
Mark> anyone else confirm this?

It should be working for all of those, as I've made no changes to the
contrary.  I'll see if I can reproduce it though...

Mark> I was only able to duplicate the breakage from a fresh start of fvwm
Mark> using "xbuffy" as a windowname; I wasn't quite sure how to clear a
Mark> style using FvwmTalk.

You can't really clear a style spec currently, although this might not
be a bad idea.  I'll put it on the TO-DO list.

Mark> If someone else can confirm this, is this change intentional? It
Mark> doesn't really matter as far as I'm concerned -- I just need to be
Mark> clear as to what the rules of the game are.

It shouldn't have changed - name, class, or resource *should* all
still be acceptable.  As I said, I'll investigate.

Chuck

---

From: Mark Borges <[email-masked]>
Date: 23 Apr 1996 11:04:29 -0600

>> On 23 Apr 1996 09:12:10 +0200,
>> Kai Grossjohann(KG) wrote:

KG> You might want to check, using FvwmIdentify, what `name' xbuffy passes
KG> to the popup windows.

I'm not sure how to accomplish this. The popup windows only popup when
the left mouse button is pushed; when you release the button they
disappear. Anyone know of a trick to do it?

---

From: "Hal L. DeVore Jr." <[email-masked]>
Date: Tue, 23 Apr 1996 13:00:14 -0500

Try using editres on it.  Pop up the window one time before you do as
most (? many?) X programs create widgets the first time they're needed
and then just manage and unmanage (display and hide) them.

-- 
Hal DeVore              | PGP Key fingerprint:
BMC Software, Inc.      | EA A3 2F 62 98 38 B0 15  F0 85 76 33 E1 5A 2A 64
Houston, TX  USA        | 
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Dave Goldberg <[email-masked]>
Date: Tue, 23 Apr 1996 14:05:09 -0400

KG> You might want to check, using FvwmIdentify, what `name' xbuffy
KG> passes to the popup windows.

> I'm not sure how to accomplish this. The popup windows only popup
> when the left mouse button is pushed; when you release the button
> they disappear. Anyone know of a trick to do it?

You can set up xbuffy to pop up the window when mail arrives and keep
it up for some period of time using the headertime directive in
.xbuffy (there's probably a command line flag as well).  Then run
FvwmIdent on it.  I just tried it.  Sure enough, the class is XBuffy,
but the window name is the name I assigned the mailbox with the title
directive in .xbuffy.

Dave Goldberg
Post: The Mitre Corporation\MS B305\202 Burlington Rd.\Bedford, MA 01730
Phone: 617-271-3887
Email: [email-masked]

---

From: Jens-U H Petersen <[email-masked]>
Date: Wed, 24 Apr 96 12:19:54 JST

>>>>> "Kai" == Kai Grossjohann <[email-masked]> writes:

    Mark> Identify reports the Name, Icon Name, and Resource as
    Mark> "xbuffy", but the Class as "XBuffy". When I made the
    Mark> change to use the Class name, as you do, it works for
    Mark> me, too. Although the man page says,

    Kai> You might want to check, using FvwmIdentify, what `name'
    Kai> xbuffy passes to the popup windows.  xpostit, for
    Kai> example, creates popup windows whose name is NOT
    Kai> `xpostit'.

Yes, that is correct.  This is (for me at least) one annoying
point about "xbuffy": the popups have the class/resource name set
to name of the mailbox (newsbox).

Jens