Subject: Re: releasing 2.4.0

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 2 Jun 2001 16:52:25 +0000

On 20 May 2001 15:55:09 +0000, Mikhael Goikhman wrote:
> 
> Sorry, I should object because there are at least 3 problems:
> 
> 1) Locking on Wait in I functions, I am still waiting for Dominik's answer.
>    If nothing else I will undo that problematic commit.
> 2) IMHO "import -frame" problem should be fixed, it worked previously and
>    it is inaceptable that existing window screenshot functions are broken.
> 3) There are several problems in function parsing, see my other thread.
>    I will try to fix them all soon.

I consider all these fixed.

On 21 May 2001, Dominik Vogt wrote:
> 
> I think the current focus problems and the Wait command have to be
> fixed first.

Are there any focus problems remaining to be fixed?

There is a small current Wait problem: in the Wait state if you delete a
window and then switch desk and return to the original desk, you see the
frame of previously deleted window, moving such unshaded frame "deletes"
it again until a new switch of desks. This only happens in functions:

  AddToFunc TestFunction I Wait "unexisting window"
  TestFunction

It is ok by me if this problem is not fixed. Ctrl-Alt-Esc fixes this well.

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: Tomas Ogren <[email-masked]>
Date: Sun, 3 Jun 2001 05:21:36 +0200

> I consider all these fixed.

There's still (cvs as of now) problems with focus in Nautilus.. I've
been busy+++ lately, but I will have spare time to spend now.. It
doesn't get any focus..

There is also a problem when an app sets it's (GNOME) WM layer before
the window is shown. It then sets a property on the window which level
it's supposed to be on, but it doesn't get read by fvwm it seems...
I see the code in gnome.c and style.c to read it, but I don't know which
order stuff is happening/supposed to happen, so it's a bit hard...

Attached is a test program written in gtk/xlib...
create some windows on layer 4 and then start the program.. one of the
windows is supposed to land on layer 3 (below the others).. then you can
raise/lower it with the up/down buttons..

If given any argument to the program, it will show (map) the window
before trying to set the layer which makes it end up on the correct
layer directly (almost.. you can see it starting infront of the windows,
then jumping back)

/Tomas
-- 
Tomas Ögren, [email-masked], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 3 Jun 2001 12:10:29 +0000

> been busy+++ lately, but I will have spare time to spend now.. It

I though Dominik fixed this... Did not the Nautilus author plan to fix
this in Nautilus too without using rare ICCCM features?

> layer directly (almost.. you can see it starting infront of the windows,

1) There is a typo in the program, so it can't be compiled without a fix,
the variable "level" should be replaced with "layer" globally.

2) To compile it: gcc -o winhints `gtk-config --cflags --libs` winhints.c

3) I can't reproduce any problem with this program, it works just well
with or without arguments. Of course it is not consistent because it
first requests to place itself to "layer-1" and then to "layer".
But if you patch the program to replace "layer-1" with "layer" it will
become consistent.

A note, it is intended that a window is lowered in FVWM when it changes a
layer, say from 5 to 4, and raised - when changes a layer from 3 to 4.

% gtk-config --version
1.2.10

Am I missing something?

Regards,
Mikhael.

---

From: Tomas Ogren <[email-masked]>
Date: Sun, 3 Jun 2001 15:48:32 +0200

On 03 June, 2001 - Mikhael Goikhman sent me these 1.9K bytes:

> I though Dominik fixed this...

He tried..

> Did not the Nautilus author plan to fix this in Nautilus too without
> using rare ICCCM features?
> 

Sorry.. I was quite tired when I sent this and I made some last second
changes without compiling..

> layer, say from 5 to 4, and raised - when changes a layer from 3 to 4.

Ok, I made some more changes to make it consistent now. The point is: It
doesn't matter what layer I request if I do it _before_ mapping the
window. Fvwm will still put it on the default layer. If you want to put
it behind everything (like the nautilus background thingie), you don't
want it to first cover the entire screen then pop back below everything.

There seems to be code to read that stuff when the window is mapped, but
I suppose it's called in the wrong order or something.

How to reproduce stuff:
1) compile with $CC -o winhints `gtk-config --cflags --libs` winhints.c
2) make a window cover most of the screen so there will be overlapping
3) run winhints .. if your normal layer is 4 (which is default), then the
  larger of the windows from 'winhints' should be below the window from 2) 
  but that doesn't happen.
4) Click on "Same" which will set the layer to layer 2 again but by
   sending an event this time, now it pops down to layer 2.
5) Clicking on up/down will raise/lower the window as expected.

If you give any arguments to winhints, it will first map the window,
then set the layer.. so it will appear at the default layer, then pop
back to layer 2.

> Am I missing something?

You forgot to remind me to be less sleepy when sending in stuff :)

/Tomas

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 3 Jun 2001 14:12:08 +0000

On 03 Jun 2001 15:48:32 +0200, Tomas Ogren wrote:
> window. Fvwm will still put it on the default layer.

As I already said I can't reproduce this. With no arguments the window
is initialy placed on the layer 2, with arguments it is iniatily placed
on layer 4 and then immediately switches to layer 2, as expected.

In case I am not clear, the button "Same" never does anything for me
if I don't press other buttons.

I can reproduce what you say only if I have this (and this is expected):

  Style winhints Layer 4

BTW, this style option Layer once set can't be disabled without Restart...

Regards,
Mikhael.

---

From: Tomas Ogren <[email-masked]>
Date: Sun, 3 Jun 2001 16:31:57 +0200

> on layer 4 and then immediately switches to layer 2, as expected.
[..]
> I can reproduce what you say only if I have this (and this is expected):

Gah. I'm such a moron!
Guess what 'Style "*"           Layer 4' does? *smacks himself*

Ok, it wasn't a bug in fvwm, it was a bug in me :) Thanks Mikhael..

The focus stuff in nautilus still remains though.. (even with only
built-in settings :)

/Tomas - kicks himself a couple of times

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 3 Jun 2001 18:04:43 +0200

> I consider all these fixed.

Yes.

> Are there any focus problems remaining to be fixed?

The one that Paul (PDS) reported with in conjunction with
FvwmAuto.  Of course I still hope he'll provide some more details.

> It is ok by me if this problem is not fixed. Ctrl-Alt-Esc fixes this well.

I can fix this, it's not hard.

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: Dominik Vogt <[email-masked]>
Date: Sun, 3 Jun 2001 18:14:36 +0200

> > I though Dominik fixed this...

Well, it's hard to fix without any feedback ;-)  I fixed the
problem with the "Globally Active" focus model.  I can't test
Nautilus since I don't have it, though.

> then set the layer.. so it will appear at the default layer, then pop

Fvwm does not honour GNOME hints, only GNOME client messages.  No
need to test code that is never compiled.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 3 Jun 2001 18:46:19 +0200

Is there anything we will do about the FvwmIconMan pipe problem?
It crashes quite often and I have no idea how to fix this or even
why it happens at all.

Bye

Dominik ^_^  ^_^

---

From: Tomas Ogren <[email-masked]>
Date: Sun, 3 Jun 2001 20:02:30 +0200

[..]
> Well, it's hard to fix without any feedback ;-)

I know.. I've been quite busy (2-3 week old mailboxes etc..), but that's
over now...

> I fixed the problem with the "Globally Active" focus model.  I can't
> test Nautilus since I don't have it, though.

There's no change now, it still won't get focus.. but if I do 'Style "*"
Lenience', it works just fine.. I'll dig into these problems with the
almighty printf() when I get home...

/Tomas

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 3 Jun 2001 18:39:34 +0000

> BTW, this style option Layer once set can't be disabled without Restart...

This is not fully correct, the error message on Style Layer with no
argument was misleading. Fixed.

Regards,
Mikhael.

---

From: "Paul D. Smith" <[email-masked]>
Date: 03 Jun 2001 21:33:48 -0400

%% Dominik Vogt <[email-masked]> writes:

  dv> The one that Paul (PDS) reported with in conjunction with
  dv> FvwmAuto.  Of course I still hope he'll provide some more details.

I posted this on May 1:

  OK, I think I have more details.  If I have mouse-2 bound to my
  Iconify-and-Compact function:

    AddToFunc Iconify-and-Compact
    +       "C" Iconify
    +       "C" All (CurrentDesk Iconic) RecaptureWindow

    Mouse 2         I       A       Function Iconify-and-Compact

  then I see this behavior.  It's very easy to reproduce; create an icon
  box like "IconBox 2 -20 -1 -1", for example (I don't use any of the
  module icon managers, just the builtin IconBox).  Now place an xterm
  over the icon box.  Then iconify the xterm.  Then click mouse-2 on the
  xterm's icon in such a way that the window will appear underneath your
  mouse cursor when it de-iconifies, even if you don't move it (the
  mouse).

  If I change mouse-2 to run just "Iconify", I can't make it happen
  anymore.

  So, maybe this behavior is no longer supported?  It used to work until
  fairly recently; someone on the workers list suggested it (although I
  checked and it's not listed in the FAQ).

I never heard anything so I assumed it was expected behavior.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>    HASMAT--HA Software Methods & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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: Mon, 4 Jun 2001 16:06:23 +0200

>   dv> FvwmAuto.  Of course I still hope he'll provide some more details.
...
> I never heard anything so I assumed it was expected behavior.

Um, now that you mention it, I never saw my reply to your mail on
the list.  Hm.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 22 Jun 2001 23:05:13 +0000

> I never heard anything so I assumed it was expected behavior.

It is not an FvwmAuto problem, it's RecaptureWindow.

I can reproduce what Paul describes without FvwmAuto with FvwmAnimate.
Or without FvwmAnimate, but when the original icon is already unfocused.
(It is possible to get unfocussed icon under cursor if you enter it during
All RecaptureWindow.)

But I don't think this problem is critical for 2.4.0.
I may help to fix it in 2.4.1.

Restoring focus may be done explicitely by adding to Iconify-and-Compact:

  + C Focus NoWarp   # or even: WindowId $w (!Iconic) Focus NoWarp

Does anyone think this problem is critical to stop the 2.4.0 release?

It also seems that a problem with not focussing of Nautilus is not
critical either, it may be fixed by Style Lenience.

We should move on. I think we agreed that 2.3.33 is the latest release.
I want to change the next version from 2.3.34 to 2.4.0. Any objections?

I also think that if we want to move, the code should be fully frozen now.
Any non obvious change (even a possible fix) should be voted, anyone is
able to veto if he thinks a problem is not critical to start to fix it.

Regards,
Mikhael.

---

From: "Paul D. Smith" <[email-masked]>
Date: 22 Jun 2001 22:10:32 -0400

%% Mikhael Goikhman <[email-masked]> writes:

  mg> I can reproduce what Paul describes without FvwmAuto with
  mg> FvwmAnimate.  Or without FvwmAnimate, but when the original icon
  mg> is already unfocused.  (It is possible to get unfocussed icon
  mg> under cursor if you enter it during All RecaptureWindow.)

  mg> Does anyone think this problem is critical to stop the 2.4.0 release?

Not me.

  mg> Restoring focus may be done explicitely by adding to Iconify-and-Compact:

  mg>   + C Focus NoWarp   # or even: WindowId $w (!Iconic) Focus NoWarp

I'll try these; although I've had this compact feature turned off ever
since it broke and I haven't really missed it much... so that tells you
how important I think it is.

Personally I vote we leave 2.3.34 out for 1 week, and only fix the most
critical of bugs (and/or build/compile issues?)... and if there aren't
any at the end of 1 week we recut it as 2.4.0.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 23 Jun 2001 12:06:27 +0200

>   mg> Does anyone think this problem is critical to stop the 2.4.0 release?

No, not if it's not something general with focus/grabs and the
like.  Hm, I thought the IconifyAndCompact version was in the FAQ,
but obviously it isn't.
 
> how important I think it is.

Icons suck anyway ;-)

> any at the end of 1 week we recut it as 2.4.0.

Agreed.  I wish I could do something about the dying FvwmIconMan,
but if I can't even find the problem description this may not
delay 2.4 any further.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sat, 23 Jun 2001 09:02:11 -0400

> like.  Hm, I thought the IconifyAndCompact version was in the FAQ,

DeiconifyAndRearrange is in the man page.

> >   mg> Restoring focus may be done explicitely by adding to Iconify-and-Comp
> >   mg> act:

Hey, they make sense to me.  (I'm not using this window now, I think
I'll make it small.)

I don't think the problem is worth delaying 2.4.

-- 
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]