Subject: FVWM: striated title bar

From: Oreos <[email-masked]>
Date: Fri, 15 Dec 1995 09:55:17 -0500 (EST)

i was wondering if anyone had a patch to borders.c that displays striated 
titlebars on all windows like the windows in MacOS.

thanks
james

--
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: Charles Chan <[email-masked]>
Date: Fri, 15 Dec 1995 10:39:12 -0500

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...

Then we don't have to hack around the source code... I am not familiar
with programming a window manager, if you find my idea stupid, please say
so. 

Eventually, we can have an object hierarchy, a FvwmBorder class, who knows
how to interact with the core Fvwm, and other Border classes derived from
there. 

--Charles

---

From: <[email-masked]> (Charles Hines)
Date: Fri, 15 Dec 1995 11:26:07 -0500

>>>>> "Charles" == Charles Chan <[email-masked]> writes:

>> james

Charles> This may sound stupid, but when everyone wants to have a
Charles> different border style, can we make the border of Fvwm a
Charles> separate module? In that case, people can write something
Charles> like FvwmBorder, FvwmWin95Border, and FvwmMacBorder.

Charles> The Style command would be: FvwmWin95Border*style "xterm"
Charles> "...." or maybe

Charles> Style "xterm" FvwmWin95Border, Color....
Charles> Style "Emacs" FvwmMacBorder, Color...

Charles> Then we don't have to hack around the source code... I am not
Charles> familiar with programming a window manager, if you find my
Charles> idea stupid, please say so.

Charles> Eventually, we can have an object hierarchy, a FvwmBorder
Charles> class, who knows how to interact with the core Fvwm, and
Charles> other Border classes derived from there.

It doesn't sound like a bad idea, but there are some potential
problems with this:

  1) Potential for very slow response on redraws if modules muck with
     borders and such.
  2) Modules don't know about a lot of the internals like this, which
     would require big rewrites in the module communicaion code.
  3) We can't please everyone without causing fvwm to really bloat.

But actually I would like to allow modules to get info about the
windows that could possibly allow them to muck with the titlebars and
such.  From the TO-DO list:

  - Add to module commincations to pass titlebar & button window ids to
    allow modules to muck with those windows (for animation, or whatever)?

I'm not sure if this is entirely feasable, but I'd like to give it a
shot sometime in the future.

And #3 is always my biggest concern.  Fvwm is supposed to be small,
fast, flexible, and powerful, and there are tradeoffs that have to be
made sometimes.  One of the main reasons why I don't want to put a lot
of Windows95 (or MacOS or whatever) lookalike stuff in the main module
unless it's really generically applicable and not a resource hog.

Perhaps I should put a statement to that effect in the FAQ, eh?

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
*******************************************************************************
--
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: Richard Lister <[email-masked]>
Date: Fri, 15 Dec 1995 16:50:05 +0000

On Fri, 15 Dec 1995 10:39:12 -0500
Charles Chan <[email-masked]> 
> people can write something like FvwmBorder, FvwmWin95Border, and

How about being able to define a pattern in a similar way as we do 
for titlebar buttons with ButtonStyle?

Hmmm, the same code could be reused to produce a pattern of the same
dimensions as a button, which would then be tiled along the length
of the titlebar.

Ric

 ~~~~~~~~~~~~~~ Richard J. Lister    [email-masked] ~~~~~~~~~~~~~~~~
            Research Assistant, Neural Computing Research Group
                  Aston University, Birmingham B4 7ET, UK
 ~~~~~~~~~~~~~~ http://neural-server.aston.ac.uk/~listerrj/ ~~~~~~~~~~~~~~~~
--
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: "Randall S. Winchester" <[email-masked]>
Date: Fri, 15 Dec 1995 11:49:03 -0500 (EST)

> >> titlebars on all windows like the windows in MacOS.

Sure I do this for my site.

*** 1.1	1995/10/31 14:42:56
--- borders.c	1995/10/31 14:43:17
***************
*** 446,452 ****
        RelieveWindow(t,t->title_w,0,0,t->title_width,t->title_height,
  		    ReliefGC, ShadowGC, BOTTOM_HILITE);
      }
!   if(t->flags & STICKY)
      {
        for(i=0 ;i< t->title_height/2-3;i+=4)
  	{
--- 446,452 ----
        RelieveWindow(t,t->title_w,0,0,t->title_width,t->title_height,
  		    ReliefGC, ShadowGC, BOTTOM_HILITE);
      }
!   if(t->flags /* & STICKY */)
      {
        for(i=0 ;i< t->title_height/2-3;i+=4)
  	{

Randall

---

From: <[email-masked]> (Charles Hines)
Date: Fri, 15 Dec 1995 16:26:17 -0500

>>>>> "Bryan" == Bryan Bartone <[email-masked]> writes:

Bryan> How about build options that define some window look options?

Actually, I feel that is an even worse option than bloating fvwm with
1000's of different runtime options.  Because then the docs would have
to cover all the different compile options and someone would install
it at some site with one set of options, and after seeing the docs
some user would complain that they wanted these other options compiled
in but definitely don't compile in this one option here, and another
user would have a different set of requirements, and so on.

Chuck

---

From: [email-masked] (Bryan Bartone)
Date: Fri, 15 Dec 1995 16:15:05 -0500 (EST)

How about build options that define some window look options?

>>>>> On Fri, 15 Dec 1995 11:26:07 -0500, [email-masked] (Charles Hines) said:

    Charles> On Fri, 15 Dec 1995, Oreos wrote:

    >>> i was wondering if anyone had a patch to borders.c that
    >>> displays striated titlebars on all windows like the windows in
    >>> MacOS.

    >>> thanks james

    Charles> Style "xterm" FvwmWin95Border, Color....  Style "Emacs"
    Charles> FvwmMacBorder, Color...

    Charles> Then we don't have to hack around the source code... I am
    Charles> not familiar with programming a window manager, if you
    Charles> find my idea stupid, please say so.

    Charles> It doesn't sound like a bad idea, but there are some
    Charles> potential problems with this:

    Charles>   1) Potential for very slow response on redraws if
    Charles> modules muck with borders and such.  2) Modules don't
    Charles> know about a lot of the internals like this, which would
    Charles> require big rewrites in the module communicaion code.  3)
    Charles> We can't please everyone without causing fvwm to really
    Charles> bloat.

    Charles> But actually I would like to allow modules to get info
    Charles> about the windows that could possibly allow them to muck
    Charles> with the titlebars and such.  From the TO-DO list:

    Charles>   - Add to module commincations to pass titlebar & button
    Charles> window ids to allow modules to muck with those windows
    Charles> (for animation, or whatever)?

    Charles> I'm not sure if this is entirely feasable, but I'd like
    Charles> to give it a shot sometime in the future.

    Charles> And #3 is always my biggest concern.  Fvwm is supposed to
    Charles> be small, fast, flexible, and powerful, and there are
    Charles> tradeoffs that have to be made sometimes.  One of the
    Charles> main reasons why I don't want to put a lot of Windows95
    Charles> (or MacOS or whatever) lookalike stuff in the main module
    Charles> unless it's really generically applicable and not a
    Charles> resource hog.

    Charles> Perhaps I should put a statement to that effect in the
    Charles> FAQ, eh?

    Charles> Chuck

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

    Charles> IBM Internal email: "Go back to sleep, Chuck.  You're
    Charles> [email-masked], just havin' a nightmare--of
    Charles> course, HINESC at FISHKILL, HINESC at FSHVMFK1 we are
    Charles> still in Hell." Gary Larson
    Charles> *******************************************************************************
    Charles> -- To unsubscribe from the list, send "unsubscribe fvwm"
    Charles> in the body of a message to [email-masked].  To
    Charles> report problems, send mail to [email-masked].

---

From: [email-masked] (Todd Fries)
Date: Fri, 15 Dec 1995 19:18:08 -0600 (CST)

> How about build options that define some window look options?

It would work, but that takes all the run-time-configurability ideas out
of the picture and reduces them to compile-time ideas.

I don't like that at all.  I'd rather help create flexible code that is
so flexible that the styles can look like other window managers and not
be bloated at the same time.  The key here is that you specify things in
the .fvwmrc, not in the sourcecode.
-- 
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].