>>>>> "Graeme" == Graeme McCaffery <mccaffer_at_eee.bham.ac.uk> writes:
Graeme> I've just had a look at xcuckoo, and I think it would be a
Graeme> great idea if fvwm could swallow applications in its title
Graeme> bars, and generally allow more formatting of the title bars.
I've got title justification on the TO-DO list. Someone submitted a
patch for 1.24r that I've been saving to merge into 2.xx sometime.
As for the idea of the title bar swallowing apps, I'm not sure about
the general usefulness of that. Perhaps in this specific instance it
makes sense, but what else could it be used for?
I assume that xcuckoo puts the time somewhere. Perhaps just a simple
FvwmClock module that merges the time into the highlighted window's
title bar would be better (if possible currently).
Graeme> For instance, you could have formatting of the title, left,
Graeme> centred and right justified. I currently use 2 Fvwmbutton
Graeme> modules and I think that if the title button could do more,
Graeme> then I could get rid of one of them. Perhaps the title bar
Graeme> could be controled by a module, however I am not an
Graeme> experienced X programmer, so I don't have a clue as to how do
Graeme> this.
Graeme> Does anyone else think that this would be a good idea?
I think that the title bars really have to be controlled by fvwm, but
modules should be able to play with them a little. If a module could
get the id for the titlebar window, it could do whatever it wanted to
the title bar I imagine (including making it swallow an application).
I'm not sure how 'safe' it would be to do though (i.e. conflicts with
what fvwm would be trying to do to the titlebar).
And if a module could get the window id's for the titlebar and the
buttons, then it could do things like animate the buttons (ala ctwm).
An interesting feature that I'd much rather see in a module instead of
wasting space in fvwm, if it were to appear. The modules don't
currently get the window ids for the titlebar or buttons, but that
could be added, I imagine.
Graeme> Also I think that the quit option should allow a yes/no
Graeme> choice. I've used Quitverify for a while now(FvwmForm module)
Graeme> but it seems painfully slow. I've seen olwm logout and it it
Graeme> about 10 to 20 times faster than Fvwm's as it is almost
Graeme> instantanious. I reckon that the quit proceedure is too
Graeme> important to be put in a module and so it should be in the
Graeme> main code, perhaps as an option to the quit command.
Graeme> Does anyone have opinions about this?
As you can probably tell from my other comments (in this and other
notes), I'd really like to keep as much in modules as possible, so I
think that FvwmForm is better for doing that than adding the code to
fvwm to do so.
Granted, for this example it probably wouldn't be a lot of code added
to fvwm, but that excuse could be used for a lot of things. Modules
are an excellent way to avoid creeping featurism and turning fvwm into
a bloated evil entity like mwm and dtwm.
FvwmForm is well suited for things like this, so I say let it do it's
job. I just ran it, and it took a second or two to come up, which is
very noticeable but it wasn't unbearable. On your machine, perhaps
it's longer.
Chuck
*******************************************************************************
Charles K. Hines
IBM Logic Synthesis developer [BooleDozer (TM)]
and Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]
Internet e-mail: chuck_hines_at_vnet.ibm.com
IBM Internal e-mail: hines_at_loki.pok.ibm.com (preferred from workstation)
HINESC at FISHKILL (preferred from mainframe)
HINESC at FSHVMFK1 (discouraged, but I'll get it)
*******************************************************************************
"dis ting could have possabiwities if I put my twisted widdle mind to it!"
- Bugs Bunny
"I have a paper plate in my head because they were all out of the metal ones"
- Rick Overton
*******************************************************************************
--
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 Oct 06 1995 - 08:42:13 BST