On Fri, 15 Dec 1995, Charles Hines wrote:
> >>>>> "Charles" == Charles Chan <charlesc_at_eecg.toronto.edu> writes:
>
> 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
>
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
> 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 <chuck_hines_at_vnet.ibm.com>
> 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
> hines_at_cold.fishkill.ibm.com, 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 majordomo_at_hpc.uh.edu.
> To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
>
--
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 - 10:49:09 GMT