Subject: Re: Maximize, but not to top of screen?

From: Tim Phipps <[email-masked]>
Date: Tue, 18 Jan 2000 14:32:03 +0000

Sorry about not quoting, I've lost the thread.

Isn't the Pick command designed for exactly this problem. e.g.

AddToFunc MaxAndMove I Pick MaxAndMoveIt $w

AddToFunc MaxAndMoveIt I Maximize 80 0
+                      I WindowId $0 (!Maximized) Move -0 0

Cheers,
Tim.

--
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: Dominik Vogt <[email-masked]>
Date: Wed, 19 Jan 2000 10:49:11 +0100

> +                      I WindowId $0 (!Maximized) Move -0 0

I'd like to add a 'This' command.  It would be similar to
'Current' but refers to the window being processed with a
complex function.  'This' would just be a dummy so you can
add a condition mask to it.

Since it's such a small change I want to add it before 2.4;
provided I get at least two votes for and none against it.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [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: Neil Bird <[email-masked]>
Date: Wed, 19 Jan 2000 10:02:40 +0000

> add a condition mask to it.

  I'll vote for it.

  And while we're on the subject: I'm /still/ trying to get my maximise
actually working. This is my current variant (which doesn't work, BTW):

AddToFunc do_Down-Maximise  \
   "I" Maximise $1 $2
+  "I" WindowId $w (Maximized)  Move w0 -0

AddToFunc Down-Maximise  \
   "I" Pick Function do_Down-Maximise $1 $2

  Currently, the args. aren't passed through, so I get a Max. 100 100.

-- 
=====================- http://www.racaldefence.com/ -===================
  Neil Bird                      |
                                 |            This .signature is
    mailto:[email-masked]  |          certified Y2K compliant
--
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: Jos <[email-masked]>
Date: Wed, 19 Jan 2000 11:10:28 +0100

Well, provided my vote counts..

Jos.

---

From: Neil Bird <[email-masked]>
Date: Wed, 19 Jan 2000 10:06:47 +0000

> actually working. This is my current variant (which doesn't work, BTW):

  D'Oh! Try using $0 for the first arg ....

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 19 Jan 2000 13:48:58 +0100

> provided I get at least two votes for and none against it.

Of course we don't need a new command when 'Pick' already
does the same.  I've added a condition mask to the 'Pick'
command.

Bye

Dominik ^_^

---

From: Tim Phipps <[email-masked]>
Date: Wed, 19 Jan 2000 10:07:03 +0000

> provided I get at least two votes for and none against it.
I'll vote for it on condition that we can agree on a better name.  I
think "current" and "this" are going to be confusing.  The name of the
"current" command was originally "if" but changed because there was a
plan for an "if" that would work on fvwm internal state.  I think
"current" is ambiguous and could be renamed at the same time as renaming
"this".

I haven't got a suggestion for "this" but "current" could be better
named as something like "if_focussed_window" or "FocusWindow" or
"ActiveWindow".

Are there any problems with parsing command names with underscores in
them? Or parsing command names that are subsets of other commands?
(Focus vs. FocusWindow)

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 20 Jan 2000 12:30:40 +0100

> named as something like "if_focussed_window" or "FocusWindow" or

Well, I've already added the functionality to the 'Pick' command
since it was already doing this, but without handling contitions
a la '(iconic)'.  The name 'Pick' doesn't fit very well either.
I considered creating an alias for a moment but didn't find a
proper name yet.

BTW, I find the 'Current' command especially useless.  Why isn't
the 'focus' state simply part of the condition?  Isn't
'Current ...' equivalent to a hypothetical 'Next (focused) ...'?
And then, why should there be explicit 'next', 'none', 'all',
'prev', ... commands?  This could easily be integrated in the
condition mask of 'TestWindow' (or whatever the name may be,
'If' doesn't fit though):

  Next ...                 -->  TestWindow (focuslist +1)
  Prev (iconic)            -->  TestWindow (focuslist -1, iconic)
  All (!shaded)            -->  TestWindow (all, !shaded)
  None (xterm) Exec xterm  -->  TestWindow (!any, xterm) Exec xterm

Potentially I there are four things such a command can do
if the condition is met or not met:

 a) do nothing
 b) proceed and set tmp_win to the first matching window
 c) proceed and set tmp_win to all matching windows
 d) proceed and set tmp_win to NULL

This could refelct in two different commands:

 - 'If' would do either (a) or (d)
 - 'SelectWindow' would do (a), (b) or (c)

These two commands would make all other contitionals superfluous.

> them?

Not as long as we only use lower case letters.  Other than
readability of course.  I don't think we should start mixing
the upper/lower-case philosophy with underscores.

> Or parsing command names that are subsets of other commands?
> (Focus vs. FocusWindow)

No.

Bye

Dominik ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 20 Jan 2000 14:50:01 +0200

> These two commands would make all other contitionals superfluous.

Maybe 'For' instead of 'SelectWindow'?
Also maybe with a postfix, i.e. 'IfWindow', 'ForWindow';
and how about not to mix (b) and (c), i.e. additional 'ForEach[Window]'?

Regards,
Mikhael.

---

From: Neil Bird <[email-masked]>
Date: Thu, 20 Jan 2000 12:57:04 +0000

> and how about not to mix (b) and (c), i.e. additional 'ForEach[Window]'?

  Or keep 'For' and allow an optional 'All' initial parameter?

---

From: Tim Phipps <[email-masked]>
Date: Mon, 24 Jan 2000 13:06:49 +0000

> I considered creating an alias for a moment but didn't find a

I think Pick is a very good name when invoked in the root context, you
get a SELECT cursor and have to pick a window.  Now that the Pick
command can take conditions it would be nice if the cursor changed to
indicate if the window under the cursor satisfies the conditions or not.
(might have to change SELECT to SELECT_YES and SELECT_NO)
> BTW, I find the 'Current' command especially useless.  Why isn't

I use the Current command to do window specific things. Instead of
WarpToWindow I use

NewFunc(my_cursorwarp)	I Current (TaskBar) WarpToWindow 55p 10p
+			I Current (!TaskBar) WarpToWindow 35p 50p
+			I Current (Eterm) WarpToWindow 97 90
+			I Current (rxvt) WarpToWindow 98 90
+			I Current (xterm) WarpToWindow 3 90
+			I Current (qsw-pc*) WarptoWindow 50 50

Which warps the cursor to the-most-likely-to-be-useful place.  Yo can
also use it to make title buttons window specific.

> 'Current ...' equivalent to a hypothetical 'Next (focused) ...'?

Yes, except it doesn't need to go all the way around the windowlist and
it turns on the CirculateHit and CirculateHitIcon flags.

Cheers,
Tim.