Re: Going to a vacation
On Thu, Aug 30, 2001 at 10:04:16AM +, Mikhael Goikhman wrote: > I am going to a vacation for 3 weeks, flying out of the home. > I will have a pretty limited internet access. Have a nice vacation then (and don't worry about internet access, fvwm won't crash and burn in the next few weeks ;-) ). > BTW, I am still running with a patch implementing command statuses > and new Otherwise command. So far there were no conflicts. Let's discuss that topic again when 2.4.1 is out and your vacation is over. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at 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]
Going to a vacation
I am going to a vacation for 3 weeks, flying out of the home. I will have a pretty limited internet access. BTW, I am still running with a patch implementing command statuses and new Otherwise command. So far there were no conflicts. Keep a good work. Regards, Mikhael. -- Visit the official FVWM web page at 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: --prefix include dir problem
On 29 Aug 2001 14:20:13 +0200, Nils Lohner wrote: > > There's a slight includ edir problem in 2.4.0 I think. > > /sup/build/fvwm-2.4.0 > ./configure --prefix=/sup > > The compilation does not contain a -I/sup/include which it would ned ot > compile properly with xpm support. This seems useful, but the questions are should -I/sup/include be added to the end or to the beginning? Should autoconf do the work for us? Are there other packages handling prefix this way, so I can take a look? Regards, Mikhael. -- Visit the official FVWM web page at 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: Q about fvwm relations with RedHat
On 30 Aug 2001 13:13:24 +0700, Dmitry Yu. Bolkhovityanov wrote: > > I've noticed that RedHat, both 7.2beta (Roswell (UFO?:)) and > RawHide still contain 2.2.5. So, they probably should be pushed to move > to 2.4. > > The question is: are there any existing contacts between fvwm team > and RedHat? If not, I can mail [EMAIL PROTECTED] (listed as last person > who touched the .spec file), or maybe somebody else, having more > experience in this area, is willing to do it? Yes, please do it if you think they should be pushed. I don't know. You may mention that all our rpms are built by "make rpm-dist release=1". Please also mention that if they decide to use another namespace, i.e. build rpm non-compatible with ours, they should package fvwm-themes too, otherwise we should suggest users to replace their fvwm rpm with ours. Regards, Mikhael. -- Visit the official FVWM web page at 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]
Q about fvwm relations with RedHat
Hi! I've noticed that RedHat, both 7.2beta (Roswell (UFO?:)) and RawHide still contain 2.2.5. So, they probably should be pushed to move to 2.4. The question is: are there any existing contacts between fvwm team and RedHat? If not, I can mail [EMAIL PROTECTED] (listed as last person who touched the .spec file), or maybe somebody else, having more experience in this area, is willing to do it? _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at 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: new MouseFocusRaises problem
Dominik Vogt wrote: > > On Mon, Aug 27, 2001 at 05:39:22PM -0400, Bob Woodside wrote: > > > > Do you know of any more situations that were mishandled? > > Any call of f_g_b with is_focused == True is a potential candidate > for another bug. There are many calls like this all over the place Yes. It's scary. I thought I had covered all the cases, but I obviously hadn't. > > > I'm beginning to think that f_g_b is really misplaced, and shouldn't > > be > > so tightly bound (in our thinking, at least) to focus issues. > > > > > > > Could you perhaps describe again what the problem of xfm was? > > > > xfm, or any program that uses XtTranslations to detect a double-click > > (like the test program I sent) has the following problem. If the window > > manager has a grab on an ancestor of the app window at the wrong time, > > then between the ButtonPress and the ButtonRelease the app sees a > > LeaveNotify with mode=grab and an EnterNotify with mode=ungrab (the > > opposite of the sequence we see on the parent window), telling the app > > window that another window grabbed the pointer and then gave it back. > > Actually, Xtlib sees this, which seems to confuse its translation logic, > > and it never reports anything but a single click to the app. > > Then I don't understand why your patch tries to release the grab > *later* than before. Doesn't what you say mean that double > clicking such windows can never work with MouseFocusRaises? No. With my original patch to f_g_b, the double click worked fine with MouseFocusClickRaises (and with all the other modes); it was the raising on the click that no longer worked. In the 2 spots I then changed in MoveFocus the grab was being released prematurely for a MouseFocusClickRaises window (on a focus change, but before a click happened): therefore we didn't catch the click and didn't raise the window. This didn't happen before my patch because those calls to f_g_b didn't ungrab - in fact they didn't do anything. (Actually, sticking some printfs in f_g_b, I could never see an ungrab happening, which I think was the original source of the double click problem.) With the changes to MoveFocus, both double clicking and raising worked fine. Unfortunately, in the icon manager case you mentioned, where another window is raised above the MouseFocusClickRaises window without a focus change, the former top window doesn't get regrabbed, so we won't catch a click and raise it. This is why I said I'm beginning to think that button grabs are too tightly bound to focus changing, when they're equally important to raising/lowering (at least in some cases) - and the two things don't always go together. Cheers, Bob -- Visit the official FVWM web page at 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]
