Re: releasing 2.4.0
On Fri, Jun 22, 2001 at 10:10:32PM -0400, Paul D. Smith wrote: %% Mikhael Goikhman [EMAIL PROTECTED] 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. 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. 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. Icons suck anyway ;-) 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. 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 ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: releasing 2.4.0
Dominik Vogt [EMAIL PROTECTED] writes: On Fri, Jun 22, 2001 at 10:10:32PM -0400, Paul D. Smith wrote: %% Mikhael Goikhman [EMAIL PROTECTED] 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. 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. DeiconifyAndRearrange is in the man page. mg Restoring focus may be done explicitely by adding to Iconify-and-Comp mg act: 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. Icons suck anyway ;-) 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 PROTECTED] 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: releasing 2.4.0
On 03 Jun 2001 21:33:48 -0400, Paul D. Smith wrote: %% Dominik Vogt [EMAIL PROTECTED] 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. 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. -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: releasing 2.4.0
%% Mikhael Goikhman [EMAIL PROTECTED] 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. -- --- Paul D. Smith [EMAIL PROTECTED]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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: releasing 2.4.0
On Sun, Jun 03, 2001 at 09:33:48PM -0400, Paul D. Smith wrote: %% Dominik Vogt [EMAIL PROTECTED] 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: ... 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 ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: releasing 2.4.0 [some gnome stuff]
On 03 Jun 2001 15:48:32 +0200, Tomas Ogren wrote: 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. 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. -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: releasing 2.4.0 [some gnome stuff]
On 03 June, 2001 - Mikhael Goikhman sent me these 0.7K bytes:
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.
[..]
I can reproduce what you say only if I have this (and this is expected):
Style winhints Layer 4
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
--
Tomas Ögren, [EMAIL PROTECTED], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: releasing 2.4.0 [some gnome stuff]
On Sun, Jun 03, 2001 at 03:48:32PM +0200, Tomas Ogren wrote: On 03 June, 2001 - Mikhael Goikhman sent me these 1.9K bytes: On 03 Jun 2001 05:21:36 +0200, Tomas Ogren wrote: 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.. I though Dominik fixed this... He tried.. 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. 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) 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. Sorry.. I was quite tired when I sent this and I made some last second changes without compiling.. 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. 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. Fvwm does not honour GNOME hints, only GNOME client messages. No need to test code that is never compiled. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: releasing 2.4.0
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 ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: releasing 2.4.0 [some gnome stuff]
On 03 June, 2001 - Dominik Vogt sent me these 3.6K bytes:
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..
[..]
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
--
Tomas Ögren, [EMAIL PROTECTED], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: releasing 2.4.0
On 20 May 2001 15:55:09 +, 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: releasing 2.4.0
Mikhael Goikhman [EMAIL PROTECTED] writes: I think we should release the last candidate beta 2.3.32 now. And set the exact date of 2.4.0 release to be sure we don't postpone it any more. Maybe May 10 or 15? I don't have critical problems which may stop the new stable release. There is a report of Olivier about MouseFocus, which I can reproduce. If possible it could be carefully fixed before 2.4.0. I myself get PositiveWrite failed timeout in some theme switches. I will see if I can narrow the problem. If no, this may be fixed in 2.4.1+ or/and I will do a workaround for this in fvwm-themes. If we compare to other software, FVWM has a good quality, size, speed and functionality. I can make time to build 2.4 if no one objects. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: releasing 2.4.0
Mikhael Goikhman [EMAIL PROTECTED] writes: Sorry, I should object because there are at least 3 problems: ... I am optimistic even if this means some more days. :) OK. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
