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 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]
