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]
