Re: xfm and moxfm: Once more unto the breach...
On Fri, Aug 17, 2001 at 03:18:18PM -0400, Bob Woodside wrote: Bob Woodside wrote: Well, this one has led me a merry chase...and I'm still chasing. The problem seems to be mostly confined to focus.c: focus_grab_buttons, which doesn't quite work as intended. I've hacked it up to the point where it does what I think was intended. It seems to work pretty well, except that it breaks MouseFocusClickRaises. There is clearly some additional synchronization needed that I haven't figured out yet. OK, I think I've finally got it right. Dominik, if you have a chance to look over (or try out) the attached patch against last night's CVS, and see if it breaks anything for you, I'd appreciate it. You did so much work rewriting and resynchronizing all that grab stuff, I'd hate to break something you had fixed. I don't thionk I did, but since I wasn't able to follow the development very closely at the time, I don't know for sure what problems you were addressing, or what apps or modes to try out. Anyway, if I don't hear any screams, squawks, or curses, I'll commit this in a day or two (I'd also like to let it run on a couple of machines here for a day or so, just to see.) Actually, I don't understand my code anymore. I think the idea was to call focus_grab_buttons() each time the pointer enters or leaves a window or a window is (un)focused. The function would then make the proper grabs. I don't quite understand the implications of the code you added to MoveFocus(). Won't not calling focus_grab_buttons() screw something up elsewhere? I don't know. However, with your patch, fvwm passes through the for (...) loop much more often then necessary. Could you try to write some condition like the former if (grab_buttons != tmp_win-grabbed_buttons) to prevent fvwm from entering the loop unnecessarily? 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: Notification: incoming/765
On Sat, Aug 18, 2001 at 02:23:59AM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/765 Message summary for PR#765 From: [EMAIL PROTECTED] Subject: xine 0.5.1 with fvwm 2.4.0 Date: Sat, 18 Aug 2001 02:23:57 -0500 0 replies 0 followups Full_Name: Roeland Moors Version: 2.4.0 CVS_Date: OS: linux X_Server: XF86 4.1.0 Submission from: (NULL) (213.224.83.174) When I wan't to play a DVD in xine 0.5.1 the program has this error: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 3 (X_GetWindowAttributes) Resource id in failed request: 0x16c Serial number of failed request: 2406 Current serial number in output stream: 2407 This doens't happen in other window managers. Whatever the window manager does, if the application crashes with an X error its bug in the application. You should really report this to the xine developers. The program probably sets some screwed up window properties and crashes because it can't deal with the way fvwm handles the situation. 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: Xinerama patch for Maximize
On Sat, Aug 18, 2001 at 06:59:56PM +0700, Dmitry Yu. Bolkhovityanov wrote: On Fri, 17 Aug 2001, Dominik Vogt wrote: On Fri, Aug 17, 2001 at 11:46:45AM +0700, Dmitry Yu. Bolkhovityanov wrote: On Thu, 16 Aug 2001, Dominik Vogt wrote: On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: I've added an optional global switch, which means that maximization should be made on a global screen, otherwise it is made on the screen where the center of a window is. grow* are also adjusted (that turned to be the easiest part of the task). I have been thinking about an entirely different approach that uses XGeometry specs: Maximize on [EMAIL PROTECTED] The problem here is to specify the resize unit (screen % or pixels) and where to place the grow option. The same syntax could be used for the Move, Resize and ResizeMove commands. IMHO these two approaches aren't contradictory That's true, but I don't think we would want to develop a second syntax. My idea was to support maximizing/moving/resizing only with the new, X geometry like syntax and phase out the old one. Okay, but there are two issues. First, while the geometry syntax is mathematically okay, it is just too complicated (messy?) for an ordinary user -- like a Perl program for a person which knows only Pascal. I don't want to say that users are silly, but 640pxgrow-5+0p is a bit too much. Well, the ordinary user would not use that syntax at all but stick with Maximize on Maximize on 100 0 Maximize on 0 100 Anyway, as nice as a common syntax for all the resizing/moving commands would be, its not the proper time to do this. BTW, this syntax employs latin letters for three different uses: 1) unit size (p); 2) keywords (grow); 3) times/multiplication operator (x); and all these go without any separators. While this is definitely parseable, it isn't very fancy and is too error-prone. Yes, and my X11 book says: If the [parse]string is not in Host Portable Character Encoding, the result is implementation-dependent. Anyway, can you please post a formal definition of new syntax, like a BNF? No, I can't. I don't even know the correct definition of the standard X11 geometry spec. Sorry for only criticizing, but I yet have to find out some reasonable suggestions. Let's skip my idea for now and update the old syntax. Second, due to compatibility reasons, the old syntax should still be supported. Of course. I only though about not writing new features for the old syntax. 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]
Xinerama support for IconBox style?
Dan, I looked at the icon box code in style.c because I wanted to make it work with changes of the Xinerama state, but the matter is too complex to write a patch in short time for me. What I want to do: 1) Default to using the primary screen for icon box specs (already works for X geometry like specs and is easy to do for the other syntax). 2) Recalculate all icon boxes when the Xinerama layout of the screen changes (switched on or off). The difficult part is (2) because all the calculations are done when the style is defined. The precise spec string is thrown away afterwards. So doing this requires to remove the calculations from style.c and do them somewhere is icons.c. Can you take a look at this, please? I think this could wait until after 2.4.1. 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]
CVS domivogt: * Applied Xinerama patch for Maximize command but changed syntax to
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/19 09:17:27 Modified files: . : ChangeLog NEWS todo-xinerama fvwm : fvwm2.1 move_resize.c placement.c screen.h update.c virtual.c libs : XineramaSupport.c XineramaSupport.h modules/FvwmIconMan: x.c modules/FvwmTaskBar: FvwmTaskBar.c modules/FvwmWinList: FvwmWinList.c Log message: * Applied Xinerama patch for Maximize command but changed syntax to Maximize Screen screen-spec. -- 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]
Xinerama patches complete
With the latest commits, I think Xinerama support is complete. It needs a bit polishing of the documentation, thoug. Probably a separate Xinerama section in the man page is a good idea. Everybody is welcome to help testing the patches, specifically Xinerama placement of modules, new module options and the changes in fvwm's core. All changes are listed in the NEWS file. 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: xfm and moxfm: Once more unto the breach...
Dominik Vogt wrote: However, with your patch, fvwm passes through the for (...) loop much more often then necessary. Could you try to write some condition like the former if (grab_buttons != tmp_win-grabbed_buttons) to prevent fvwm from entering the loop unnecessarily? Yeah, I was thinking of trying to add something like that; I just wanted to get the darn thing working first. The problem with the original test is that it is only valid when you enter for a grab - for an ungrab, the test needs an inverted mask; and formerly we always set tmp_win-grabbed_buttons = grab_buttons on exit, so that after the first pass through for a given window, this test would cause us to exit prematurely without actually doing anything. I'll try to put a test like this in before committing the changes. I don't quite understand the implications of the code you added to MoveFocus(). Won't not calling focus_grab_buttons() screw something up elsewhere? These 2 calls in MoveFocus() to *ungrab* the buttons happen prematurely for the case of MouseFocusClickRaises windows (we're still waiting for a possible click). They never caused a problem before because focus_grab_buttons() didn't actually do the ungrab (because of the test mentioned above). That's why MouseFocusClickRaises broke when I made focus_grab_buttons() actually do the ungrab. I've been running with these changes on 2 machines for a couple of days now, and haven't noticed anything untoward happening. I've tried to exercise all the combinations of focus policy options (we support so many!), so it's probably about time to see if other people find problems with them. Cheers, Bob -- 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]
Focus Policy and Window List Reordering
In looking through all the focus code recently I was reminded of something that has puzzled me for some time. Does anyone know a really good reason why the window list is reordered two different ways on a focus change, depending on whether the newly-focused window is ClickToFocus or MouseFocus? (If the newly-focused window is MouseFocus, that window is plucked out of the list and inserted at the top, so the list reflects the order of most- to least-recently focused windows; if the newly-focused window is ClickToFocus, the list is effectivel rotated so that the target window is at the top, but the relative order remains the same.) This goes way back to the Version 1 days, when the focus policies were an all-or-nothing proposition (i.e., not Style options), and ClickToFocus mode didn't reorder the window list on a focus change. I don't remember what the reason for this was, but I question whether it's really useful to try to preserve this behavior. Since you can have a mixed-mode configuration (i.e., some mousey-focus windows and some clicky), this just seems to engender confusion about the meaning of the window list order. In fact, it really isn't meaningful if you have different focus policies in effect for different windows. Any ideas? Cheers, Bob -- 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: xfm and moxfm: Once more unto the breach...
On Sun, Aug 19, 2001 at 01:36:24PM -0400, Bob Woodside wrote: Dominik Vogt wrote: However, with your patch, fvwm passes through the for (...) loop much more often then necessary. Could you try to write some condition like the former if (grab_buttons != tmp_win-grabbed_buttons) to prevent fvwm from entering the loop unnecessarily? Yeah, I was thinking of trying to add something like that; I just wanted to get the darn thing working first. The problem with the original test is that it is only valid when you enter for a grab - for an ungrab, the test needs an inverted mask; and formerly we always set tmp_win-grabbed_buttons = grab_buttons on exit, so that after the first pass through for a given window, this test would cause us to exit prematurely without actually doing anything. I noticed some problems with MouseFocusClickRaises in the past months (i.e. a click didn't raise the window sometimes) but could never find a way to make it happen on command. Maybe your patch fixes this after all. I don't quite understand the implications of the code you added to MoveFocus(). Won't not calling focus_grab_buttons() screw something up elsewhere? These 2 calls in MoveFocus() to *ungrab* the buttons happen prematurely for the case of MouseFocusClickRaises windows (we're still waiting for a possible click). They never caused a problem before because focus_grab_buttons() didn't actually do the ungrab (because of the test mentioned above). That's why MouseFocusClickRaises broke when I made focus_grab_buttons() actually do the ungrab. I've been running with these changes on 2 machines for a couple of days now, and haven't noticed anything untoward happening. I've tried to exercise all the combinations of focus policy options (we support so many!), so it's probably about time to see if other people find problems with them. I think we can risk this. Your patch changes something under very peculiar circumstances, so even if it broke something, probably only a few people would ever notice. 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: Xinerama support for IconBox style?
Dominik Vogt [EMAIL PROTECTED] writes: Dan, I looked at the icon box code in style.c because I wanted to make it work with changes of the Xinerama state, but the matter is too complex to write a patch in short time for me. What I want to do: 1) Default to using the primary screen for icon box specs (already works for X geometry like specs and is easy to do for the other syntax). 2) Recalculate all icon boxes when the Xinerama layout of the screen changes (switched on or off). The difficult part is (2) because all the calculations are done when the style is defined. The precise spec string is thrown away afterwards. So doing this requires to remove the calculations from style.c and do them somewhere is icons.c. Can you take a look at this, please? I think this could wait until after 2.4.1. It doesn't look too hard, it just needs to save the signs separately (for -0) and apply screen dimensions later. Is there a way to test screen size changes without Xinerama working? I did a CVS update, now I have this: Undefined first referenced symbol in file XineramaSupportGetNumberedScrRect placement.o -- 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: Xinerama support for IconBox style?
Oops, ignore that comment about XineramaSupportGetNumberedScrRect. -- 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]
CVS dane: * fvwm/icons.c (AutoPlaceIcon): Apply screen dimensions as icon is
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: dane01/08/19 18:31:40 Modified files: . : ChangeLog fvwm : fvwm.h icons.c style.c Log message: * fvwm/icons.c (AutoPlaceIcon): Apply screen dimensions as icon is placed. * fvwm/style.c (CMD_Style): Don't apply screen dimensions to iconbox until later when the window is actually placed. * fvwm/fvwm.h (icon_boxes_struct): Save sign for later screen position calculation. -- 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: Focus Policy and Window List Reordering
Michael Han wrote: On Sun, Aug 19, 2001 at 10:48:38PM +0200, Dominik Vogt wrote: On Sun, Aug 19, 2001 at 03:40:26PM -0400, Bob Woodside wrote: Does anyone know a really good reason why the window list is reordered two different ways on a focus change, depending on whether the newly-focused window is ClickToFocus or MouseFocus? The distinction seems useless to me. No reason why two concurrent approaches should be maintained. Perhaps its simply a Mwm compatibility issue? I don't know where this comes from either, but I've always vaguely wished that ClickToFocus would use last-focus order and wondered why it didn't. It always seemed like a bug, but not one I could nail down enough to look into. I think, as Dominik suggested, that the idea of the two modes was suggested by mwm, although it wasn't implemented quite the way mwm does it; and, in any case, it's not consistent anymore, since you can have a mix of mousey and clicky windows. I think using the last-focus order universally would make a good deal more sense. Maybe we should solicit some votes...? I vote for the universal last-focus order. Mike, I take it your vote would make 2 for that approach. I suspect, from his previous comment, that Dominik would make a third, but I'll let him speak for himself. Cheers, Bob -- 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]
