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]