Subject: Xinerama patch for "Maximize"

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Wed, 15 Aug 2001 20:30:20 +0700

Hi!

	This patch touches solely the move_resize.c.  I've tried to modify
fvwm2.1, but my roff skills seem to be below what required to keep
"Maximize" description in the same style (the latter seems a bit wrong BTW
-- too many spaces).

	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).

	There are some problems with maximizing windows that aren't on the
current page when the page itself doesn't start on a page boundary, but
that effect existed before anyway.  

	And there is a comment "maximize on visible page" after
IsRectangleOnThisPage() check, which doesn't seem to be correct -- somehow
it happens that windows are maximized on visible page even if they are by
some part (not entirely) on it. 

BTW, Dominik, was it done intentionally that in Xinerama emulation mode
     the vertical separator doesn't separate, but in fact overlaps two
     left pixels of the second pseudo-screen?  The result seems a bit
     confusing ;-)

	_________________________________________
	  Dmitry Yu. Bolkhovityanov
	  [email-masked]
	  The Budker Institute of Nuclear Physics

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 16 Aug 2001 11:14:54 +0200

> (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 100x100+10-0@c

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.

> that effect existed before anyway.  

I see.  Consider it fixed :)

> some part (not entirely) on it. 

The comment should better read:

  maximize on the page where the center of the window is, but if
  any part of the window is on the current page, maximize it
  there.

>      left pixels of the second pseudo-screen?  The result seems a bit

You would have to ask Olivier.  He wrote that stuff.  Anyway, I
don't really care about this.  It is only meant as visible
feedback for testing and debugging.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
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-masked].
To report problems, send mail to [email-masked]

---

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Fri, 17 Aug 2001 11:46:45 +0700

> could be used for the Move, Resize and ResizeMove commands.

	IMHO these two approaches aren't contradictory -- 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.

	There's a pitfall in geometry syntax for Maximize: what would
mean "Maximize ...@c" 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?

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 17 Aug 2001 10:16:14 +0200

On Fri, Aug 17, 2001 at 11:46:45AM +0700, Dmitry Yu. Bolkhovityanov wrote:
> 	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

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.

> applied)?  And what to do in case when current page doesn't start on a 

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 ^_^  ^_^

---

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Sat, 18 Aug 2001 18:59:56 +0700

> only with the new, X geometry like syntax and phase out the old

	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).

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 19 Aug 2001 14:11:09 +0200

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

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

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

Let's skip my idea for now and update the old syntax.

> be supported.

Of course.  I only though about not writing new features for the
old syntax.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]