Re: Xinerama patch for Maximize
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 -- yours allows more flexibility, while the logic im my patch is required in case when no parameters are specified (i.e. just Maximize) or the old syntax is used (incl. e.g. grow). But, of course, with some efforts old syntax parser can be changed to generate an appropriate on geometry spec. There's a pitfall in geometry syntax for Maximize: what would mean Maximize [EMAIL PROTECTED] if applied to a window on different page/desk? Would it be current screen where the *pointer* is, or the screen, where that *window* is (more precisely, where it *would* be when Focus applied)? And what to do in case when current page doesn't start on a page boundary? _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- 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 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. -- yours allows more flexibility, while the logic im my patch is required in case when no parameters are specified (i.e. just Maximize) or the old syntax is used (incl. e.g. grow). But, of course, with some efforts old syntax parser can be changed to generate an appropriate on geometry spec. Basically, the parser would have to do the same as the non geometry based dimension/position parsers we have. For each bit of the geometry spec it should optionally accept a suffix to the number, e.g. 100px100p+0m+0m, and possibly a list of key words. This way it would finally possible to have something like this: Maximize 640pxgrow-5+0p (maximized window is placed 5% of the screen width off the right border and ant the top of the screen with a width of 640 pixels and whatever height fits). Of course this requires a pre parsing pass over the geometry string that filters out all the fancy suffices and key words before calling ...ParseGeometry. int FancyParseGeometry( char *geom, int *ret_x, int *ret_y, int *ret_w, int *ret_h, char *xy_suffix_array, int *xy_units_array, char **xy_keywords, int *ret_x_unit, int *ret_y_unit, char *wh_suffix_array, int *wh_units_array, char **wy_keywords, int *ret_w_unit, int *ret_h_unit, int *ret_w_keyword, int *ret_h_keyword); Pretty complex I guess, but very useful. There's a pitfall in geometry syntax for Maximize: what would mean Maximize [EMAIL PROTECTED] if applied to a window on different page/desk? Would it be current screen where the *pointer* is, or the screen, where that *window* is (more precisely, where it *would* be when Focus applied)? And what to do in case when current page doesn't start on a page boundary? As usual, @c would address the screen that contains the pointer, possibly projected to other pages or desks. To force the window into the current viewport, the MoveToDesk/Page/Screen commands can be used. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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/762
On Tue, Aug 14, 2001 at 02:53:48PM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/762 Message summary for PR#762 From: [EMAIL PROTECTED] Subject: Pager has drawing problem Date: Tue, 14 Aug 2001 14:53:47 -0500 0 replies 0 followups Full_Name: Bob Bell Version: 2.4.0 CVS_Date: OS: Tru64 UNIX V5.1 X_Server: Tru64's X server Submission from: (NULL) (206.152.163.42) My 3x3 pager has some sort of flood fill problem. It appears to be tied to the color of an active pixel on page 1 1. The best way to describe this is to show you: http://www.css.tayloru.edu/~bbell/pager1.png http://www.css.tayloru.edu/~bbell/pager2.png Note that window with the focus is green, and others are grey/white. I can't access these pictures. If they are of reasonable size, please mail them to me directly. Also, I will most likely need your fvwm config file as well as a description what you have to do to make that happen. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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...
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.) Cheers, Bob grabfix.diff.gz Description: Binary data
