On 05 Aug 2001 13:34:02 +0200, Dominik Vogt wrote:
>
> How about this enhancement to conditional commands:
>
> Next (conditions) { false-action } true-action
>
> This would allow an "else" case in all conditional commands
> without the need to store a return code of these commands. For
> example:
>
> AddToFunc ToggleWindow
> + I Next ($0) { Exec $0 } Close
This may work, but is this the best possible solution? This syntax is not
very readable and having else-command before then-command does not make it
better. As before there is still a limit to one command in both branches,
so you are forced to create small functions without a real need. It also
adds a problem of escaping curly brackets in else-command when needed.
What about parsing of nested conditional commands, braces in braces? :)
It seems that an idea of 2 commands on the same line is not very good.
Here is my revised proposal that solves all problems described above.
There are 2 constructs, one is long and one is short, both may be mixed:
if Next (conditions) {
then-commands, one per line
}
else {
else-commands, one per line
}
if Next (conditions) then-command
else else-command
Other one-or-zero-window commands may be used instead of "Next" as well:
"Prev", "Current" and "None". The default if not specified is "Current".
The rules are similar to C, "else" belongs to the last "if", braces may
be used to change this. "else" part is optional. Indentation is optional.
The "{" may only appear in "if" or "else" line, "}" should be on its own.
The syntax seems to be unambiguous, but a more formal proof is needed.
Here is a long example demostrating the syntax that may be used with
FvwmEvent add_window:
# when a new window appears do the following with it
if ("Netscape: *") {
# this "Certification" logic is from my real config
if ("Netscape: Certificate Authority Is Expired") {
WarpToWindow 310p 330p
FakeClick depth 0 wait 200 press 1 wait 100 release 1
}
# warp to Question, so Find dialog does not lose focus
if ("Netscape: Question") WarpToWindow 20p 70p
elsif ("Netscape: Find") {
if Next ("Netscape: my page") {
Next (Netscape: Find") AnimatedMove 40 40
}
}
}
elsif ("Terminal") {
AnimatedMove +100 -0 # gnome-terminal lacks position
WarpToWindow 50 10p
}
elsif ("Annoying Window") {
Delete # try to delete it nicely first
if Next ("Annoying Window") Destroy
}
elsif ("Unimportant Window") Lower
elsif WindowId $w (!AllowsFocus) {
if WindowId $w (XClock) {
# force only one xclock, close all previous ones
WindowId $w Layer +1
All (XClock, Layer) Close
WindowId $w Layer -1
}
# individual window Style implementation is only in plans
Style (Id $w) CirculateSkip
}
For a comparision, try to implement the same logic using the suggested
Next (conditions) { else-command } then-command syntax, and count how
many functions you should create. Which one is more readable?
There are 5 new commands "if", "else", "elsif", "{" and "}" in this
proposal. No existing command syntax is changed, which is an advantage.
The problem here is psychological, we all know that to add a command, some
prefix like "+ " should be used. We got used to a limiting syntax. :)
Other news is that now a command may be ignored if it's in "false" branch.
Here are some problems to think about, some are easily solvable, some not.
If someone forgets to close a brace he gets an error at the end of file.
FvwmConsole may handle and show the level of "if" in the prompt.
What happens if modules try to send command groups concurently. They
will be mixed, just like now if modules try to define menus and functions
concurently bad things happens. So this is not really a new problem.
It should be thought more of course. But implementing this is not hard.
The commands "{" and "}" used to group other commands may be used in other
places too if we accept this idea.
Regards,
Mikhael.
--
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]
