Subject: New non-window conditional command On

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 2 Jan 2003 09:55:22 +0000

I have implemented a new conditional command that is unlike all others
do not work on windows. Currently only several conditions are available,
but more useful conditions may be added.

  On (Version 2.6.*) Echo Ok
  Cond (NoMatch) Echo Not ok

As usual, these lines should be placed in a function for Cond to work.

InitFunction and RestartFunction now may be obsoleted, everything
could be done in StartFunction and the user chooses the order:

  AddToFunc StartFunction
  + I Module FvwmBanner
  + I On (Init) Exec xterm
  + I Module FvwmButtons
  + I On (Restart) Exec play dzin.wav
  + I Module FvwmPager

Thinking about this, if I add SessionInit and SessionRestart conditions we
may remove even more special functions in the long run. Having totally 2
functions StartFunction and ExitFunction instead of the current 8.

Should I mark InitFunction and RestartFunction as obsoleted in the man
page and/or the code, or we need to support them forever?

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

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 2 Jan 2003 11:12:06 +0100

> page and/or the code, or we need to support them forever?

The problem is that since 2003-01-01 fvwm/fvwm is feature freezed!
Yes, we do not get a warning message from Dominik ...

Dominik, are you still our maintainer for 2.5.x/2.6.x ?  I strongly
hope this. Note that we should fix a date for module feature freeze
and also a date for string freeze (for translation; this involves
fvwmrc discussion).

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 2 Jan 2003 11:02:17 +0000

> Yes, we do not get a warning message from Dominik ...

I noticed you worked very hard to fulfil this date.

I would not make dates holy, fvwm should be ready for the freeze first.
If we cut it on some date, it may be a set of random features not working
well together. Additionally, I see no problems if someone has plans (and
I wrote that I have my todo list, just didn't have a time to post it on
December) and asks for some additional time.

Since we did not really discuss the freeze date. I suggest to do it now.
Let it be January, 15 for the core? At least we have a time to think what
is missing.

> and also a date for string freeze (for translation; this involves

I hope too.

There is also perllib, that I will decide when will be its freeze date,
I don't think it will be before March/April. It should be finalized as
API for 2.6.x and future versions and it is not complete yet.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 3 Jan 2003 05:45:19 +0100

> Let it be January, 15 for the core? At least we have a time to think what

I am not against this date. I will simply prefer a message from
Dominik. I think that date are important if not we will never stop to
add new features. As usual, freeze does not mean that no new feature at
all should be added (the procedure is no vote against it and 2 votes
for it). But we should spent our main fvwm time to test and fix fvwm
and to do some special work (e.g., config, better web page, new format
for our doc).

Olivier

---

From: Dan Espen <[email-masked]>
Date: Mon, 06 Jan 2003 14:58:09 -0500

> and also a date for string freeze (for translation; this involves

I don't know what you expect Dominik to do.
I don't think he wants to be "maintainer", and he shouldn't have to be.
Anyone that puts code into fvwm should follow thru to the final release.

I think its clear that we have to stop adding things to 2.5.x
and turn it into a stable release.

For that, we need to make sure we have a complete set of features,
get the documentation up to date and create test cases.

I think I've seen  todo lists from all  the major players.   Just keep
publishing them.  (And try to make them get  smaller over time.)  Make
sure that test cases are part of your todo lists.

Hey, I know I'm not doing much development.  Maybe that qualfies
me to give direction.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Marcus Lundblad <[email-masked]>
Date: Mon, 6 Jan 2003 22:50:24 +0100 (CET)

> sure that test cases are part of your todo lists.

My plan is to remove the unnessesay
"Closable","Maximizable","Iconifiable" and "AllowMaximizeFixedSize"
since they correspond to "!" variants of
"Unclosable","Unmaximizable","Uniconifiable" and
"DisallowMaximizeFixedSize"

Does it make sence to let the non-default styles be the only ones, and
have the opposite styles as the default?

I guess this should be done for all styles. But I guess this will be done
for 3.0, since it breaks backwards compatablility.

Also, I might add a "DisallowIconifyFixedSize" to complement
"DisallowMaximize" fixed size. But I guess this would also call for a
"DisallowShadeFizedSize".

Or maybe this better wait until after 2.6.

//Marcus

---

From: Cameron Simpson <[email-masked]>
Date: Tue, 7 Jan 2003 12:18:08 +1100

On 22:50 06 Jan 2003, Marcus Lundblad <[email-masked]> wrote:
| My plan is to remove the unnessesay
| "Closable","Maximizable","Iconifiable" and "AllowMaximizeFixedSize"
| since they correspond to "!" variants of
| "Unclosable","Unmaximizable","Uniconifiable" and
| "DisallowMaximizeFixedSize"
| 
| Does it make sence to let the non-default styles be the only ones, and
| have the opposite styles as the default?
| 
| I guess this should be done for all styles. But I guess this will be done
| for 3.0, since it breaks backwards compatablility.
| 
| Also, I might add a "DisallowIconifyFixedSize" to complement
| "DisallowMaximize" fixed size. But I guess this would also call for a
| "DisallowShadeFizedSize".

Could I cast a vote for NOT doing it this way?

You should keep "Closable" and discard "Unclosable", using "!Closable"
and so forth. All these attributes should be positive statements.

Likewise there shouldn't be any "Disallow*" options, just Allow*
and !Allow*.

This issue is entirely separate from what the defaults are.
-- 
Cameron Simpson, DoD#743        [email-masked]    http://www.zip.com.au/~cs/

If people were meant to run around naked, they'd have been born that way.
	- Rico the Masher, [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: Dominik Vogt <[email-masked]>
Date: Tue, 7 Jan 2003 06:16:13 +0100

> Dominik, are you still our maintainer for 2.5.x/2.6.x ?

No.  I *may* fix a few bugs, but other than that I do not plan to
spend much time on fvwm anymore.

> I strongly

Well, I see nothing that should stop someone else from setting the
dates.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 7 Jan 2003 06:51:41 +0100

> This issue is entirely separate from what the defaults are.

I agree 100%.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 7 Jan 2003 08:57:04 +0000

> > This issue is entirely separate from what the defaults are.

The weak side of this is that a user has no any indication of what is the
normal window behaviour. Other than this I have no problem to name options
regardless of their default.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 7 Jan 2003 10:26:03 +0100

> regardless of their default.

The default is written out in the man page.  It is always the last
style of all the alternatives.  For example,

  !AllowMaximize / Allow Maximize

means that AllowMaximize is the default.

Bye

Dominik ^_^  ^_^

---

From: Cameron Simpson <[email-masked]>
Date: Tue, 7 Jan 2003 22:29:26 +1100

On 10:26 07 Jan 2003, Dominik Vogt <[email-masked]> wrote:
| On Tue, Jan 07, 2003 at 08:57:04AM +0000, Mikhael Goikhman wrote:
| > On 07 Jan 2003 06:51:41 +0100, Dominik Vogt wrote:
| > > 
| > > On Tue, Jan 07, 2003 at 12:18:08PM +1100, Cameron Simpson wrote:
| > > > On 22:50 06 Jan 2003, Marcus Lundblad <[email-masked]> wrote:
| > > > | My plan is to remove the unnessesay
| > > > | "Closable","Maximizable","Iconifiable" and "AllowMaximizeFixedSize"
| > > > | since they correspond to "!" variants of
| > > > | "Unclosable","Unmaximizable","Uniconifiable" and
| > > > | "DisallowMaximizeFixedSize"
[...]
| > > > Could I cast a vote for NOT doing it this way?
| > > > You should keep "Closable" and discard "Unclosable", using "!Closable"
| > > > and so forth. All these attributes should be positive statements.
| > > > Likewise there shouldn't be any "Disallow*" options, just Allow*
| > > > and !Allow*.
| > > > 
| > > > This issue is entirely separate from what the defaults are.
| > > 
| > > I agree 100%.
| > 
| > The weak side of this is that a user has no any indication of what is the
| > normal window behaviour. Other than this I have no problem to name options
| > regardless of their default.
| 
| The default is written out in the man page.  It is always the last
| style of all the alternatives.  For example,
| 
|   !AllowMaximize / Allow Maximize
| 
| means that AllowMaximize is the default.

I have to say I've never realised this. Could someone (Dan?) put a paragraph break
after the words:

	options is a comma separated list containing one or more of the
	following keywords.  Each group of style names is separated by
	slashes ('/').  The last style in  these  groups  is the  
	default."

I know I for one missed this. My fault of course.

Cheers,

A good newspaper is never good enough, but a lousy newspaper is a joy
forever.	- Garrison Keillor
--
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: Tue, 7 Jan 2003 12:53:09 +0100

> I know I for one missed this. My fault of course.

Maybe you missed it because it was deleted at some time.  I added
it again only recently.

Bye

Dominik ^_^  ^_^