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]
Re: Xinerama patch for Maximize
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. 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. Anyway, can you please post a formal definition of new syntax, like a BNF? Sorry for only criticizing, but I yet have to find out some reasonable suggestions. Second, due to compatibility reasons, the old syntax should still be supported. Otherwise most users of =2.4 (especially those with 1 monitor) will live with old versions, and in some cases even fvwmNN_convert wouldn't be able to help them (think about AnotherLevel and alikes). _ 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 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: Xinerama patch for Maximize
On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: Hi! This patch touches solely the move_resize.c. I've tried to modify fvwm2.1, but my roff skills seem to be below what required to keep Maximize description in the same style (the latter seems a bit wrong BTW -- too many spaces). 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. There are some problems with maximizing windows that aren't on the current page when the page itself doesn't start on a page boundary, but that effect existed before anyway. I see. Consider it fixed :) And there is a comment maximize on visible page after IsRectangleOnThisPage() check, which doesn't seem to be correct -- somehow it happens that windows are maximized on visible page even if they are by some part (not entirely) on it. The comment should better read: maximize on the page where the center of the window is, but if any part of the window is on the current page, maximize it there. BTW, Dominik, was it done intentionally that in Xinerama emulation mode the vertical separator doesn't separate, but in fact overlaps two left pixels of the second pseudo-screen? The result seems a bit confusing ;-) You would have to ask Olivier. He wrote that stuff. Anyway, I don't really care about this. It is only meant as visible feedback for testing and debugging. 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]
