Re: CVS domivogt: * Applied Xinerama patch for Maximize command but changed syntax to
On Mon, Aug 20, 2001 at 04:40:52PM +0700, Dmitry Yu. Bolkhovityanov wrote: > On Sun, 19 Aug 2001, FVWM CVS wrote: > > > Log message: > > * Applied Xinerama patch for Maximize command but changed syntax to > > "Maximize Screen ". > > fvwm.org seems to be offline, so the question: would it be > possible to maximize on the same screen where the window currently is? > I.e., if the window is completely on screen 2, and I'm issuing "Next > (WINNAME) Maximize" from FvwmCommand on screen 3 (i.e. "c"==3), the window > gets geometry [EMAIL PROTECTED] Isn't that the default behaviour of your patch without "global"? I only changed the syntax of the additional key words: Maximize global ... becomes Maximize screen g ... Im addition you can specify Maximize screen p ... Maximize screen c ... Maximize screen 0 ... Maximize screen 1 ... ... 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 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]
Re: CVS domivogt: * Applied Xinerama patch for Maximize command but changed syntax to
On Sun, 19 Aug 2001, FVWM CVS wrote: > Log message: > * Applied Xinerama patch for Maximize command but changed syntax to > "Maximize Screen ". fvwm.org seems to be offline, so the question: would it be possible to maximize on the same screen where the window currently is? I.e., if the window is completely on screen 2, and I'm issuing "Next (WINNAME) Maximize" from FvwmCommand on screen 3 (i.e. "c"==3), the window gets geometry [EMAIL PROTECTED] _ 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]
CVS domivogt: * Applied Xinerama patch for Maximize command but changed syntax to
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/19 09:17:27 Modified files: . : ChangeLog NEWS todo-xinerama fvwm : fvwm2.1 move_resize.c placement.c screen.h update.c virtual.c libs : XineramaSupport.c XineramaSupport.h modules/FvwmIconMan: x.c modules/FvwmTaskBar: FvwmTaskBar.c modules/FvwmWinList: FvwmWinList.c Log message: * Applied Xinerama patch for Maximize command but changed syntax to "Maximize Screen ". -- 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]
Re: Xinerama patch for "Maximize"
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 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]
Re: Xinerama patch for "Maximize"
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]
Re: Xinerama patch for "Maximize"
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 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]
Re: Xinerama patch for "Maximize"
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 -- 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 [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? _ 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]
Re: Xinerama patch for "Maximize"
On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: > 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). 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. > 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. I see. Consider it fixed :) > 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. 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. > 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 ;-) 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 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 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]
Xinerama patch for "Maximize"
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 PROTECTED] The Budker Institute of Nuclear Physics maximize.diff.gz Description: Binary data
