Border Styles (was Re: FVWM: striated title bar)

From: Charles Hines <>
Date: Fri, 15 Dec 1995 14:45:38 -0500

>>>>> "Todd" == Todd Fries <tfries_at_umr.edu> 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
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Fri Dec 15 1995 - 13:46:10 GMT

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:57 BST