Subject: FVWM: cool

From: [email-masked] (Todd Fries)
Date: Fri, 19 Apr 1996 03:46:25 -0500 (CDT)

I love the pixmaps in the title bar option.  One thing that would be nice,
though, is if the MWMButtons style is set, that the button would stay
'pressed in' as the man page suggests...if one uses pixmaps instead of the
traditional button styles..

-- 
Todd Fries
--
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: Fri, 19 Apr 1996 09:42:45 -0400

>>>>> "Todd" == Todd Fries <[email-masked]> writes:

Todd> I love the pixmaps in the title bar option.  One thing that
Todd> would be nice, though, is if the MWMButtons style is set, that
Todd> the button would stay 'pressed in' as the man page suggests...if
Todd> one uses pixmaps instead of the traditional button styles..

I've been thinking about that, and I think a different way should
probably be used.  I've been toying with a generic parameter, either
to be given to the ButtonStyle command or as a separate one, to make
individual buttons act with a toggle behavior.  That way they could
work with any bindings (not just Maximize).

Chuck

---

From: Chris Rode <[email-masked]>
Date: Fri, 19 Apr 1996 09:39:16 CDT

<[email-masked]> (Charles Hines) wrote:

}>>>>> "Todd" == Todd Fries <[email-masked]> writes:
}
}Todd> I love the pixmaps in the title bar option.  One thing that
}Todd> would be nice, though, is if the MWMButtons style is set, that
}Todd> the button would stay 'pressed in' as the man page suggests...if
}Todd> one uses pixmaps instead of the traditional button styles..
}
}I've been thinking about that, and I think a different way should
}probably be used.  I've been toying with a generic parameter, either
}to be given to the ButtonStyle command or as a separate one, to make
}individual buttons act with a toggle behavior.  That way they could
}work with any bindings (not just Maximize).

now what would be really nice, is along with that, you could specify
an alternate pixmap to use instead of having it "pressed in".  that
way, you could, for instance, after maximizing, replace the maximize
button with a restore button, a la win95 or somesuch.  

btw, i've got 2.0.42 compiled under ultrix 4.3, osf1 3.2, and irix
5.3.  works great on all three.  keep up the good work! :)

--chris.

--
chris rode - [email-masked]                -- Help Room Consultant
http://www.public.iastate.edu/~crode/         -- 138 Durham Center, 294-1314
"why don't we just have a stupidity    depeche mode, erasure, moby, new order,
 tax? just tax the stupid people!"     pet shop boys and recoil rock my world.

---

From: <[email-masked]> (Charles Hines)
Date: Fri, 19 Apr 1996 10:46:46 -0400

>>>>> "Chris" == Chris Rode <[email-masked]> writes:

Chris> <[email-masked]> (Charles Hines) wrote:

Chris> }>>>>> "Todd" == Todd Fries <[email-masked]> writes:
Chris> }
Chris> }Todd> I love the pixmaps in the title bar option.  One thing that
Chris> }Todd> would be nice, though, is if the MWMButtons style is set, that
Chris> }Todd> the button would stay 'pressed in' as the man page suggests...if
Chris> }Todd> one uses pixmaps instead of the traditional button styles..
Chris> }
Chris> }I've been thinking about that, and I think a different way should
Chris> }probably be used.  I've been toying with a generic parameter, either
Chris> }to be given to the ButtonStyle command or as a separate one, to make
Chris> }individual buttons act with a toggle behavior.  That way they could
Chris> }work with any bindings (not just Maximize).

Chris> now what would be really nice, is along with that, you could specify
Chris> an alternate pixmap to use instead of having it "pressed in".  that
Chris> way, you could, for instance, after maximizing, replace the maximize
Chris> button with a restore button, a la win95 or somesuch.

2.0.42 basically has that capability now.  If using Pixmaps as the
button style, if you specify 2 pixmaps, the second is the "pressed in"
one, but you only see it while it's actually pressed in.  Using
FullPixmap removes the border, so this toggle ability that I was
referring to would be all that would be needed to get what you want.

BTW - keep in mind that mentioning 'win95' along with any idea is
enough to turn me off of it... :)

Chris> btw, i've got 2.0.42 compiled under ultrix 4.3, osf1 3.2, and irix
Chris> 5.3.  works great on all three.  keep up the good work! :)

Glad to hear it.

Thanks,
Chuck

---

From: Chris Taylor <[email-masked]>
Date: Fri, 19 Apr 1996 14:02:12 -0400 (EDT)

> if you specify 2 pixmaps, the second is the "pressed in"

Not exactly. What's need is pixmaps for four button states:
    normal (not clicked-on), un-maximized
    depressed, un-maximized
    normal, maximized
    depressed, maximized

I suppose you could replace "maximized" with "sticky" or any other on/off
window state.

But... that leads to a bug in the way fvwm deals with button decorations: fvwm
assumes that minimize and maximize are always on buttons 4 and 2. Because of
this, three problems result:

    * Fvwm alters the appearance of buttons bound to maximize *only* when bound
      to button 2.
    * Fvwm won't alter the appearance of button 2 when not using the default 
      buttonstyle for that button.
    * Fvwm always removes buttons 4 and 2 from transient windows, even if they
      aren't bound to minimize and maximize.

In my case, minimize and maximize are bound to buttons 8 and 6. Close is bound
to button 2. (I bind nothing to button 4.) As a result, decorations on my
transient windows don't make much sense: I end up with minimize and maximize
buttons on my transient windows. Minimize and maximize typically don't work
(and aren't needed) for transient windows. Because fvwm removes buttons 4 and
2, I can't close the window by clicking the close button.

Perhaps the code used to fiddle with the maximize button's appearance and
presence can be modified to handle a more general case? Maybe the code can look
at a button's bindings and change the button's appearance based on the binding
and whatever window state flags exist at the time. The code must already do
that to some extent for button 2. (In my case, this theoretical checking
wouldn't help: my maximize button is actually bound to a function, since I use
maximize with parameters in several places throughout my fvwmrc. That's outside
the scope of this problem, though.)

Chris Taylor     / My views do not represent \ PGP public key available
[email-masked] \    those of Cabletron.    / via keyserver or request

---

From: Andrew Veliath <[email-masked]>
Date: Fri, 19 Apr 1996 14:29:33 -0400

>>>>>  Frosty the Snowman, with all his might, exclaimed:
>>>>> "All feel wholesome at the words of the omnipresent Chris Taylor!"

    >> if you specify 2 pixmaps, the second is the "pressed in" one,
    >> but you only see it while it's actually pressed in.  Using
    >> FullPixmap removes the border, so this toggle ability that I
    >> was referring to would be all that would be needed to get what
    >> you want.

    Chris> Not exactly. What's need is pixmaps for four button states:
    Chris> normal (not clicked-on), un-maximized depressed,
    Chris> un-maximized normal, maximized depressed, maximized

    Chris> I suppose you could replace "maximized" with "sticky" or
    Chris> any other on/off window state.

    Chris> But... that leads to a bug in the way fvwm deals with
    Chris> button decorations: fvwm assumes that minimize and maximize
    Chris> are always on buttons 4 and 2. Because of this, three
    Chris> problems result:

There are a lot of details (and complications) that arise when trying
to implement something like this.  I think the best thing to do would
give Charles some time to see what he thinks is best (discussion is
good though).  I think he would want the solution to be as small,
unintrusive and generic as possible.  Usually simple, but generic
ideas end up being the most flexible and bug-free.

I think MWM-like operation would be good, and it would be more
conformant to FVWM's operation as well, however a first implementation
(such as Chuck described previously) IMHO is okay.  Getting too
complicated too early leads to all sorts of problems.

Regards,

PC sellers are Bill collectors.
Andrew Veliath <[email-masked]>
http://www.rpi.edu/~veliaa
Finger for PGP Key
--
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: Fri, 19 Apr 1996 17:13:01 -0400

>>>>> "Andrew" == Andrew Veliath <[email-masked]> writes:

Perhaps my approach is 'not exactly' but it's probably close enough.

Correct.  I would want it to be general, perhaps even disconnected
from the function entirely to help keep it simple.

I mentioned this in my initial note actually, saying that would need
to be redone.

Andrew> There are a lot of details (and complications) that arise when
Andrew> trying to implement something like this.

Yup.

Andrew> I think the best thing to do would give Charles some time to
Andrew> see what he thinks is best (discussion is good though).

Discussion is always good.

Andrew> I think he would want the solution to be as small, unintrusive
Andrew> and generic as possible.  Usually simple, but generic ideas
Andrew> end up being the most flexible and bug-free.

Very true, on all points.

Andrew> I think MWM-like operation would be good, and it would be more
Andrew> conformant to FVWM's operation as well, however a first
Andrew> implementation (such as Chuck described previously) IMHO is
Andrew> okay.

I think so too.

Andrew> Getting too complicated too early leads to all sorts of
Andrew> problems.

True again.

Chuck