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]
