Subject: Xinareama patch: apply or not apply?

From: Dominik Vogt <[email-masked]>
Date: Sat, 10 Feb 2001 16:47:33 +0100

I wonder if we should apply that Xinerama patch before 2.4.
People will ask for that feature again and again in the near
future, so it would be nice to have before the hypothetical 3.0
release.  What do you think?

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: Dan Espen <[email-masked]>
Date: Sat, 10 Feb 2001 13:59:58 -0500

> release.  What do you think?

I think we have too many things in the to do list for 2.4.

I think we should run the purify tests as they stand.
If Purify doesn't detect a problem we should release 2.4.

What do you think?

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: Sat, 10 Feb 2001 22:04:02 +0100

> I think we have too many things in the to do list for 2.4.

Most of these are tests, plus a few problems that we never really
looked after (e.g. the Winch signal problem and the disappearing
icons).  I could live with any of these problems in the 2.4
release.  But I do think the stuff listed under testing has to be
done somehow:

 33) Test the GNOME patches.

     These patsches seem trivial.  I'd skip this test if noone
     wants to do it.

 34) Update and run the purify script again.

     Originally I wrote these tests to find out all the parsing
     problems fvwm had back two years ago.  Therefore, the test is
     of limited usefulness today.  I'd rather have a kind of
     automated test suite that tests features, not parsing.
     Anyway, what is missing in the tests right now?

 35) Test the strokes patch.

     Not very important, but at least I'd like to have some
     feedback.

 92) Test new session management code.

     I believe there are still some problems hidden regarding
     restarts.

 94) Test colour set support in modules and fvwm.

     May not be this important.  Fvwm-theme already tests most of
     this stuff.

 95) Test new panel implementation in FvwmButtons.

     This is nearly untested.  Only few people are using this, and
     most options are probably not used at all.

105) Test binding code.

     The most important test in my eyes.  I'll start testing
     today.

106) Test window position code.

     Bob's modifications of the code have been around for nearly
     two years.  Thus, the test may be skipped.
 
Skip: 33 (?), 94 (?), 106
Do (in order of importance): 105, 92, 95, 35 (?)
Finally, run the purify tests.

I will do 105 myself.  A volunteer is needed for 92 - I won't
release 2.4 before the SM code has been tested thoroughly - the
functionality is simply too important.  I could also do 95, but
since I wrote the code I'd prefer if someone else volunteered.
The test is not this big.

> If Purify doesn't detect a problem we should release 2.4.

Right now we know there are still some unfixed problems.  The last
purify/insure++ sessions we made still showed some problems that I
could not fix.

> What do you think?

I really don't know.  The patch applies quite cleanly to current
CVS (except a few -Wall -Werror problems), but of course I'd have
to proof read it.  But first I need to upgrade my SuSE 6.4 to 7.0
or 7.1 so that I can compile with Xinerama support.  An option
would be to provide the Xinerama patch in a later 2.4.x release.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sat, 10 Feb 2001 17:17:59 -0500

> release.  But I do think the stuff listed under testing has to be

I don't think the winch problem is real, and I've never seen the
disappearing icons, so I agree, lets skip them.

>      These patsches seem trivial.  I'd skip this test if noone

Agree.

>      Anyway, what is missing in the tests right now?

I've tried to turn this whole thing into a combination
parsing test and a regression test.  I did a read thru of the man
page and tried to make sure everything described in the man page
is tested.  In general, the tests exercise every option
but only test for correct behavior in a limited way.

There are comments in the purify.fvwm2rc file that I made when I
felt that something important wasn't tested adequately.  Why don't
you take a look.
I'm so tired of looking at those tests that its hard to think
objectively about them.

I don't know what other OSS projects do to decide when they have
an official release vs. a beta.  For other things I work on,
passing the regression test is the final barrier.

(And regression tests are always inadequate.)

>      Not very important, but at least I'd like to have some

I don't use it but I've seen enough on the workers list to get
the idea that it works.

>      I believe there are still some problems hidden regarding

I don't use it so I rely on problem reports to know whether it
works.  My impression is that the majority of X applications are
incapable of restoring their state anyway, so I don't think its
important.

>      May not be this important.  Fvwm-theme already tests most of

Agreed.

>      most options are probably not used at all.

A good reason to not worry about testing it.

>      The most important test in my eyes.  I'll start testing

Key and Mouse binding?

I thought they were rock solid, but if you want more tests
thats OK with me.

>      two years.  Thus, the test may be skipped.

This I do use, and it seems to work.

> functionality is simply too important.

See my reasons why I don't think its important, but if someone
volunteers,  I'm all for it.  If no one volunteers,  I think thats
an indication of how important it is.

> I could also do 95, but

Are there any panels in FvwmThemes?  Does someone else have an
FvwmButtons setup configured for panels, that we could add to our
test suite?

> purify/insure++ sessions we made still showed some problems that I

I thought you got them all.  I know you got everything that could
lead to a crash or incorrect behavior.

I can run these tests again, but I've been waiting.  The next time
I run them I'd like to have a goal of having them pass and then
releasing 2.4 when they do pass.

> would be to provide the Xinerama patch in a later 2.4.x release.

I don't  have an opinion about this  patch.  I don't  have room  on my
desk for a second monitor.  Two side by side 21 inch monitors would be
interesting, but they might give me a sun tan.

I have been thinking we go too long between official releases.

I think it might help if we get an official release out, and then
apply 1 major change and a few minor changes.  Then freeze major
changes again until we can release the major change in another
official release.

---

From: Lorenz Minder <[email-masked]>
Date: Sun, 11 Feb 2001 10:57:54 +0100

> release.  What do you think?

Well, you probably didn't mean me with `you', but I'll comment anyway. I'd
apply it, with the following changes

*	Apply code changes with `patch -DHAS_XINERAMA'

*	configure.in: disable xinerama by default, rather than enabling it;
	tag it as experimental.

Rationale
=========

*	This way, it surely won't bite anybody who didn't ask for it. And it
	will probably help people who were asked to be bitten :)

*	Makes sure, the patch doesn't get out of sync.

*	If you want to wait for the next official release for inclusion,
	people had to wait a loong time, judging from the release cycle
	length fvwm has.

Regards,
--Lorenz

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 11 Feb 2001 07:28:26 -0600

> > > release.  What do you think?

If this is important for many, I don't see it a problem to include it just
like we included multibyte support. --disable-xinerama may be a default.

>      Not very important, but at least I'd like to have some

% locate themes/default/settings/stroke/enabled

Seems like it tests all related things. We use it for a year or more.

>      I believe there are still some problems hidden regarding

If you don't mind I would call problems which happen on a regular Restart
as "Restart problems" and problems which happen when using xsm or
gnome-session (usually on start-up) as "SM problems".

I am not aware of "Restart problems" in the current code.

There are for sure "SM problems", which are related to "save session",
"save and quit session" and "restore session". Anyway SM support is called
experimental and I don't see them fixed without some enthusiast familar
with XSMP, working on it.
 
>      May not be this important.  Fvwm-theme already tests most of

Let at least us workers be correct on names. :) There is no such thing as
Fvwm-theme. Dan in other message mentions FvwmThemes, there is no such
thing either.

There is a module FvwmTheme and a distribution FVWM Themes (fvwm-themes).

>      most options are probably not used at all.

Agree. We use a new panel implementation in many themes, but it is
probably far from being fully tested.

> Skip: 33 (?), 94 (?), 106

Yes.

> Finally, run the purify tests.

I would not release 2.4 without 117 - window borders flicker a lot
on any opaque operation, this looks unprofessional. I see no any
flickering in 2.2. I simply have no time to invistigate it for now.

> functionality is simply too important.

Please see my comments about 92 above. I would test 92 if we agree on what
to test.

> I could also do 95, but since I wrote the code I'd prefer if someone
> else volunteered. The test is not this big.

Ok, I will test 95. Maybe on weekend.

Now, there are really many small problems and bugs (about 10), which I
don't want to report not to postpone 2.4.

However, there are 2 recent problems.

1) As I already reported in other message PopupDelay 0 is broken after
PopdownDelay changes in 2.3.28. It was ok in 2.3.27.

2) Animation of FvwmButtons panels (at least when the panel is FvwmPager)
was recently broken. It was ok in 2.3.22 IIRC. I will send screenshots
when I have a bit more time. You may run fvwm-themes, choose olicha or
migo themes and expand/collapse panels several times. The animation is not
as smooth as it was and it offen stops at the middle causing a bad visual
effect (a panel border with half expanded, half transparent contents).

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Sun, 11 Feb 2001 09:11:11 -0500

> effect (a panel border with half expanded, half transparent contents).

The FvwmButtons config that I posted yesterday produces the problem.
It doesn't do it every time.  I've attached a window dump.

It looks like its only seeing the first step in animation.  I have
5 desks in the popup, and I used 5 steps in the animation.  It looks
like 1/5 of the popup is being used.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 11 Feb 2001 13:52:57 +0100

On Sun, Feb 11, 2001 at 10:57:54AM +0100, Lorenz Minder wrote:
> Well, you probably didn't mean me with `you', but I'll comment anyway.

With 'you' I address everybody on the list.

> I'd apply it, with the following changes
> 

I'm already keeping a patched version in parallel on my disk.

> 	people had to wait a loong time, judging from the release cycle

Yes, waiting for 3.0 may be way too long.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 11 Feb 2001 13:46:19 +0100

> incapable of restoring their state anyway, so I don't think its

The reason why I think the test is important is that the SM code
has the power to screw up things.  We already had a lot of
problems whith windows being restored to an incorrect position or
state.

> A good reason to not worry about testing it.

What I wanted to say was that only few people made the effort to
convert their configuration file - yet.

> I thought they were rock solid, but if you want more tests

A while ago I rewrote large parts of the binding code.  Problems
are still showing up once in a while.

> an indication of how important it is.

Or perhaps it's an indication of how enthusiatic people are about
testing.  That's one of the reasons why I did little work of fvwm
in the last two weeks.  It's so boring.

Yes.

> interesting, but they might give me a sun tan.

The risk may be too big.  It would be tested only for a very short
time and I'd even have to set up Xinerama first.

> I have been thinking we go too long between official releases.

Yes.  All these bugs delayed it tremendously.

> changes again until we can release the major change in another

I think you are right.  If we really go for 3.0 after 2.4, we will
have to spend more work on 2.4.x that we spent on 2.2.x anyway.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 11 Feb 2001 16:35:07 +0100

> Ok, I will test 95. Maybe on weekend.

Thanks!

> don't want to report not to postpone 2.4.

The small problems are not delaying the release.  Please do
report them.  That does not mean that we will fix them.

> PopdownDelay changes in 2.3.28. It was ok in 2.3.27.

Fixed.

> effect (a panel border with half expanded, half transparent contents).

Fixed.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 11 Feb 2001 15:49:19 +0100

> gnome-session (usually on start-up) as "SM problems".

I meant exactly what I was talking about: Restart when using xsm.

> with XSMP, working on it.

Okay, that let's document that this functionality is experimental.

> There is a module FvwmTheme and a distribution FVWM Themes (fvwm-themes).

Gee.

> I would not release 2.4 without 171 - window borders flicker a lot
> on any opaque operation, this looks unprofessional.

Agreed.  I was talking only about the tests.

> Please see my comments about 92 above. I would test 92 if we agree on what

See my other posting.  The only thing I am really concerned about
is that restarting fvwm under xsm does not screw up things.

> PopdownDelay changes in 2.3.28. It was ok in 2.3.27.

Um, did you? I never saw that message.

> effect (a panel border with half expanded, half transparent contents).

I can only imagine that some other process is hogging CPU.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 11 Feb 2001 16:32:53 +0100

> like 1/5 of the popup is being used.

Well, I never saw the config you talk about, but I found a bug I
introduced into FvwmPager's ConfigureNotify handling (fixed).  For
me it works normally again.  Another bug in FvwmButtons could lead
to orphaned panels on the desktop (fixed also).

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sun, 11 Feb 2001 11:06:12 -0500

Dominik Vogt <[email-masked]> writes:
> Well, I never saw the config you talk about

Seems like someone is holding on to my mails with attachments.
The file is short but wide.  I'll backslash it and include as text.

There are 2 problems, using "Panel...position Root 46 -100p"
the panel gets positioned correctly, but the "46" seems wrong.

After using it for a while, FvwmIconMan starts repainting like crazy.
This happened twice, once I saw this on the console:

[FVWM][PositiveWrite]: <<ERROR>> Failed to read descriptor:
- data available=N
- terminate signal=N

Heres the config:

################## FvwmButtons button-bar ################################
KillModule FvwmButtons
DestroyModuleConfig FvwmButtons: *
*FvwmButtons: Geometry 520x100-1-1
*FvwmButtons: Back bisque3
*FvwmButtons: (Frame 2, Padding 2 2, \
  Container(Rows 2 Columns 9 Frame 1 Padding 10 0))
# Show 5 more desks in a popup panel:
# Unfortunately, a popup shows the desks 1 to 5, then 0
*FvwmButtons: (4x2, Frame 2, Swallow "FvwmIconMan" "Module FvwmIconMan")
*FvwmButtons: (2x2, Frame 0, Container(Rows 2 Columns 2 Frame 0))
*FvwmButtons: (Frame 2, Swallow(UseOld,NoHints,Respawn) \
  "xbiff" `Exec exec xbiff -bg bisque3`)
*FvwmButtons: (Frame 3, Swallow(UseOld,NoHints,Respawn) \
  "xclock" `Exec exec xclock -bg bisque3 -fg black \
  -hd black -hl black -padding 0 -update 1`)
*FvwmButtons: (2x1, Frame 2, Swallow(UseOld,NoHints,Respawn) \
  "xload" `Exec exec xload -bg bisque3 -fg black -update 5 -nolabel`)
*FvwmButtons: (End)
Style FvwmButtons BorderWidth 4, HandleWidth 4
Style FvwmPagerSubPanel BorderWidth 4, HandleWidth 4
# The 8 pixels in -108 are to account for the frames:
*FvwmButtons: (1x2, Panel(up, indicator, delay 0, steps 5, \
  position Root 46 -108p) FvwmPagerSubPanel \
  "Module FvwmPager FvwmPagerSubPanel 1 5")
*FvwmButtons: (2x2, Frame 2, Swallow(UseOld) \
  "Inline" "Module FvwmPager Inline 0 0")
*FvwmButtons: (End)

DestroyModuleConfig Inline: *
*Inline: Rows 1
*Inline: Columns 1
DestroyModuleConfig FvwmPagerSubPanel: *
*FvwmPagerSubPanel: Rows 5
*FvwmPagerSubPanel: Columns 1

# Use this command to start it:
FvwmButtons

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 17 Feb 2001 23:03:04 +0100

> don't want to report not to postpone 2.4.

I don't mind if you report problems before 2.4.  Give me a chance
to judge which problems are important and which are not.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 17 Feb 2001 18:05:08 -0600

> to judge which problems are important and which are not.

It may take some time to reproduce them and make good reports.

BTW, one of those was incorrect pager sizes, which you successfully fixed.

Another one was also "fixed", I though that ClickToFocus windows should
never get focus without mouse click, i.e. on start-up, but it is a known
documented feature. I think this is annoying, but it's ok, since this can
be turned off by Style "*" GrabFocusOff after all ClickToFocus styles.

Regards,
Mikhael.