Subject: A pair of questions regarding FVWM setup

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Sat, 4 Aug 2001 16:15:37 +0700

Hi!

    First, is it possible to do a Windows-3.1-like windows and menus?  The
problem with borders is that in case of "BorderStyle -- flat" handles are
invisible even without "HiddenHandles".  The accompanying problem with menus
is that there's only "BorderWidth" flag, without an ability to switch
3D-ness off (with Nops too).  Both seems to be caused by lack of
"BorderColor" concept.  Am I missing something?

    Second, is it possible to create an "if-then-else" construct in a
function?  I tried to emulate the behaviour of Win9x's TaskBar, which can be
described as:

    if (Iconic  ||  !Raised)
    {
        Iconify Off
        Raise
        Focus
    }
    else
    {
        Iconify On
    }

(i.e. deiconify if iconified, otherwise raise of not raised, otherwise
iconify).

    But this can't be done with a syntax of "if-then; if-then", since the
following happens:

    AddToFunc "Deiconify-Raise-Focus"
    + "I" Iconify Off
    + "I" Raise
    + "I" Focus
    AddToFunc "Deiconify-or-Raise-or-Iconify"
    + "I" Current (Iconic) Deiconify-Raise-Focus
    + "I" Current (!Raised) Raise
    + "I" Current (Raised, !Iconic) Iconify On

but by the time the last line is reached, the window will *always* be raised
and deiconified.  Is this fixable somehow?

    TIA,
        Dmitry

       ___________________________________________________________________
       Dmitry Yu. Bolkhovityanov  |  Novosibirsk, RUSSIA
       phone (383-2)-39-49-56     |  The Budker Institute of Nuclear Physics
                                  |  Lab. 5-13
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 4 Aug 2001 11:35:27 +0000

> "BorderColor" concept.  Am I missing something?

Windows have "BorderColor" concept. Style * [Hilight]BorderColorset.

Menus have "BorderColor" concept (kind of) using MenuStyle MenuColorset
and ActiveColorset; you may specify sh and hi colors in these colorsets.

I don't remember how should look windows-3.1 windows and menus, so I can't
say whether something is missing to fully or partially emulate the look.
It is hard to believe someone is interesting in microsoft solutions. :)

> (i.e. deiconify if iconified, otherwise raise of not raised, otherwise

We discussed adding shell abilities to fvwmrc two years ago and the
decission was not to do this, since preprocessors and PipeRead can do it.

But if-else construct does not seem too hard to implement. If we do this
we may have if, else, endif commands, so braces are not needed.

	if (Iconic || !Raised)
		Iconify Off
	else
		if (!Iconic)
			Iconify On
		endif
	endif

This only seems complex, in fact it is simple. There is a list of boolean
conditions (one for each level of "if") and the current command is
executed or skipped depending on the last boolean. (if, else, endif)
commands only manipulate this list of booleans (push, not, pop).

> and deiconified.  Is this fixable somehow?

Well, with some hacks everything is possible, including your example. :)

  SetEnv MyCondition 0
  Current (Iconic || !Raised) SetEnv MyCondition 1
  PipeRead `if [ $[MyCondition] == 1]; echo Iconify Off; echo Raise; \
	echo Focus; else echo Iconify On; fi`

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 5 Aug 2001 13:34:02 +0200

> It is hard to believe someone is interesting in microsoft solutions. :)

It simply has 2D borders.  It looks a bit like a wire frame around
the windows.  You can get the same effect if you choose sh/hi
colours on the border appropriately, e.g.

  bg = black
  sh = white
  hi = white

> decission was not to do this, since preprocessors and PipeRead can do it.

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

> >     + "I" Current (Raised, !Iconic) Iconify On

  AddToFunc Deiconify-Raise-Focus
  + I Iconify Off
  + I Raise
  + I Focus
  AddToFunc "Deiconify-or-Raise-or-Iconify"
  + I Current (Raised, !Iconic) { Deiconify-Raise-Focus } Iconify on

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 6 Aug 2001 00:05:51 +0000

>   + 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.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 06 Aug 2001 10:01:51 +0100

> It seems that an idea of 2 commands on the same line is not very good.

I think we can already do conditional code using self modifying
functions:

AddtoFunc true_case
+ I true case commands
+ ...

AddToFunc false_case
+ I false case commands
+ ...

AddToFunc its_true
+ I DestroyFunc conditional_code
+ I AddToFunc conditional_code I true_case

AddToFunc its_false
+ I DestroyFunc conditional_code
+ I AddToFunc conditional_code I false_case

AddToFunc test
+ I its_true
+ I Next (whatever) its_false
+ I conditional_code

I know it's a bit wordy but it's probably possible to use FvwmM4 to wrap
it up into something a bit easier to type.

> Here is my revised proposal that solves all problems described above.

long example snipped...

> proposal. No existing command syntax is changed, which is an advantage.

But then you'll end up doing a "while" command, then a "switch", then a
"break" and I think you've got youself a new language to learn. I think
the SCWM approach is better if this is what you want i.e. put a real
interpreter in there (I'd prefer TCL since I already know it) so that
people don't have to learn a new language and we don't have to design
and test it.

Cheers,
Tim.

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 6 Aug 2001 20:29:38 +0000

> The syntax seems to be unambiguous, but a more formal proof is needed.

I realize that starting with the long form would be a bit revolutionary.
But the short form is a reasonably better alternative to the optional
{ else } argument in all Condition commands.

So the construct looks like this (only the first line is mandatory):

  if Condition1 (param1) Command1
  elsif Condition2 (param2) Command2
  else Command3

The words if-elsif-else are taken from perl. Nested if-else commands are
not allowed in the short form, i.e. more than one command "if", "else" or
"elsif" on the same line is forbidden.

This has a potential for a future extension in two directions:

  1) more Condition commands may be added, and not only the ones dealing
     with windows
  2) command blocks using commands "{" and "}" may be added in the future

What do you think?

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 6 Aug 2001 21:14:06 +0000

> I think we can already do conditional code using self modifying

Ah yes, I forgot, I use self modifying functions in fvwm-themes to
implement a state. But I would prefer functions to be used on purpose,
to define an interface with parameters that can be called from any place.
Using functions to implement state variables and "switch" is not ok. :)

> people don't have to learn a new language and we don't have to design

If you ask me, I would place a real interpreter language, tcl is fine.
But this does not seem possible. This would require an absolutely new
syntax. I am ready to rewrite hundreds of kilobytes of fvwm-themes
configs, but I fear that some others have problems to rewrite their.

I only suggested my version of if-else implementation (which I think is
good to have anyway), because I felt it is a better solution than the
"two alternative commands on the same line", suggested previously.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 6 Aug 2001 20:36:05 +0200

> people don't have to learn a new language and we don't have to design

I agree with Tim.  It might be better to only implement some basic
functionality.  Of course the syntax I proposed is not nice and
flexible, but it is very easy to implement.  Other approaches
require that commands have a return value on which to base the
decision which bracnch to take.

Bye

Dominik ^_^  ^_^

---

From: Tim Phipps <[email-masked]>
Date: Tue, 07 Aug 2001 09:15:36 +0100

> configs, but I fear that some others have problems to rewrite their.

We should think long and hard before putting anything into Fvwm that
would preclude us from adding a real interpreter later. What I mean is
that the only problematic commands that Fvwm has so far is "*", "+",
"function" and "module". If we add "if", "then", "else", "{" and "}"
then we could have much worse problems later. I'm not saying no to this
just be careful about the choice of names. I think { and } should be
avoided because they will be used by a real interpreter. Is it a big
problem to have to put multiline blocks into seperate functions so that
the if-else construct takes only one command (short form)?

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 7 Aug 2001 13:08:00 +0200

> the if-else construct takes only one command (short form)?

Perhaps we should first agree on the feature we want to provide.
Currently, the solutions for even the most simple if-else problems
is PipeRead.  This is a bit uncomfortable because even very simple
things require PipeRead.  I'd be content to have a solution for
these problems:

 1) If a certain window exists, kill it; if not, start it.
 2) If a window is off screen or iconified, make it visible;
    if not, iconify it.
 ...

For more complex problems we would still say: use PipeRead.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Tue, 07 Aug 2001 17:50:43 +0100

[email-masked] wrote:
> I'd be content to have a solution for
> these problems:
> 

AddToFunc temp_true_list
+ I Prev (certain_window) Close
AddToFunc temp_true
+ I DestroyFunc temp
+ I AddToFunc temp I temp_true_list
AddToFunc temp_false_list
+ I Exec certain_program
AddToFunc temp_false
+ I DestroyFunc temp
+ I AddToFunc temp I temp_false_list
AddToFunc toggle
+ I None (certain_window) temp_false
+ I Prev (certain_window) temp_true
+ I temp
Key F1 A A toggle

or by in-lining

AddToFunc toggle
+ I None (certain_window) DestroyFunc temp
+ I None (certain_window) AddToFunc temp I Exec certain_program
+ I Prev (certain_window) DestroyFunc temp
+ I Prev (certain_window) AddToFunc temp I Next (certain_window) Close
+ I temp

>  2) If a window is off screen or iconified, make it visible;

I'm not sure what you mean by make it visible (you could warp screen to
it or move it to the current screen) so I've left it to
make_it_visible_func

AddToFunc make_it_visible_func
+ I Iconify off
+ I Raise
+ I MoveToPage

AddToFunc toggle
+ I DestroyFunc temp
+ I AddToFunc temp I Next ($0) Iconify On
+ I None ($0 CurrentScreen) DestroyFunc temp
+ I None ($0 CurrentScreen) AddToFunc temp I Next ($0)
make_it_visible_func
+ I None ($0 Iconic) DestroyFunc temp
+ I None ($0 Iconic) AddToFunc temp I Next ($0) make_it_visible_func
+ I temp
Key F1 A A toggle certain_window

Cheers,
Tim.