How about build options that define some window look options?
>>>>> On Fri, 15 Dec 1995 11:26:07 -0500, chuck_hines_at_VNET.IBM.COM (Charles Hines) said:
>>>>> "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
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.... 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> 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.
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 <chuck_hines_at_vnet.ibm.com> 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> hines_at_cold.fishkill.ibm.com, 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 majordomo_at_hpc.uh.edu. To
Charles> 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 - 15:16:39 GMT