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]

Reply via email to