Subject: Re: FVWM: striated title bar

From: [email-masked] (Todd Fries)
Date: Fri, 15 Dec 1995 12:25:22 -0600 (CST)

> This may sound stupid, but when everyone wants to have a different border
> style, can we make the border of Fvwm a separate module? In that case,
> people can write something like FvwmBorder, FvwmWin95Border, and
> FvwmMacBorder. 
> 
> The Style command would be: FvwmWin95Border*style "xterm" "...." or maybe
> 
> Style "xterm" FvwmWin95Border, Color....
> Style "Emacs" FvwmMacBorder, Color...

Call me crazy, but I had more of a 'generic' idea of how one could configure
boarders.

When you get right down to it, there are some basic things that make 'boarders'
look like olvwm, fvwm, mwm, os/2, win95, mac, nextstep, etc.

So, if we could have the following controls over the boarderstyles:

boarderwidth... this would have to be independently controllable up down right & left
cornerdecoration.. either a symmetrically mirrored bitmap, 'dot configuration' such
                   as the current 'buttons' are, or independently configurable top
		   and bottom
boardershadowwidth
boarderhilightwidth
buttonstyle ... this would have to be configurable as either the current 'dot'
                notation, as a bitmap, and also as an indented (i.e. macos) button,
		or an 'extending' (i.e. nextstep button).
titlebarstyle .. this would have to be the current 'bulgy' look, or the
                 'flat encompassing the buttons' nextstep/win95 look,
		 or optionally allow a 'pixmap' to be displayed over a certain
		 length, so as to 'force' certain appearances..i.e. the 'mac'
		 style titlebar
colors for the boarder, boarderhilight, boardershadow...maybe colors for the 
                button hilights would allow for the above mentioned 'indented'
		vs 'extending' buttons
'capture' something in a button... this is a strange contortion of what FvwmButtons
               does, i.e. run and capture, say, 'FvwmIconDisplay' for every
	       app that runs, and then it can display a miniturized app icon in
	       one of the buttons on the title bar...
cursorlook     this would need to be able to change the cursor when it is over
               the boarder vs the corners (i.e. olvwm's circle at the corner)
menuloook      yes, the menus should have their own little styles to them..
               'ctrl3d' for win95'ish, 'plain black on white' for macos look,
	       'pop-off actions align to the top of the menu' for nextstep look,
	       'plain and boring' for win311 type look, '3d' for OS/2 look,
	       etc...this should be on a 'per windowstyle basis'.  I KNOW this
	       seems to be alot of bloat.  I guess definately for a module, eh?

Now I don't pretend to know how to implement all of this, or whether it goes in
the window manager, or if it goes in a module.  If it did go in a module, that
module would either have to be started per window opened (ugh...NO! bad idea!)
or be able to manage all of the different windows, and if the module were not
present, fvwm would then revert back to it's primitive window decorations.

But, what I am asking, is...would the above 'boarderstyle' attributes be
all that is needed in order to provide Fvwm the flexibility to make each window
independently look like 'any os' the user desires?

BTW, for those of you not following the 'wine' development project for Linux, they
just added a '-managed' command line option to wine, which allows the program
to act like an X app and instead of the 'windows' decorations around it, it makes
the X window manager 'manage' the app...it would be hilarious (in my warped sense
of humr) if one could do a win95/win311 'boarderstyle' to Fvwm...this would really
screw with people.

One thing that would help, instead of having pages and pages of:

Style "thisapp" boarderwidth 4,boardershadowwidth 2,boarderhiligytwith 0,.....
Style "thatapp" boarderwidth 4,boardershadowwidth 2,boarderhiligytwith 0,.....
Style "theotherapp" boarderwidth 4,boardershadowwidth 2,boarderhiligytwith 0,.....

all being eactly the same, would be to have 'recursion' in style commands...
something like:

Style "Win95_Look" blah...blah...define a few styles for win95look
Style "Win95_Look" define more styles for win95look
Style "Win95_Look" define even more styles for win95look
Style "Win95_Look" define the rest of the styles for win95look
Style "wordpad"  UseStyle Win95_Look
Style "Solitare" UseStyle Win311_Look
Style "rxvt"     UseStyle Mwm
Style "xterm"    UseStyle Olvwm
Style "Fvwm*"    UseStyle Fvwm  # Just outt'a curiosity, what WOULD the fvwm style
                                # be if we can do all of the above? <grin>

You get the picture.. I assume (hope, maybe I'll hack it tonight) that this would
not be a hard thing to do.  But boy, would it be a useful thing.

Please, comment on my above suggestion as to 'boarderstyle' decorations...
Did I miss anything?
-- 
Todd [email-masked]
http://www.cs.umr.edu/~tfries
--
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, 15 Dec 1995 14:45:38 -0500

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

Todd> Call me crazy, but I had more of a 'generic' idea of how one
Todd> could configure boarders.

Todd> When you get right down to it, there are some basic things that
Todd> make 'boarders' look like olvwm, fvwm, mwm, os/2, win95, mac,
Todd> nextstep, etc.

Todd> So, if we could have the following controls over the
Todd> boarderstyles:
....

I've had similar (but simpler) thoughts from time to time.  But it
always just seems to be a lot of overkill.  What I would perhaps like
to implement:

  - control over 3d look of borders (like width of shadow)
  - separate control over border width and control handle width
  - titlesytles like flat, sunk, raised, & justification controls
  - Xpm/bitmaps for buttons
  - cursorstyle patch (perhaps modified for use in Style commands to
    make it per window?)

This should allow you to get relatively close to looking like pretty
much any window border look you want.  I don't feel that FVWM should
have to be able to look exactly like any other window manager type
program down to the exact pixel.  If you can get close, that's good.
This approach shouldn't bloat fvwm too badly, and a lot of that list
is already on my TO-DO list.

Comments?  Anyone think I'm way off base with that?

Todd> menuloook yes, the menus should have their own little styles to
Todd> them..  'ctrl3d' for win95'ish, 'plain black on white' for macos
Todd> look, 'pop-off actions align to the top of the menu' for
Todd> nextstep look, 'plain and boring' for win311 type look, '3d' for
Todd> OS/2 look, etc...this should be on a 'per windowstyle basis'.  I
Todd> KNOW this seems to be alot of bloat.  I guess definately for a
Todd> module, eh?

Again, just like above, I don't think that FVWM should have to have 10
different menu styles to look like 10 different window managers.
Perhaps some more generic controls though could be thought up to make
it customizable though.  I haven't given as much thought to this as to
the borders/titles "problem".

A module that has it's own menuing system that sends the commands to
FVWM instead of asking FVWM to put up the menus is an excellent idea
though.  Then you could make 10 different modules if you wanted
without bloating FVWM at all.  Plus it could be used w/ FvwmButtons to
get menus in it's buttons to popup on the button press instead of
release (since FVWM won't display the menu until the release).

What would make it even better is to make it so the module can stay
running instead of being reinvoked every time you want to pop the
menus up.  Then there would be no more delay than popping up a normal
menu.  This will require some more thought though...

Todd> Now I don't pretend to know how to implement all of this, or
Todd> whether it goes in the window manager, or if it goes in a
Todd> module.  If it did go in a module, that module would either have
Todd> to be started per window opened (ugh...NO! bad idea!)  or be
Todd> able to manage all of the different windows, and if the module
Todd> were not present, fvwm would then revert back to it's primitive
Todd> window decorations.

As I said in an earlier note, having modules control border/title
attributes presents some problems, but there shouldn't be any problems
with modules that popup menus themselves.

Todd> But, what I am asking, is...would the above 'boarderstyle'
Todd> attributes be all that is needed in order to provide Fvwm the
Todd> flexibility to make each window independently look like 'any os'
Todd> the user desires?

I think so.  But (like I said above) I don't think that it has to
match exactly.  Would the simpler approach I suggested be ok?

Todd> BTW, for those of you not following the 'wine' development
Todd> project for Linux, they just added a '-managed' command line
Todd> option to wine, which allows the program to act like an X app
Todd> and instead of the 'windows' decorations around it, it makes the
Todd> X window manager 'manage' the app...it would be hilarious (in my
Todd> warped sense of humr) if one could do a win95/win311
Todd> 'boarderstyle' to Fvwm...this would really screw with people.

At least they aren't taking the evil WABI approach of override
redirect windows...

Todd> One thing that would help, instead of having pages and pages of:
....
Todd> all being eactly the same, would be to have 'recursion' in style
Todd> commands...  something like:

Todd> Style "Win95_Look" blah...blah...define a few styles for win95look
....
Todd> Style "wordpad"  UseStyle Win95_Look
Todd> Style "Fvwm*"    UseStyle Fvwm  # Just outt'a curiosity, what WOULD the fvwm style
Todd>                                 # be if we can do all of the above? <grin>

Todd> You get the picture.. I assume (hope, maybe I'll hack it
Todd> tonight) that this would not be a hard thing to do.  But boy,
Todd> would it be a useful thing.

I know that this Style command type modification has been suggested
before and I haven't really responded to it except to say "you could
do this with FvwmM4 or Cpp", but this way of presenting it looks very
good and I bet not overly difficult to implement.

Todd, if you come up with this in the near future, let me know.  I'm
adding it to the TO-DO list, so I'll take a crack at it eventually,
but if you do it first, that'd be great.

Todd> Please, comment on my above suggestion as to 'boarderstyle'
Todd> decorations...  Did I miss anything?

Only the misspelling of "border".  ;^)

Chuck

---

From: [email-masked] (Robert Nation 885-9815)
Date: Mon, 18 Dec 95 09:05:24 EST

>  - separate control over border width and control handle width

I'm not sure what the 2nd option in this list means, but please
note that the mwm-style has some items (titlebar) with a 1 pixel highlight/
shadow on the top and sides, and a 2 pixel shadow on the bottom.

Also, note that any dynamic configuration (while generally good) will slow
down the redraw operatation just a little.

Now, I've been thinking about the "module to do decorations". You
could have fvwm re-parent the application window (use the 2-level
reparenting that it uses now, but leave out the title-bar, buttons,
side-bars, and corners.  This would leave a decor-less frame in which
a module would work. The module would tell fvwm how big to make the
frame, and where to put the window inside the frame, and the module
could create its own windows within the frame for decoration. This would not
be unnecessarily slow, since the module would do its own redraws, and get
expose events for its own windows. Note that the module would also have
to handle receipt of and processing for all the actions that are bound
to window decorations.

This is a very complicated undertaking, of course.

Rob

---

From: <[email-masked]> (Charles Hines)
Date: Mon, 18 Dec 1995 11:25:33 -0500

>>>>> "Rob" == Robert Nation 885-9815 <[email-masked]> writes:

>> - separate control over border width and control handle width

Rob> I'm not sure what the 2nd option in this list means,

I meant being able to set the sidebara to one width and the corner
(which is what I meant to type, not 'control') handles to another,
like how olwm has thick corners and thin sides with no shadow.

Rob> but please note that the mwm-style has some items (titlebar) with
Rob> a 1 pixel highlight/ shadow on the top and sides, and a 2 pixel
Rob> shadow on the bottom.

Actually, I hadn't noticed that before...  I don't really use the MWM
lookalike features that often.

But I didn't mean for for the first line above to control the borders
of the titlebar & buttons, just for the sidebars & corners.  The
button look could be controlled via the pixmaps for buttons, and the
titlebar via the titlebar style options (which would have to account
for the MWM style).

Rob> Also, note that any dynamic configuration (while generally good)
Rob> will slow down the redraw operatation just a little.

Right, which is why I'd like any proposed changes to be as simple as
possible, so as not to impact performance.

Honestly, I don't care if fvwm can look like any other window managers
or not.  I like fvwm's look the way it is, but it was the other
features (and the fact that it was so small) that made me want to use
it initially.  And I plan to keep it that way - as small as possible
and as powerful as possible too, only adding things to enhance it's
"value" without bloating it.

Rob> Now, I've been thinking about the "module to do decorations". You
Rob> could have fvwm re-parent the application window (use the 2-level
Rob> reparenting that it uses now, but leave out the title-bar,
Rob> buttons, side-bars, and corners.  This would leave a decor-less
Rob> frame in which a module would work. The module would tell fvwm
Rob> how big to make the frame, and where to put the window inside the
Rob> frame, and the module could create its own windows within the
Rob> frame for decoration. This would not be unnecessarily slow, since
Rob> the module would do its own redraws, and get expose events for
Rob> its own windows. Note that the module would also have to handle
Rob> receipt of and processing for all the actions that are bound to
Rob> window decorations.

Rob> This is a very complicated undertaking, of course.

Yes, it certainly doesn't seem trivial...

I was thinking about just adding the window id's for the titlebar &
buttons to the module communication protocol, to allow the modules to
play with those windows.  I was hoping that would be almost enough,
but perhaps not.

Chuck

---

From: [email-masked] (Robert Nation 885-9815)
Date: Mon, 18 Dec 95 11:34:34 EST

>"value" without bloating it.

Just a historical side-note...
The original versions of fvwm had the top corners merged with the buttons, and
the title-bar merged with the top side-bar, so that the top of the window
looked more or less like the bottom, but fatter. I liked it, but several
people sent patches to make it look like the current scheme, so I figured,
its time to switch...

Anyway, it would probably be genuinely useful to modify fvwm to gracefully
acept malloc and window creation failures than to make it have more border
styles. Right now, when you run out of swap space, its likely that fvwm will
die, instead of just some user-application. This seems kind of bad, even if
it doesn't generally happen much. (Does anyone know if the X server handles
malloc failures well? If not, there's not much point in fixing fvwm...)

Rob

---

From: [email-masked] (Robert Nation 885-9815)
Date: Mon, 18 Dec 95 12:07:40 EST

>Rob> Just a historical side-note...
>Rob> The original versions of fvwm had the top corners merged with the
>Rob> buttons, and the title-bar merged with the top side-bar, so that
>Rob> the top of the window looked more or less like the bottom, but
>Rob> fatter. I liked it, but several people sent patches to make it
>Rob> look like the current scheme, so I figured, its time to switch...
>
>Sounds interesting.  Just out of curiosity, what version # did that
>change in?

That would have been about 0.1, I guess.

Rob

---

From: <[email-masked]> (Charles Hines)
Date: Mon, 18 Dec 1995 11:58:15 -0500

Rob> Anyway, it would probably be genuinely useful to modify fvwm to
Rob> gracefully acept malloc and window creation failures than to make
Rob> it have more border styles.

Agreed, and actually I think there are a lot of other things that fall
into the "more important than more border styles" category right now.
I'm going to try and do some of them over my vacation next week.

Rob> Right now, when you run out of swap space, its likely that fvwm
Rob> will die, instead of just some user-application. This seems kind
Rob> of bad, even if it doesn't generally happen much.

Yeah, that should probably be handled a little better...

Rob> (Does anyone know if the X server handles malloc failures well?
Rob> If not, there's not much point in fixing fvwm...)

Good question.  No clue here.

Chuck

---

From: [email-masked] (Dan Miner)
Date: Mon, 18 Dec 1995 14:13:18 -0700 (MST)

> Good question.  No clue here.

Atleast with 3.1.1, I have experienced *many* lockups due to memory
exhaustion in X.  (Didn't have swap on the time).  I'd tentively
would say "it don't handle them well."  Also, I've read in a couple
of places that XFree86 servers are known for locking up the
actual machine when the machine runs out of memory.

	Regards,
		Dan

-- 
Dan Miner					[email-masked]
	"The longer I stare at this screen; the blanker it gets."
						Linux: try it, you'll like.
"Your program is encoded in pi."		I started with a 64
--
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: "John Henders" <[email-masked]>
Date: Mon, 18 Dec 1995 16:05:11 -0800 (PST)

> down the redraw operatation just a little.

On the subject of dynamic configuration, how hard would it be to have
the window border colors dynamically update by communicating with a
module? The only window manager I've seen do this is olwm.

-- 
      Artificial Intelligence stands no chance against Natural Stupidity.
                GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v
                     b+++ e* s-/+ n-(?) h++ f+g+ w+++ y*