[EMAIL PROTECTED] wrote:
This is not the only problem. Here are related ones.
Currently Style list is always optimized. It is not obvious how to do this
with this new StyleFunction. The function functionality just does not
allow to do everything we may want to do with StyleFunction.
I just replied to Dominik with an idea for implementing this. Optimizing
the StyleFucntion would be part of the plan and would require some
way of deleting lines from a function. Is this optimization sufficient?
For each style flag given to the Style command {
For each line of StyleFunction {
Delete any line with a matching pattern that sets/clears that flag
}
Add the pattern and style flags to the end of the StyleFunction
}
This would result in the StyleFunction being quite simple e.g.
Style Fvwm* Sticky, Layer 4
gives a StyleFunctions that looks like
+ I WindowId $0 (Fvwm*) WindowStyle Sticky
+ I WindowId $0 (Fvwm*) WindowStyle Layer 4
Maybe it could use a simplified version of WindowStyle that only works
on one style flag and doesn't actually do any visual updates until the end
( like the style function does ).
The matching patterns to delete is not just a straight string match but
a match
of any subset e.g. F* would delete any Fvwm* patterns. I don't know how
hard that would be.
Examples. I want a solution for these two problems.
1) Being able to switch normal icons on and off. Currently the only
solution is to issue "Style * NoIcon" to switch it off and hundreds of
"Style pattern Icon image" to switch them on again. Of course, the
solution to this is to add aditional Style flag HasIcon/NoIcon, so Icon is
stored for a window even it has NoIcon. But you may get the point. If
currently switching icons on and off two times is the same as doing this
10 times (because there is merging), with StyleFunction thousand of
new lines would be added, unless there is a way to optimize a function.
In this case it will not be a function in a normal sence.
You're right, it would not be a normal function. There may be no point
in exposing
it to users so maybe a hidden one would be better. But it would use the same
function creation routines we already have plus a special line-deletion
routine.
Line deletion from functions may be useful anyway so maybe
DeleteFromFunction StyleFunction "I WindowId \$0 (Fvwm*) Sticky"
DeleteFromFunction StyleFunction "I WIndowId \$0 (Fvwm*) Slippery"
would be the way to go.
2) It would be nice to have a way to do and undo style changes. This may
be useful for Style GUIs with ability to try/cancel style options. Or if
someone wants to enter to some temporary mode, i.e. to remember the way a
window (or windows) start now, apply some changes (say, iconify all new
windows) and then return to the previous state (with only some windows
started iconified). I see two possible solutions to this. First:
StartStyleGroup, EndStyleGroup, DeleteStyleGroup commands and disable
merging with styles inside the group. Second: DumpStyle / RestoreStyle.
In any case, to implement this, more operations over StyleFunction needed.
A really nice way to do this would be for the GUI to embed an XNest
window and have it
run a captive fvwm inside with a couple of example windows (term,
mozilla, transients etc.)
Dumping any function contents would be useful for debug anyway and
dumping StyleFunction
would give the equivalent of DumpStyle, Restore Style would be a read of
the file.
Cheers,
Tim.
Off for Christmas, See you In Jan.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
