EWMH and Maximize growonwindowlayer patch
In my config i have:
EwmhBaseStruts 0 0 20 0
Style * EWMHUseStrutHints, EWMHPlacementUseWorkingArea
Mouse 1 4 A Maximize growonwindowlayer grow grow
However when i maximize a window the EWMH area is covered. That should
only happen if ewmhiwa is set on Maximize. Correct me if this is not
true, anyway i attached a patch that applies against cvs.
--
Arnaud Vrac
diff -Nur fvwm-2.5.12-orig/fvwm/move_resize.c fvwm-2.5.12/fvwm/move_resize.c
--- fvwm-2.5.12-orig/fvwm/move_resize.c 2004-09-27 11:33:04.0 +0200
+++ fvwm-2.5.12/fvwm/move_resize.c 2004-10-27 22:22:34.807981792 +0200
@@ -4090,7 +4090,6 @@
int layers[2] = { -1, -1 };
Bool global_flag_parsed = False;
int scr_x, scr_y, scr_w, scr_h;
- int sx, sy, sw, sh;
rectangle new_g;
FvwmWindow *fw = exc->w.fw;
@@ -4180,14 +4179,10 @@
&fscr, FSCREEN_XYPOS, &scr_x, &scr_y, &scr_w, &scr_h);
}
- sx = scr_x;
- sy = scr_y;
- sw = scr_w;
- sh = scr_h;
if (!ignore_working_area)
{
EWMH_GetWorkAreaIntersection(
- fw, &sx, &sy, &sw, &sh, EWMH_MAXIMIZE_MODE(fw));
+ fw, &scr_x, &scr_y, &scr_w, &scr_h,
EWMH_MAXIMIZE_MODE(fw));
}
#if 0
fprintf(stderr, "%s: page=(%d,%d), scr=(%d,%d, %dx%d)\n", __FUNCTION__,
@@ -4195,7 +4190,6 @@
#endif
/* parse first parameter */
- val1_unit = sw;
token = PeekToken(action, &taction);
if (token && StrEquals(token, "grow"))
{
@@ -4221,24 +4235,23 @@
if (GetOnePercentArgument(token, &val1, &val1_unit) == 0)
{
val1 = 100;
- val1_unit = sw;
+ val1_unit = scr_w;
}
else if (val1 < 0)
{
/* handle negative offsets */
- if (val1_unit == sw)
+ if (val1_unit == scr_w)
{
val1 = 100 + val1;
}
else
{
- val1 = sw + val1;
+ val1 = scr_w + val1;
}
}
}
/* parse second parameter */
- val2_unit = sh;
token = PeekToken(taction, NULL);
if (token && StrEquals(token, "grow"))
{
@@ -4264,33 +4257,22 @@
if (GetOnePercentArgument(token, &val2, &val2_unit) == 0)
{
val2 = 100;
- val2_unit = sh;
+ val2_unit = scr_h;
}
else if (val2 < 0)
{
/* handle negative offsets */
- if (val2_unit == sh)
+ if (val2_unit == scr_h)
{
val2 = 100 + val2;
}
else
{
- val2 = sh + val2;
+ val2 = scr_h + val2;
}
}
}
- if (!grow_left && !grow_right)
- {
- scr_x = sx;
- scr_w = sw;
- }
- if (!grow_up && !grow_down)
- {
- scr_y = sy;
- scr_h = sh;
- }
-
#if 0
fprintf(stderr, "%s: page=(%d,%d), scr=(%d,%d, %dx%d)\n", __FUNCTION__,
page_x, page_y, scr_x, scr_y, scr_w, scr_h);
Re: Single click RootMenu, double click WindowList
> It looks like earthlink put my reply in your "suspect email" folder. > I got your first reply. Thanks. If I don't get to look at my suspect email soon enought to put a previously unknown sender in my address book the well meaning sender gets the alert that you got. Sorry about that. > Here is one more attempt to reach you and my original reply: > Thanks for responding and the additional info. > Both those functions "menu" and "windowlist" are meant to grab the > xserver and cause the "hang" that you observed. > But shouldn't the code waiting (or hanging) on a user's menu choice release the wait when a menu choice has been chosen? Maybe my use of the term "hang" along with lack of some more information was misleading. I took your advice and posted a slightly revised and hopefully more accurate explanation to fvwm-workers@fvwm.org that (see below) where I say > > the mouse is moved. For example if you launch an application using > > this it will not come up until the mouse is moved. In other words, fvwm does the right thing according to the RootMenu-or-WindowList function and displays the root menu or windows list depending on whether the user single clicks or double clicks. But when this RootMenu-or-WindowList is asserted for "mouse 1" and then the user launches an application from the root menu, *then* the application does not come up until the mouse is moved. If however, the RootMenu-or-WindowList function is asserted for a title bar button this works fine. And therefore this seems like an inconsistency in the way that fvwm works, ie. RootMenu-or-WindowList works fine at one place but not at another. Bill > There has been some experimental code developed for "tear off menus" which > would be a prerequiste for solving this problem with menus. > > You might try the Module FvwmWindowList instead of using the built in > windowlist. The FvwmGtk might serve as a substitute for the menu. > > I've closed your problem report as "not a problem". Send mail to > fvwm-workers@fvwm.org if you feel this is still a problem. > > > -- > Dan Espen E-mail: [EMAIL PROTECTED] > > > > William Paul Vrotney <[EMAIL PROTECTED]> writes: > > > > This function works fine if bound to almost anything (like a button): > > > > Single click RootMenu, double click WindowList > > DestroyFunc RootMenu-or-WindowList > > AddToFunc RootMenu-or-WindowList > > + I Menu Root-Menu mouse -1p -1p > > + D WindowList mouse -1p -1p NoGeometry > > > > If bound to mouse 1 on the root plane > > > > Mouse 1 R N Menu Root-Menu mouse -1p -1p > > > > it also works fine but, after executing it successfully, fvwm hangs until > > the mouse is moved. For example if you launch an application using this it > > will not come up until the mouse is moved. > > > > Is this a bug? Is there another way of achieving this? It seems like a bug > > because it seems to imply that one can not have a flawless binding to a > > single and double click on the root plane. > -- 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: Single click RootMenu, double click WindowList
William Paul Vrotney <[EMAIL PROTECTED]> writes: > > This function works fine if bound to almost anything (like a button): > > Single click RootMenu, double click WindowList > DestroyFunc RootMenu-or-WindowList > AddToFunc RootMenu-or-WindowList > + I Menu Root-Menu mouse -1p -1p > + D WindowList mouse -1p -1p NoGeometry > > If bound to mouse 1 on the root plane > > Mouse 1 R N Menu Root-Menu mouse -1p -1p > > it also works fine but, after executing it successfully, fvwm hangs until > the mouse is moved. For example if you launch an application using this it > will not come up until the mouse is moved. > > Is this a bug? Is there another way of achieving this? It seems like a bug > because it seems to imply that one can not have a flawless binding to a > single and double click on the root plane. It looks like earthlink put my reply in your "suspect email" folder. Here is one more attempt to reach you and my original reply: Both those functions "menu" and "windowlist" are meant to grab the xserver and cause the "hang" that you observed. There has been some experimental code developed for "tear off menus" which would be a prerequiste for solving this problem with menus. You might try the Module FvwmWindowList instead of using the built in windowlist. The FvwmGtk might serve as a substitute for the menu. I've closed your problem report as "not a problem". Send mail to fvwm-workers@fvwm.org if you feel this is still a problem. -- Dan Espen E-mail: [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]
